Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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

DCI / EVPN Gateway Overvew

In der Vergangenheit haben Unternehmen die DCI-Technologie (Data Center Interconnect) als Baustein für Business Continuity, Disaster Recovery (DR) oder Continuity of Operations (COOP) genutzt. Diese Anwendungsfälle für die Serviceverfügbarkeit beruhten in erster Linie auf der Notwendigkeit, geografisch getrennte Datencenter mit Layer-2-Konnektivität zu verbinden, um Anwendungsverfügbarkeit und -leistung zu gewährleisten.

Mit dem Aufkommen hochgradig virtualisierter softwaredefinierter Datencenter (SDDC), Cloud-Computing und in jüngster Zeit auch Edge-Computing haben sich zusätzliche Anwendungsfälle ergeben:

  • Colocation-Erweiterung: Gemeinsame Nutzung von Rechen- und Speicherressourcen für Colocation-Datencenter.
  • Ressourcen-Pooling: Teilen und verschieben Sie Anwendungen zwischen Datencentern, um die Effizienz zu steigern oder die Endbenutzererfahrung zu verbessern.
  • Schnelle Skalierbarkeit: Erweitern Sie die Kapazität von einem Standort mit begrenzten Ressourcen auf eine andere Einrichtung oder ein anderes Datencenter.
  • Legacy-Migration: Verschieben Sie Anwendungen und Daten von älteren und ineffizienten Geräten und Architekturen in eine effizientere, leistungsfähigere und kostengünstigere Architektur.

Mit Apstra-Software können Sie eine anbieterübergreifende DCI-Lösung bereitstellen und verwalten, die einfach, flexibel und absichtsbasiert ist. Apstra nutzt das standardbasierte MP-BGP EVPN mit VXLAN, das in der Netzwerkbranche eine breite Akzeptanz von Soft- und Hardware erreicht hat. Sie können aus einer großen Auswahl an kostengünstiger Standardhardware von traditionellen Anbietern bis hin zu White-Box-ODMs und Softwareoptionen wählen, die von herkömmlichen herstellerintegrierten Netzwerkbetriebssystemen (NOS) bis hin zu disaggregierten Open-Source-Optionen reichen.

EVPN VXLAN ist ein standardbasierter (RFC-7432) Ansatz für den Aufbau moderner Datencenter. Sie umfasst sowohl Data Plane Encapsulation (VXLAN) als auch eine Routing-Control-Plane (MP-BGP EVPN Address Family) zur Erweiterung von Layer-2-Broadcast-Domänen zwischen Hosts sowie von Layer-3-Routing-Domänen in Spine-Leaf-Netzwerken. EVPN stützt sich auf ein reines Layer-3-Underlay für das Routing von VXLAN-Tunneldatenverkehr zwischen VXLAN-Tunnelendpunkten (VTEPs), führt eine neue Adressfamilie in die MP-BGP-Protokollfamilie ein und unterstützt den Austausch von MAC/IP-Adressen zwischen VTEPs. Die Ankündigung von Endpunkt-MACs und -IPs sowie die "ARP/ND-Unterdrückung" machen einen Großteil des Broadcast/Unknown/Multicast (BUM)-Datenverkehrs überflüssig und basieren auf ECMP-Unicast-Routing von VXLAN von Quell-VTEP zu Ziel-VTEP. Dies gewährleistet eine optimale Routenauswahl und eine effiziente Lastverteilung der Weiterleitungspfade für Overlay-Netzwerkverkehr.

So wie EVPN VXLAN innerhalb eines einzelnen Standorts zur Erweiterung von Layer 2 zwischen Hosts funktioniert, ermöglicht die DCI-Funktion Layer-2-Konnektivität zwischen Standorten. Die Apstra DCI-Funktion ermöglicht die Erweiterung von Layer-2- oder Layer-3-Services zwischen Datencentern für Disaster Recovery, Load Balancing von Aktiv-Aktiv-Standorten oder sogar zur Erleichterung der Migration von Services von einem Datencenter in ein anderes.

Einschränkungen:

  • EVPN-GW (DCI) zwischen der EVPN-Fabric verschiedener Anbieter wird nicht unterstützt.

  • IPv6 wird auf Remote-EVPN-Gateways nicht unterstützt. (Tatsächliche EVPN-Routen können IPv6 Typ 2 und Typ 5 enthalten.)

DCI-Bereitstellungsoptionen

Sie können Data Center Interconnect mit den folgenden Methoden implementieren:

  • Den Bogen überziehen
  • Gateways (GW)
  • Grenzrouter des autonomen Systems (ASBR)

Wenn Sie Hilfe bei der Auswahl der besten Option für Ihr Unternehmen benötigen, wenden Sie sich an Ihren Apstra Solutions Architect (SA) oder Systemingenieur (SE).

Die folgenden Merkmale gelten für alle Bereitstellungsoptionen:

  • Sie können Apstra DCI auf andere, von Apstra verwaltete Datencenter, nicht von Apstra verwaltete Datencenter oder sogar auf ältere Nicht-Spine-Leaf-Geräte ausweiten.
  • Die Implementierung und das Verhalten von Apstra sind in allen drei Fällen gleich.
  • Unabhängig davon, ob es sich bei dem Remote-Ende um einen anderen DCI GW oder einen ASBR handelt, ist dies für Apstra transparent.
  • Apstra verwaltet weder die GWs noch die ASBRs.

Den Bogen überziehen

DCI "Over the Top" ist eine transparente Lösung, d. h. EVPN-Routen werden in Standard-IP gekapselt 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 bis gar keiner Koordination mit WAN- oder Service Provider-Gruppen implementieren können. Dies reduziert die Implementierungszeiten und die internen Reibungsverluste im Unternehmen. Der Kompromiss besteht jedoch in 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 (gekennzeichnet als externer Router) am selben Standort ist, wodurch die EVPN-Attribute auf dieses Gateway erweitert werden. Mit dieser Lösung wird eine Fehlerdomäne pro Standort erstellt, wodurch verhindert wird, dass Fehler die Konvergenz an Remotestandorten beeinträchtigen und mehrere Fehlerdomänen erstellen. IP/MAC-Endpunkttabellen 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.

Grenzrouter des autonomen Systems (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 einheitliche Kapselung und eliminiert die dedizierte GW-Anforderung. Es ist betrieblich komplex, hat aber eine größere Skalierbarkeit im Vergleich zu "DCI Using Gateway" und "Over the Top".

Umsetzung

Sie können Routing-Zonen und virtuelle Netzwerke (VN) so erweitern, dass sie sich über von Apstra verwaltete Blueprints (über Pods) oder über Remote-Netzwerke (über Datencenter hinweg) erstrecken, die Apstra nicht verwaltet. Mit dieser Funktion wird die Rolle EVPN-Gateway (GW) eingeführt, bei der es sich um einen Switch handeln kann, der an der Fabric oder an RouteServern auf einem generischen System (als Server gekennzeichnet) beteiligt ist, das mit der Fabric verbunden ist.

Anwendungsfälle für EVPN-Gateways

  • Übertragen 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änenendungen für L2VNI / virtuelle Netzwerke.
  • Helfen Sie mit, die EVPN-Domäne von Apstra auf Apstra-verwaltete und Apstra auf nicht verwaltete Pods auszudehnen.
  • Keine VXLAN-Datenverkehrsterminierung auf Spine-Geräten: Verbinden Sie externe generische Systeme (gekennzeichnet als externe Router) mit 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 (die als externe Router gekennzeichnet sind) verbunden sind. Kurz gesagt, damit können IPv4-Routen zu Remote-VTEPs (in der Standard-Routing-Zone/VRF) ausgetauscht werden, und es ist nur Layer-3-Konnektivität erforderlich:

Den Bogen überziehen

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

In den nächsten Abschnitten werden die Verfahren zum Verbinden von zwei oder mehr BGP-basierten EVPN-Standorten (Ethernet VPN) in skalierbarer Weise über ein IP-Netzwerk beschrieben. Die Motivation besteht darin, die Erweiterung von EVPN-Standorten zu unterstützen, ohne sich auf typische DCI-Technologien (Data Center Interconnect) wie MPLS/VPLS verlassen zu müssen, 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 zur Unterstützung der VXLAN-Kapselung zwischen Gateway-Endpunkten erfordert. Bei einer solchen Implementierung werden EVPN-Routen über MP-BGP zwischen Standorten Ende-zu-Ende verlängert. Multi-Hop-BGP wird unter der Annahme aktiviert, dass es mehrere Layer-3-Hops zwischen Standorten über ein WAN gibt. Andernfalls sinkt die Standard-TTL auf 0, 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 den Standorten zusammengeführt. Durch das Zusammenführen von zuvor getrennten EVPN-Domänen an verschiedenen Standorten wird der Vorteil der Erweiterung von Layer-2- und Layer-3-Services (VRF) zwischen Standorten realisiert, aber die Standorte werden auch als eine einzige Fehlerdomäne gerendert. Ein Ausfall an einem Standort wird also zwangsläufig propagiert. Und jedes Mal, wenn Sie Layer 2 über das WAN zwischen Standorten ausdehnen, erweitern Sie auch die Flood-Domäne und damit auch den gesamten Datenverkehr über Ihre kostspieligen WAN-Verbindungen. Derzeit bietet diese Lösung keine Filterung oder QoS.

Hinweis:

Wenn einzelne Sites von Apstra durch separate Apstra-Blueprints verwaltet werden (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 voneinander erstellen und verwalten. Sie müssen VRFs und VNs manuell zwischen Standorten zuordnen, was zu Verwaltungsaufwand führt.

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 am flexibelsten und hat die niedrigste Eintrittsbarriere. Der Nachteil ist jedoch, dass es nur 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 impliziert auch, dass sich ein Broadcast-Sturm an einem Standort auf den anderen Standort ausdehnt.

Bei jeder DCI-Implementierung ist eine sorgfältige Ressourcenplanung und -koordination erforderlich. Das Hinzufügen weiterer Standorte erfordert einen exponentiellen Anstieg dieser Planung und Koordination. VTEP-Loopbacks im Underlay müssen durchgesickert sein. VNIDs müssen zwischen den 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.

Data Plane-Erweiterung: Layer 3

VXLAN-Netzwerk-IDs (VNIDs) sind Teil des VXLAN-Headers, die eindeutige VXLAN-Tunnel identifizieren, von denen jeder von den anderen VXLAN-Tunneln in einem IP-Netzwerk isoliert ist. Layer-3-Pakete können in ein VXLAN-Paket oder Layer-2-MAC-Frames direkt in ein VXLAN-Paket gekapselt 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, fügen Sie im Wesentlichen VXLAN-Tunnel zwischen Standorten zusammen. VNIDs müssen daher zwischen den Standorten übereinstimmen.

Es ist wichtig zu verstehen, dass eine bestimmte VNID nur einer VRF (oder Routing-Zone in der Apstra-Terminologie) zugeordnet ist. VNIDs sind innerhalb einer VRF vorhanden. Sie sind an einen VRF gebunden. Bei Layer-3-Services erfolgt das Stitching oder Erweitern jeder VNID durch den 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 desselben Werts automatisch am EVPN-Gateway (Edge) importiert, das in die Fabric kommt. Wenn Sie also die Layer-3-VNIDs an einem Standort so koordinieren, dass sie mit dem anderen übereinstimmen, 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 Gateway importiert weiterhin automatisch RTs mit dem gleichen Wert. Im folgenden Beispiel ist ein zusätzlicher Schritt des manuellen Hinzufügens der RTs vom anderen Standort erforderlich.

Data Plane-Erweiterung: Layer 2

Bei einem virtuellen Netzwerk kann es sich um einen reinen Layer-2-Service handeln (Layer-3-Anycast-Gateway wird nicht instanziiert). Dabei kann es sich um Rack-lokal (VLAN auf serverseitigen Ports, die in einem Rack enthalten sind) 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 (im Gegensatz zu IP-Paketen) werden mit der VNID der Layer-2-Domäne in den VXLAN-Header gekapselt.

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

Apstra-Workflow

Erweiterung der Steuerungsebene: EVPN-Gateway

Apstra verwendet das Konzept eines "EVPN-Gateways". Bei diesem Gerät kann es sich theoretisch um einen Leaf-, Spine- oder Superspine-Fabric-Knoten sowie um das DCI-Gerät handeln. EVPN-Gateways trennen die Fabric-Seite vom Netzwerk, das die Standorte miteinander verbindet, und maskieren die standortinternen VTEPs.

In Apstra ist ein EVPN-Gateway ein Gerät, das zu einer EVPN-Fabric gehört und sich dort 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 Apstra-Terminologie das "Remote EVPN Gateway". Es wird davon ausgegangen, dass es sich bei dem lokalen EVPN-Gateway um eines der von Apstra verwalteten Geräte im Blueprint handelt, und wird beim Erstellen des "Remote EVPN Gateway" ausgewählt. Das lokale EVPN-Gateway ist der Border-Leaf-Switch mit einer oder mehreren externen Routing-Verbindungen für den Datenverkehr, der in die und aus der EVPN Clos-Fabric ein- und ausgeht.

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

Underlay VTEP-Routenwerbung

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

Erstellen von Remote-EVPN-Gateways

VORSICHT:

Standardmäßig ist ESI MAC msb (höchstwertiges Byte) für alle Blueprints auf 2 gesetzt. Jeder Apstra-Blueprint, der verbunden ist, muss über eine eindeutige msb verfügen, um Probleme zu vermeiden, die den Service beeinträchtigen. Bevor Sie Gateways erstellen, ändern Sie ESI MAC msb 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 zum 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 Remote-EVPN-Domäne zu verwenden.

  1. Navigieren Sie im Blueprint zu Staged > Virtual > Remote EVPN Gateways und klicken Sie auf Remote EVPN Gateway erstellen.
  2. Geben Sie im daraufhin angezeigten 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 (ab Apstra Version 4.1.0), nur EVPN-Routentyp-RT-5-Präfixe auszutauschen (schnittstellenloses Modell). Dies ist nützlich, wenn nicht alle Hostrouten zwischen Datencenterstandorten ausgetauscht werden müssen. Dies führt zu geringeren Anforderungen an die Routing-Informationsbasis (Routing Information Base, RIB), auch als Routing-Tabelle bezeichnet, und die Forwarding Information Base (FIB), auch als Weiterleitungstabelle bezeichnet, auf DCI-Geräten.

  3. Wählen Sie die lokalen Gateway-Knoten aus. Dies sind die Geräte im Blueprint, die mit einem lokalen EVPN-Gateway konfiguriert werden. Sie können ein oder mehrere Geräte auswählen, die mit dem konfigurierten Remote-EVPN-Gateway verbunden werden sollen. Sie können die Abfragefunktion verwenden, um die entsprechenden Knoten zu finden. Wir empfehlen die Verwendung mehrerer Border-Leaf-Geräte, die über direkte Verbindungen zu externen generischen Systemen (gekennzeichnet als externe Router) verfügen.
  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. Um weitere Remote-EVPN-Gateways zu konfigurieren, wiederholen Sie die obigen Schritte.

Wenn Sie das/die Remote-EVPN-Gateway(s) für einen anderen Apstra-Blueprint konfigurieren, müssen Sie das/die Remote-EVPN-Gateway(s) separat in diesem Blueprint konfigurieren und bereitstellen.

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

Erweiterte Routing-Zone

RT (Route-Target) Import-/Exportrichtlinien auf Geräten, die Teil des erweiterten Service sind, regeln die EVPN-Routeninstallation. Legen Sie Routing-Zielrichtlinien fest, um Import- und Export-Routenziele hinzuzufügen, die Apstra für Routing-Zonen/VRFs verwendet. Dies geschieht beim Erstellen von Routing-Zonen. Navigieren Sie zu Staged > Virtual > Routing Zones und klicken Sie auf Create Routing Zone. 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 richtigen Routen bei VTEP empfangen werden, stellen Sie sicher, dass die L3VNIs und das Routenziel zwischen der Blueprint- und der Remote-EVPN-Domäne identisch sind.

Erweiterte virtuelle Netzwerke

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

Hinweis:

Das Standardroutenziel, das Apstra für virtuelle Netzwerke generiert, ist <L2 VNI>:1. Daran können Sie nichts ändern.

Für die Intra-VNI-Kommunikation wird L2VNI-spezifische RT verwendet. Die Import-RT wird verwendet, um zu bestimmen, welche empfangenen Routen für einen bestimmten VNI gelten. Um Konnektivität herzustellen, müssen Layer-2-VNIs zwischen der Blaupause und den Remotedomä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 Abbildung unten dargestellt. (Die Abbildung unten unterscheidet sich geringfügig von neueren Versionen.)