Vernetzung von Datencentern (DCI) / Remote-EVPN-Gateways

Übertrieben

DCI "Over the Top" ist eine transparente Lösung, d. h. EVPN-Routen werden in eine Standard-IP eingekapselt und vor dem zugrunde liegenden Transport verborgen. Dies macht die Erweiterung von Services einfach und flexibel und wird häufig gewählt, weil Datencenter-Teams sie mit wenig oder gar keiner Koordination mit WAN- oder Service Provider-Gruppen implementieren können. Das reduziert die Implementierungszeiten und die innerbetrieblichen Reibungsverluste. Der Kompromiss ist jedoch Skalierbarkeit und Ausfallsicherheit.

Gateway (GW)

Aufbauend auf der Apstra Remote EVPN Gateway-Funktion können Sie optional angeben, dass das Remote EVPN Gateway ein externes generisches System (als externer Router gekennzeichnet) am selben Standort ist, wodurch die EVPN-Attribute auf dieses Gateway erweitert werden. Diese Lösung erstellt eine Fehlerdomäne pro Standort, die verhindert, dass Fehler die Konvergenz an Remotestandorten beeinträchtigen und mehrere Fehlerdomänen erstellen. IP/MAC-Endgerät-Tabellen für Remote-Standorte werden verarbeitet und auf einem generischen System-Gateway (gekennzeichnet als externer Router) gehalten. Sie können auch WAN-QoS und -Sicherheit sowie Optimierungen implementieren, die die Transporttechnologie zur Verfügung stellt (z. B. MPLS TE). Diese Lösung ist jedoch betrieblich komplexer und erfordert zusätzliche Hardware und Kosten.

Autonomes System Border Router (ASBR)

Mit der Apstra Remote EVPN Gateway-Funktion können Sie optional angeben, dass das Remote EVPN Gateway ein ASBR WAN Edge-Gerät ist. Dieses End-to-End-EVPN ermöglicht eine gleichmäßige Kapselung und macht die dedizierte GW-Anforderung überflüssig. Es ist betrieblich komplex, hat aber eine größere Skalierbarkeit im Vergleich zu "DCI mit Gateway" und "Over the Top".

Anwendungsszenarien für EVPN-Gateways

• Verteilen Sie Layer-3-Isolationsdomänen (VRFs/Routing-Zonen) auf mehrere von Apstra verwaltete Pods (Blueprints) oder erweitern Sie sie auf Remote-EVPN-Domänen.
• Bereitstellung von Layer-2-Domänenerweiterungen für L2VNI / virtuelle Netzwerke.
• Helfen Sie bei der Erweiterung der EVPN-Domäne von Apstra auf Apstra-verwaltete Pods und Apstra auf nicht verwaltete Pods.
• Keine VXLAN-Datenverkehrsterminierung auf Spine-Geräten – Verbinden Sie externe generische Systeme (als externe Router gekennzeichnet) auf Spine-Geräten. Dies dient der Unterstützung externer IPv4-Konnektivität (Underlay). Hier müssen Spine-Geräte im Gegensatz zu Border-Leaf-Geräten den VXLAN-Datenverkehr nicht beenden, wenn sie mit externen generischen Systemen verbunden sind (als externe Router gekennzeichnet). Kurz gesagt, mit dieser Technologie können IPv4-Routen zu Remote-VTEPs (in der Standard-Routing-Zone/VRF) ausgetauscht werden, und es ist nur Layer-3-Konnektivität erforderlich:

Übertrieben

Wenn BGP EVPN-Peering "over the top" durchgeführt wird, ist das Datencenter-Gateway (DC-GW) eine reine IP-Transportfunktion, und BGP EVPN-Peering wird zwischen Gateways in verschiedenen Datencentern eingerichtet.

In den nächsten Abschnitten werden die Verfahren zum skalierbaren Verbinden von zwei oder mehr BGP-basierten Ethernet VPN (EVPN)-Standorten über ein IP-Netzwerk beschrieben. Die Motivation besteht darin, die Erweiterung von EVPN-Standorten zu unterstützen, ohne auf typische DCI-Technologien (Data Center Interconnect) wie MPLS/VPLS angewiesen zu sein, die oft schwer zu konfigurieren, manchmal proprietär und wahrscheinlich veralteter Natur sind.

"Over the Top" ist eine einfache Lösung, die nur IP-Routing zwischen Datencentern und eine angepasste MTU erfordert, um die VXLAN-Kapselung zwischen Gateway-Endpunkten zu unterstützen. In einer solchen Implementierung werden EVPN-Routen End-to-End über MP-BGP zwischen Standorten erweitert. Multi-Hop-BGP wird unter der Annahme aktiviert, dass es mehrere Layer-3-Hops zwischen Standorten über ein WAN gibt. Andernfalls wird die Standard-TTL auf 0 dekrementiert und Pakete werden verworfen und gelangen nicht zum Remote-Router. Apstra rendert automatisch die erforderliche Konfiguration, um diese Einschränkungen zu beheben.

Bei diesem Design werden die separaten EVPN-VXLAN-Domänen und VXLAN-Tunnel zwischen Standorten zusammengeführt. Durch die Zusammenführung zuvor getrennter EVPN-Domänen an verschiedenen Standorten wird der Vorteil der Erweiterung von Layer 2- und Layer 3 (VRF)-Services zwischen Standorten realisiert, aber auch die Standorte werden zu einer einzigen Fehlerdomäne. Ein Ausfall an einem Standort wird also zwangsläufig propagiert. Jedes Mal, wenn Sie Layer 2 über das WAN zwischen Standorten ausdehnen, erweitern Sie auch die Flood-Domäne und damit den gesamten Broadcast-Datenverkehr über Ihre kostspieligen WAN-Verbindungen. Derzeit bietet diese Lösung keine Filterung oder QoS.

Hinweis:

Wenn separate Apstra-Blueprints einzelne Standorte verwalten (oder wenn nur ein Standort von Apstra verwaltet wird), müssen Sie erweiterte Routing-Zonen (VRFs) und virtuelle Netzwerke (Layer 2 und/oder Layer 3 definierte VLANs/Subnetze) an jedem Standort unabhängig erstellen und verwalten. Sie müssen VRFs und VNs manuell zwischen Standorten zuordnen (was administrativen Aufwand verursacht).

Hinweis:

Wenn Sie P2P-Verbindungen zwischen zwei Datencentern (Blueprints) im selben Apstra-Controller einrichten, muss jeder Blueprint Ressourcen aus verschiedenen IP-Pools abrufen, um Build-Fehler zu vermeiden. Erstellen Sie dazu zwei IP-Pools mit demselben IP-Subnetz, aber mit unterschiedlichen Namen.

Diese "Over-the-Top"-Lösung ist am einfachsten zu implementieren, erfordert keine zusätzliche Hardware und führt außer der Erhöhung der MTU keine zusätzliche WAN-Konfiguration ein. Es ist das flexibelste und hat die niedrigste Eintrittsbarriere. Der Nachteil ist jedoch, dass es eine einzige EVPN-Steuerungsebene gibt und eine Routing-Anomalie an einem Standort die Konvergenz und Erreichbarkeit an den anderen Standorten beeinträchtigt. Die Erweiterung von Layer-2-Flood-Domains bedeutet auch, dass sich ein Broadcast-Sturm an einem Standort auf den/die anderen/die anderen(n) Standort(e) ausdehnt.

Bei jeder DCI-Implementierung ist eine sorgfältige Ressourcenplanung und Koordination erforderlich. Das Hinzufügen weiterer Standorte erfordert eine exponentielle Steigerung dieser Planung und Koordination. VTEP-Loopbacks im Underlay müssen durchgesickert sein. VNIDs müssen zwischen Standorten übereinstimmen und in einigen Fällen müssen zusätzliche Routenziele (RTs) importiert werden. Dies wird weiter unten in diesem Dokument ausführlich behandelt.

Erweiterung der Data Plane: Layer 3

VXLAN-Netzwerk-IDs (VNIDs) sind Teil des VXLAN-Headers, der eindeutige VXLAN-Tunnel identifiziert, die jeweils von den anderen VXLAN-Tunneln in einem IP-Netzwerk isoliert sind. Layer-3-Pakete können in ein VXLAN-Paket eingekapselt werden, oder Layer-2-MAC-Frames können direkt in ein VXLAN-Paket eingekapselt werden. In beiden Fällen wird eine eindeutige VNID entweder dem Layer-3-Subnetz oder der Layer-2-Domäne zugeordnet. Wenn Sie Layer-3- oder Layer-2-Services zwischen Standorten erweitern, verknüpfen Sie im Wesentlichen VXLAN-Tunnel zwischen Standorten. VNIDs müssen daher zwischen den Standorten übereinstimmen.

Es ist wichtig zu verstehen, dass eine bestimmte VNID nur einem VRF (oder einer Routing-Zone in der Apstra-Terminologie) zugeordnet ist. VNIDs existieren innerhalb eines VRF. Sie sind an ein VRF gebunden. Bei Layer-3-Services erfolgt das Stitching oder Erweitern jeder VNID mit dem Export und Import von RTs innerhalb einer Routing-Zone (VRF). Layer-3-Subnetze (Routen) werden über RTs identifiziert. Alle VNIDs werden automatisch am EVPN-Gateway (Edge) in Richtung WAN exportiert. Umgekehrt werden RTs mit demselben Wert automatisch am EVPN-Gateway (Edge) importiert, das in die Fabric kommt. Wenn Sie also die Layer-3-VNIDs an einem Standort koordinieren, ist keine zusätzliche Konfiguration erforderlich.

In der obigen Abbildung ist kein zusätzlicher Export oder Import erforderlich. Alles wird automatisch exportiert (Alle exportieren) und da die RTs übereinstimmen, werden sie automatisch importiert.

Wenn sich jedoch eine VNID in DC1 von einer VNID in DC2 unterscheidet, müssen Sie die RTs entsprechend importieren. Jedes jeweilige Gateway importiert weiterhin automatisch RTs mit demselben Wert. Im folgenden Beispiel ist ein zusätzlicher Schritt zum manuellen Hinzufügen der RTs von der anderen Site erforderlich.

Erweiterung der Data Plane: Layer 2

Ein virtuelles Netzwerk kann ein reiner Layer-2-Service sein (Layer-3-Anycast-Gateway ist nicht instanziiert). Es kann sich um ein Rack-lokales (VLAN auf serverseitigen Ports in einem Rack) oder VXLAN (Auswahl der Racks, um die Layer-2-Flood- und -Broadcast-Domäne zwischen den Racks zu erweitern) handeln. Diese Layer-2-Domäne verfügt über eine eigene VNID, und die MAC-Frames sind (im Gegensatz zu IP-Paketen) im VXLAN-Header mit der VNID der Layer-2-Domäne eingekapselt.

Es gelten die gleichen Prinzipien, da alle VNIDs auf dem EVPN-Gateway exportiert werden (in diesem Fall Typ-2-Routen/MAC-Adressen) und entsprechende RTs automatisch importiert werden. Der Speicherort für das Importieren und Exportieren von RTs befindet sich jedoch nicht auf Routingzonenebene, sondern im virtuellen Netzwerk selbst.

Erweiterung der Steuerungsebene: EVPN-Gateway

Apstra verwendet das Konzept eines "EVPN-Gateways". Dieses Gerät kann theoretisch ein Leaf-, Spine- oder Superspine-Fabric-Knoten sowie das DCI-Gerät sein. EVPN-Gateways trennen die Fabric-Seite vom Netzwerk, das die Standorte miteinander verbindet und die standortinternen VTEPs verschleiert.

In Apstra ist ein EVPN-Gateway ein Gerät, das zu einer EVPN-Fabric gehört und sich an deren Rand befindet, die auch mit einem externen IP-Netzwerk verbunden ist. In einem Apstra EVPN-Blueprint ist dies immer ein Border-Leaf-Gerät. Das EVPN-Gateway eines Datencenters stellt BGP EVPN-Peering mit einem oder mehreren reziproken EVPN-Gateways in einem anderen Datencenter her. Das "andere" EVPN-Gateway ist in der Terminologie von Apstra das "Remote EVPN Gateway". Das lokale EVPN-Gateway wird im Blueprint als eines der von Apstra verwalteten Geräte angesehen und bei der Erstellung des "Remote-EVPN-Gateways" ausgewählt. Das lokale EVPN-Gateway ist der Border-Leaf-Switch mit einer oder mehreren externen Routing-Verbindungen für den ein- und ausgehenden Datenverkehr in und aus der EVPN Clos-Fabric.

Aufgrund dieser Funktion können Sie ein lokales EVPN-Gateway (immer ein von Apstra verwalteter Switch) für das Peeren mit einem nicht von Apstra verwalteten oder sogar einem nicht Spine-Leaf-Gerät in einem anderen DC konfigurieren. Das EVPN Gateway BGP-Peering wird verwendet, um alle EVPN-Attribute von innerhalb eines Pods nach außerhalb des Pods zu übertragen. In der Apstra-Umgebung repräsentiert jeder Entwurf ein Datencenter. Wenn zwei oder mehr Standorte von Apstra verwaltet werden, müssen Sie dennoch jede Website so konfigurieren, dass sie auf die "Remote-EVPN-Gateways" in anderen Standorten verweist. Es wird empfohlen, für jedes Datencenter mehrere redundante EVPN-Gateways zu erstellen. Derzeit besteht auch eine vollständige Mesh-Anforderung zwischen EVPN-Gateways, obwohl diese Anforderung in zukünftigen Versionen entfernt wird.

Underlay-VTEP-Routenankündigungen

Die Underlay-Erreichbarkeit zu VTEP-IP-Adressen oder einer gleichwertigen zusammenfassenden Route muss reziprok festgelegt werden. Jeder Standort muss diese VTEP-Loopbacks innerhalb der Standardroutingzone in die exportierten BGP (IPv4)-Underlay-Ankündigungen ankündigen. Loopbacks in der Routing-Richtlinie sind standardmäßig aktiviert.

Remote-EVPN-Gateways erstellen

VORSICHT:

Standardmäßig ist ESI MAC msb (höchstwertiges Byte) auf allen Blueprints auf 2 gesetzt. Jeder vernetzte Apstra-Entwurf muss über einen eigenen MSB verfügen, um Probleme zu vermeiden, die sich auf den Service auswirken. Ändern Sie ESI MAC msb vor dem Erstellen von Gateways entsprechend. (Sie können einen von ihnen auf dem Standardwert belassen.)

Remote EVPN Gateway ist eine logische Funktion, die Sie überall und auf jedem Gerät instanziieren können. Es erfordert BGP-Unterstützung im Allgemeinen, L2VPN/EVPN AFI/SAFI im Speziellen. Um eine BGP-Sitzung mit einem EVPN-Gateway einzurichten, sollten IP-Konnektivität sowie Konnektivität mit TCP-Port 179 (IANA weist BGP-TCP-Ports zu) verfügbar sein.

Hinweis:

Aus Gründen der Ausfallsicherheit empfehlen wir, mindestens zwei Remote-Gateways für dieselbe EVPN-Remotedomäne zu haben.

1. Navigieren Sie im Blueprint zu Gestuftes >DCI-> über die Oberseite oder zu externe Gateways , und klicken Sie auf Darüber oben oder externes Gateway erstellen.
2. Geben Sie im sich öffnenden Dialogfeld die folgenden Informationen für das Remote-EVPN-Gateway ein.

   Bei der Erweiterung von L2-Netzwerken zwischen Datencenter-Fabrics haben Sie die Möglichkeit, nur EVPN-Routentyp-RT-5-Präfixe auszutauschen (schnittstellenloses Modell). Dies ist nützlich, wenn nicht alle Host-Routen zwischen den Standorten der Datencenter ausgetauscht werden müssen. Dies führt zu geringeren Anforderungen an die Routing-Informationsbasis (RIB), auch bekannt als Routing-Tabelle, und die Weiterleitungsinformationsbasis (FIB), auch bekannt als Weiterleitungstabelle, auf DCI-Geräten.

3. Wählen Sie die lokalen Gateway-Knoten aus. Dies sind die Geräte im Entwurf, die mit einem lokalen EVPN-Gateway konfiguriert werden. Sie können ein oder mehrere Geräte auswählen, die per Peer mit dem konfigurierten EVPN-Remote-Gateway verbunden werden sollen. Mit der Abfragefunktion können Sie die entsprechenden Knoten finden. Es wird empfohlen, mehrere Border-Leaf-Geräte zu verwenden, die über direkte Verbindungen zu externen generischen Systemen verfügen (als externe Router gekennzeichnet).
4. Klicken Sie auf Erstellen , um das Gateway bereitzustellen und zur Tabellenansicht zurückzukehren.
5. Wenn Sie bereit sind, die Geräte im Blueprint bereitzustellen, bestätigen Sie Ihre Änderungen.

Wir empfehlen die Verwendung mehrerer Remote-EVPN-Gateways. Wiederholen Sie die obigen Schritte, um weitere Remote-EVPN-Gateways zu konfigurieren.

Wenn Sie die Remote-EVPN-Gateways für einen anderen Apstra-Blueprint konfigurieren, müssen Sie die Remote-EVPN-Gateways separat in diesem Blueprint konfigurieren und bereitstellen.

Sobald die Änderung implementiert ist, überwacht Apstra die BGP-Sitzung für die entfernten EVPN-Gateways. Um Anomalien aus dem Blueprint anzuzeigen, navigieren Sie zu Aktive > Anomalien.

Erweiterte Routing-Zone

RT-Import-/Exportrichtlinien (Route-Target) auf Geräten, die Teil des erweiterten Dienstes sind, regeln die EVPN-Routeninstallation. Legen Sie Routenzielrichtlinien fest, um Import- und Exportroutenziele hinzuzufügen, die Apstra für Routing-Zonen/VRFs verwendet. Dies tun Sie, wenn Sie Routing-Zonen erstellen. Navigieren Sie zu Abgestufte > Virtual > Routing-Zonen und klicken Sie auf Routing-Zone erstellen. Weitere Informationen finden Sie unter Routingzonen.

Hinweis:

Das generierte Standard-Routenziel für Routing-Zonen ist <L3 VNI>:1. Sie können diesen Standardwert nicht ändern.

Um zu bestätigen, dass die korrekten Routen bei VTEP empfangen werden, stellen Sie sicher, dass L3VNIs und Routenziel zwischen der Blueprint- und der Remote-EVPN-Domäne identisch sind.

Verbesserte virtuelle Netzwerke

Sie können zusätzliche Import- und Export-Routen-Ziele hinzufügen, die Apstra für virtuelle Netzwerke verwendet.

Hinweis:

Das Standard-Routenziel, das Apstra für virtuelle Netzwerke generiert, ist <L2 VNI>:1. Sie können das nicht ändern.

Für die Intra-VNI-Kommunikation wird L2VNI-spezifische RT verwendet. Der Import-RT wird verwendet, um zu bestimmen, welche empfangenen Routen für einen bestimmten VNI gelten. Um eine Verbindung herzustellen, müssen die Layer-2-VNIs zwischen dem Blueprint und den Remote-Domänen identisch sein. SVI-Subnetze müssen domänenübergreifend identisch sein.

Darstellung der Remote-Gateway-Topologie

Remote-EVPN-Gateways werden in der Topologieansicht als Cloud-Elemente mit gestrichelten Linienverbindungen zu den Blueprint-Elementen dargestellt, mit denen BGP-Sitzungen eingerichtet werden, wie in der folgenden Abbildung dargestellt. (Das Bild unten unterscheidet sich geringfügig von neueren Versionen.)