Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
AUF DIESER SEITE
 

Konfiguration von VXLAN-Stitching für Layer 2-Vernetzung von Datencentern

In diesem Dokument werden die Konfigurations- und Validierungsschritte für die Implementierung von Data Center Interconnect (DCI) mithilfe von VXLAN-Stitching in einem Gateway-Gerät beschrieben. Mit der VXLAN-Stitching-Funktion können Sie bestimmte VXLAN Virtual Network Identifier (VNIs) zusammenfügen, um Layer-2-Stretch zwischen DCs auf granularer Basis bereitzustellen.

Die Switching- und Routing-Geräte von Juniper Network unterstützen eine Reihe verschiedener DCI-Optionen. Beispielsweise kann Over-the-Top-DCI (OTT) verwendet werden, um das Overlay zwischen PODs zu erweitern. Weitere Informationen finden Sie unter OTT DCI . Ein Nachteil der OTT-Methode besteht darin, dass sie alle VLANs zwischen den PODs erweitert, entweder auf Layer 2 oder Layer 3. Außerdem erfordert OTT DCI die End-to-End-VXLAN-VNI-Signifikanz. Dies kann ein Problem sein, wenn zwei DC/PODs zusammengeführt werden, die keine überlappenden VLAN-zu-VNI-Zuweisungen haben.

In einigen Fällen möchten Sie eine genauere Steuerung darüber, welche VLANs zwischen PODs erweitert werden. Mit der Junos VXLAN-Stitching-Funktion können Sie DCI auf VNI-Ebene durchführen, um die Layer-2-Konnektivität auf VLAN-Basis zu erweitern. Oder Sie müssen VNIs übersetzen, um Instanzen zu berücksichtigen, in denen dieselben VNIs unterschiedlichen VLANs in jedem POD zugewiesen sind. Nehmen wir zum Beispiel den Fall, dass VLAN 1 VNI 10001 in POD 1 zugewiesen ist, während in POD 2 dasselbe VLAN VNI 20002 zugewiesen ist. In diesem Fall müssen Sie entweder einen der PODs neu konfigurieren, um eine globale (überlappende) Zuordnung von VLANs zu VNIs zu erreichen. Alternativ können Sie mithilfe von translationalem Stitching lokale POD-VNI-Werte dem über das WAN verwendeten VNI zuordnen.

Juniper Networks unterstützt VXLAN-Stitching sowohl für 3- als auch für 5-stufige IP-Fabrics. Darüber hinaus wird VXLAN-Stitching für CRB-Overlays (Central-Routed Bridging), ERB-Overlays (Edge-Routed Bridging) und Bridged-Overlay-Architekturen unterstützt. In diesem Anwendungsfall wird davon ausgegangen, dass Ihre EVPN-VXLAN POD-Fabrics bereits mit Leaves und Spines konfiguriert sind, die eine oder eine Kombination der in Tabelle 1 gezeigten unterstützten Architekturen verwenden.

Um VXLAN-Stitched-Konnektivität zwischen den beiden PODs zu ermöglichen, fügen Sie eine Reihe von WAN-Routern hinzu, um das Underlay zu erweitern. Die Underlay-Erweiterung erweitert das Overlay zwischen den PODs. Anschließend konfigurierenSie das VXLAN-Stitching auf den Gateway-Geräten, um die gewünschten VLANs (jetzt als VXLAN-VNIs dargestellt) zwischen den PODs zu erweitern.

Anmerkung:

Wir verwenden in diesem Dokument den Begriff "WAN-Router". Dies bedeutet nicht, dass zwischen den PODs tatsächlich ein WAN-Netzwerk besteht. Die WAN-Router können auf beiden PODs lokal sein, wie es in diesem Beispiel der Fall ist. Sie können VXLAN-Stitching auch über ein erweitertes WAN-Netzwerk verwenden, wenn die PODs geografisch entfernt sind.

Abbildung 1 zeigt ein allgemeines Diagramm mit den POD/DC-Fabric-Typen, die wir in diesem Referenzdesign validiert haben.

Abbildung 1: VXLAN-Stitching-Referenzarchitekturen VXLAN Stitching Reference Architectures

In Abbildung 1 stellt jeder WAN-Router eine Verbindung zu jedem Gateway-Gerät in beiden PODs her. Diese Verbindungen und die zugehörigen BGP-Peer-Sitzungen dienen dazu, das Underlay zwischen den beiden PODs zu erweitern. Insbesondere kündigen die Geräte die Loopbackadressen der Gateway-Geräte zwischen den PODs an. Diese Loopback-Erreichbarkeit richtet eine EBGP-basierte Peering-Sitzung ein, um das Overlay zwischen den Gateway-Geräten in beiden Pods zu erweitern.

POD 1 stellt eine 3-stufige CRB-Architektur dar, bei der die Gateway-Funktion in den Spine-Geräten integriert ist. Somit sind in POD 1 jeweils die Begriffe Spine und Gateway anwendbar. Im Allgemeinen verwenden wir bei der Beschreibung der Spine-Geräte den Begriff Gateway, da der Schwerpunkt hier auf ihrer Gateway-Funktionalität liegt.

POD 2 hingegen ist eine 5-stufige ERB-Architektur mit schlanken Spines und diskreten Gateway-Geräten. Die Gateway-Geräte in POD 2 können auch als Super-Spine- oder Border-Leaf-Geräte bezeichnet werden. In diesem Beispiel führen sie die VXLAN-Stitching-Funktion aus und werden daher als Gateway-Geräte bezeichnet.

Tabelle 1 beschreibt die POD-Architekturen, die wir im Rahmen dieses Referenzdesigns validiert haben.

Tabelle 1: Unterstützte POD-Architekturen für VXLAN-Stitching

POD 1

POD 2

Bridging mit Edge-Routing

Bridging mit Edge-Routing

Zentral geroutetes Bridging

Bridging mit Edge-Routing

Zentral geroutetes Bridging

Zentral geroutetes Bridging

Überbrücktes Overlay

Überbrücktes Overlay

3- oder 5-stufige Fabric

3- oder 5-stufige Fabric

Weitere Punkte, die bei der Verwendung von VXLAN-Stitching zu beachten sind, sind:

  • Sie können die Rolle von Spine und Gateway in einem reduzierten Design kombinieren, wie für POD 1 gezeigt.

  • Der zusammengefügte VNI kann denselben Wert haben (globales Stitching), wenn die PODs überlappende VLAN-zu-VNI-Zuweisungen haben, oder er kann zwischen den beiden PODs übersetzt werden. Letztere Funktion ist nützlich beim Zusammenführen von PODs (DCs), die keine überlappenden VNI-zu-VLAN-Zuweisungen haben.

  • Wir unterstützen VXLAN-Stitching in der Standard-Switch-EVPN-Instanz (EVI) und in MAC-VRF-Routing-Instanzen.

  • Wir unterstützen Layer-2-Stitching nur für Unicast- und BUM-Datenverkehr. Bei BUM-Datenverkehr führt die designierte Weiterleitung (DF) für die ESI-LAG des lokalen Gateways eine eingehende Replikation durch und leitet eine Kopie des BUM-Datenverkehrs an jedes Remote-Gateway weiter. Auf den Remote-Gateway-Geräten führt der DF für die Remote-ESI-LAG eine Eingangsreplikation durch und sendet eine Kopie des BUM-Datenverkehrs an alle Leaf-Knoten im lokalen POD.

  • Es wird empfohlen, die IRB-Schnittstellen auf den Spine-Geräten in einer CRB-Fabric mit der proxy-macip-advertisement Konfigurationsanweisung zu konfigurieren. Diese Option gewährleistet den korrekten ARP-Betrieb über eine CRB EVPN-VXLAN-Fabric und ist Teil der CRB-Referenzarchitektur. Weitere Informationen zu dieser Option finden Sie unter proxy-mac-ip-advertisement .

Beachten Sie Folgendes zum Referenzdesign der EVPN-VXLAN-Fabric:

  • In diesem Beispiel wird davon ausgegangen, dass die Ebenen der Spine- und Leafgeräte in den beiden PODs bereits vorhanden und betriebsbereit sind. Daher enthält dieses Thema die Konfiguration für das EBGP-Underlay-Peering zwischen Gateway und WAN-Router, das EBGP-Overlay-Peering zwischen POD und die für das VXLAN-Stitching erforderliche Konfiguration.

    Informationen zum Konfigurieren der Spine- und Leaf-Geräte in den beiden PODs finden Sie unter:

  • In diesem Beispiel werden die WAN-Router in eine vorhandene EVPN-VXLAN-Fabric mit zwei Pods integriert. Um den Fokus auf VXLAN-Stitching zu behalten, verwenden beide PODs im Beispiel dieselbe 3-stufige Clos-Fabric basierend auf einer CRB-Architektur. Zusätzlich zu ihrer Rolle als Layer-3-VXLAN-Gateways führen die Spines auch die VXLAN-Stitching-Funktion aus. Das Ergebnis ist ein Beispiel für eine Collapsed Gateway-Architektur.

    Abbildung 2 zeigt die CRB-basierte VXLAN-Stitching-Beispieltopologie des Collapsed Gateways.

    Abbildung 2: Beispieltopologie VXLAN Stitching Example Topology für VXLAN-Stitching

    In diesem Beispiel fügen Sie die Gatewayfunktionalität zu einer bereits vorhandenen CRB-Spine-Konfiguration hinzu. Wie bereits erwähnt, unterstützen wir auch 5-stufige Architekturen, wobei die Super-Spine-Schicht die Gateway-Peering- und Stitching-Funktionen ausführt. Es wird empfohlen, ein separates Gateway-Gerät zu verwenden, um maximale Skalierung und Leistung zu erzielen. Bei einer 3-stufigen oder 5-stufigen ERB-Architektur fügen Sie die Gateway-Konfiguration zu den Lean-Spine- bzw. Super-Spine-Geräten hinzu.

  • Wenn Sie das Overlay-BGP-Peering zwischen den PODs konfigurieren, können Sie entweder IBGP oder EBGP verwenden. In der Regel verwenden Sie IBGP, wenn Ihre Datencenter (PODs) dieselbe AS-Nummer (Autonomous System) verwenden, und EBGP, wenn Ihre PODs unterschiedliche AS-Nummern verwenden. In unserem Beispiel werden in jedem POD unterschiedliche AS-Nummern verwendet, daher wird EBGP-Peering verwendet, um das Overlay zwischen den PODs zu erweitern.

  • Nachdem Sie die WAN-Router integriert haben, um das Underlay und Overlay zwischen den beiden PODs zu erweitern, konfigurieren Sie das translationale VXLAN-Stitching, um ein bestimmtes VLAN zwischen den PODs zu erweitern. Translationales VXLAN-Stitching übersetzt den lokal in jedem POD verwendeten VNI-Wert in einen gemeinsamen VNI-Wert, der im gesamten WAN-Segment verwendet wird. Beachten Sie, dass wir in unserem Beispiel VLAN 1 in jedem POD einen anderen (nicht überlappenden) VNI-Wert zuweisen. Aus diesem Grund verwenden wir in diesem Fall Translational Stitching. Normalerweise verwenden Sie das globale Modus-Stitching, wenn derselbe VNI-Wert demselben VLAN in beiden PODs zugeordnet ist.

Was kommt als nächstes

Konfigurieren von Gateway-Geräten zur Erweiterung des Underlay über das WAN

In diesem Abschnitt erfahren Sie, wie Sie die Collapsed Gateway-Geräte (ein CRB-Spine mit zusätzlicher VXLAN-Stitching-Gateway-Funktionalität) so konfigurieren, dass sie mit den WAN-Geräten kommunizieren können. Denken Sie daran, dass jeder POD bereits über ein voll funktionsfähiges Underlay und ein CRB-Overlay verfügt, das auf der Referenzimplementierung für eine 3-stufige CRB-Architektur basiert. Weitere Informationen finden Sie unter Entwurf und Implementierung von Bridging-Overlays mit zentralem Routing.

Sie konfigurieren die Spine-/Gateway-Geräte für ein Peering mit den WAN-Routern, um das Underlay zwischen den beiden PODs zu erweitern. Dazu gehört die Konfiguration von EBGP-Peering und -Richtlinien, um die Loopback-Routen von jedem Gateway mit Tags zu versehen und anzukündigen. Diese Routen richten die EBGP-Peering-Sitzungen zwischen den PODs ein, die das Fabric-Overlay im nächsten Abschnitt erweitern.

Anmerkung:

Die Konfiguration der WAN-Router würde den Rahmen dieses Dokuments sprengen. Sie müssen lediglich aggregierte Ethernet-Schnittstellen und EBGP-Peering zu den Gateway-Geräten unterstützen. In diesem Beispiel müssen die WAN-Router alle von einem POD empfangenen Routen zum anderen erneut bekannt geben. Im Fall eines Junos-Geräts ist dies die Standardrichtlinie für das EBGP-Underlay-Peering in diesem Beispiel.

Abbildung 3 enthält die Details zu Schnittstellen, IP-Adressierung und AS-Nummerierung für den DCI-Teil der POD-Netzwerke.

Abbildung 3: Details zur Underlay- und Overlay-Erweiterung im gesamten WAN Details for Underlay and Overlay Extension Across the WAN

Die Konfiguration auf allen Gateway-Geräten ist ähnlich. Wir führen Sie durch die Konfiguration des Gateway-1-Geräts und stellen dann das vollständige Konfigurationsdelta für die anderen 3 Gateways bereit.

Gateway 1

  1. Konfigurieren Sie die Schnittstellen, die das Gerät von Gateway 1 mit den beiden WAN-Routern verbinden.

    Hier erstellen wir eine aggregierte Ethernet (AE)-Schnittstelle, die ein einzelnes Mitglied enthält. Bei diesem Ansatz können Sie problemlos zusätzliche Mitgliederlinks hinzufügen, um den WAN-Durchsatz oder die Ausfallsicherheit zu erhöhen.

  2. Erstellen Sie eine BGP-Peer-Gruppe mit dem Namen underlay-bgp-wan, und konfigurieren Sie sie als EBGP-Gruppe.
  3. Konfigurieren Sie die EBGP-Underlay-AS-Nummer.

    Bei diesem Referenzdesign weisen Sie jedem Gerät im Underlay-Netzwerk eine eindeutige AS-Nummer zu. Siehe Abbildung 3 für die AS-Nummern des Gateways und der WAN-Geräte.

    Sie konfigurieren die AS-Nummer für EBGP im Underlay-Netzwerk auf der Ebene der BGP-Peer-Gruppe mithilfe der local-as Anweisung, da die AS-Nummerneinstellung des Systems in der [edit routing-options autonomous-system] Hierarchie für MP-IBGP-Overlay-Peering in der lokalen Fabric und für das EBGP-Peering zum Erweitern des Overlays zwischen den PODs verwendet wird.

  4. Konfigurieren Sie EBGP-Peering mit den WAN-Geräten 1 und 2.

    Sie konfigurieren jedes WAN-Gerät als EBGP-Nachbar, indem Sie die IP-Adresse und die AS-Nummer des WAN-Geräts angeben. Siehe Abbildung 3 für die IP-Adressen und AS-Nummern der Spine-Geräte.

  5. Konfigurieren Sie eine Import-Routing-Richtlinie, die 10 vom lokalen Präferenzwert der vom WAN empfangenen Routen subtrahiert, wenn sie einer bestimmten Community zugeordnet sind. Diese Richtlinie stellt sicher, dass das Gateway-Gerät immer eine lokale Underlay-Route bevorzugt, selbst wenn dieselbe Gateway-Loopback-Adresse auch über das WAN-Peering gelernt wird.

    Zur Erinnerung: Wir verwenden EBGP für das Peering zwischen Gateway und WAN-Router. Standardmäßig meldet EBGP alle empfangenen Routen erneut für alle anderen EBGP-Nachbarn (und IBGP-Nachbarn). Das heißt, wenn Gateway 1 seine Loopback-Route an WAN-Router 1 weitergibt, meldet der WAN-Router diese Route erneut an Gateway 2. Das Ergebnis ist, dass jedes Gateway sowohl über eine Intra-Fabric-Route als auch über eine Inter-Fabric-Route verfügt, um das andere Gateway in seinem lokalen POD zu erreichen.

    Wir möchten sicherstellen, dass das Gateway immer den Intra-Fabric-Pfad bevorzugt. Wir tun dies, indem wir den lokalen Präferenzwert für die vom WAN empfangenen Routen anpassen (um sie unabhängig von der AS-Pfadlänge weniger bevorzugt zu machen). Die Richtlinie blockiert auch die erneute Ankündigung von Gateway-Loopback-Routen, die über das WAN erlernt wurden und in die lokale Fabric spähen. Das Ergebnis ist, dass die Leaf-Geräte nur die Loopbackroute des Gateways innerhalb des Fabric sehen, während die Gatewaygeräte immer die Route des Gateways innerhalb des Fabric bevorzugen.

    Im nächsten Schritt definieren Sie die referenzierte Community.

    Anmerkung:

    In diesem Beispiel wird davon ausgegangen, dass Sie in beiden PODs von einer Baselinereferenzarchitektur ausgehen. Ein Teil der bereits vorhandenen Referenz-Baseline ist das Fabric-Underlay und -Overlay für BGP-Peering und -Richtlinien. In diesem Beispiel werden Spine und Gateway in einem einzigen Gerät zusammengefasst. Nachdem Sie nun die Underlay- und Overlay-Erweiterung über WAN-Router hinzugefügt haben, sollten Sie Ihre vorhandene Underlay-Richtlinie auf dem Gateway oder in unserem Fall auf dem Spine-/Gateway-Gerät ändern, um die erneute Ankündigung von Routen zu blockieren, die mit dem von den wan_underlay_comm anderen Fabric-Geräten getaggt sind.

    Ein Beispiel für diese Modifikation zeigen wir hier. Der neu hinzugefügte from_wan Begriff unterdrückt die Ankündigung von Routen mit der passenden Community in das Fabric-Underlay.
  6. Konfigurieren Sie eine Export-Routing-Richtlinie, um den WAN-Geräten die Adresse der Gateway-Loopback-Schnittstelle bekannt zu geben. Diese Richtlinie lehnt alle anderen Anzeigen ab. Sie definieren nun die Community, die wan_underlay_comm zum Markieren dieser Routen verwendet wird.
  7. Konfigurieren Sie Multipath mit der multiple-as Option, das Load Balancing zwischen EBGP-Peers in verschiedenen ASs zu aktivieren.

    Standardmäßig wählt EBGP für jedes Präfix einen besten Pfad aus und installiert diese Route in der Weiterleitungstabelle. Außerdem konfigurieren Sie den BGP-Multipath so, dass alle Pfade zu gleichen Kosten zu einem bestimmten Ziel in der Routing-Tabelle installiert werden.

  8. Aktivieren Sie die bidirektionale Weiterleitungserkennung (BFD) für die WAN-EBGP-Sitzungen. BFD ermöglicht die schnelle Erkennung von Ausfällen und damit eine schnelle Rekonvergenz.

Konfigurieren von Gateway-Geräten zum Erweitern des Overlays über das WAN

In diesem Abschnitt wird gezeigt, wie Sie das EVPN-Overlay mithilfe von EBGP zwischen den beiden PODs erweitern. Denken Sie daran, dass in diesem Beispiel die beiden PODs eindeutige AS-Nummern haben, sodass EBGP verwendet wird.

Wie für eine 3-stufige CRB-Fabric üblich, fungieren unsere Spine-Geräte (Gateways) als Routenreflektoren im Overlay für die Leaf-Geräte in ihren jeweiligen PODs. In diesem Abschnitt definieren Sie eine neue EBGP-Peering-Gruppe, die das Overlay zwischen den PODs erweitert. In Abbildung 3 finden Sie Details zur AS-Nummerierung und den Loopback-Adressen des Spine-Geräts.

Die Konfiguration auf allen Gateway-Geräten ist ähnlich. Wir führen Sie noch einmal durch die Konfiguration des Gateway-1-Geräts und stellen das vollständige Konfigurationsdelta für die anderen 3 Gateways bereit.

Gateway 1

  1. Konfigurieren Sie die EBGP-Gruppe so, dass das EVPN-Overlay auf die Remote-Gateway-Geräte ausgeweitet wird.

    Normalerweise verwenden wir IBGP für ein EVPN-Overlay. Wir verwenden hier EBGP, weil wir den PODS unterschiedliche AS-Nummern zugewiesen haben. Beachten Sie hier, dass Sie die multihop Option aktivieren müssen. Standardmäßig erwartet EBGP einen direkt verbundenen Peer. In diesem Beispiel ist der Peer remote mit der anderen Seite des WAN verbunden. Außerdem müssen Sie die no-nexthop-change Option konfigurieren. Mit dieser Option wird das EBGP-Standardverhalten geändert, bei dem der nächste BGP-Hop beim erneuten Ankündigung von Routen auf einen lokalen Wert aktualisiert wird. Mit dieser Option weisen Sie das Gatewaygerät an, den nächsten Hop des BGP-Protokolls für die Overlay-Route unverändert zu lassen. Dies ist wichtig, da die Gateway-IP-Adresse möglicherweise keine VXLAN-VTEP-Adresse ist, z. B. in einer ERB-Fabric, bei der der nächste Hop für eine EVPN-Route vom Typ 2 dieses Leaf-Gerät identifizieren muss. Indem der nächste Hop nicht überschrieben wird, wird sichergestellt, dass die richtigen VTEPs für VXLAN-Tunnel verwendet werden.

    Sie konfigurieren das EBGP-Peering zwischen den Loopbackadressen des Gateway-Geräts.

  2. Wie beim Underlay-Peering fügen wir in der Overlay-Erweiterung BFD zur schnellen Fehlererkennung hinzu. Beachten Sie, dass wir hier ein längeres Intervall für das Overlay-Peering angeben. Beim Peering der Underlay-Erweiterung haben wir ein Intervall von 1 Sekunde verwendet. Hier konfigurieren wir ein Intervall von 4 Sekunden, um sicherzustellen, dass die Overlay-Sitzungen im Falle eines Underlay-Fehlers, der eine erneute Konvergenz erfordert, aktiv bleiben.
  3. Stellen Sie sicher, dass Sie die Änderungen nach diesen Schritten auf allen Gateway-Geräten übernehmen.

Gateway-Gerätekonfigurationen für Underlay- und Overlay-Erweiterung

Dieser Abschnitt enthält das Konfigurationsdelta für alle vier Gatewaygeräte. Sie addieren dieses Delta zur anfänglichen CRB-Baseline, um das POD-Underlay und das Overlay über das WAN zu erweitern.

Anmerkung:

Mit den letzten beiden Anweisungen wird die vorhandene Fabric-Underlay-Richtlinie dahingehend geändert, dass die erneute Ankündigung von Routen, die mit der wan_underlay_comm Community gekennzeichnet sind, von den anderen Leaf-Geräten blockiert wird.

Gateway 1 (POD 1)

Gateway 2 (Pod 1)

Gateway 3 (POD 2)

Gateway 4 (POD 2)

Überprüfen der Underlay- und Overlay-Erweiterung über das WAN

In diesem Abschnitt wird gezeigt, wie Sie überprüfen, ob die Gateway-Geräte ordnungsgemäß in das WAN integriert sind, um die Underlay- und Overlay-Netzwerke zwischen den beiden PODs zu erweitern.

  1. Stellen Sie sicher, dass die aggregierten Ethernet-Schnittstellen betriebsbereit sind. Ein ordnungsgemäßer BGP-Sitzungsaufbau ist ein gutes Zeichen dafür, dass die Schnittstelle Datenverkehr passieren kann. Pingen Sie im Zweifelsfall das entfernte Ende der AE-Verbindung an.

    Die Ausgabe bestätigt, dass die aggregierte Ethernet-Schnittstelle ae4 auf Gateway 1 betriebsbereit ist. Die Datenverkehrszähler bestätigen außerdem, dass die Schnittstelle Pakete sendet und empfängt.

  2. Vergewissern Sie sich, dass die Underlay-EBGP-Sitzungen für die WAN-Geräte eingerichtet sind.

    Die Ausgabe zeigt, dass beide EBGP-Peering-Sitzungen auf dem Gerät des Gateways 1 mit beiden WAN-Routern eingerichtet sind.

  3. Stellen Sie sicher, dass die Overlay-EBGP-Sitzungen zwischen den Gateway-Geräten im gesamten WAN eingerichtet wurden.

    Die Ausgabe bestätigt, dass beide Overlay-EBGP-Sitzungen vom Gerät des Gateways 1 zu beiden Remote-Gateways in POD 2 eingerichtet wurden.

    Nachdem die Underlay- und Overlay-Erweiterung überprüft wurde, können Sie mit der Konfiguration des VXLAN-Stitchings für Layer 2-DCI zwischen den PODs fortfahren.

Konfigurieren der DCI für translationales VXLAN-Stitching in der Standard-Switch-Instanz

In diesem Abschnitt konfigurieren Sie VXLAN-Stitching in den Gateway-Geräten, um Layer-2-Stretch zwischen den beiden PODs mithilfe der Standard-Switch-Instanz bereitzustellen. Wir unterstützen VXLAN-Stitching in der Standard-Switch-Instanz und in MAC-VRF-Instanzen. Wir beginnen mit der Standard-Switch-Instanz und zeigen später das Delta für den Fall der MAC-VRF-Instanz an.

VXLAN-Stitching unterstützt sowohl einen globalen als auch einen translatorischen Modus. Im globalen Modus bleibt der VNI durchgängig gleich, d. h. sowohl über die PODs als auch über das WAN-Netzwerk hinweg. Sie verwenden den globalen Modus, wenn sich die VLAN- und VNI-Zuweisungen zwischen den PODs überschneiden. Im Translationsmodus ordnen Sie einen lokalen POD-VNI-Wert einem VNI zu, der im gesamten WAN verwendet wird.

Sie konfigurieren VXLAN-Stitching nur auf den Gateway-Geräten. Für die Leaf-Geräte sind keine Änderungen erforderlich. In ERB-Fabrics erfordern die Lean-Spine-Geräte ebenfalls keine Änderungen, wenn Sie eine Super-Spine-Schicht haben, die die Gateway-Funktion ausführt.

Tabelle 2 beschreibt die POD-VLAN- und VNI-Zuweisungen. In diesem Beispiel verwenden die PODs einen anderen VNI für dasselbe VLAN. Aus diesem Grund konfigurieren Sie in diesem Fall das translationale Stitching. Beim translationalen Stitching kann der VNI für jeden POD eindeutig sein und dennoch über das WAN mit einer gemeinsamen VNI-Zuweisung verknüpft werden.

Tabelle 2: Zuordnungen von VLANs zu VNI

POD 1

POD 2

WAN-DCI

VLAN 1

VNI: 100001

VNI: 110001

VNI: 910001

VLAN 2

VNI: 100002

VNI: 110002

VNI: 910002

Abbildung 4 bietet einen Überblick über den VXLAN-Stitching-Plan für VLAN 1 in unserem Beispiel.

Abbildung 4: Zusammenfassung des translatorischen VXLAN-Stitchings für VLAN 1 Translational VXLAN Stitching Summary for VLAN 1

Abbildung 4 zeigt, dass VLAN 1 in POD 1 VNI-100001 verwendet, während dasselbe VLAN in POD 2 11000 zugeordnet ist. Sie fügen beide VLANs für den Transport über das WAN zu einem gemeinsamen VNI-910001 zusammen. Wenn das Gateway vom WAN empfangen wird, übersetzt es den zusammengefügten VNI zurück in den VNI, der lokal in seinem POD verwendet wird.

Auch hier ist die Konfiguration auf den Gateway-Geräten ähnlich. Wir führen Sie durch die Schritte, die auf dem Gerät "Gateway 1" erforderlich sind, und stellen das Konfigurationsdelta für die anderen Gatewayknoten bereit.

Führen Sie die folgenden Schritte aus, um das translationale VXLAN-Stitching auf Gateway 1 zu konfigurieren.

Gateway 1

  1. Konfigurieren Sie die Standard-EVPN-Parameter für die Switch-Instanz für den Routenaustausch zwischen den beiden PODs. Diese Konfiguration umfasst die Unterstützung für eine allaktive ESI-LAG zwischen den Gateways. Durch die Einrichtung einer ESI-LAG über das WAN wird sichergestellt, dass alle WAN-Verbindungen aktiv für die Weiterleitung von Datenverkehr genutzt werden, ohne dass das Risiko von Paketschleifen besteht. Sie müssen für alle Gateways innerhalb eines bestimmten POD denselben ESI-Wert verwenden, und jeder POD muss einen eindeutigen ESI-Wert verwenden. Daher konfigurieren Sie in diesem Beispiel zwei eindeutige ESIs, eine für jedes Gatewaypaar in jedem POD.

    Das Routenziel steuert Routenimporte. Sie konfigurieren dasselbe Routenziel auf allen Gateway-Geräten, um sicherzustellen, dass alle von einem POD angekündigten Routen von dem anderen importiert werden. Sie legen die Routenunterscheidung so fest, dass sie die Loopback-Adresse jedes Gateway-Geräts widerspiegelt.

  2. Konfigurieren Sie VXLAN-Stitching für die VLANs 1 und 2. Sie geben die VNIs an, die in der [edit protocols evpn interconnect interconnected-vni-list] Hierarchie über das WAN geheftet werden. Die Gateway-Geräte in beiden PODs müssen für jeden zusammengefügten VNI denselben VNI im gesamten WAN verwenden.
  3. Konfigurieren Sie das translationale VXLAN-Stitching für VLAN 1, indem Sie das lokale VLAN/VNI mit einem translatorischen VNI verknüpfen. Beachten Sie, dass der Wert für den translatorischen VNI mit dem VNI übereinstimmt, den Sie im vorherigen Schritt in der Hierarchie protocols evpn interconnect interconnected-vni-list konfiguriert haben. Mit den folgenden Befehlen ordnen Sie also einen lokalen VNI einem WAN-VNI zu.

    Für globales VXLAN-Stitching lassen Sie die translationale Anweisung einfach weg und konfigurieren das Benutzer-VLAN so, dass derselbe VNI-Wert verwendet wird, den Sie in der [edit protocols evpn interconnect interconnected-vni-list] Hierarchie konfigurieren.

    Denken Sie daran, dass die Leaf- und Spine-Geräte in jedem Pod bereits für die CRB-Referenzarchitektur konfiguriert sind. Im Rahmen der bereits bestehenden Konfiguration werden VLANs sowohl auf den Spine- als auch auf den Leaf-Geräten definiert. Die VLAN-Definition auf allen Geräten umfasst die Zuordnung einer VLAN-ID zu VXLAN VNI. Die VLAN-Konfiguration des Spines unterscheidet sich jedoch von der des Leafs dadurch, dass sie die Layer-3-IRB-Schnittstelle enthält, was dies wiederum zu einem Beispiel für CRB macht. Die vorhandene Konfiguration für VLAN 1 wird am Gerät von Gateway 1 (Spine 1) als Referenz angezeigt:

    Sie ändern nun die Konfiguration für VLAN 1 auf dem Gateway 1-Gerät, um translationales VXLAN-Stitching aufzurufen. Der von Ihnen angegebene VNI stimmt mit einem der VNI-Werte überein, die Sie in einem vorherigen Schritt in der edit protocols evpn interconnect interconnected-vni-list Hierarchie konfiguriert haben. Das Ergebnis ist, dass das Gerät VNI-100001 (lokal in POD 1 für VLAN 1 verwendet) in VNI-910001 übersetzt, wenn es sie über das WAN sendet. Im Remote-POD wird eine ähnliche Konfiguration vom WAN-VNI zurück dem lokalen VNI zugeordnet, der demselben VLAN im Remote-POD zugeordnet ist. Geben Sie im Konfigurationsmodus den folgenden Befehl ein:

  4. Konfigurieren Sie das translationale VXLAN-Stitching für VLAN 2.

    Sie ändern die Konfiguration für VLAN 2 so, dass translationales VXLAN-Stitching von VNI-100002 (lokal in POD 1 für VLAN 2 verwendet) zu VNI-910002 über WAN aufgerufen wird.

  5. Bestätigen Sie die Änderung für VLAN 1. VLAN 2 wird der Kürze halber weggelassen. Der folgende Befehl zeigt die Änderung zu VLAN 1 im Konfigurationsmodus an:
  6. Stellen Sie sicher, dass Sie Ihre Änderungen auf allen Gateway-Geräten übernehmen, wenn Sie fertig sind.

Gateway-Gerätekonfigurationen für translationales VXLAN-Stitching in der Standard-Switch-Instanz

Dieser Abschnitt enthält das Konfigurationsdelta für alle vier Gatewaygeräte. Sie fügen dieses Delta der CRB-Baseline hinzu, die Sie für DCI über das WAN geändert haben. Nachdem Sie das Underlay und Overlay erweitert haben, führen die folgenden Konfigurationen ein translationales VXLAN-Stitching zwischen dem VNI des lokalen POD und dem VNI im WAN durch.

Gateway 1 (POD 1)

Gateway 2 (Pod 1)

Gateway 3 (POD 2)

Gateway 4 (POD 2)

Überprüfen des übersetzten VXLAN-Stitchings in der Standard-Switch-Instanz

  1. Vergewissern Sie sich, dass die ESI-LAG zwischen den Gateway-Geräten betriebsbereit ist und sich im Aktiv-Aktiv-Modus befindet.

    Die Ausgabe zeigt, dass ESI 00:00:ff:ff:00:11:00:00:00:01 betriebsbereit ist. Die Ausgabe zeigt auch die Aktiv-Aktiv-Weiterleitung (Mode Spalte zeigt all-active) und sowohl als auch Designated forwarder Backup forwarder die Geräteadressen.

  2. Zeigen Sie Remote-VXLAN-VTEPs an, um zu bestätigen, dass die Remote-Gateway-Geräte als WAN-VTEPs aufgeführt sind.

    In der Ausgabe werden beide Remote-Gateways korrekt als Wan-VTEPangezeigt.

  3. Zeigen Sie die EVPN-Datenbank auf dem Gerät "Gateway 1" für VXLAN-VNI-100001 an. Zur Erinnerung: In unserem Beispiel ist dies der VNI, den Sie VLAN 1 auf den CRB-Leaves und Spines in POD 1 zugewiesen haben.

    Die Ausgabe bestätigt, dass der VNI-Wert 100001 der VLAN 1 zugeordnet ist, im lokalen POD angekündigt und verwendet wird.

  4. Zeigen Sie die EVPN-Datenbank auf dem Gateway 1-Gerät für VXLAN-VNI-910001 an. Denken Sie daran, dass dies der VNI ist, der VLAN 1 für das translationale VXLAN-Stitching über das WAN zugeordnet ist.

    Die Ausgabe bestätigt, dass der VNI-Wert 910001 der VLAN 1 zugeordnet ist, dem Remote-POD bekannt gegeben wird. Dies bestätigt, dass VNI-910001 über das WAN verwendet wird. Angesichts der Tatsache, dass sich der lokale VNI von dem im WAN verwendeten VNI unterscheidet, bestätigt dies das translationale VXLAN-Stitching für den Anwendungsfall der Standard-Switch-Instanz.

VXLAN-Stitching in einer MAC-VRF-Routing-Instanz

Wir unterstützen sowohl globales als auch translationales VXLAN-Stitching in MAC-VRF-Routing-Instanzen. Da wir das translationale Stitching für die vorherige Standard-Switch-Instanz demonstriert haben, zeigen wir für den MAC-VRF-Fall VXLAN-Stitching im globalen Modus.

Die Behandlung von MAC-VRF-Routinginstanzen würde den Rahmen dieses Dokuments sprengen. Auch hier wird davon ausgegangen, dass Sie über eine funktionierende CRB-Fabric mit MAC-VRF-Instanzen verfügen, die gemäß der Referenzbaseline konfiguriert sind. Weitere Informationen zur Konfiguration von MAC-VRF finden Sie unter Übersicht über den MAC-VRF-Routinginstanztyp und ein Beispielanwendungsfall unter EVPN-VXLAN DC IP Fabric MAC VRF L2-Services.

Um den Fokus auf die VXLAN-Stitching-Funktion zu legen, nennen wir das Delta für das Hinzufügen von VXLAN-Stitching zu einem vorhandenen MAC-VRF. Wie bei der Standard-Switch-Instanz wenden wir die Stitching-Konfiguration nur auf die Gateway-Geräte an. Im Fall von MAC-VRF konfigurieren Sie die Zuordnung von VLAN zu VNI jedoch in der MAC-VRF-Instanz und nicht in der Hierarchie [edit vlans] . Ein weiterer Unterschied im Fall MAC-VRF besteht darin, dass Sie die interconnected-vni-list Anweisung in der Routinginstanz und nicht in der [edit protocols evpn interconnect interconnected-vni-list] Hierarchie konfigurieren.

Das Ziel in diesem Beispiel besteht darin, globales VXLAN-Stitching für die VLANs 1201 und 1202 durchzuführen, die VXLAN-VNIs 401201 bzw. 401201 zugeordnet sind. Sie konfigurieren in beiden PODs dieselbe Zuordnung von VLAN zu VNI. Sie können das Global-Mode-Stitching verwenden, da sich die Zuweisungen von VLAN zu VNI in beiden PODs überschneiden.

Sie fügen die folgenden Befehle zu den Gateway-Geräten für die MAC-VRF-Instanz hinzu, die das Stitching durchführt. Die Konfiguration definiert die ESI-LAG, die zwischen den lokalen Gateways verwendet wird, und gibt die Liste der miteinander verbundenen VNIs an.

Sie benötigen eine ähnliche Konfiguration auf allen Gateway-Geräten. Wie zuvor gehen wir die Konfigurationsdetails für das Gateway 1-Gerät durch und stellen dann das vollständige Konfigurationsdelta für die anderen Gateways bereit.

Im folgenden Beispiel konfigurieren Sie VNIs 401201 und 401202 für VXLAN-Stitching über das WAN-Segment.

Anmerkung:

Wenn Sie VXLAN-Stitching in einem MAC-VRF-Kontext konfigurieren, müssen Sie die set forwarding-options evpn-vxlan shared-tunnels Option auf allen Leaf-Knoten in der QFX5000 Reihe von Switches einschließen, auf denen Junos OS ausgeführt wird. Nachdem Sie diese Anweisung hinzugefügt haben, müssen Sie den Switch neu starten. Es wird nicht empfohlen, die shared tunnels Anweisung für Gateway-Knoten in der QFX10000-Reihe von Switches zu verwenden, die Junos OS mit VXLAN-Stitching in MAC-VRF-Routing-Instanzen ausführen.

Gemeinsam genutzte Tunnel sind standardmäßig auf Geräten aktiviert, auf denen Junos OS Evolved ausgeführt wird (das EVPN-VXLAN nur mit MAC-VRF-Konfigurationen unterstützt).

Wie bereits erwähnt, würde eine vollständige Konfiguration einer MAC-VRF-Routing-Instanz den Rahmen sprengen. Der folgende Konfigurationsblock verwendet eine bereits vorhandene MAC-VRF-Instanz, die auf dem MAC-VRF-Referenzdesign basiert. Wir zeigen diesen Konfigurationsausschnitt, um besser zu veranschaulichen, warum dies ein Beispiel für VXLAN-Stitching im globalen Modus (für eine MAC-VRF-Instanz) ist. Das Beispiel stammt vom CRB-Spine-1-Gerät, das in unserer Beispieltopologie für ausgeblendete Gateways auch ein Gateway ist. Der Kürze halber zeigen wir nur die Konfiguration für VLAN 1201.

Im obigen Beispiel gibt die MAC-VRF-Definition für VLAN 1201 denselben VNI (401201) an, der in der Hierarchie [edit routing-instances MACVRF-mac-vrf-ep-t2-stchd-1 protocols evpn interconnect interconnected-vni-list] aufgeführt ist. Daraus ergibt sich eine durchgängige (globale) Signifikanz für diesen VNI.

Wie bei der Standard-Switch-Instanz ist es trivial, translationales VXLAN-Stitching im MAC-VRF-Kontext aufzurufen.

Um beispielsweise von einem lokalen VNI-300801 für VLAN 801 in ein WAN-VNI von 920001 zu übersetzen, ändern Sie einfach die VLAN-Definition in der zugehörigen MAC-VRF-Instanz, um die translation-vni 920001 Anweisung einzuschließen.

Indem Sie die translation-vni 920001 Anweisung zur MAC-VRF-VLAN-Konfiguration hinzufügen, weisen Sie das Gateway-Gerät an, beim Senden über WAN von lokalen VNI-300801 in VNI-920001 zu übersetzen.

Gateway-Gerätekonfigurationen für globales VXLAN-Stitching mit MAC-VRF

Dieser Abschnitt enthält das Konfigurationsdelta für alle vier Gateway-Geräte, um VXLAN-Stitching im globalen Modus in einem MAC-VRF-Kontext zu unterstützen. Sie fügen hinzu, dass dieses Delta der CRB-Baseline hinzugefügt wird, die Sie für DCI über das WAN modifiziert haben. Nachdem Sie das Underlay und Overlay erweitert haben, führen die folgenden Konfigurationen globales VXLAN-Stitching für VNIs 401201 und 401202 durch. Da es sich um ein Beispiel für den globalen Modus handelt, schließen Sie die translation-vni Anweisung nicht ein. Die Werte für VLAN und Interconnect-VNI sind identisch.

Gateway 1 (POD 1)

Gateway 2 (Pod 1)

Gateway 3 (POD 2)

Gateway 4 (POD 2)

Anmerkung:

Wenn Sie VXLAN-Stitching in einem MAC-VRF-Kontext konfigurieren, müssen Sie die set forwarding-options evpn-vxlan shared-tunnels Option auf allen Leaf-Knoten in der QFX5000 Zeile von Switches einschließen. Nachdem Sie diese Anweisung hinzugefügt haben, müssen Sie den Switch neu starten. Es wird nicht empfohlen, die Anweisung "Shared Tunnel" auf Gateway-Knoten in der QFX10000-Reihe von Switches zu konfigurieren, auf denen Junos OS mit VXLAN-Stitching in MAC-VRF-Routing-Instanzen ausgeführt wird.

Gemeinsam genutzte Tunnel sind standardmäßig auf Geräten aktiviert, auf denen Junos OS Evolved ausgeführt wird (das EVPN-VXLAN nur mit MAC-VRF-Konfigurationen unterstützt).

Überprüfen des globalen VXLAN-Stitchings in einer MAC-VRF-Instanz

  1. Vergewissern Sie sich, dass die zwischen den Gateway-Geräten verwendete ESI-LAG für den MAC-VRF-Fall betriebsbereit ist und sich im Aktiv-Aktiv-Modus befindet.

    Die Ausgabe zeigt, dass ESI 00:00:ff:ff:00:11:00:00:00:01 betriebsbereit ist. Die Aktiv-Aktiv-Weiterleitung wird durch den Modus und das all-active Vorhandensein eines designierten und eines Backup-Forwarders überprüft.

  2. Zeigen Sie Remote-VXLAN-VTEPs an, um zu bestätigen, dass die Remote-Gateway-Geräte als WAN-VTEPs aufgeführt sind.

    In der Ausgabe werden beide Remote-Gateways korrekt als .Wan-VTEP

  3. Zeigen Sie die EVPN-Datenbank auf dem Gerät des Gateways 1 für VXLAN VNI-401201 an, um Ankündigungen für das WAN zu erhalten. In unserem Beispiel ist dies der VNI, der VLAN 1201 in beiden PODs zugewiesen ist. Da es sich hierbei um ein CRB-Beispiel handelt, haben Sie VLAN 1201 für die Spines und die Leaf-Geräte definiert. Allerdings enthalten nur die Spine-Geräte die Layer-3-IRB-Schnittstellen in ihren VLAN-Konfigurationen.

    Der Ausgang bestätigt, dass der VNI-Wert 401201, der VLAN 1201 und der irb.1201-Schnittstelle zugeordnet ist, dem Remote-POD bekannt gegeben wird. Dies bestätigt, dass VNI-401201 über das WAN für VLAN 1201 verwendet wird.

  4. Zeigen Sie die EVPN-Datenbank auf dem Gerät "Gateway 1" für VXLAN VNI 401201 an, um Ankündigungen für den lokalen POD zu erhalten. Zur Erinnerung: Dies ist der VNI, der VLAN 1201 in beiden PODs zugeordnet ist. Dies ist derselbe VNI, den Sie im vorherigen Befehl verwendet haben, um Ankündigungen für die Remote-Gateways anzuzeigen.

    Die Ausgabe zeigt, dass VNI-401201 dem lokalen POD angekündigt wird. Dadurch wird bestätigt, dass VNI 401201 lokal verwendet wird. Unter der Voraussetzung, dass derselbe VNI lokal und im gesamten WAN verwendet wird, bestätigt dies das globale VXLAN-Stitching in einem MAC-VRF-Fall.

Verkehrsoptimierung für virtuelle Maschinen (VMTO) mit VXLAN-Stitching

In einigen Umgebungen können Sie /32- oder /128-Hostrouten installieren, um den Datenverkehr zu einer bestimmten VM zu optimieren. Wenn Sie VXLAN-Stitching verwenden, konfigurieren Sie auf allen Gateway-Knoten Folgendes, um die Installation von Hostrouten zu ermöglichen.

Mit dem ersten Befehl wird der Standard-Switch-Instanz Unterstützung für Hostrouten hinzugefügt. Die zweite fügt Hostroutenunterstützung für eine bestimmte MAC-VRF-Instanz hinzu. Sie müssen beide konfigurieren, wenn Sie eine Mischung aus Instance-Typen verwenden.

Überprüfen der Hostroutenunterstützung

Zweck

Vergewissern Sie sich, dass /32-Hostrouten in eine Layer 3-VRF-Tabelle importiert werden, wenn Sie die Standard-Switch-Instanz verwenden, oder in eine MAC-VRF-Tabelle, wenn Sie MAC-VRF verwenden.

Aktion

Zeigen Sie die Routing-Tabelle der zugehörigen Routing-Instanz an, und suchen Sie nach Routen mit dem Präfix /32 (oder /128). Wir beginnen mit der Anzeige einer Layer-3-VRF-Tabelle, die mit VXLAN-Stitching, der Standard-Switch-Instanz, verwendet wird:

Als Nächstes zeigen wir eine Routing-Tabelle für MAC-VRF-Instanzen an.