Erstellen eines Nexus 9000 VXLAN Multisite TRM mit DCNM

Einführung

In diesem Dokument wird erläutert, wie eine Cisco Nexus 9000 VXLAN Multisite TRM-Fabric bereitgestellt wird, in der Border Gateways über DCI-Switches verbunden sind.

Topologie

Details der Topologie

• DC1 und DC2 sind zwei Rechenzentrumsstandorte, auf denen VXLAN ausgeführt wird.
• Die RZ1- und RZ2-Border Gateways werden über DCI-Switches miteinander verbunden.
• Auf den DCI-Switches wird kein VXLAN ausgeführt. Auf diesen wird eBGP für das Underlay ausgeführt, um die Erreichbarkeit von DC1 bis DC2 und umgekehrt zu gewährleisten. Die DCI-Switches sind auch mit dem Tenant-VRF konfiguriert. In diesem Beispiel wäre dies "vrf-Tenant-1".
• DCI-Switches sind auch mit externen Netzwerken verbunden, die nicht VXLAN sind.
• VRFLITE-Verbindungen werden an Border Gateways terminiert(Unterstützung der Koexistenz von VRFLITE- und Border Gateway-Funktionen, gestartet von NXOS-9.3(3) und DCNM-11.3(1))
• Grenz-Gateways werden im Anycast-Modus ausgeführt. Wenn auf dieser Version TRM(Tenant Routed Multicast) ausgeführt wird, können Border Gateways nicht als vPC konfiguriert werden (weitere Einschränkungen finden Sie im Multisite TRM Configuration Guide)
• Für diese Topologie verfügen alle BGW-Switches über zwei physische Verbindungen zu jedem der DCI-Switches. Eine Verbindung ist das Standard-VRF (das für den standortübergreifenden Datenverkehr verwendet wird), die andere Verbindung befindet sich im VRF-Tenant-1, der verwendet wird, um VRFLITE auf die Nicht-VXLAN-Umgebung auszudehnen.

PIM/Multicast-Details(TRM-spezifisch)

• Der zugrunde liegende PIM-RP für beide Standorte sind die Spine-Switches, und Loopback254 ist für dasselbe konfiguriert. Underlay PIM RP wird verwendet, damit die VTEPs PIM-Registrierungen sowie PIM-Joins an die Spines senden können (für die Zwecke der BUM-Datenreplikation für verschiedene VNIDs)
• Für TRM kann der RP auf verschiedene Weise angegeben werden. Für die Zwecke dieses Dokuments ist PIM RP der Core-Router an der Spitze der Topologie, der sich außerhalb der VXLAN-Fabric befindet. 
• Bei allen VTEPs wird der Core-Router als PIM RP in den entsprechenden VRFs konfiguriert.
• DC1-Host1 sendet Multicast an die Gruppe 239.144.144.144. DC2-Host1 ist der Empfänger für diese Gruppe in DC2, und ein Host External(172.17.100.100) für die VXLAN-Gruppe ist ebenfalls für diese Gruppe verantwortlich
• DC2-Host1 sendet Multicast an die Gruppe 239.145.145.145. DC1-Host1 ist der Empfänger für diese Gruppe in DC1, und ein Host External(172.17.100.100) für die VXLAN-Gruppe ist ebenfalls für diese Gruppe verantwortlich
• DC2-Host2 befindet sich im VLAN 144 und ist Empfänger für Multicast-Gruppen - 239.144.144.144 und 239.100.100.100.
• Der externe Host (172.17.100.100) sendet Datenverkehr, für den sowohl DC1-Host1 als auch DC2-Host1 Empfänger sind.
• Dies umfasst die Multicast-Datenverkehrsflüsse Ost-West-Inter und Intra-VLAN sowie Nord-Süd.

Verwendete Komponenten

• Nexus 9000-Switches mit 9.3(3)
• DCNM mit 11.3(1)

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

High Level Steps

1) Da dieses Dokument auf zwei Rechenzentren basiert, die VXLAN Multisite-Funktion verwenden, müssen zwei Easy Fabrics erstellt werden.

2) MSD erstellen und RZ1 und RZ2 verschieben

3) Erstellen einer externen Fabric und Hinzufügen von DCI-Switches

4) Multisite-Underlay und Overlay erstellen

5) Erstellen von VRF-Extension-Anhängen an Border Gateways

6) Überprüfung von Unicast-Datenverkehr

7) Überprüfung des Multicast-Datenverkehrs

Schritt 1: Erstellung von Easy Fabric für DC1

• Melden Sie sich bei DCNM und im Dashboard an, und wählen Sie die Option "Fabric Builder" aus.

• Wählen Sie die Option Create Fabric (Fabric erstellen).

• Geben Sie als Nächstes den Fabric-Namen, die Vorlage und dann unter der Registerkarte "Allgemein" das entsprechende ASN, die Fabric-Schnittstellennummerierung, Any Cast Gateway MAC (AGM) ein.

# AGM wird von Hosts in der Fabric als MAC-Adresse des Standard-Gateways verwendet. Dies ist bei allen Leaf-Switches gleich (da alle Leaf-Switches in der Fabric Anycast Fabric Forwarding ausführen). Die IP-Adresse des Standard-Gateways und die MAC-Adresse sind für alle Leaf-Switches identisch.

• Als Nächstes wird der Replikationsmodus festgelegt.

# Der Replikationsmodus für dieses Dokument ist Multicast. Eine weitere Option ist die Verwendung der Ingress Replication (IR).

# Multicast Group Subnet ist die Multicast-Gruppe, die von VTEPs zur Replikation von BUM-Datenverkehr verwendet wird (wie ARP-Anfragen).

# Aktivieren Sie das Kontrollkästchen "Enable Tenant Routed Multicast (TRM) aktivieren".

# Füllen Sie bei Bedarf andere Felder aus.

• Die Registerkarte für vPC bleibt unberührt, da in der Topologie kein vPC verwendet wird.
• Weiter geht es zur Registerkarte Protokolle

# Ändern Sie die relevanten Felder nach Bedarf.

• Weiter: Registerkarte Erweitert

# Für dieses Dokument werden alle Felder standardmäßig belassen.

# Das ASN wird automatisch von dem auf der Registerkarte "Allgemein" bereitgestellten ASN übernommen.

• Als Nächstes füllen Sie die Felder auf der Registerkarte "Ressourcen" aus.

# Der IP-Bereich für Underlay Routing Loopback entspricht dem für Protokolle wie BGP, OSPF

# Der zugrunde liegende VTEP-Loopback-IP-Bereich wird für die NVE-Schnittstelle verwendet.

# Underlay RP ist für den PIM RP, der für BUM-Multicast-Gruppen verwendet wird.

• Füllen Sie andere Registerkarten mit den relevanten Informationen aus, und speichern Sie sie anschließend.

Schritt 2: Erstellung von Easy Fabric für DC2

• Führen Sie die gleiche Aufgabe wie in Schritt 1 durch, um eine Easy Fabric für DC2 zu erstellen.
• Stellen Sie sicher, dass Sie unter Ressourcen für NVE- und Routing-Loopbacks und andere relevante Bereiche einen anderen IP-Adressblock angeben.
• ASNs sollten ebenfalls unterschiedlich sein.
• Layer-2- und Layer-2-VNIDs sind identisch.

Schritt 3: Erstellung von MSD für mehrere Standorte

• Eine MSD-Fabric muss wie unten gezeigt erstellt werden.

• Füllen Sie auch die Registerkarte "DCI" aus. 

# Die Overlay IFC Deployment-Methode für mehrere Standorte ist "Direct_To_BGWS", da DC1-BGWs die Overlay-Verbindung mit den DC2-BGWs bilden. Die in der Topologie gezeigten DCI-Switches sind lediglich Transit-Layer-3-Geräte (sowie VRFLITE).

• Im nächsten Schritt wird der Multisite Loopback Range (Multisite-Loopback-Bereich) erwähnt. Diese IP-Adresse wird als Multisite Loopback-IP für DC1- und DC2-BGWs verwendet. DC1-BGW1 und DC1-BGW2 verwenden dieselbe Loopback-IP für mehrere Standorte. DC2-BGW1 und DC2-BGW2 verwenden dieselbe Multisite-Loopback-IP, unterscheiden sich jedoch von der DC1-BGWs.

# Wenn die Felder ausgefüllt sind, klicken Sie auf "Speichern".

# Sobald die Schritte 1 bis 3 abgeschlossen sind, sieht die Fabric-Builder-Seite wie unten aus.

Schritt 4: Migration von RZ1- und RZ2-Fabrics zu Multisite MSD

# In diesem Schritt werden die DC1- und DC2-Fabrics auf Multisite-MSD verschoben, die in Schritt 3 erstellt wurde. Im Folgenden finden Sie Screenshots, wie Sie dasselbe erreichen können.

# Wählen Sie die MSD, klicken Sie auf "move Fabrics" (Fabrics verschieben), und wählen Sie dann "DC1 and DC2 one by one" (Gleichstrom1 und Gleichstrom2 einzeln verschieben) und dann "Add" (Hinzufügen) aus.

# Sobald beide Stoffe verschoben wurden, würde die Startseite wie folgt aussehen:

# Multisite-MSD zeigt DC1 und DC2 als Mitglieder-Fabrics an

Schritt 5: Erstellung von VRFs

# Das Erstellen von VRFs kann über MSD Fabric erfolgen, die für beide Fabrics gilt. Unten finden Sie die Screenshots, um dasselbe zu erreichen.

# Geben Sie auch die Registerkarte "Erweitert" und dann "Erstellen" ein.

Schritt 6: Netzwerkerstellung

# Erstellen von VLANs und entsprechenden VNIDs, SVIs können aus MSD Fabric ausgeführt werden, die für beide Fabrics gilt.

# Aktivieren Sie auf der Registerkarte "Erweitert" das Kontrollkästchen, wenn die BGWs das Gateway für Netzwerke sein müssen.

# Wenn alle Felder ausgefüllt sind, klicken Sie auf "Netzwerk erstellen".

# Wiederholen Sie die gleichen Schritte für alle anderen VLANs/Netzwerke

Schritt 7: Erstellung einer externen Fabric für die DCI-Switches

# In diesem Beispiel werden die DCI-Switches berücksichtigt, die sich im Paketpfad von DC1 bis DC2 befinden (was die standortübergreifende Kommunikation betrifft). Dies wird häufig beobachtet, wenn mehr als 2 Fabrics vorhanden sind. 

# Die externe Fabric umfasst die beiden DCI-Switches, die sich oben in der Topologie befinden, die zu Beginn dieses Dokuments gezeigt wurde.

# Erstellen Sie die Fabric mit der "externen" Vorlage, und geben Sie das ASN an.

# Ändern Sie alle anderen relevanten Felder für die Bereitstellung

Schritt 8: Hinzufügen von Switches zu jeder Fabric

# Hier werden alle Switches pro Fabric dem jeweiligen Fabric hinzugefügt.

Die Vorgehensweise zum Hinzufügen von Switches ist in den folgenden Screenshots dargestellt.

# Wenn "Konfig. beibehalten" "Nein" ist; alle vorhandenen Switch-Konfigurationen werden gelöscht. Exception ist der Hostname, die Boot-Variable, die MGMT0-IP-Adresse, die Route in der VRF-Kontextverwaltung.

# Legen Sie die Rollen auf Switches richtig fest (durch Klicken mit der rechten Maustaste auf den Switch, Rolle festlegen und dann relevante Rolle)

# Ordnen Sie auch das Switch-Layout dementsprechend an, und klicken Sie dann auf "Layout speichern".

Schritt 9: TRM-Einstellungen für einzelne Fabrics

• Im nächsten Schritt aktivieren Sie die TRM-Kontrollkästchen für die einzelnen Fabrics.

# Führen Sie diesen Schritt für alle Netzwerke für alle Fabrics durch.

• Anschließend müssen VRFs in einzelnen Fabrics ebenfalls einige Änderungen vornehmen und wie unten beschrieben weitere Informationen hinzufügen.

# Dies muss in DC1 und DC2 sowie für den VRF-Abschnitt erfolgen.

# Beachten Sie, dass die Multicast-Gruppe für VRF-> 239.1.2.100 manuell von der automatisch ausgefüllten geändert wurde. Best Practice ist die Verwendung einer anderen Gruppe für das Layer-3-VNI-VRF und für alle Multicast-Gruppen von L2-VNI-VLANs im BUM-Datenverkehr.

Schritt 10: VRFLITE-Konfiguration auf Border Gateways

# Ab NXOS 9.3(3) und DCNM 11.3(1) können Border Gateways als Border Gateways und VRFLITE-Konnektivitätspunkt fungieren (wodurch das Border Gateway über eine VRFLITE-Nachbarschaft mit einem externen Router verfügt und externe Geräte mit den Geräten in der Fabric kommunizieren können)

# Für die Zwecke dieses Dokuments bilden die Grenz-Gateways die VRFLITE-Nachbarschaft zum DCI-Router, der nördlich der oben gezeigten Topologie liegt. 

# Eine Anmerkung: VRFLITE- und Multisite Underlay-Links dürfen nicht dieselben physischen Links sein. Es müssen separate Links erstellt werden, um das Multisite Underlay und das VRF-Format zu bilden.

# Die folgenden Screenshots zeigen, wie Sie sowohl VRF LITE- als auch Multi-Site-Erweiterungen auf Border Gateways erreichen können.

# Wechseln zur "Tabellenansicht"

# Wechseln Sie zur Registerkarte "Links", und fügen Sie dann eine "VRFLITE-übergreifende" Verbindung hinzu. Die Source-Fabric muss als DC1 und die Ziel-Fabric als DCI angegeben werden.

# Wählen Sie die richtige Schnittstelle für die Quellschnittstelle aus, die zum richtigen DCI-Switch führt.

# unter Link-Profil, geben Sie die lokalen und Remote-IP-Adressen an

# Aktivieren Sie außerdem das Kontrollkästchen "auto deploy flag", sodass die Konfiguration der DCI-Switches für VRFLITE ebenfalls automatisch eingetragen wird (dies wird in einem späteren Schritt durchgeführt).

Anzahl der automatisch ausgefüllten ASNs

# Wenn alle Felder mit den richtigen Informationen ausgefüllt sind, klicken Sie auf die Schaltfläche "Speichern".

• Der obige Schritt muss für alle BGW-DCI-Verbindungen auf allen vier Border Gateways zu den beiden DCI-Switches ausgeführt werden.
• In Anbetracht der Topologie dieses Dokuments gibt es insgesamt 8 VRF-LITE-Verbindungen zwischen den Fabrics, die wie unten dargestellt aussehen.

Schritt 11: Underlay-Konfiguration für mehrere Standorte auf Border Gateways

# Der nächste Schritt besteht in der Konfiguration des Multisite Underlay auf jedem Border Gateway in jeder Fabric.

# Hierfür sind separate physische Verbindungen von BGWs zu DCI-Switches erforderlich. Die Links, die in Schritt 10 für VRFLITE verwendet wurden, können nicht für das Overlay an mehreren Standorten verwendet werden.

# Diese Schnittstellen sind Teil von "default vrf", anders als die vorherige, wo die Schnittstellen Teil von Tenant-VRF sind (in diesem Beispiel ist es Tenant-1)

# Mithilfe der unten stehenden Screenshots können Sie die Schritte für diese Konfiguration durchgehen.

# Der gleiche Schritt muss für alle Verbindungen von BGWs zu DCI-Switches ausgeführt werden.

# Am Ende werden insgesamt acht Multi-Site-Underlay-Verbindungen zwischen Fabrics wie unten dargestellt.

Schritt 12: Overlay-Einstellungen für mehrere Standorte für TRM

# Wenn Multisite Underlay abgeschlossen ist, werden die Overlay-Schnittstellen/-Links für mehrere Standorte automatisch ausgefüllt und können in der tabellarischen Ansicht unter Links in der MSD-Fabric für mehrere Standorte angezeigt werden.

# Standardmäßig bildet das Multisite-Overlay nur die bgp l2vpn-Ereignisumgebung von jedem Standort BGWs zum anderen, die für die Unicast-Kommunikation zwischen Standorten erforderlich ist. Wenn jedoch Multicast zwischen den Standorten ausgeführt werden muss (die über die Funktion für mehrere Standorte von vxlan verbunden sind), muss das Kontrollkästchen TRM aktiviert werden, wie unten für alle Overlay-Schnittstellen in MSD Fabric für mehrere Standorte dargestellt. Screenshots zeigen, wie das funktioniert.

Schritt 13: Speichern/Bereitstellen in MSD und individuellen Fabrics

# Führen Sie eine Speicherung/Bereitstellung durch, die relevante Konfigurationen gemäß den oben beschriebenen Schritten weiterleitet.

# Bei der Auswahl von MSD sind die Konfigurationen, die gedrückt werden, nur für die Border Gateways anwendbar.

# Daher ist es erforderlich, die einzelnen Fabrics zu speichern/bereitzustellen, um die entsprechenden Konfigurationen auf alle regulären Leaf-Switches/VTEPs zu übertragen.

Schritt 14: VRF-Extension-Anhänge für MSD

# Wählen Sie das MSD aus, und gehen Sie zum VRF-Abschnitt

# Bitte beachten Sie, dass die Erweiterungs-Option wie in diesem Dokument "MULTISITE+VRF_LITE" lauten muss. Border Gateway-Funktionalität und VRFLITE sind in die Border Gateway-Switches integriert.

# AUTO_VRF_LITE wird auf true festgelegt.

# Der PEER-VRF-NAME muss manuell für alle 8 VRF-Instanzen eingegeben werden, wie unten von den BGWs zu den DCI-Switches gezeigt. (Hier wird der gleiche VRF-NAME für DCI-Switches verwendet.)

# Klicken Sie abschließend auf "Speichern".

# Beim Erstellen von VRF-Erweiterungen verfügen nur die Boder-Gateways über zusätzliche Konfigurationen für die VRFLITE DCI-Switches.

# Daher muss das reguläre Leaf separat ausgewählt werden, und klicken Sie dann auf die "Kontrollkästchen" für die einzelnen Tenant-VRFs, wie oben gezeigt.

# Klicken Sie auf Bereitstellen, um die Konfigurationen zu verschieben.

Schritt 15: Versenden von Netzwerkkonfigurationen auf die Fabric von MSD

# Wählen Sie die relevanten Netzwerke in MSD Fabric aus. 

# Beachten Sie, dass derzeit nur die Border Gateways ausgewählt sind. Führen Sie den gleichen Vorgang aus, und wählen Sie in diesem Fall die regulären Leaf-Switches/VTEPs-> DC1-VTEP und DC2-VTEP aus.

# Klicken Sie abschließend auf "Bereitstellen" (wodurch Konfigurationen auf alle 6 Switches oben übertragen werden).

Schritt 16: Überprüfung von VRF und Netzwerken auf allen VRFs

# Mit diesem Schritt wird überprüft, ob VRF und Netzwerke in allen Fabrics als "bereitgestellt" angezeigt werden. Wenn der Status als ausstehend angezeigt wird, stellen Sie sicher, dass Sie die Konfigurationen "bereitstellen".

Schritt 17: Bereitstellen von Konfigurationen auf einer externen Fabric

# Dieser Schritt ist erforderlich, um alle relevanten IP-Adressen-, BGP- und VRFLITE-Konfigurationen an die DCI-Switches weiterzuleiten.

# Wählen Sie dazu die externe Fabric aus, und klicken Sie auf "Speichern und Bereitstellen".

DCI-1# sh ip bgp sum
BGP summary information for VRF default, address family IPv4 Unicast
BGP router identifier 10.10.100.1, local AS number 65001
BGP table version is 173, IPv4 Unicast config peers 4, capable peers 4
22 network entries and 28 paths using 6000 bytes of memory
BGP attribute entries [3/504], BGP AS path entries [2/12]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.4.10.1       4 65000      11      10      173    0    0 00:04:42 5         
10.4.10.9       4 65000      11      10      173    0    0 00:04:46 5         
10.4.20.37      4 65002      11      10      173    0    0 00:04:48 5         
10.4.20.49      4 65002      11      10      173    0    0 00:04:44 5         
DCI-1# sh ip bgp sum vrf tenant-1
BGP summary information for VRF tenant-1, address family IPv4 Unicast
BGP router identifier 10.33.10.2, local AS number 65001
BGP table version is 14, IPv4 Unicast config peers 4, capable peers 4
2 network entries and 8 paths using 1200 bytes of memory
BGP attribute entries [2/336], BGP AS path entries [2/12]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.33.10.1      4 65000       8      10       14    0    0 00:01:41 2         
10.33.10.9      4 65000      10      11       14    0    0 00:03:16 2         
10.33.20.1      4 65002      11      10       14    0    0 00:04:40 2         
10.33.20.9      4 65002      11      10       14    0    0 00:04:39 2    

DCI-2# sh ip bgp sum
BGP summary information for VRF default, address family IPv4 Unicast
BGP router identifier 10.10.100.2, local AS number 65001
BGP table version is 160, IPv4 Unicast config peers 4, capable peers 4
22 network entries and 28 paths using 6000 bytes of memory
BGP attribute entries [3/504], BGP AS path entries [2/12]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.4.10.5       4 65000      12      11      160    0    0 00:05:10 5         
10.4.10.13      4 65000      12      11      160    0    0 00:05:11 5         
10.4.20.45      4 65002      12      11      160    0    0 00:05:10 5         
10.4.20.53      4 65002      12      11      160    0    0 00:05:07 5         
DCI-2# sh ip bgp sum vrf tenant-1 
BGP summary information for VRF tenant-1, address family IPv4 Unicast
BGP router identifier 10.33.10.6, local AS number 65001
BGP table version is 14, IPv4 Unicast config peers 4, capable peers 4
2 network entries and 8 paths using 1200 bytes of memory
BGP attribute entries [2/336], BGP AS path entries [2/12]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.33.10.5      4 65000      10      11       14    0    0 00:03:28 2         
10.33.10.13     4 65000      11      11       14    0    0 00:04:30 2         
10.33.20.5      4 65002      12      11       14    0    0 00:05:05 2         
10.33.20.13     4 65002      12      11       14    0    0 00:05:03 2     

# Nach der Bereitstellung sehen wir 4 IPv4-BGP-Nachbarschaften von jedem DCI-Switch zu allen BGWs und 4 IPv4-VRF-BGP-Nachbarschaften (dies ist für die Tenant-VRF-EX-Spannung vorgesehen).

Schritt 18: Konfigurieren von iBGP zwischen DCI-Switches

# Da die DCI-Switches über Verbindungen miteinander verbunden sind, ist eine iBGP-IPv4-Nachbarschaft ideal, sodass bei Downstream-Verbindungen auf dem DCI-1-Switch der Nord-Süd-Datenverkehr weiterhin über DCI-2 weitergeleitet werden kann.

# Hierfür ist eine iBGP IPv4-Nachbarschaft zwischen DCI-Switches erforderlich, die auf beiden Seiten auch Next-Hop-Self verwendet. 

# Um dies zu erreichen, muss auf DCI-Switches eine Freeform gestartet werden. Nachfolgend sind die erforderlichen Konfigurationsreihen aufgeführt.

# DCI-Switches in der oben genannten Topologie werden in vPC konfiguriert; Die Backup-SVI kann also zum Erstellen der iBGP-Nachbarschaften verwendet werden.

# Wählen Sie die DCI-Fabric aus, und klicken Sie mit der rechten Maustaste auf jeden Switch und "View/Edit Policies" (Richtlinien anzeigen/bearbeiten).

# Gleiche Änderung am DCI-2-Switch und dann "Save&Deploy" zum Übertragen der eigentlichen Konfigurationen an die DCI-Switches

# Anschließend kann die CLI-Verifizierung mit dem folgenden Befehl durchgeführt werden.

DCI-2# sh ip bgp sum
BGP summary information for VRF default, address family IPv4 Unicast
BGP router identifier 10.10.100.2, local AS number 65001
BGP table version is 187, IPv4 Unicast config peers 5, capable peers 5
24 network entries and 46 paths using 8400 bytes of memory
BGP attribute entries [6/1008], BGP AS path entries [2/12]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.4.10.5       4 65000    1206    1204      187    0    0 19:59:17 5         
10.4.10.13      4 65000    1206    1204      187    0    0 19:59:19 5         
10.4.20.45      4 65002    1206    1204      187    0    0 19:59:17 5         
10.4.20.53      4 65002    1206    1204      187    0    0 19:59:14 5         
10.10.8.1       4 65001      12       7      187    0    0 00:00:12 18    # iBGP neighborship from DCI-2 to DCI-1

Schritt 19: Verifizierung von IGP/BGP-Nachbarschaften

OSPF-Nachbarschaften

# Da alle Underlay IGP in diesem Beispiel OSPF sind, bilden alle VTEPs eine OSPF-Nachbarschaft zu den Spines. Dies schließt auch die BGW-Switches an einem Standort ein.

DC1-SPINE# show ip ospf neighbors 
 OSPF Process ID UNDERLAY VRF default
 Total number of neighbors: 3
 Neighbor ID     Pri State            Up Time  Address         Interface
 10.10.10.3        1 FULL/ -          1d01h    10.10.10.3      Eth1/1     # DC1-Spine to DC1-VTEP
 10.10.10.2        1 FULL/ -          1d01h    10.10.10.2      Eth1/2     # DC1-Spine to DC1-BGW2
 10.10.10.1        1 FULL/ -          1d01h    10.10.10.1      Eth1/3     # DC1-Spine to DC1-BGW1

# Alle Loopbacks (BGP Router IDs, NVE Loopbacks) werden in OSPF angekündigt. Daher werden alle Loopbacks innerhalb einer Fabric über das OSPF-Routing-Protokoll erfasst, was bei der weiteren Ausgestaltung der l2vpn-Ereignisumgebung hilfreich wäre.

BGP-Nachbarschaften

# Innerhalb einer Fabric umfasst diese Topologie l2vpn-sogar-Nachbarschaften von Spines zu den regulären VTEPs und auch zu Border Gateways.

DC1-SPINE# show  bgp l2vpn evpn sum
BGP summary information for VRF default, address family L2VPN EVPN
BGP router identifier 10.10.10.4, local AS number 65000
BGP table version is 80, L2VPN EVPN config peers 3, capable peers 3
22 network entries and 22 paths using 5280 bytes of memory
BGP attribute entries [14/2352], BGP AS path entries [1/6]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.10.1      4 65000    1584    1560       80    0    0    1d01h 10        # DC1-Spine to DC1-BGW1
10.10.10.2      4 65000    1565    1555       80    0    0    1d01h 10        # DC1-Spine to DC1-BGW2
10.10.10.3      4 65000    1550    1554       80    0    0    1d01h 2         # DC1-Spine to DC1-VTEP

# Angesichts der Tatsache, dass es sich um eine Bereitstellung an mehreren Standorten mit Border Gateways handelt, die von einem Standort zu einem anderen mithilfe des eBGP l2vpn-Ereignisses Peering aufnehmen, kann dies mit dem folgenden Befehl auf einem Border Gateway-Switch überprüft werden.

DC1-BGW1# show  bgp l2vpn evpn sum
BGP summary information for VRF default, address family L2VPN EVPN
BGP router identifier 10.10.10.1, local AS number 65000
BGP table version is 156, L2VPN EVPN config peers 3, capable peers 3
45 network entries and 60 paths using 9480 bytes of memory
BGP attribute entries [47/7896], BGP AS path entries [1/6]
BGP community entries [0/0], BGP clusterlist entries [2/8]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.10.4      4 65000    1634    1560      156    0    0    1d01h 8       # DC1-BGW1 to DC1-SPINE  
10.10.20.3      4 65002    1258    1218      156    0    0 20:08:03 9       # DC1-BGW1 to DC2-BGW1  
10.10.20.4      4 65002    1258    1217      156    0    0 20:07:29 9       # DC1-BGW1 to DC2-BGW2  

Neighbor        T    AS PfxRcd     Type-2     Type-3     Type-4     Type-5    
10.10.10.4      I 65000 8          2          0          1          5         
10.10.20.3      E 65002 9          4          2          0          3         
10.10.20.4      E 65002 9          4          2          0          3     

BGP-MVPN-Nachbarschaften für TRM

# Wenn TRM-Konfigurationen vorhanden sind, bilden alle Leaf-Switches (einschließlich BGWs) die mvpn-Nachbarschaft zu den Spines.

DC1-SPINE# show bgp ipv4 mvpn summary
BGP summary information for VRF default, address family IPv4 MVPN
BGP router identifier 10.10.10.4, local AS number 65000
BGP table version is 20, IPv4 MVPN config peers 3, capable peers 3
0 network entries and 0 paths using 0 bytes of memory
BGP attribute entries [0/0], BGP AS path entries [0/0]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.10.1      4 65000    2596    2572       20    0    0    1d18h 0         
10.10.10.2      4 65000    2577    2567       20    0    0    1d18h 0         
10.10.10.3      4 65000    2562    2566       20    0    0    1d18h 0    

# Außerdem müssen die Border Gateways die mvpn-Nachbarschaft bilden, sodass der Ost-West-Multicast-Verkehr korrekt verläuft.

DC1-BGW1# show bgp ipv4 mvpn summary
BGP summary information for VRF default, address family IPv4 MVPN
BGP router identifier 10.10.10.1, local AS number 65000
BGP table version is 6, IPv4 MVPN config peers 3, capable peers 3
0 network entries and 0 paths using 0 bytes of memory
BGP attribute entries [0/0], BGP AS path entries [0/0]
BGP community entries [0/0], BGP clusterlist entries [2/8]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.10.4      4 65000    2645    2571        6    0    0    1d18h 0         
10.10.20.3      4 65002    2273    2233        6    0    0    1d12h 0         
10.10.20.4      4 65002    2273    2232        6    0    0    1d12h 0  

Schritt 20: Erstellung von Tenant-VRF-Loopbacks auf Border Gateway-Switches

# Erstellen Sie Loopbacks in Tenant-VRF mit eindeutigen IP-Adressen auf allen Border Gateways.

# Wählen Sie dazu DC1 aus, klicken Sie mit der rechten Maustaste auf DC1-BGW1, verwalten Sie Schnittstellen, und erstellen Sie dann Loopback, wie unten dargestellt.

# Derselbe Schritt muss auf anderen 3 Border Gateways durchgeführt werden.

Schritt 21: VRFLITE-Konfigurationen für DCI-Switches

# In dieser Topologie werden die DCI-Switches mit VRFLITE zu den BGWs konfiguriert. VRFLITE wird auch für die Nördlichen DCI-Switches konfiguriert (d. h. für die Core-Switches).

# Zu TRM-Zwecken befindet sich der PIM RP innerhalb des VRF-Tenant-1 im Core-Switch, der über VRFLITE mit den DCI-Switches verbunden ist.

# Diese Topologie weist eine IPv4-BGP-Nachbarschaft von DCI-Switches zum Core-Switch innerhalb des VRF-Tenant-1 auf, der sich oben im Diagramm befindet.

# Zu diesem Zweck werden Subschnittstellen erstellt und mit IP-Adressen zugewiesen, und auch BGP-Nachbarschaften werden eingerichtet (diese werden von der CLI direkt auf dem DCI und den Core Switches ausgeführt)

DCI-1# sh ip bgp sum vrf tenant-1 
BGP summary information for VRF tenant-1, address family IPv4 Unicast
BGP router identifier 10.33.10.2, local AS number 65001
BGP table version is 17, IPv4 Unicast config peers 5, capable peers 5
4 network entries and 10 paths using 1680 bytes of memory
BGP attribute entries [3/504], BGP AS path entries [3/18]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.33.10.1      4 65000    6366    6368       17    0    0    4d10h 2         
10.33.10.9      4 65000    6368    6369       17    0    0    4d10h 2         
10.33.20.1      4 65002    6369    6368       17    0    0    4d10h 2         
10.33.20.9      4 65002    6369    6368       17    0    0    4d10h 2         
172.16.111.2    4 65100      68      67       17    0    0 00:49:49 2  # This is towards the Core switch from DCI-1

# Oben rot ist der BGP-Nachbarn zum Core-Switch von DCI-1.

DCI-2# sh ip bgp sum vr tenant-1 
BGP summary information for VRF tenant-1, address family IPv4 Unicast
BGP router identifier 10.33.10.6, local AS number 65001
BGP table version is 17, IPv4 Unicast config peers 5, capable peers 5
4 network entries and 10 paths using 1680 bytes of memory
BGP attribute entries [3/504], BGP AS path entries [3/18]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.33.10.5      4 65000    6368    6369       17    0    0    4d10h 2         
10.33.10.13     4 65000    6369    6369       17    0    0    4d10h 2         
10.33.20.5      4 65002    6370    6369       17    0    0    4d10h 2         
10.33.20.13     4 65002    6370    6369       17    0    0    4d10h 2         
172.16.222.2    4 65100      53      52       17    0    0 00:46:12 2  # This is towards the Core switch from DCI-2

# Entsprechende BGP-Konfigurationen sind auch auf dem Core-Switch erforderlich (zurück zum DCI-1 und DCI-2)

Unicast-Verifizierungen

Ost/West von DC1-Host1 bis DC2-Host1

# Wenn alle oben genannten Konfigurationen von DCNM und manueller CLI (Schritte 1 bis 21) übertragen werden, sollte die Unicast-Erreichbarkeit Ost-West-Richtung sein.

DC1-Host1# ping 172.16.144.2 source 172.16.144.1
PING 172.16.144.2 (172.16.144.2) from 172.16.144.1: 56 data bytes
64 bytes from 172.16.144.2: icmp_seq=0 ttl=254 time=0.858 ms
64 bytes from 172.16.144.2: icmp_seq=1 ttl=254 time=0.456 ms
64 bytes from 172.16.144.2: icmp_seq=2 ttl=254 time=0.431 ms
64 bytes from 172.16.144.2: icmp_seq=3 ttl=254 time=0.454 ms
64 bytes from 172.16.144.2: icmp_seq=4 ttl=254 time=0.446 ms

--- 172.16.144.2 ping statistics ---
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 0.431/0.529/0.858 ms

Nord/Süd von DC1-Host1 zu PIM RP(10.200.200.100)

DC1-Host1# ping 10.200.200.100 source 172.16.144.1
PING 10.200.200.100 (10.200.200.100) from 172.16.144.1: 56 data bytes
64 bytes from 10.200.200.100: icmp_seq=0 ttl=250 time=0.879 ms
64 bytes from 10.200.200.100: icmp_seq=1 ttl=250 time=0.481 ms
64 bytes from 10.200.200.100: icmp_seq=2 ttl=250 time=0.483 ms
64 bytes from 10.200.200.100: icmp_seq=3 ttl=250 time=0.464 ms
64 bytes from 10.200.200.100: icmp_seq=4 ttl=250 time=0.485 ms

--- 10.200.200.100 ping statistics ---
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 0.464/0.558/0.879 ms

Multicast-Verifizierungen

Zu diesem Zweck wird der PIM-RP für die VRF-Instanz "Tenant-1" konfiguriert und extern für die VXLAN-Fabric bereitgestellt. Je nach Topologie wird der PIM RP auf dem Core-Switch mit der IP-Adresse konfiguriert -> 10.200.200.100

Quelle in Nicht-VXLAN (hinter Core-Switch), Empfänger in DC2

Siehe Topologie, die zu Beginn gezeigt wird.

# Nord/Süd-Multicast-Datenverkehr, der vom Nicht-VXLAN-Host stammt > 172.17.100.100; Empfänger ist in beiden Rechenzentren vorhanden; DC1-Host1-> 172.16.144.1 und DC2-Host1-> 172.16.144.2, Gruppe -> 239.100.100.100

Legacy-SW#ping 239.100.100.100 source 172.17.100.100 rep 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.100.100.100, timeout is 2 seconds:
Packet sent with a source address of 172.17.100.100

Reply to request 0 from 172.16.144.1, 3 ms
Reply to request 0 from 172.16.144.1, 3 ms
Reply to request 0 from 172.16.144.2, 3 ms
Reply to request 0 from 172.16.144.2, 3 ms

Quelle in DC1, Empfänger in DC2 sowie extern

DC1-Host1# ping multicast 239.144.144.144 interface vlan 144 vrf vlan144 cou 1
PING 239.144.144.144 (239.144.144.144): 56 data bytes
64 bytes from 172.16.144.2: icmp_seq=0 ttl=254 time=0.781 ms       # Receiver in DC2
64 bytes from 172.17.100.100: icmp_seq=0 ttl=249 time=2.355 ms     # External Receiver

--- 239.144.144.144 ping multicast statistics ---
1 packets transmitted,
From member 172.17.100.100: 1 packet received, 0.00% packet loss
From member 172.16.144.2: 1 packet received, 0.00% packet loss
--- in total, 2 group members responded ---

Quelle in DC2, Empfänger in DC1 sowie extern

DC2-Host1# ping multicast 239.145.145.145 interface vlan 144 vrf vlan144  cou 1
PING 239.145.145.145 (239.145.145.145): 56 data bytes
64 bytes from 172.16.144.1: icmp_seq=0 ttl=254 time=0.821 ms       # Receiver in DC1
64 bytes from 172.17.100.100: icmp_seq=0 ttl=248 time=2.043 ms     # External Receiver

--- 239.145.145.145 ping multicast statistics ---
1 packets transmitted,
From member 172.17.100.100: 1 packet received, 0.00% packet loss
From member 172.16.144.1: 1 packet received, 0.00% packet loss
--- in total, 2 group members responded ---