Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Überprüfung

Überprüfung der Campus Fabric IP Clos-Bereitstellung. Siehe Abbildung 1.

Derzeit gibt es zwei Desktops, um die Campus-Fabric zu validieren. Lassen Sie uns einen kurzen Blick darauf werfen, ob Desktop1 intern und extern eine Verbindung herstellen kann. Ein Drittanbieter-Tool wie SecureCRT kann verwendet werden, um die Konfiguration jedes Desktops mit Desktop1 zu validieren, wie in Abbildung 1 dargestellt.

Abbildung 1: Konfigurationsvalidierung in der CLI A computer screen shot of a black screen Description automatically generated

Validierungsschritte:

  • Die bestätigte lokale IP-Adresse, das VLAN und das Standard-Gateway wurden auf Desktop1 konfiguriert.
  • Kann Standard-Gateway pingen: Zeigt an, dass wir den Zugriffs-Switch erreichen können.
  • Ping an WAN-Router fehlgeschlagen (10.99.99.254) – wir müssen das Problem beheben.

Beginnen Sie mit der Validierung der Campus-Fabric in der Mist-Benutzeroberfläche, indem Sie zu Organization > Campus Fabric navigieren.

Der Remote-Shell-Zugriff auf jedes Gerät innerhalb der Campus-Fabric wird hier ebenso unterstützt wie die visuelle Darstellung der folgenden Funktionen:

  • BGP-Peering-Einrichtung.
  • Senden und empfangen Sie Datenverkehr auf Link-by-Link-Basis.
  • Telemetrie, z. B. lldp, von jedem Gerät, das den physischen Build überprüft.

A screenshot of a computer Description automatically generated

BGP-Underlay

Zweck

Die Überprüfung des eBGP-Status zwischen benachbarten Schichten ist für den erwarteten Betrieb von EVPN VXLAN unerlässlich. Dieses Netzwerk von Punkt-zu-Punkt-Verbindungen zwischen den einzelnen Schichten unterstützt:

  • Load Balancing mit ECMP für höhere Ausfallsicherheit und Bandbreiteneffizienz.
  • Bidirektionale Weiterleitung (BFD) zur Verkürzung der Konvergenzzeiten bei Ausfällen.
  • BGP-Peering.
  • Loopback zur VXLAN-Erreichbarkeit.

Ohne dass eine Verifizierung auf jeder Ebene erforderlich ist, kann der Fokus auf Dist1 und Dist2 und ihren eBGP-Beziehungen mit Access1 und Access2 sowie Core1 und Core2 liegen. Wenn beide Distribution-Switches eBGP-Peering-Sitzungen mit jeder benachbarten Schicht "etabliert" haben, können Sie zur nächsten Phase der Verifizierung übergehen.

Aufgrund der automatischen Zuweisung von Loopback-IP-Adressen müssen wir uns für diese Fabric die folgende Konfiguration merken:

Switch-Typ Switch-Name Automatisch zugewiesene Loopback-IP
Kern Kern 1 172.16.254.2
Kern Core2 172.16.254.1
Verteilung Dist1 172.16.254.3
Verteilung Dist2 172.16.254.4
Zugriff Zugang1 172.16.254.6
Zugriff Zugriff2 172.16.254.5

Aktion

Stellen Sie sicher, dass BGP-Sitzungen von Dist1 und Dist2 mit Zugriffs- und Core-Geräten eingerichtet werden, um die Erreichbarkeit des Loopbacks, den BFD-Sitzungsstatus und den Lastausgleich mithilfe von ECMP sicherzustellen.

Hinweis:

Betriebsdaten können über den Campus-Fabric-Bereich der Mist-GUI oder mithilfe einer externen Anwendung wie SecureCRT oder Putty erfasst werden.

Verifizierung von BGP-Peering

Abt1:

Greifen Sie über Switch > Utilities über die untere rechte Ecke der Campus-Fabric, über die Switch-Ansicht oder über Secure Shell (SSH) auf Remote Shell zu.

A screenshot of a computer Description automatically generated

Aus der BGP-Zusammenfassung können wir ersehen, dass die Underlay-Peer-Beziehungen (10.255.240.X) hergestellt wurden, um anzuzeigen, dass die Underlay-Links an die richtigen Geräte angeschlossen sind und die Links aktiv sind.

Außerdem wird gezeigt, dass die Overlay-Beziehungen (172.16.254.x) hergestellt wurden und dass ein Peering an den richtigen Underlay-Loopback-Adressen durchgeführt wird. Dies demonstriert die Erreichbarkeit von Underlay-Loopbacks.

Wir können auch die empfangenen Routen sehen. Da die ermittelte Zeit ungefähr gleich ist, sieht das bisher gut aus.

Der Campus-Fabric-Build veranschaulicht den in Abbildung 2 von Dist1 dargestellten Echtzeit-BGP-Peering-Status pro Gerät.

Abbildung 2: BGP-Nachbarinformationen A table with numbers and letters Description automatically generated

Wenn BGP nicht eingerichtet ist, gehen Sie zurück und validieren Sie die Underlay-Links und die Adressierung. Stellen Sie außerdem sicher, dass die Loopback-Adressen korrekt sind. Loopback-Adressen müssen von anderen Loopback-Adressen pingbar sein. Beispielsweise kann Dist1 die Loopback-Adressen von Core1 und Access1 erreichen, sobald die Underlay-eBGP-Peering-Sitzungen eingerichtet sind.

A screenshot of a computer program Description automatically generated

Hinweis:

eBGP-Sitzungen werden zwischen benachbarten Schichten in der Campus Fabric IP Clos eingerichtet.

Lassen Sie uns überprüfen, ob die Routen zum Core und zu anderen Geräten über mehrere Pfade eingerichtet sind. Beispielsweise sollten Access1 und Access2 beide Pfade über Dist1 und Dist2 nutzen, um auf die Loopbackadressen von Core1 und Core2 sowie auf die Loopbackadressen des jeweils anderen zuzugreifen.

Access1: Loopback-Erreichbarkeit zu Core1 über Dist1 und Dist2

A screenshot of a computer Description automatically generated

Access1: Loopback-Erreichbarkeit mit Core2 bis Dist1 und Dist2

A screenshot of a computer Description automatically generated

Access1: Loopback-Erreichbarkeit mit Access2 bis Dist1 und Dist2

A screenshot of a computer Description automatically generated

Dies kann für Access 2 usw. wiederholt werden, um den ECMP-Lastenausgleich zu überprüfen.

Bedeutung: An diesem Punkt sind BGP-Underlay und -Overlay durch die Überprüfung von eBGP zwischen den entsprechenden Schichten der Campus-Fabric betriebsbereit, und es werden Routen zu Zugriffs-, Core- und Verteilungsschichten eingerichtet.

EVPN VXLAN-Verifizierung zwischen Access- und Core-Switches

Da der Desktop sein Standard-Gateway pingen kann, können wir davon ausgehen, dass die Ethernet-Switching-Tabellen korrekt ausgefüllt sind und dass die VLANs und der Schnittstellenmodus korrekt sind. Wenn das Pingen des Standard-Gateways fehlgeschlagen ist, führen Sie eine Fehlerbehebung bei der Underlay-Konnektivität durch.

Verifizierung der EVPN-Datenbank auf beiden Access Switches

A screenshot of a computer Description automatically generated

Sie können die gesamte Datenbank anzeigen oder nach MAC-Adresse suchen.

A screenshot of a computer Description automatically generated

Beide Access Switches verfügen über identische EVPN-Datenbanken, was zu erwarten ist. Beachten Sie die Einträge für Desktop1 (10.99.99.99) und Desktop2 (10.88.88.88), die in jedem Zugriffsswitch vorhanden sind. Diese Einträge werden lokal oder über die Campus-Fabric gelernt, wie in der Spalte "Aktive Quelle" der Ausgabe gezeigt.

10.99.99.99 ist mit irb.1099 verknüpft und wir sehen VNI von 11099. Überprüfen wir noch einmal die VLAN-VNI-Zuordnung auf den Zugriffs- und Core-Switches.

Zugriff

Kern

Verifizierung des VXLAN-Tunnelings zwischen Zugriffs- und Core-Geräten

Zugang 1:

Zugang 2:

Wir müssen den Anhang des WAN-Routers konfigurieren, um das gesamte Design abzuschließen. Ohne die WAN-Routerkonfiguration lässt die Fabric nur die folgenden Kommunikationen zu.

Hinweis:

Keiner der Zugriffs-Switches zeigt Core1 oder Core2 als Remote-Tunnelziele an. Der Grund dafür ist, dass wir die Uplinks zum WAN-Router auf der Fabric noch nicht konfiguriert haben. Daher weiß kein Core-Switch über VLAN1099 Bescheid.

Externe Campus-Fabric-Konnektivität über die Border Gateway Core EX9204-Switches

Es stehen mehrere Optionen zur Verfügung, um einen WAN-Router an eine Campus-Fabric anzuschließen:

  • Verwendung einer L2-Weiterleitung:
  • Bei dieser Methode werden die Fabric-Uplinks als ESI-LAG konfiguriert und enthalten ein oder mehrere getaggte VLANs (eines für jede VRF) für die Kommunikation mit dem WAN-Router.
  • Sie müssen die IP-Adresse der WAN-Router-Schnittstelle manuell als Next-Hop-IP-Adresse für die Standardweiterleitung auf jeder Fabric-VRF konfigurieren, wie oben bereits geschehen.
  • Der WAN-Router muss den Standard IEEE 802.3ad LAG mit aktivem LACP verstehen.
  • Wenn Sie mehr als einen WAN-Router für Redundanz angeschlossen haben, empfehlen wir, VRRP zwischen ihnen für die Schnittstellen-IP-Adressen in Richtung Fabric zu konfigurieren.
  • Verwendung einer L3-Weiterleitung:
  • Konfigurieren Sie die Fabric-Uplinks als L3-Peer-to-Peer-IP-Verbindungen.
  • Sie müssen eine Peer-to-Peer-Verbindung pro Fabric-VRF mit dem WAN-Router herstellen.
  • In der Regel befinden sich mehrere Peer-to-Peer-Links auf einem einzigen physischen Uplink. Die Peer-to-Peer-Verbindungen werden mithilfe von getaggten VLANs weiter segmentiert, um eine Isolierung der Uplinks zu gewährleisten.
  • Es ist nicht erforderlich, die nächsten Hops für jede VRF innerhalb der Fabric manuell zu konfigurieren, da davon ausgegangen wird, dass die Weitergabe der Standard-Gateways für den WAN-Router über ein Routing-Protokoll erfolgt.
  • Zwischen der Fabric und dem WAN-Router muss ein Routing-Protokoll eingerichtet werden, um Routen auszutauschen. Die Campus Fabric unterstützt externe BGP und OSPF als Routing-Protokolle zum WAN-Router.

Der Einfachheit halber haben wir uns entschieden, in diesem JVD den L2-Ausgang über ESI-LAG zu verwenden. Dies ist jedoch nicht die empfohlene Methode für große Fabrics, da IP Clos zum Wachsen gedacht ist. Für IP-Clos-Fabrics in Produktionsumgebungen sollten Sie die Verwendung von BGP als Routenaustauschprotokoll sowie eines redundanten Paares von WAN-Routern in Betracht ziehen.

Denken Sie daran, dass Sie die BGP-Funktion der EX9204-Switches während der Campus Fabric IP Clos-Bereitstellung genutzt haben, wie in Abbildung 3 dargestellt.

Abbildung 3: L2 ESI-LAG zur Unterstützung des Aktiv-Aktiv-Lastenausgleichs A close-up of a computer diagram Description automatically generated

Mist ermöglicht es dem EX9204-Switch, zwischen VXLAN-Datenverkehr innerhalb der Campus-Fabric und Standard-Ethernet-Switching für externe Konnektivität, in diesem Fall einen MX-Router, zu übersetzen. Überprüfen wir den ESI-Status (Ethernet Segment Identifier) auf den Core-Switches.

Wir müssen die ESI-LAG konfigurieren, da Mist dies nicht automatisch konfiguriert. Fügen Sie ein Portprofil auf Core-Switches-Schnittstellen hinzu, die dem WAN-Router zugewandt sind.

Im Folgenden wird ein vorhandenes Portprofil dargestellt, das auf jeden MX-Router angewendet wird, der einem EX9204-Switch-Port zugewandt ist. (Auf dem Core2-Switch ist der Port xe-1/0/1).

A screenshot of a computer Description automatically generated

Speichern Sie die Konfiguration, und überprüfen Sie dann die Änderungen auf dem Core-Switch.

A screenshot of a computer Description automatically generated

Beachten Sie, dass LACP aktiv ist, und dies schließt daraus, dass eine vorhandene Konfiguration auf dem MX-Router vorhanden ist.

A picture containing graphical user interface Description automatically generated

Überprüfen Sie, ob die MAC-Adresse von Desktop1 über BGP angekündigt wird:

A computer screen with white text Description automatically generated

Überprüfen Sie, ob die Route auf dem Core empfangen wird.

A screenshot of a computer Description automatically generated

Lassen Sie uns überprüfen, ob der Core die MAC-Adresse Desktop1 hat.

Überprüfen Sie, ob die MAC-Adresse der richtigen VTEP-Schnittstelle zugeordnet ist. Das ist der Kern. Sie können dies auch auf einem Zugriffs-Switch überprüfen.

A screenshot of a computer Description automatically generated

A screenshot of a computer Description automatically generated

A screen shot of a computer Description automatically generated

Schließlich ist die VTEP-Schnittstelle betriebsbereit und leitet Datenverkehr weiter.

A screen shot of a computer Description automatically generated

Vergewissern Sie sich dann, dass die EVPN-Datenbank jetzt über den ESI-Eintrag verfügt. Kehren Sie zu Desktop1 zurück, um zu sehen, ob er die Fabric überwinden kann.

Text Description automatically generated

Der letzte Schritt besteht darin, zu überprüfen, ob Desktop1 Desktop2 anpingen kann.

Text Description automatically generated

A diagram of a network connection Description automatically generated

Das bedeutet: Die Konnektivität innerhalb der Campus-Fabric und extern wird überprüft. Desktops kommunizieren über die Campus-Fabric miteinander, jeweils in einer isolierten VRF, und werden dann über die Dual-Homing-ESI-LAG auf Core1 und Core2 zum Routing zwischen VRFs oder Routing-Instanzen an den MX-Router weitergeleitet. Die Internetverbindung wurde auch von jedem Desktop aus überprüft.