VMware SASE supporta l'interconnessione di più Edge hub o cluster hub per aumentare l'intervallo degli Edge spoke che possono comunicare tra loro. Questa funzionalità consente la comunicazione tra gli Edge spoke connessi a un Edge hub oppure a un cluster hub e gli Edge spoke connessi a un altro Edge hub o cluster hub, utilizzando più connessioni di overlay e underlay.
Quando un Edge spoke tenta di connettersi a un cluster hub, uno dei membri del cluster hub viene selezionato come hub per l'Edge spoke. Se questo hub diventa inattivo, un altro membro dello stesso cluster hub viene selezionato automaticamente come hub per l'Edge spoke, senza alcuna configurazione dell'utente. I membri del cluster hub sono connessi tra loro tramite underlay (BGP) e possono scambiare le route e i dati utilizzando questa connessione underlay. Gli Edge spoke connessi a membri diversi dello stesso cluster hub possono quindi comunicare tra loro utilizzando questa connessione underlay. Questa soluzione offre una resilienza migliore.
- La funzionalità Hub o Cluster Interconnect (Hub or Cluster Interconnect) deve essere attivata.
- È necessario selezionare la casella di controllo Da filiale a sito hub (VPN permanente) (Branch to Hub Site (Permanent VPN)). I due nodi hub interconnessi devono essere configurati come hub l'uno per l'altro, come illustrato nella tabella seguente.
Profilo | Designazione hub |
---|---|
hub_profile1 | hub2 |
hub_profile2 | hub1 e hub3 |
hub_profile3 | hub2 |
Quando la funzionalità Hub o Cluster Interconnect (Hub or Cluster Interconnect) è attivata, i tunnel vengono creati da un cluster a un altro cluster che includa almeno un peer. In base alla condizione, due membri di un cluster possono creare tunnel verso gli stessi membri in un altro cluster. Nel caso di una singola interconnessione tra hub e cluster hub, tutti i membri del cluster creano tunnel verso tale hub singolo. Gli Edge spoke finali connessi a questi cluster hub possono quindi comunicare tra loro tramite questi due cluster hub e gli hop del protocollo di routing di VMware SD-WAN intermedi.
Le route interne al cluster vengono annunciate con una community estesa BGP specifica in cui gli ultimi quattro byte dell'ID cluster vengono incorporati nella community estesa. Ad esempio, se l'ID cluster è fee2f589-eab6-4738-88f2-8af84b1a3d9c
, la parte 4b1a3d9c
viene invertita e utilizzata per derivare la community del cluster come 9c3d1a4b00000003
. In base a questo tag di community, le route interne al cluster vengono filtrate in base al controller. In questo modo, si evita di riflettere le route ridondanti di più membri del cluster.
- Connessione overlay tra S1 e C1.
- Connessione overlay tra S2 e C2.
- Connessione overlay tra C1 e C2.
- Connessione underlay all'interno di C1.
- Connessione underlay all'interno di C2.
In questo modo, i cluster hub possono scambiare route tra loro, offrendo ai pacchetti un modo per passare tra gli Edge spoke connessi a cluster hub diversi.
- L'opzione dinamica da filiale a filiale è supportata tra spoke connessi a due cluster diversi o allo stesso cluster.
- L'isolamento del profilo nel profilo spoke è supportato.
- Il backhaul Internet tramite cluster è supportato.
Limitazioni:
- Hub o Cluster Interconnect tramite gateway non è supportato.
- Lo scambio di route tra i membri del cluster hub tramite OSPF non è supportato.
- Il routing asimmetrico può verificarsi quando due cluster sono interconnessi. Enhanced Firewall Services o il firewall stateful non devono essere attivati perché possono bloccare il traffico a causa del routing asimmetrico.
- Quando tutti i tunnel di overlay tra due membri del cluster diventano inattivi, è prevista l'eliminazione del traffico è prevista finché non creano un tunnel con altri membri nel cluster peer.
- Se sono presenti più router LAN/WAN che eseguono BGP con cluster, la casella di controllo Origine attendibile (Trusted Source) deve essere selezionata e il valore di Inoltro percorso inverso (Reverse Path Forwarding) deve essere Non abilitato (Not enabled) nelle interfacce dell'Edge cluster che connettono i router BGP. Per ulteriori informazioni, vedere Configurazione delle Impostazioni interfaccia per gli Edge.
- Senza la funzionalità Hub o Cluster Interconnect (Hub or Cluster Interconnect), un profilo hub del cluster non può avere un altro cluster o hub configurato come hub.
Configurazione di Hub o Cluster Interconnect
Prerequisiti
- Assicurarsi di aggiornare Orchestrator, i gateway e gli hub o i cluster hub alla versione 5.4.0.0 o successiva.
- Il servizio VPN cloud (Cloud VPN) deve essere attivato per il profilo del cluster associato ai cluster o agli hub Edge.
- La casella di controllo VPN da filiale a filiale (di transito e dinamica) (Branch to Branch VPN (Transit & Dynamic)) non deve essere selezionata nei profili hub di interconnessione, come illustrato di seguito.
La configurazione di Designazione hub (Hubs Designation) nei profili di interconnessione è sufficiente per la comunicazione end-to-end con tutti i nodi. È possibile configurare l'opzione Da filiale a filiale tramite hub (Branch to Branch via Hubs) per i profili spoke.
- La funzionalità Hub o Cluster Interconnect (Hub or Cluster Interconnect) deve essere attivata in tutti i profili hub coinvolti nel processo di interconnessione.
- I membri del cluster devono eseguire BGP con il router LAN/L3 e il router deve essere configurato per inoltrare le community estese BGP.
- In caso di assegnazione del gateway partner, deve essere presente almeno un gateway comune per tutti gli Edge (spoke e hub). L'ordine di assegnazione dei gateway partner deve essere lo stesso in tutti i profili hub/cluster.
Procedura
Operazioni successive
- Assegnare profili agli Edge: Passare a per assegnare i profili agli Edge disponibili.
- È possibile monitorare gli eventi passando a Hub o Cluster Interconnect (Hub or Cluster Interconnect):
Evento Livello Descrizione CLUSTER_IC_ENABLED Informazioni Questo evento viene generato ogni volta che un Edge viene associato a un servizio cluster. CLUSTER_IC_DISABLED Informazioni Questo evento viene generato ogni volta che l'associazione di un Edge a un servizio cluster viene annullata. CLUSTER_IC_PEER_UP Avviso Questo evento viene generato ogni volta che il primo tunnel di interconnessione tra due nodi dell'hub cluster diventa attivo. CLUSTER_IC_PEER_DOWN Avviso Questo evento viene generato ogni volta che l'ultimo tunnel di interconnessione tra due nodi dell'hub cluster diventa inattivo. CLUSTER_IC_TUNNEL_UP Avviso Questo evento viene generato ogni volta che i tunnel di interconnessione tra i cluster diventano attivi. CLUSTER_IC_TUNNEL_DOWN Avviso Questo evento viene generato ogni volta che i tunnel di interconnessione tra i cluster diventano inattivi. HUB_CLUSTER_REBALANCE Avviso Questo evento viene generato ogni volta che viene attivata un'azione di ribilanciamento del cluster.
. Nella tabella seguente sono elencati i nuovi eventi di Orchestrator aggiunti per la funzionalità
- Dopo che la funzionalità Hub o Cluster Interconnect (Hub or Cluster Interconnect) viene attivata, la rimozione o l'aggiunta di un membro del cluster in Servizi di rete (Network Services) attiva il riavvio del servizio in tale Edge specifico. È consigliabile eseguire tali azioni durante la finestra di manutenzione.
- Quando uno spoke è connesso al cluster hub primario e secondario e acquisisce la stessa route da entrambi, l'ordine delle route si basa sugli attributi BGP. Se gli attributi di routing sono uguali, l'ordinamento delle route viene eseguito in base alla configurazione dell'ordine dell'hub VPN. D'altra parte, le subnet dello spoke vengono ridistribuite dall'hub o dal cluster hub primario e secondario al router adiacente con le metriche (MED) 33 e 34 rispettivamente. È necessario configurare "bgp always-compare-med" nel router adiacente per il routing simmetrico.
- Quando l'hub o i cluster hub sono connessi al core MPLS tramite CE, è necessario configurare il tag UPLINK in tali router adiacenti BGP.
- In una rete configurata con uno spoke, un hub primario e un hub secondario, l'avvio di un flusso da dietro lo spoke crea un flusso locale nello spoke che viene quindi instradato attraverso l'hub primario. Se l'hub primario diventa inattivo, la route del flusso locale viene aggiornata verso l'hub secondario. Poiché la route viene verificata con ogni pacchetto per i flussi locali, quando l'hub primario torna attivo, la route viene aggiornata di conseguenza. Tuttavia, il comportamento è diverso quando il flusso è un flusso peer. In questo caso, se l'hub primario diventa inattivo, il flusso peer viene instradato tramite l'hub secondario, ma quando l'hub primario torna attivo, la route peer non viene aggiornata. Ciò è dovuto al fatto che il flusso peer si basa sugli aggiornamenti del peer, ovvero il comportamento previsto. La soluzione consiste nello svuotare i flussi interessati.