VMware SASE unterstützt die Zusammenschaltung mehrerer Hub-Edges oder Hub-Cluster, um den Bereich der Spoke-Edges, die miteinander kommunizieren können, zu vergrößern. Diese Funktion ermöglicht über mehrere Overlay- und Underlay-Verbindungen hinweg die Kommunikation zwischen den Spoke-Edges, die mit einem Hub-Edge/Hub-Cluster verbunden sind, und den Spoke-Edges, die mit einem anderen Hub-Edge/Hub-Cluster verbunden sind.
Wenn ein Spoke-Edge versucht, eine Verbindung zu einem Hub-Cluster herzustellen, wird eines der Mitglieder des Hub-Clusters als Hub für den Spoke-Edge ausgewählt. Wenn dieser Hub ausfällt, wird automatisch ein anderes Mitglied desselben Hub-Clusters ausgewählt, um den Spoke-Edge zu bedienen, ohne dass eine Benutzerkonfiguration erforderlich ist. Die Hub-Cluster-Mitglieder sind über Underlay (BGP) miteinander verbunden und können die Routen und Daten über diese Underlay-Verbindung austauschen. Spoke-Edges, die mit verschiedenen Mitgliedern desselben Hub-Clusters verbunden sind, können dann über diese Underlay-Verbindung miteinander kommunizieren. Diese Lösung bietet eine bessere Ausfallsicherheit.
- Die Funktion Hub- oder Cluster-Interconnect (Hub or Cluster Interconnect) muss aktiviert sein.
- Das Kontrollkästchen Zweigstelle-zu-Hub-Site (permanentes VPN) (Branch to Hub Site (Permanent VPN)) muss aktiviert sein. Die beiden miteinander verbundenen Hub-Knoten müssen als gegenseitige Hubs konfiguriert werden (siehe Erläuterung in der folgenden Tabelle).
| Profil | Hub-Bezeichnung |
|---|---|
| hub_profile1 | hub2 |
| hub_profile2 | hub1 und hub3 |
| hub_profile3 | hub2 |
Wenn die Funktion Hub- oder Cluster-Interconnect (Hub or Cluster Interconnect) aktiviert ist, werden Tunnel von einem Cluster zu einem anderen Cluster mit mindestens einem Peer in einem anderen Cluster erstellt. Je nach Bedingung können zwei Mitglieder eines Clusters Tunnel für dieselben Mitglieder in einem anderen Cluster erstellen. Bei einer Verbindung zwischen einzelnen Hubs und Hub-Clustern erstellen alle Clustermitglieder Tunnel zu diesem einzelnen Hub. Die an diese Hub-Cluster angeschlossenen End-Spoke-Edges können dann über diese beiden Hub-Cluster und die dazwischenliegenden VMware SD-WAN-Routingprotokoll-Hubs miteinander kommunizieren.
Die internen Cluster-Routen werden mit einer speziellen erweiterten BGP-Community angekündigt, wobei die letzten vier Bytes der Cluster-ID in die erweiterte Community eingebettet werden. Wenn die Cluster-ID beispielsweise fee2f589-eab6-4738-88f2-8af84b1a3d9c lautet, wird 4b1a3d9c umgekehrt und zum Ableiten der Cluster-Community als 9c3d1a4b00000003 verwendet. Basierend auf diesem Community-Tag werden die Intra-Cluster-Routen zum Controller herausgefiltert. Auf diese Weise wird vermieden, dass redundante Routen von mehreren Clustermitgliedern angezeigt werden.
- Overlay-Verbindung zwischen S1 und C1.
- Overlay-Verbindung zwischen S2 und C2.
- Overlay-Verbindung zwischen C1 und C2.
- Underlay-Verbindung innerhalb von C1.
- Underlay-Verbindung innerhalb von C2.
Auf diese Weise können die Hub-Cluster untereinander Routen austauschen, sodass die Pakete zwischen Spoke-Edges, die mit verschiedenen Hub-Clustern verbunden sind, fließen können.
- Die Funktion „Dynamische Zweigstelle-zu-Zweigstelle (Dynamic branch to branch)“ wird zwischen Spokes unterstützt, die mit zwei verschiedenen oder gleichen Clustern verbunden sind.
- Profilisolierung im Spoke-Profil wird unterstützt.
- Internet-Backhaul über Cluster wird unterstützt.
Einschränkungen:
- Hub oder Cluster Interconnect über Gateway wird nicht unterstützt.
- Der Austausch von Routen zwischen Hub-Cluster-Mitgliedern unter Verwendung von OSPF wird nicht unterstützt.
- Asymmetrisches Routing kann auftreten, wenn zwei Cluster miteinander verbunden sind. Die Option „Erweiterte Firewalldienste (Enhanced Firewall Services)“ oder „Statusbehaftete Firewall (Stateful Firewall)“ darf nicht aktiviert werden, da sie den Datenverkehr aufgrund von asymmetrischem Routing blockieren kann.
- Wenn alle Overlay-Tunnel zwischen zwei Clustermitgliedern ausfallen, kommt es solange zu einem Rückgang des Datenverkehrs, bis ein Tunnel mit anderen Mitgliedern im Peer-Cluster erstellt wurde.
- Wenn mehrere LAN/WAN-Router vorhanden sind, die BGP mit Clustern ausführen, muss das Kontrollkästchen Vertrauenswürdige Quelle (Trusted Source) aktiviert sein. Weiterhin muss der Wert von Umgekehrte Pfadweiterleitung (Reverse Path Forwarding) auf den Cluster-Edge-Schnittstellen, die BGP-Router verbinden, auf Nicht aktiviert (Not enabled) festgelegt sein. Weitere Informationen finden Sie unter Konfigurieren von Schnittstelleneinstellungen für Edges.
- Ohne die Funktion Hub- oder Cluster-Interconnect (Hub or Cluster Interconnect) kann für ein Cluster-Hub-Profil kein anderer Cluster oder Hub als Hub konfiguriert werden.
Konfigurieren von Hub- oder Cluster-Interconnect
Voraussetzungen
- Stellen Sie sicher, dass Sie den Orchestrator, Gateways und Hubs oder Hub-Cluster auf Version 5.4.0.0 oder höher aktualisieren.
- Der Dienst Cloud-VPN (Cloud VPN) muss für das Clusterprofil aktiviert werden, das mit den Edge-Clustern oder -Hubs verknüpft ist.
- Das Kontrollkästchen Zweigstelle-zu-Zweigstelle-VPN (Transit und Dynamisch) (Branch to Branch VPN (Transit & Dynamic)) darf in Interconnect-Hub-Profilen nicht aktiviert sein (siehe unten).
Die Konfiguration der Hub-Bezeichnung (Hubs Designation) in Interconnect-Profilen reicht für die End-to-End-Kommunikation mit allen Knoten aus. Sie können Zweigstelle-zu-Zweigstelle über Hubs für Spoke-Profile konfigurieren.
- Die Funktion Hub- oder Cluster-Interconnect (Hub or Cluster Interconnect) muss in allen Hub-Profilen aktiviert sein, die am Interconnect-Prozess beteiligt sind.
- Clustermitglieder müssen BGP mit einem LAN/L3-Router ausführen. Der Router muss so konfiguriert werden, dass die erweiterten BGP-Communitys weitergeleitet werden.
- Bei der Zuweisung von Partner-Gateways muss mindestens ein gemeinsames Gateway für alle Edges (Spokes und Hubs) vorhanden sein. Die Reihenfolge der Zuweisung von Partner-Gateways sollte für alle Hub-/Clusterprofile identisch sein.
Prozedur
- Bestimmen Sie den Hub für das Cluster-Profil:
- Navigieren Sie auf dem Bildschirm Profilgeräteeinstellungen (Profile Device Settings) zu VPN-Dienste (VPN Services) und aktivieren Sie den Dienst Cloud-VPN (Cloud VPN).
- Aktivieren Sie das Kontrollkästchen „Zweigstelle-zu-Hub“ aktivieren (Enable Branch to Hubs).
- Klicken Sie auf Hubs bearbeiten (Edit Hubs) unter Hub-Bezeichnung (Hub Designation).
- Klicken Sie auf Hubs aktualisieren (Update Hubs).
- Navigieren Sie auf dem Bildschirm Profilgeräteeinstellungen (Profile Device Settings) zu VPN-Dienste (VPN Services) und aktivieren Sie den Dienst Cloud-VPN (Cloud VPN).
- Aktivieren Sie die Funktion „Hub- oder Cluster-Interconnect“: Navigieren Sie auf dem Bildschirm Profilgeräteeinstellungen (Profile Device Settings) unter VPN-Dienste (VPN Services) zu Hub- oder Cluster-Interconnect (Hub or Cluster Interconnect) und aktivieren Sie dann das Kontrollkästchen Aktivieren (Enable).
Hinweis: Hub- und Cluster-Interconnect-Konfigurationen können nur auf Profilebene durchgeführt werden.Dadurch wird die Funktion aktiviert und ein Tunnel zwischen den Hub-Clustern erstellt, über den ihre jeweiligen Spoke-Edges miteinander kommunizieren können.Vorsicht: Das Aktivieren oder Deaktivieren der Funktion Hub- oder Cluster-Interconnect (Hub or Cluster Interconnect) führt dazu, dass alle dem Profil zugeordneten Edge-Geräte neu gestartet werden. Daher wird empfohlen, die Funktion nur in einem Wartungsmodus zu konfigurieren, um Unterbrechungen des Datenverkehrs zu vermeiden.
Nächste Maßnahme
- Weisen Sie den Edges Profile zu: Navigieren Sie zu , um den verfügbaren Edges Profile zuzuweisen.
- Sie können die Ereignisse überwachen, indem Sie zu navigieren. In der folgenden Tabelle werden die neuen Orchestrator-Ereignisse aufgelistet, die für die Funktion Hub- oder Cluster-Interconnect (Hub or Cluster Interconnect) hinzugefügt wurden:
Ereignis Ebene Beschreibung CLUSTER_IC_ENABLED Info Dieses Ereignis wird generiert, wenn ein Edge mit einem Clusterdienst verknüpft wird. CLUSTER_IC_DISABLED Info Dieses Ereignis wird generiert, wenn ein Edge von einem Clusterdienst getrennt wird. CLUSTER_IC_PEER_UP Warnung Dieses Ereignis wird generiert, wenn sich der erste Verbindungstunnel zwischen zwei Cluster-Hub-Knoten öffnet. CLUSTER_IC_PEER_DOWN Warnung Dieses Ereignis wird generiert, wenn der letzte Verbindungstunnel zwischen zwei Cluster-Hub-Knoten ausfällt. CLUSTER_IC_TUNNEL_UP Warnung Dieses Ereignis wird generiert, wenn sich Verbindungstunnel zwischen den Clustern öffnen. CLUSTER_IC_TUNNEL_DOWN Warnung Dieses Ereignis wird generiert, wenn Verbindungstunnel zwischen den Clustern ausfallen. HUB_CLUSTER_REBALANCE Warnung Dieses Ereignis wird generiert, wenn eine Aktion zur Neuverteilung des Clusters ausgelöst wird.
- Nach dem Aktivieren der Funktion Hub- oder Cluster-Interconnect (Hub or Cluster Interconnect) wird durch Entfernen oder Hinzufügen eines Clustermitglieds unter „Netzwerkdienste (Network Services)“ ein Neustart des Diensts auf diesem bestimmten Edge ausgelöst. Es wird empfohlen, solche Aktionen während des Wartungsfensters durchzuführen.
- Wenn ein Spoke mit einem primären und sekundären Hub-Cluster verbunden ist und von beiden dieselbe Route erlernt, basiert die Routenreihenfolge auf BGP-Attributen. Wenn die Routing-Attribute identisch sind, erfolgt die Routensortierung basierend auf der Konfiguration der VPN-Hub-Reihenfolge. Andererseits werden die Subnetze des Spokes vom primären und sekundären Hub oder Hub-Cluster mit der Metrik (MED) 33 bzw. 34 an ihre Nachbarn umverteilt. Sie müssen „bgp always-compare-med“ im Nachbarrouter für symmetrisches Routing konfigurieren.
- Wenn Hub- oder Hub-Cluster über CE mit dem MPLS-Kern verbunden sind, müssen Sie das UPLINK-Tag in diesen BGP-Nachbarn konfigurieren.
- In einem Netzwerk, das mit einem Spoke, einem primären Hub und einem sekundären Hub eingerichtet ist, wird beim Initiieren eines Flows hinter dem Spoke ein lokaler Flow auf dem Spoke erstellt, der dann über den primären Hub geleitet wird. Wenn der primäre Hub ausfällt, wird die Route des lokalen Flows auf den sekundären Hub aktualisiert. Da die Route mit jedem Paket auf lokale Flows überprüft wird, wird die Route entsprechend aktualisiert, sobald der primäre Hub wieder aktiviert wird. Das Verhalten ändert sich jedoch, wenn es sich bei dem Flow um einen Peer-Flow handelt. Wenn in diesem Fall der primäre Hub ausfällt, wird der Peer-Flow über den sekundären Hub geleitet. Wenn der primäre Hub jedoch wieder aktiviert wird, findet keine Aktualisierung der Peer-Route statt. Dies liegt daran, dass der Peer-Flow auf den Updates des Peers basiert, was dem erwarteten Verhalten entspricht. Das Problem kann umgangen werden, indem die betroffenen Flows geleert werden.
