Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
AUF DIESER SEITE
 

Collapsed Spine Fabric Design und Implementierung

In Collapsed Spine Fabrics werden core EVPN-VXLAN-Overlay-Funktionen nur auf einer Spine-Schicht zusammengefasst. Es gibt keine Leaf-Layer; können die Spine-Geräte direkt mit vorhandenen Top-of-Rack-Switches (ToR) in der Zugriffsebene, die EVPN-VXLAN möglicherweise nicht unterstützen, anknnen.

TOR-Switches können zur Ausfallsicherheit auf Zugriffsebenen an mehr als ein Spine-Gerät multihomed werden, was die Spine-Geräte mit EVPN-Multihoming (auch ESI-LAG genannt) verwalten, genauso wie die Leaf-Geräte in anderen EVPN-VXLAN-Referenzarchitekturen. (Weitere Informationen finden Sie unter Multihoming an Ethernet-connected End System Design und Implementierung .)

Die Spine-Geräte übernehmen auch alle Randgeräterollen für die Konnektivität außerhalb des Datencenters.

Einige häufige Elemente in Anwendungsfällen für collapsed Spine-Architektur:

  • Collapsed Spine Fabric mit Back-to-Back-Spine-Geräten:

    In diesem Modell sind die Spine-Geräte mit Punkt-zu-Punkt-Verbindungen verbunden. Die Spine-Geräte richten BGP-Peering im Underlay ein und legen diese Links über ihre Loopback-Adressen über. Siehe Abbildung 1.

    Alternativ können die Collapsed Spine Core-Geräte mit einem Route Reflector-Cluster in einer Super-Spine-Schicht integriert werden, was später erläutert wird (unsere Referenzarchitektur).

  • Datencenter-Standorte, die mit Data Center Interconnect (DCI) verbunden sind:

    Die Spine-Geräte können Border-Gateway-Funktionen ausführen, um EVPN-Peering zwischen Datencentern einzurichten, einschließlich Layer-2-Stretch und Layer-3-Konnektivität, wie Abbildung 1 zeigt.

  • Eigenständige Switches oder Virtual Chassis auf der Zugriffsebene:

    Die ToR-Ebene kann eigenständige Switches oder Virtual Chassis multihomed mit den zusammengeklappten Spine-Geräten enthalten. Mit Virtual Chassis können Sie redundante Verbindungen in den ESI-LAGs zwischen den Spine-Geräten und verschiedenen Virtual Chassis-Member-Switches aufbauen, um die Ausfallsicherheit zu erhöhen. Siehe Abbildung 2.

Abbildung 1 zeigt eine logische Ansicht eines collapsed Spine-Datencenters mit Randkonnektivität, DCI zwischen Datencentern und Virtual Chassis im ToR-Layer, das multihomed mit den Spine-Geräten ist.

Abbildung 1: Collapsed Spine Data Center With Multihomed Virtual Chassis TOR Devices and Data Center Interconnect (Collapsed Spine Data Center Data Center With Multihomed Virtual Chassis TOR Devices and Data Center Interconnect Collapsed Spine Data Center With Multihomed Virtual Chassis TOR Devices and Data Center Interconnect)

Abbildung 2 veranschaulicht Virtual Chassis im ToR-Layer multihomed zu einer Back-to-Back-Collapsed-Spine-Schicht, auf der die Spine-Geräte mit verschiedenen Virtual Chassis-Member-Switches verbinden, um die ESI-LAG-Ausfallsicherheit zu verbessern.

Abbildung 2: Collapsed Spine-Design mit Back-to-Back-Spine-Geräten und Multihomed Virtual Chassis in ToR-Layer Collapsed Spine Design With Back-to-Back Spine Devices and Multihomed Virtual Chassis in ToR Layer

Lesen Sie Collapsed Spine mit EVPN Multihoming, ein Beispiel für die Netzwerkkonfiguration, das einen häufigen Collapsed Spine-Anwendungsfall bei Back-to-Back-Spine-Geräten beschreibt. In diesem Beispiel handelt es sich bei den ToR-Geräten um Virtual Chassis, die multihomed mit den zusammengeklappten Spine-Geräten sind. Das Beispiel umfasst die Konfiguration zusätzlicher Sicherheitsservices mit einem SRX-Chassis-Cluster zum Schutz des mandantenübergreifenden Datenverkehrs, wobei der Datenverkehr zwischen den Datencentern auch als DCI-Lösung über den SRX-Cluster geleitet wird.

Ein weiteres Collapsed Spine Fabric-Modell verbindet die Spine-Geräte durch einen IP-Transit-Layer-Route-Reflector-Cluster, den Sie in die Collapsed Spine Core Underlay- und Overlay-Netzwerke integrieren. Unsere Referenzarchitektur verwendet dieses Modell und wird in den folgenden Abschnitten beschrieben.

Überblick über die Collapsed Spine-Referenzarchitektur

Unsere Referenzarchitektur stellt einen Anwendungsfall für eine collapsed Spine-Datencenter-Fabric dar, die zwei Pod-Module (Inter-Point of Delivery) umfasst. Die PODs und collapsed Spine-Geräte in den PODs werden durch eine Super-Spine-IP-Transitschicht miteinander verbunden, die als Route Reflector Cluster konfiguriert ist. Siehe Abbildung 3. Diese Architektur ähnelt einem fünfstufigen IP-Fabric-Design (siehe Fünfstufiges IP-Fabric-Design und -Implementierung), aber nur mit super Spine-, Spine- und Zugriffsebenen. Sie konfigurieren die collapsed Spine Fabric so, dass die Route Reflector-Cluster-Geräte auf ähnliche Weise in das IP-Fabric-Underlay und das EVPN-Overlay integriert werden.

Abbildung 3: Collapsed Spine Fabric integriert mit einem Route Reflector Cluster Collapsed Spine Fabric Integrated With a Route Reflector Cluster

Abbildung 3 zeigt ein Beispiel für das Collapsed Spine-Referenzdesign, das die folgenden Elemente umfasst:

  • POD 1: ToR 3 multihomed zu Spine 1 und Spine 2

  • POD 2: ToR 1 und ToR 2 multihomed zu Spine 3 und Spine 4

  • Route Reflector Cluster: RR 1 und RR 2 verbinden Spine-Geräte 1 bis 4 miteinander

Die vier Spine-Geräte bilden den Collapsed Spine EVPN Fabric Core, mit Layer-2-Stretch und Layer-3-Routing zwischen den Spine-Geräten in den beiden PODs. Die Spine-Geräte in jedem POD verwenden ESI-LAGs für die multihomed ToR-Switches im selben POD.

Konfigurieren Sie das Collapsed Spine IP-Fabric-Underlay, das in die Route Reflector-Ebene integriert ist

In diesem Abschnitt wird beschrieben, wie Sie die Verbindungsverbindungen und das IP-Fabric-Underlay auf den Spine- und Route-Reflector-Geräten konfigurieren.

Abbildung 4 zeigt die zusammengelegten Spine- und Route-Reflektorgeräte, die über aggregierte Ethernet-Schnittstellenverbindungen verbunden sind.

Abbildung 4: Collapsed Spine Referenzarchitektur Underlay integriert in Route Reflector Cluster Collapsed Spine Reference Architecture Underlay Integrated With Route Reflector Cluster

So konfigurieren Sie das Underlay:

  1. Bevor Sie die Schnittstellen konfigurieren, die den Routenreflektor und die Spine-Geräte in der Fabric verbinden, müssen Sie auf jedem dieser Geräte die Anzahl der auf dem Gerät möglicherweise benötigten aggregierten Ethernet-Schnittstellen festlegen. Das Gerät weist jeder aggregierten Ethernet-Schnittstelle, die Sie konfigurieren, eindeutige MAC-Adressen zu.

    Konfigurieren Sie die Anzahl der aggregierten Ethernet-Schnittstellen auf RR 1, RR 2, Spine 1, Spine 2, Spine 3 und Spine 4:

  2. Konfigurieren Sie die aggregierten Ethernet-Schnittstellen auf dem Routenreflektor und den Spine-Geräten, die die Collapsed Spine-Fabric bilden, wie in Abbildung 4 dargestellt.

    Aus Gründen der Redundanz verwendet dieses Referenzdesign zwei physische Schnittstellen in jeder aggregierten Ethernet-Verbindung zwischen Dem Route Reflector- und Spine-Geräten. Die Route Reflector-Geräte verbinden sich mit den vier Spine-Geräten über aggregierte Ethernet-Schnittstellen ae1 über ae4. Jedes Spine-Gerät verwendet aggregierte Ethernet-Schnittstellen ae1 (zu RR 1) und ae2 (zu RR 2).

    Außerdem konfigurieren wir eine höhere MTU (9192) auf den physischen Schnittstellen, um die VXLAN-Kapselung zu berücksichtigen.

    RR 1:

    RR 2:

    Spine 1:

    Spine 2:

    Spine 3:

    Spine 4:

  3. Konfigurieren Sie die IP-Adressen für die Loopback-Schnittstellen und die Router-ID für jedes Route Reflector- und Spine-Gerät, wie in Abbildung 4 dargestellt.
  4. Konfigurieren Sie auf routenreflektor- und Spine-Geräten das EBGP IP-Fabric-Underlay. Die Underlay-Konfiguration ähnelt anderen Spine- und Leaf-Referenzarchitekturdesigns in IP Fabric Underlay Network Design and Implementation. Im Underlay dieses Referenzdesigns ist die collapsed Spine Fabric jedoch in die Routenreflektorgeräte für IP-Transitfunktionen zwischen den Spine-Geräten innerhalb und über die PODs integriert.

    Die Underlay-Konfiguration umfasst Folgendes:

    • Definieren Sie eine Export-Routing-Richtlinie (underlay-clos-export), die die IP-Adresse der Loopback-Schnittstelle für EBGP-Peering-Geräte ankündigen. Diese Export-Routing-Richtlinie wird verwendet, um die IP-Adresse der Loopback-Schnittstelle jedes Geräts für alle Geräte in der IP-Fabric (alle Route Reflector- und Spine-Geräte) erreichbar zu machen.

    • Definieren Sie auf jedem Gerät eine lokale AS-Nummer.

    • Auf den Routenreflektorgeräten: Identifizieren Sie die vier Spine-Geräte anhand ihrer aggregierten Ethernet-Link-IP-Adressen und lokalen AS-Nummern als EBGP-Nachbarn.

      Auf Spine-Geräten: Identifizieren Sie die beiden Route Reflector-Geräte anhand ihrer aggregierten Ethernet-Link-IP-Adressen und lokalen AS-Nummern als EBGP-Nachbarn.

    • Aktivieren Sie die BGP-Peer-Statusübergangsprotokollierung.

    RR 1:

    RR 2:

    Spine 1:

    Spine 2:

    Spine 3:

    Spine 4:

Konfigurieren Sie das Collapsed Spine EVPN-VXLAN-Overlay, das in die Route Reflector-Ebene integriert ist

In diesem Design ähnelt das Overlay anderen EVPN-VXLAN-Datencenter-Spine- und Leaf-Referenzarchitekturen, umfasst jedoch keine Leaf-Ebene. Nur die Spine-Geräte (integriert in den Route Reflector Cluster) führen Intra-VLAN- und Inter-VLAN-Routing in der Fabric durch. Wir konfigurieren IBGP mit Multiprotocol BGP (MP-IBGP) mit einer einzigen autonomen Systemnummer (AS) auf den Spine-Geräten, um einen Signalpfad zwischen ihnen über die Routenreflektor-Cluster-Geräte wie folgt herzustellen:

  • Die Route Reflector-Cluster-Geräte peeren mit den Spine-Geräten in beiden PODs für den IP-Transit.

  • Die Spine-Geräte peeren mit den Routenreflektorgeräten.

Siehe Abbildung 5, die die Spine- und Routenreflektor-Cluster-Geräte und BGP-Nachbarn-IP-Adressen veranschaulicht, die wir im EVPN-Overlay-Netzwerk konfigurieren.

Abbildung 5: Collapsed Spine Referenzarchitektur-Overlay integriert mit Route Reflector Cluster Collapsed Spine Reference Architecture Overlay Integrated With Route Reflector Cluster

Die Overlay-Konfiguration ist auf beiden Routenreflektorgeräten mit Ausnahme der lokalen Adresse des Geräts (die Loopback-Adresse) gleich. Die Routenreflektorgeräte peeren mit allen Spine-Geräten.

Die Overlay-Konfiguration ist auf jedem Spine-Gerät gleich, mit Ausnahme der lokalen Adresse des Geräts (die Loopback-Adresse). Alle Spine-Geräte peeren mit dem Route Reflector Cluster.

Wir konfigurieren EVPN mit VXLAN-Kapselung und VTEP-Schnittstellen (Virtual Tunnel Endpoint) nur auf den Spine-Geräten in der collapsed Spine Fabric.

So konfigurieren Sie das Overlay:

  1. Konfigurieren Sie eine AS-Nummer für das IBGP-Overlay auf allen Spine- und Routenreflektorgeräten:
  2. Konfigurieren Sie IBGP mit EVPN-Signalübertragung auf den Routenreflektorgeräten, um mit den collapsed Spine-Geräten zu peeren, die aufgrund ihrer Geräte-Loopback-Adressen als IBGP-Nachbarn identifiziert werden, wie in Abbildung 5 dargestellt.

    In diesem Schritt können Sie außerdem:

    • Definieren Sie RR 1 und RR 2 als Routenreflektor-Cluster (mit Cluster-ID 192.168.2.1).

    • Aktivieren Sie die MTU-Erkennung (Path Maximum Transmission Unit), um die MTU-Größe auf dem Netzwerkpfad zwischen der Quelle und dem Ziel dynamisch zu bestimmen, wodurch eine IP-Fragmentierung vermieden werden kann.

    • Richten Sie bidirektionale Weiterleitungserkennung (BIDIRECTIONAL Forwarding Detection, BFD) zur Erkennung von IBGP-Nachbarnfehlern ein.

    • Legen Sie die vpn-apply-export Option fest, um sicherzustellen, dass sowohl die VRF- als auch die BGP-Gruppen- oder Nachbarnexportrichtlinien in der BGP-Konfiguration (in dieser Reihenfolge) angewendet werden, bevor das Gerät Routen in den VPN-Routing-Tabellen an die anderen Routenreflektor- oder Spine-Geräte ankündt. (Weitere Informationen finden Sie unter Verteilen von VPN-Routen .)

    RR 1:

    RR 2:

  3. Konfigurieren Sie IBGP mit EVPN auf den collapsed Spine-Geräten, um mit den Route-Reflektorgeräten zu peeren, die aufgrund der in Abbildung 5 dargestellten Geräte-Loopback-Adressen als IBGP-Nachbarn identifiziert werden. Die Konfiguration ist auf allen Spine-Geräten gleich, es sei denn, Sie ersetzen die Loopback-IP-Adresse des Spine-Geräts durch den local-address device-loopback-addr Wert.

    In diesem Schritt können Sie außerdem:

    • Aktivieren Sie die MTU-Erkennung (Path Maximum Transmission Unit), um die MTU-Größe auf dem Netzwerkpfad zwischen der Quelle und dem Ziel dynamisch zu bestimmen, wodurch eine IP-Fragmentierung vermieden werden kann.

    • Richten Sie BFD zur Erkennung von IBGP-Nachbarnfehlern ein.

    • Legen Sie die vpn-apply-export Option fest, um sicherzustellen, dass sowohl die VRF- als auch die BGP-Gruppen- oder Nachbarnexportrichtlinien in der BGP-Konfiguration (in dieser Reihenfolge) angewendet werden, bevor das Gerät Routen in den VPN-Routing-Tabellen an die anderen Routenreflektor- oder Spine-Geräte ankündt. (Weitere Informationen finden Sie unter Verteilen von VPN-Routen .)

    Alle Spine-Geräte:

  4. Stellen Sie sicher, dass LLDP auf allen Schnittstellen außer der Verwaltungsschnittstelle (em0) des Route Reflector-Clusters und der Spine-Geräte aktiviert ist.

    Alle Route Reflector- und Spine-Geräte:

  5. Konfigurieren Sie EVPN mit VXLAN-Kapselung im Overlay auf den Spine-Geräten. Die Konfiguration ist auf allen Spine-Geräten in der collapsed Spine Fabric gleich.

    In diesem Schritt:

    • Geben Sie eine Richtlinie für paketbasiertes Load Balancing für ECMP in der Weiterleitungstabelle an und wenden Sie sie an.

    • Konfigurieren Sie diese EVPN-Optionen auf der Hierarchieebene [Protokolle bearbeiten eVPN] und setzen Sie die VXLAN-Kapselung:

      • default-gateway no-gateway-community: Ankündigung des virtuellen Gateways und der IRB-MAC-Adressen bei den EVPN-Peer-Geräten, damit nur Ethernet-Edge-Geräte diese MAC-Adressen lernen können. Sie konfigurieren no-gateway-community in einer zusammengeklappten Spine-Fabric, wenn die Spines Folgendes verwenden:

      • extended-vni-list all Option: Lassen Sie alle konfigurierten VXLAN-Netzwerkbezeichner (VNIs) Teil dieser EVPN-VXLAN-BGP-Domäne. In einem späteren Abschnitt konfigurieren wir VLANs und VLANs zu VNI-Zuordnungen.

      • remote-ip-host-routes: Ermöglichen Der Datenverkehrsoptimierung für virtuelle Maschinen (VMTO). (Weitere Informationen finden Sie unter Optimierung des eingehenden datenverkehrs für virtuelle Maschinen für EVPN .)

    Alle Spine-Geräte:

  6. Konfigurieren Sie VTEP-, Routenziel- und VRF-Switch-Optionen (Virtual Routing and Forwarding) auf den Spine-Geräten.

    Die Konfiguration ist auf allen Spine-Geräten gleich, außer auf jedem Gerät, das durch die Loopback-IP-Adresse des Geräts durch den route-distinguisher Wert ersetzt wird. Dieser Wert definiert einen eindeutigen Routenscheider für Routen, die von jedem Gerät generiert werden.

    Die VTEP-Quellschnittstelle in der EVPN-Instanz sollte auch mit der lokalen IBGP-Peer-Adresse übereinstimmen, die ebenfalls die Ip-Adresse des Geräts ist.

    Spine 1:

    Spine 2:

    Spine 3:

    Spine 4:

  7. (Nur auf Routern der PTX10000-Serie erforderlich) Globale Tunnelterminierung (also auf allen Schnittstellen) auf dem Gerät aktivieren:

Konfigurieren Sie EVPN-Multihoming und virtuelle Netzwerke auf den Spine-Geräten für die ToR-Switches

Dieses Collapsed Spine-Referenzdesign implementiert EVPN-Multihoming, wie in Multihoming an Ethernet-Connected End System Design and Implementation beschrieben, außer weil die Leaf-Layer-Funktionen in die Spine-Ebene eingeklappt sind, konfigurieren Sie die ESI-LAGs auf den Spine-Geräten. Außerdem konfigurieren Sie VLANs und Layer 2- und Layer 3-Routing-Funktionen auf den Spine-Geräten ähnlich wie auf Leaf-Geräten in einem Erb-Overlay-Design (Edge-Routed Bridging). Die Core-Collapsed-Spine-Konfiguration implementiert eine Layer-2-Erweiterung , indem dieselben VLANs (und VLAN-zu-VNI-Zuordnungen) auf allen Spine-Geräten in beiden PODs festgelegt werden. EVPN Typ 2-Routen ermöglichen die Kommunikation zwischen Endgeräten innerhalb und über die PODs hinweg.

Abbildung 6 zeigt die zusammengeklappten Spine-Geräte in jedem POD, die mit aggregierten Ethernet-Schnittstellenverbindungen zu den multihomed ToR-Switches im POD verbunden sind.

Abbildung 6: Collapsed Spine Fabric with Multihomed ToR Switches (Collapsed Spine Fabric with Multihomed ToR Switches Collapsed Spine Fabric With Multihomed ToR Switches)

Aus Gründen der Kürze zeigt dieser Abschnitt eine aggregierte Ethernet-Verbindung zwischen jedem Spine und jedem ToR-Gerät, wobei eine Schnittstelle auf jeder aggregierten Ethernet-Verbindung von den Spine-Geräten zu den ToR-Geräten im POD konfiguriert ist.

In diesem Abschnitt werden nur Konfigurationsdetails für Spine- und ToR-Geräte in POD 2 behandelt. Sie können eine ähnliche Konfiguration mit entsprechenden Geräteparametern und Schnittstellen auf die Spine- und ToR-Geräte in POD 1 anwenden.

Die ToR-Geräte umfassen zwei Schnittstellen in ihren aggregierten Ethernet-Verbindungen, eine zu jedem Spine-Gerät im POD, die die ESI-LAG für Multihoming bilden.

Die Konfiguration umfasst Folgende Schritte:

  • Konfigurieren Sie die Schnittstellen.

  • Richten Sie die ESI-LAGs für EVPN-Multihoming ein.

  • Konfigurieren Sie Layer 2- und Layer 3-Gateway-Funktionen, einschließlich der Definition von VLANs, den zugehörigen IRB-Schnittstellen für das Inter-VLAN-Routing und entsprechende VLAN-zu-VNI-Zuordnungen.

  1. Konfigurieren Sie die Schnittstellen und aggregierten Ethernet-Verbindungen auf den Spines (Spine 3 und Spine 4) zu den multihomed ToR-Switches (ToR 1 und ToR 2) in POD 2.

    Spine 3:

    Spine 4:

  2. Konfigurieren Sie die ESI-LAGs für EVPN-Multihoming auf den Spine-Geräten für die multihomed ToR-Switches in POD 2. Dieses Design verwendet die gleichen aggregierten Ethernet-Schnittstellen auf den Spine-Geräten zu den ToR-Switches, sodass Sie auf beiden Geräten dieselbe Konfiguration verwenden.

    Verbindet sich in diesem Referenzdesign ae3 mit ToR 1 und ae10 verbindet sich mit ToR 2.

    Spine 3 und Spine 4:

  3. Konfigurieren Sie VLANs auf den Spine-Geräten in POD 2 mit ae3 und ae10 als VLAN-Member.

    Spine 3 und Spine 4:

  4. Zuordnen sie die VLANs zu VNIs für die VXLAN-Tunnel und zuordnen Sie jedem eine IRB-Schnittstelle.

    Spine 3 und Spine 4:

  5. Konfigurieren Sie die IRB-Schnittstellen für die VLANs (VNIs) auf den Spine-Geräten in POD 2 mit IPv4- und IPv6-Dual-Stack-Adressen für die IRB-IP-Adresse und die IP-Adresse des virtuellen Gateways.

    Spine 3:

    Spine 4:

  6. Definieren Sie die VRF-Routing-Instanz und die entsprechenden IRB-Schnittstellen für EVPN Typ 2-Routen auf jedem Spine-Gerät in POD 2 für die konfigurierten VLANs (VNIs).

    Spine 3:

    Spine 4:

  7. Konfigurieren Sie die Schnittstellen und aggregierten Ethernet-Verbindungen auf den multihomed ToR-Switches (ToR 1 und ToR 2) zu den Spine-Geräten (Spine 3 und Spine 4) in POD 2. In diesem Schritt:

    • Legen Sie die Anzahl der aggregierten Ethernet-Schnittstellen auf dem Switch fest, die Sie möglicherweise benötigen (wir haben hier 20 als Beispiel festgelegt).

    • Konfigurieren Sie die aggregierte Ethernet-Verbindung ae1 auf jedem ToR-Switch zu den Spine-Geräten in POD 2.

    • Konfigurieren Sie LLDP auf den Schnittstellen.

    ToR 1:

    ToR 2:

  8. Konfigurieren Sie die VLANs auf den ToR-Switches in POD 2. Diese entsprechen den VLANs, die Sie in Schritt 3 auf den Spine-Geräten in POD 2 konfiguriert haben.

    ToR 1 und ToR 2:

Überprüfung der Collapsed Spine Fabric-Konnektivität mit Route Reflector Cluster und ToR-Geräten

In diesem Abschnitt werden CLI-Befehle dargestellt, mit der sie die Konnektivität zwischen den zusammengeklappten Spine-Geräten und dem Route Reflector-Cluster sowie zwischen den collapsed Spine-Geräten und den ToR-Geräten überprüfen können.

Aus Gründen der Kürze enthält dieser Abschnitt die Überprüfung der Konnektivität auf den Spine-Geräten, die nur Spine 3 und Spine 4 in POD 2 verwenden. Sie können die gleichen Befehle auf den Spine-Geräten (Spine 1 und Spine 2) in POD 1 verwenden.

  1. Überprüfen Sie die Konnektivität der aggregierten Ethernet-Verbindungen auf den Routenreflektorgeräten zu den vier zusammengeklappten Spine-Geräten. Auf jedem Routenreflektorgerät verbindet aeX sich mit Spine X).

    RR 1:

    RR 2:

  2. Überprüfen Sie die Konnektivität der aggregierten Ethernet-Verbindungen auf den Spine-Geräten in POD 2 (Spine 3 und Spine 4) zu den Routenreflektorgeräten. Verbinden ae1 und ae2 Verbinden mit Routing-Reflektorgeräten RR 1 bzw. RR 2 auf Spine 3 und Spine 4.

    Spine 3:

    Spine 4:

  3. Überprüfen Sie die Konnektivität der aggregierten Ethernet-Verbindungen der Spine-Geräte in POD 2 (Spine 3 und Spine 4) zu den multihomed ToR-Switches. Verbindet ae3 und ae10 verbinden Sie sich mit ToR 1 bzw. ToR 2 auf Spine 3 und Spine 4, sodass diese Befehlszeile die Ausgabe filtert, um Verbindungszustände zu finden, die mit ae3. Die Ausgabe wird abgeschnitten, um den Status nur für die relevanten Links anzuzeigen.

    Spine 3:

    Spine 4:

  4. Stellen Sie sicher, dass die Spine-Geräte in POD 2 (Spine 3 und Spine 4) die Routenreflektorgeräte und die ToR-Switches in POD 2 als LLDP-Nachbarn erkennen. Für die Spine-to-ToR-Links wird überprüft, ob die ESI-Mitgliedsverbindungen zu den multihomed ToR-Switches eingerichtet wurden.

    Diese Beispielbefehlsausgabe wird gefiltert und abgeschnitten, um nur die relevanten aggregierten Ethernet-Verbindungen anzuzeigen. Kommentarzeilen zeigen die Spalten für die Werte, die in der resultierenden Ausgabe angezeigt werden. Siehe nochmals Abbildung 4, die zeigt, dass sowohl Spine-Switches in POD 2 als auch um eine Verbindung mit den Routenreflektorgeräten, ae3 zur Verbindung mit ToR1 und ae10 zu ToR 2 zu verbinden ae1 ae2.

    Spine 3:

    Spine 4:

Überprüfen der Collapsed Spine Fabric BGP Underlay und EVPN-VXLAN Overlay-Konfiguration

In diesem Abschnitt werden CLI-Befehle angezeigt, mit denen Sie überprüfen können, ob Das Underlay und das Overlay für die zusammengeklappten Spine-Geräte funktionieren, die in den Route Reflector cluste integriert sind. Weitere Informationen zu den konfigurierten Underlay- und Overlay-Parametern finden Sie in Abbildung 4 und Abbildung 5 .

Aus Gründen der Kürze enthält dieser Abschnitt die Überprüfung der Konnektivität auf den Spine-Geräten, die nur Spine 3 und Spine 4 in POD 2 verwenden. Sie können die gleichen Befehle auf den Spine-Geräten (Spine 1 und Spine 2) in POD 1 verwenden.

  1. Überprüfen Sie auf den Route Reflector-Geräten, dass EBGP- und IBGP-Peering eingerichtet ist und die Datenverkehrspfade mit den vier Spine-Geräten aktiv sind. Diese Beispielbefehlsausgabe wird gefiltert, um nur die relevanten Statuszeilen anzuzeigen, die das etablierte Peering zeigen. Kommentarzeilen zeigen die Spalten für die Werte, die in der resultierenden Ausgabe angezeigt werden.

    RR 1:

    RR 2:

  2. Überprüfen Sie auf den Spine-Geräten in POD 2, dass die Underlay-EBGP- und Overlay-IBGP-Peerings eingerichtet sind. Diese Beispielbefehlsausgabe wird gefiltert, um nur die relevanten Statuszeilen anzuzeigen, die das etablierte Peering zeigen. Kommentarzeilen zeigen die Spalten für die Werte, die in der resultierenden Ausgabe angezeigt werden.

    Spine 3:

    Spine 4:

  3. Überprüfen Sie die Ziel-IP-Adressen des Endgeräts für die Remote-VTEP-Schnittstellen, bei denen es sich um die Loopback-Adressen der anderen drei Spine-Geräte in POD 1 und POD 2 dieser collapsed Spine-Topologie handelt. Hier finden Sie Eine Beispielausgabe für Spine 3 in POD 2. die Ergebnisse auf den anderen Spine-Geräten ähnlich sind.

    Spine 3:

  4. Überprüfen Sie die ESI-LAGs auf den Spine-Geräten in Richtung der ToR-Switches. Hier finden Sie Eine Beispielausgabe für Spine 3 in POD 2. die Ergebnisse auf den anderen Spine-Geräten ähnlich sind.

    Spine 3:

Ähnliche Dokumentation