Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
AUF DIESER SEITE
 

Konfigurieren von VXLAN-Stitching für Layer 2 Data Center Interconnect

In diesem Dokument werden die Konfigurations- und Validierungsschritte für die Implementierung von Data Center Interconnect (DCI) mithilfe von VXLAN-Stitching in einem Gatewaygerät beschrieben. Mit der VXLAN-Stitching-Funktion können Sie bestimmte VXLAN Virtual Network Identifiers (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 (OTT) DCI verwendet werden, um die Überlagerung 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 auf Layer 3. Außerdem erfordert OTT-DCI eine End-to-End-VXLAN-VNI-Signifikan. 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 detailliertere Kontrolle 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 verschiedenen 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 Translational Stitching verwenden, um lokale POD-VNI-Werte dem VNI zuzuordnen, der über das WAN verwendet wird.

Juniper Networks unterstützt VXLAN-Stitching sowohl für 3-stufige als auch für 5-stufige IP-Fabrics. Darüber hinaus wird VXLAN-Stitching für CRB-Overlays (Centrally-Routing), ERB-Overlays (Edge-Routing-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, wobei eine oder eine Kombination der unterstützten Architekturen in Tabelle 1 verwendet wird.

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

Hinweis:

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

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 Gatewaygerä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 Loopback-Adressen der Gateway-Geräte zwischen den PODs an. Durch diese Loopback-Erreichbarkeit wird eine EBGP-basierte Peering-Sitzung eingerichtet, 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 die Spine-Geräte 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.

Im Gegensatz dazu ist POD 2 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. Im Kontext dieses Beispiels führen sie die VXLAN-Stitching-Funktionalität aus und werden daher als Gatewaygeräte bezeichnet.

Tabelle 1 zeigt die POD-Architekturen, die wir als Teil dieses Referenzdesigns validiert haben.

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

POD 1

POD 2

Edge-Routing-Bridging

Edge-Routing-Bridging

Zentral geroutetes Bridging

Edge-Routing-Bridging

Zentral geroutetes Bridging

Zentral geroutetes Bridging

Überbrückte Überlagerung

Überbrückte Überlagerung

3- oder 5-stufiger Stoff

3- oder 5-stufiger Stoff

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 EVPN-Instanz (EVI) des Standard-Switches und in MAC-VRF-Routing-Instanzen.

  • Wir unterstützen Layer-2-Stitching nur für Unicast- und BUM-Datenverkehr. Bei BUM-Datenverkehr führt der Designated Forwarder (DF) für die ESI-LAG des lokalen Gateways eine Eingangsreplikation 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.

  • Bei dem Gateway-Gerät muss es sich um einen Switch in der QFX10000 Reihe handeln, auf dem die Junos-Softwareversion 20.4R3 oder höher ausgeführt wird.

  • Es wird empfohlen, die IRB-Schnittstellen auf den Spine-Geräten in einem 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 von Spine- und Leaf-Geräten in den beiden PODs bereits vorhanden sind und ausgeführt werden. Daher enthält dieses Thema die Konfiguration für das EBGP-Underlay-Peering des Gateways zum WAN-Router, das EBGP-Overlay-Peering zwischen POD und die Konfiguration, die für das VXLAN-Stitching erforderlich ist.

    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 Zwei-POD-EVPN-VXLAN-Fabric integriert. Um den Fokus weiterhin auf das VXLAN-Stitching zu legen, verwenden beide PODs im Beispiel dieselbe 3-stufige Clos-Fabric, die auf einer CRB-Architektur basiert. 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 reduzierte Gateway-Architektur.

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

    Abbildung 2: VXLAN-Stitching-Beispieltopologie VXLAN Stitching Example Topology

    In diesem Beispiel fügen Sie die Gateway-Funktionalitä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. Wir empfehlen die Verwendung eines diskreten Gateway-Geräts für maximale Skalierung und Leistung. Bei einer 3- oder 5-stufigen ERB-Architektur fügen Sie die Gateway-Konfiguration zu den Lean-Spine- bzw. Super-Spine-Geräten hinzu.

  • Bei der Konfiguration des Overlay-BGP-Peerings zwischen den PODs 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 das 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 VNI-Wert, der lokal in jedem POD verwendet wird, 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 Translationshefte. Normalerweise verwenden Sie das Stitching im globalen Modus, wenn derselbe VNI-Wert in beiden PODs demselben VLAN zugeordnet ist.

Was kommt als nächstes

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

In diesem Abschnitt erfahren Sie, wie Sie die ausgeblendeten 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 CRB-Overlay verfügt, das auf der Referenzimplementierung für eine 3-stufige CRB-Architektur basiert. Weitere Informationen finden Sie unter Design und Implementierung von zentral gerouteten Bridging-Overlays .

Sie konfigurieren die Spine-/Gateway-Geräte für das Peering mit den WAN-Routern, um das Underlay zwischen den beiden PODs zu erweitern. Dazu müssen EBGP-Peering und -Richtlinien so konfiguriert werden, dass die Loopback-Routen von jedem Gateway markiert und angekündigt werden. Diese Routen richten die EBGP-Peering-Sitzungen zwischen POD ein, die das Fabric-Overlay im nächsten Abschnitt erweitern.

Hinweis:

Die Konfiguration der WAN-Router liegt außerhalb des Rahmens dieses Dokuments. 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 Routen, die von einem POD zum anderen empfangen werden, erneut ankündigen. Bei einem Junos-Gerät ist dies die Standardrichtlinie für das EBGP-Underlay-Peering in diesem Beispiel.

Abbildung 3 enthält 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 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 Geräts von Gateway 1 und stellen dann das vollständige Konfigurationsdelta für die anderen 3 Gateways bereit.

Gateway 1

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

    Hier erstellen wir eine aggregierte Ethernet-Schnittstelle (AE), die ein einzelnes Mitglied enthält. Mit 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-Peergruppe mit dem Namen underlay-bgp-wan, und konfigurieren Sie sie als EBGP-Gruppe.
  3. Konfigurieren Sie die EBGP-Underlay-AS-Nummer.

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

    Sie konfigurieren die AS-Nummer für EBGP im Underlay-Netzwerk auf BGP-Peergruppenebene mithilfe der local-as Anweisung, da die System-AS-Nummerneinstellung in der [edit routing-options autonomous-system] Hierarchie für das MP-IBGP-Overlay-Peering in der lokalen Fabric und für das EBGP-Peering verwendet wird, das 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-Nachbarn, indem Sie die IP-Adresse und die AS-Nummer des WAN-Geräts angeben. In Abbildung 3 sind die IP-Adressen und AS-Nummern der Spine-Geräte aufgeführt.

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

    Denken Sie daran, dass wir EBGP für das Gateway-zu-WAN-Router-Peering verwenden. Standardmäßig kündigt EBGP alle empfangenen Routen allen anderen EBGP- (und IBGP-) Nachbarn erneut an. Das heißt, wenn Gateway 1 seine Loopback-Route an WAN-Router 1 ankündigt, kündigt der WAN-Router diese Route erneut an Gateway 2 an. 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. Dazu passen wir den lokalen Präferenzwert für Routen an, die vom WAN empfangen werden (um sie unabhängig von der Länge des AS-Pfads weniger bevorzugt zu machen). Die Richtlinie blockiert auch die erneute Ankündigung von Gateway-Loopback-Routen, die über das WAN-Peering in die lokale Fabric gelernt wurden. Das Ergebnis ist, dass die Leaf-Geräte nur die Intra-Fabric-Gateway-Loopback-Route sehen, während die Gateway-Geräte immer die Intra-Fabric-Gateway-Route bevorzugen.

    Im nächsten Schritt definieren Sie die referenzierte Community.

    Hinweis:

    In diesem Beispiel wird davon ausgegangen, dass Sie in beiden PODs von einer Baseline-Referenzarchitektur ausgehen. Teil der bereits vorhandenen Referenz-Baseline ist das BGP-Peering und die BGP-Richtlinie für Fabric-Underlay und -Overlay. Dieses Beispiel basiert darauf, dass Spine und Gateway zu einem einzigen Gerät zusammengefasst werden. Nachdem Sie nun Underlay- und Overlay-Erweiterungen über WAN-Router hinzugefügt haben, sollten Sie Ihre vorhandene Underlay-Richtlinie auf dem Gateway oder in unserem Fall dem Spine/Gateway-Gerät ändern, um die erneute Ankündigung von Routen zu blockieren, die mit dem wan_underlay_comm von den anderen Fabric-Geräten gekennzeichnet 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 im Fabric-Underlay.
  6. Konfigurieren Sie eine Export-Routing-Richtlinie, um den WAN-Geräten die Gateway-Loopback-Schnittstellenadresse anzukündigen. Diese Richtlinie lehnt alle anderen Anzeigen ab. Sie definieren nun die Community, in der wan_underlay_comm diese Routen getaggt werden.
  7. Konfigurieren Sie Multipath mit der multiple-as Option, den Lastausgleich 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 BGP-Multipath so, dass alle Pfade zu gleichen Kosten zu einem bestimmten Ziel in der Routing-Tabelle installiert werden.

  8. Aktivieren Sie die Bidirectional Forwarding Detection (BFD) für die WAN-EBGP-Sitzungen. BFD ermöglicht die schnelle Erkennung von Fehlern und damit eine schnelle Rekonvergenz.

Konfigurieren von Gateway-Geräten, um das Overlay über das WAN auszudehnen

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

Wie für 3-stufiges CRB-Gewebe typisch, 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 zu den Loopback-Adressen der Spine-Geräte.

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ündigen von Routen auf einen lokalen Wert aktualisiert wird. Mit dieser Option weisen Sie das Gateway-Gerät an, den nächsten Hop des BGP-Protokolls für die Overlay-Route unverändert zu lassen. Dies ist wichtig, da es sich bei der Gateway-IP-Adresse möglicherweise nicht um eine VXLAN-VTEP-Adresse handelt, z. B. in einer ERB-Fabric, bei der der nächste Hop für eine EVPN-Typ-2-Route dieses Leaf-Gerät identifizieren muss. Wenn 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 Loopback-Adressen 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 4-Sekunden-Intervall, 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 Gatewaygeräten übernehmen.

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

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

Hinweis:

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

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. Der ordnungsgemäße Aufbau einer BGP-Sitzung ist ein gutes Zeichen dafür, dass die Schnittstelle Datenverkehr weiterleiten 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 auch, dass die Schnittstelle Pakete sendet und empfängt.

  2. Stellen Sie sicher, dass die Underlay-EBGP-Sitzungen zu den WAN-Geräten eingerichtet sind.

    Die Ausgabe zeigt, dass beide EBGP-Peering-Sitzungen auf dem Gerät von Gateway 1 für beide WAN-Router eingerichtet sind.

  3. Stellen Sie sicher, dass die Overlay-EBGP-Sitzungen zwischen den Gateway-Geräten über das WAN eingerichtet sind.

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

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

Konfigurieren von Translational VXLAN Stitching DCI 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 MAC-VRF-Instance-Fall.

VXLAN-Stitching unterstützt sowohl einen globalen Modus als auch einen Translationsmodus. Im globalen Modus bleibt der VNI End-to-End 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. Die Leaf-Geräte erfordern keine Änderungen. In ERB-Fabrics müssen die Lean-Spine-Geräte auch nicht geändert werden, wenn Sie eine Super-Spine-Schicht haben, die die Gateway-Funktion ausführt.

In Tabelle 2 sind die POD-VLAN- und VNI-Zuweisungen aufgeführt. In diesem Beispiel verwenden die PODs einen anderen VNI für dasselbe VLAN. Aus diesem Grund konfigurieren Sie in diesem Fall Translational Stitching. Beim Translational 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: VLAN-zu-VNI-Zuordnungen

POD 1

POD 2

WAN-DCI

VLAN 1

VNI: 100001

VNI: 110001

VNI: 910001

VLAN 2

VNI: 100002

VNI: 110002

VNI: 910002

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

Abbildung 4: Translationale VXLAN-Stitching-Zusammenfassung 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 zu einem gemeinsamen VNI-910001 für den Transport über das WAN 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 von 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 standardmäßigen EVPN-Parameter der Switch-Instanz für den Routenaustausch zwischen den beiden PODs. Diese Konfiguration umfasst die Unterstützung für eine aktive ESI-LAG zwischen den Gateways. Durch das Einrichten einer ESI-LAG über das WAN wird sichergestellt, dass alle WAN-Verbindungen aktiv für die Weiterleitung des Datenverkehrs 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 Gateway-Paar in jedem POD.

    Das Routenziel steuert Routenimporte. Sie konfigurieren dasselbe Routenziel auf allen Gateway-Geräten, um sicherzustellen, dass alle Routen, die von einem POD angekündigt werden, 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 über das WAN in der Hierarchie [edit protocols evpn interconnect interconnected-vni-list] zusammengefügt 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 translationalen VNI verknüpfen. Beachten Sie, dass der Wert für den translationalen 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 translatorische Anweisung einfach weg und konfigurieren das Benutzer-VLAN so, dass es denselben VNI-Wert verwendet, den Sie in der Hierarchie [edit protocols evpn interconnect interconnected-vni-list] konfigurieren.

    Denken Sie daran, dass die Leaf- und Spine-Geräte in jedem Pod bereits für die CRB-Referenzarchitektur konfiguriert sind. Als Teil der bereits vorhandenen Konfiguration werden VLANs sowohl auf den Spine- als auch auf den Leaf-Geräten definiert. Die VLAN-Definition auf allen Geräten enthält eine VLAN-ID-zu-VXLAN-VNNI-Zuordnung. Die VLAN-Konfiguration des Spines unterscheidet sich jedoch von der des Leafs dadurch, dass sie die Layer-3-IRB-Schnittstelle enthält, was wiederum ein Beispiel für CRB ist. Die vorhandene Konfiguration für VLAN 1 wird auf dem Gateway 1 (Spine 1)-Gerät 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 Hierarchie edit protocols evpn interconnect interconnected-vni-list 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 über das WAN gesendet wird. Im Remote-POD wird eine ähnliche Konfiguration vom WAN-VNI zurück dem lokalen VNI zugeordnet, das 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, um das translationale VXLAN-Stitching von VNI-100002 (lokal in POD 1 für VLAN 2 verwendet) zu VNI-910002 über das WAN aufzurufen.

  5. Bestätigen Sie die Änderung für VLAN 1. VLAN 2 wird der Kürze halber weggelassen. Der folgende Befehl zeigt den Wechsel 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 das Overlay erweitert haben, führen die folgenden Konfigurationen ein translationales VXLAN-Stitching zwischen dem VNI des lokalen PODs 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 translationalen 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 wird angezeigt all-active) und sowohl als Backup forwarder auch Designated forwarder 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 Gateway 1-Gerät für VXLAN VNI 100001 an. Denken Sie daran, dass dies in unserem Beispiel der VNI ist, 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, angekündigt und im lokalen POD 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 angekündigt wird. Dies bestätigt, dass VNI 910001 über das WAN verwendet wird. Da sich der lokale VNI von dem im WAN verwendeten VNI unterscheidet, bestätigt dies das translationale VXLAN-Stitching für den Standardanwendungsfall der Switch-Instanz.

VXLAN-Stitching in einer MAC-VRF-Routinginstanz

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

Die Abdeckung von MAC-VRF-Routing-Instanzen würde den Rahmen dieses Dokuments sprengen. Auch hier gehen wir davon aus, dass Sie über eine funktionierende CRB-Fabric mit MAC-VRF-Instanzen verfügen, die gemäß der Referenz-Baseline konfiguriert sind. Weitere Informationen zur Konfiguration von MAC-VRF finden Sie unter Übersicht über den MAC-VRF-Routing-Instance-Typ und einen 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 VLAN-zu-VNI-Zuordnung jedoch in der MAC-VRF-Instanz und nicht in der Hierarchie [edit vlans] . Ein weiterer Unterschied im MAC-VRF-Fall besteht darin, dass Sie die interconnected-vni-list Anweisung in der Routinginstanz und nicht in der Hierarchie [edit protocols evpn interconnect interconnected-vni-list] konfigurieren.

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

Sie fügen den Gateway-Geräten für die MAC-VRF-Instanz, die das Stitching durchführt, die folgenden Befehle hinzu. 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 Gerät von Gateway 1 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.

Hinweis:

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 mit Junos OS einschließen. 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 mit Junos OS mit VXLAN-Stitching in MAC-VRF-Routing-Instanzen zu verwenden.

Freigegebene 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, liegt eine vollständige Konfiguration der MAC-VRF-Routing-Instanz außerhalb unseres Umfangs. 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 auch ein Gateway in unserer Beispieltopologie für ein reduziertes Gateway ist. Der Kürze halber zeigen wir nur die Konfiguration für VLAN 1201 an.

Im obigen Beispiel spezifiziert die MAC-VRF-Definition für VLAN 1201 denselben VNI (401201), 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) Bedeutung für diesen VNI.

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

Um beispielsweise von einem lokalen VNI-300801 für VLAN 801 in einen 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 das WAN von lokalem 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 zur Unterstützung von VXLAN-Stitching im globalen Modus in einem MAC-VRF-Kontext. Sie fügen hinzu, dass dieses Delta der CRB-Baseline hinzugefügt wird, die Sie für DCI über das WAN geändert haben. Nachdem Sie das Underlay und die Überlagerung 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 VLAN- und Interconnect-VNI-Werte sind identisch.

Gateway 1 (POD 1)

Gateway 2 (Pod 1)

Gateway 3 (POD 2)

Gateway 4 (POD 2)

Hinweis:

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 Switch-Reihe einschließen. Nachdem Sie diese Anweisung hinzugefügt haben, müssen Sie den Switch neu starten. Es wird nicht empfohlen, die Shared Tunnel-Anweisung auf Gateway-Knoten in der QFX10000-Reihe von Switches mit Junos OS mit VXLAN-Stitching in MAC-VRF-Routing-Instanzen zu konfigurieren.

Freigegebene 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 und im Aktiv-Aktiv-Modus ist.

    Die Ausgabe zeigt, dass ESI 00:00:ff:ff:00:11:00:00:00:01 betriebsbereit ist. Die Aktiv-Aktiv-Weiterleitung wird durch den all-active Modus und das Vorhandensein sowohl einer designierten als auch einer Backup-Weiterleitung ü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 Gateway 1-Gerät für VXLAN VNI 401201 für Ankündigungen im WAN an. In unserem Beispiel ist dies der VNI, der VLAN 1201 in beiden PODs zugewiesen ist. Da es sich um ein CRB-Beispiel handelt, haben Sie VLAN 1201 auf den Spines und auf den Leaf-Geräten definiert. Allerdings enthalten nur die Spine-Geräte die Layer-3-IRB-Schnittstellen in ihren VLAN-Konfigurationen.

    Die Ausgabe bestätigt, dass der VNI-Wert 401201, der VLAN 1201 und der irb.1201-Schnittstelle zugeordnet ist, dem Remote-POD angekündigt wird. Dies bestätigt, dass VNI 401201 über das WAN für VLAN 1201 verwendet wird.

  4. Zeigen Sie die EVPN-Datenbank auf dem Gateway-1-Gerät für VXLAN-VNI-401201 an, um Ankündigungen für den lokalen POD zu erhalten. Denken Sie daran, dass dies der VNI ist, 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 Remotegateways anzuzeigen.

    Die Ausgabe zeigt, dass VNI-401201 dem lokalen POD angekündigt wird. Dies bestätigt, dass VNI 401201 lokal verwendet wird. Wenn derselbe VNI lokal und im gesamten WAN verwendet wird, bestätigt dies globales VXLAN-Stitching in einem MAC-VRF-Fall.

Optimierung des Datenverkehrs virtueller Maschinen (VMTO) mit VXLAN-Stitching

In einigen Umgebungen kann es sinnvoll sein, /32- oder /128-Hostrouten zu installieren, um den Datenverkehr zu einer bestimmten VM zu optimieren. Wenn Sie VXLAN-Stitching verwenden, konfigurieren Sie auf allen Gatewayknoten Folgendes, um die Installation von Hostrouten zu ermöglichen.

Der erste Befehl fügt der Standard-Switch-Instanz Unterstützung für Host-Routen hinzu. Die zweite fügt Host-Route-Unterstü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 Unterstützung von Hostrouten

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 Bitprä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.