EVPN Multihoming – Übersicht
Einführung in EVPN Multihoming
Ein Ethernet VPN (EVPN) besteht aus Kunden-Edge-Geräten (CE), die mit Provider-Edge-Geräten (PE) verbunden sind, die den Edge der MPLS-Infrastruktur bilden. Ein CE-Gerät kann ein Host, ein Router oder ein Switch sein. Die PE-Geräte bieten virtuelle Layer-2-Bridge-Konnektivität zwischen den CE-Geräten. Es kann mehrere EVPNs im Provider-Netzwerk geben. Das Lernen zwischen den PE-Routern findet in der Steuerungsebene mit BGP statt, im Gegensatz zu herkömmlichem Bridging, wo das Lernen in der Data Plane stattfindet.
In Versionen vor Junos OS Version 15.1 war die Unterstützung der EVPN-Funktionen auf Routern der MX-Serie nur auf Router beschränkt, die nur MPC- und MIC-Schnittstellen nutzten. Ab Junos OS Version 15.1 können Router der MX-Serie, die DPCs verwenden, genutzt werden, um EVPN-Unterstützung auf der gerätegerichteten CE-Schnittstelle bereitzustellen.
DPC Unterstützung für EVPN wird mit den folgenden Überlegungen bereitgestellt:
DPCs bieten Unterstützung für EVPN im Aktiv-Standby-Modus, einschließlich Unterstützung für folgendes:
EVPN-Instanz (EVI)
Virtueller Switch
Integrierte Routing- und Bridging-Schnittstellen (IRB)
DPCs, die für die Bereitstellung der EVPN-Aktiv-Standby-Unterstützung vorgesehen sind, müssen die auf dem CE-Gerät ausgerichtete Linecard sein. Das PE-Gerät in der EVPN-Domain muss MPC- oder MIC-Schnittstellen sein.
Die EVPN-Multihoming-Funktion ermöglicht es Ihnen, einen Kundenstandort mit zwei oder mehr PE-Geräten zu verbinden, um redundante Konnektivität bereitzustellen. Ein CE-Gerät kann mit verschiedenen PE-Geräten oder demselben PE-Gerät vernetzt werden. Ein redundantes PE-Gerät kann dem Kunden einen Netzwerkservice anbieten, sobald ein Fehler erkannt wird. Daher hilft EVPN-Multihoming bei der Aufrechterhaltung des EVPN-Service und der Weiterleitung des Datenverkehrs zu und von der Multihomed-Site im Falle der folgenden Arten von Netzwerkausfällen:
PE-Geräte-zu-CE-Geräteverbindungsfehler
PE-Geräteausfall
Fehler bei der MPLS-Erreichbarkeit zwischen dem lokalen PE-Gerät und einem Remote-PE-Gerät
Abbildung 1 zeigt, wie ein CE-Gerät mit zwei PE-Routern vernetzt werden kann. Gerät CE 1 ist multihomed mit den Routern PE 1 und PE 2. Gerät CE 2 hat zwei potenzielle Pfade, um das Gerät CE 1 zu erreichen, und je nach Multihoming-Redundanzmodus sind nur ein Oder beide Pfade jederzeit aktiv. Der Multihoming-Modus bestimmt auch, welcher PE-Router oder -Router den Datenverkehr an das CE-Gerät weiterleite. Der PE-Router leitet Datenverkehr an das CE-Gerät weiter (auch als designated forwarder bezeichnet) verwendet MPLS LSP oder GRE-Tunnel, um den Datenverkehr weiterzuleiten. Wenn über diesen Pfad ein Fehler auftritt, wird ein neuer, dafür vorgesehener Weiterleitungsgeber ausgewählt, der den Datenverkehr an Device CE 1 weiterleite.
EVPN MPLS Multhoming-Funktionen, die von QFX10000-Switches unterstützt werden
Ab Junos OS 17.4R1 unterstützen QFX10000-Switches Multihoming für EVPN-MPLS. Nur Aktiv-Aktiv-Multihoming wird unterstützt. Die folgenden Unterfunktionen werden unterstützt:
ESI-Konfiguration (nur manuelle Typ 0-Konfiguration und IFD (physische Schnittstellen) werden unterstützt)
Aliasing und Label-Route
EVPN-Route Typ 4 (Ethernet-Segment-Route)
Erweiterte Communitys
BUM-Datenverkehr
Designated Forwarder Election (DF)-Rollen: DF und BDF
QFX10000-Switches über einen MPLS-EVPN-Core unterstützen nur die Standard-Switch-Routing-Instanz. Eine EVPN-Instanz (EVI) wird nicht unterstützt.
EVPN MPLS Multihoming auf ACX5448-Routern
Ab Junos OS Version 19.4R1 unterstützen ACX5448-Router Multihoming für EVPN-MPLS. Nur Aktiv-Aktiv-Multihoming wird unterstützt. Um EVPN Aktiv-Aktiv-Multihoming auf dem ACX5448-Router zu aktivieren, fügen Sie die evpn-mh-profile Konfigurationsaussage auf der Hierarchieebene [edit system packet-forwarding-options firewall-profile] bei.
user@host# set system packet-forwarding-options firewall-profile ? Possible completions: default-profile Set the profile to support default services. evpn-mh-profile Set the profile to support evpn-mh
Nach dem Ändern und Festlegen des Profils müssen Sie den Chassis-Management-Prozess neu starten, indem Sie den restart chassis-control CLI-Befehl zum Aufrufen des neuen Profils ausgeben.
Eine Syslog-Warnung wird angezeigt, um die PFE neu zu starten.
Grundlegendes zu EVPN-Multihoming-Konzepten
Abbildung 2 zeigt eine einfache EVPN-Netzwerktopologie zur Definition von EVPN-Multihoming-Konzepten. .
Ethernet segment— Wenn ein CE-Gerät mit zwei oder mehr PE-Routern vernetzt ist, bilden die Ethernet-Verbindungen ein Ethernet-Segment. Ein Ethernet-Segment wird als Link Aggregation Group (LAG) zum CE-Gerät angezeigt.
Die Verbindungen von den Routern PE1 und PE2 zum Gerät CE1 bilden ein Ethernet-Segment.
Beim Aktiv-Standby-Multihoming bilden die Verbindungen, die ein Ethernet-Segment bilden, eine Bridge-Domain. Im aktiv-aktiven Multihoming wird ein Ethernet-Segment als LAG für das CE-Gerät angezeigt.
ESI—Ein Ethernet-Segment muss einen eindeutigen Nicht-Zero-Bezeichner haben, den sogenannten Ethernet Segment Identifier (ESI). Der ESI ist als 10-Oktett-Ganzzahl codiert. Bei der manuellen Konfiguration eines ESI-Wertes muss das wichtigste Oktett, das als Typ-Byte bekannt ist, 00 sein. Wenn ein einzelnes CE-Gerät an ein Ethernet-Segment angeschlossen ist, ist der gesamte ESI-Wert Null.
Dem Ethernet-Segment des Multihomed Device CE1 wird ein ESI-Wert von 00:11:22:33:44:55:66:77:88:99 zugewiesen. Das Single-Homed-Gerät CE2 hat einen ESI-Wert von 0.
EVI— Eine EVPN-Instanz (EVI) ist eine EVPN-Routing- und Weiterleitungsinstanz, die alle an diesem VPN beteiligten PE-Router umfasst. Eine EVI wird auf den PE-Routern kundenbezogen konfiguriert. Jede EVI verfügt über einen eigenen Routenscheider und ein oder mehrere Routenziele.
Ein EVI wird auf den Routern PE1, PE2 und PE3 konfiguriert.
Ethernet tag— Ein Ethernet-Tag identifiziert eine bestimmte Broadcast-Domain, z. B. ein VLAN. Eine EVPN-Instanz besteht aus einer oder mehreren Broadcast-Domänen. Ethernet-Tags werden den Broadcast-Domänen einer bestimmten EVPN-Instanz vom Anbieter dieser EVPN zugewiesen. Jeder PE-Router in dieser EVPN-Instanz führt eine Zuordnung zwischen Broadcast-Domänenbezeichnern durch, die von jedem seiner angeschlossenen CE-Geräte und dem entsprechenden Ethernet-Tag verstanden werden.
Ethernet segment route—Die PE-Router, die mit einem multihomed CE-Gerät verbunden sind, verwenden BGP Ethernet-Segment-Routenmeldungen, um zu erkennen, dass jeder PE-Router mit demselben Ethernet-Segment verbunden ist. Die PE-Router werben für die Ethernet-Segment-Route, die aus einer erweiterten Community mit ESI- und ES-Import besteht.
Router PE1 und PE2 werben für eine ES-Route mit einer erweiterten Community mit ES-Import (zusammen mit anderen erweiterten Communitys wie dem Routenziel). Die PE-Router bauen auch einen Filter auf, der auf einer erweiterten Community mit ES-Import basiert, sodass nur diese PE-Router die ES-Route importieren und identifizieren, dass sie mit demselben Ethernet-Segment verbunden sind.
Extended community— Eine erweiterte Community ist in den meisten Hinsichten einer regulären Community ähnlich. EVPNs nutzen erweiterte Communitys, da der regelmäßige Mehrwert der Community mit vier Oktettn nicht genug Erweiterung und Flexibilität bietet. Eine erweiterte Community ist ein 8-Oktett-Wert, der in zwei Hauptabschnitte unterteilt ist.
BUM traffic— Diese Art von Datenverkehr wird an mehrere Ziele gesendet, einschließlich Broadcast-Datenverkehr, unbekannter Unicast-Datenverkehr, der im Ethernet-Segment übertragen wird, und Multicast-Datenverkehr.
DF— Wenn ein CE-Gerät mit zwei oder mehr PE-Routern vernetzt ist, werden je nach Multihoming-Betriebsart entweder ein oder alle multihomed PE-Router verwendet, um den Kundenstandort zu erreichen. Der PE-Router, der die primäre Rolle für die Weiterleitung von BUM-Datenverkehr an das CE-Gerät übernimmt, heißt Designated Forwarder (DF).
BDF— Jeder Router in anderen PE-Routern, die die automatische Erkennungsroute pro Ethernet-Segment für denselben ESI anzeigen und als Backup-Pfad dient, falls der DF auf einen Fehler kommt, wird als Backup Designated Forwarder (BDF) bezeichnet. Ein BDF wird auch als Nicht-DF-Router bezeichnet.
DF election— In jedem Ethernet-Segment nehmen die PE-Router an einem Verfahren namens Designated Forwarder Election teil, um die DF- und BDF-PE-Router auszuwählen.
EVPN-Multihoming-Betriebsart
Zu den verschiedenen Betriebsarten für EVPN-Multihoming gehören:
Single: Wenn ein PE-Router mit einem Single-Homed-Kundenstandort verbunden ist, ist dieser Modus in Betrieb. Der Single Mode ist der Standardbetriebsmodus und erfordert keine Konfiguration von Ethernet-Segmentwerten.
-
Aktiv-Standby: Wenn nur ein einzelner PE-Router zu einer Gruppe von PE-Routern gehört, die an ein Ethernet-Segment angeschlossen sind, den Datenverkehr an und von diesem Ethernet-Segment weiterleiten darf, wird das Ethernet-Segment für den Betrieb im Aktiv-Standby-Redundanzmodus definiert.
Um den Aktiv-Standby-Modus zu konfigurieren, fügen Sie den ESI-Wert und die
single-activeAnweisung auf der[edit interfaces]Hierarchieebene ein.Hinweis:Wir unterstützen keinen Aktiv-Standby-Multihoming-Modus auf Switches der QFX-Serie oder in EVPN-Konfigurationen mit VXLAN-Overlays. Wenn Sie also die Option auf Switches der
single-activeQFX-Serie oder in EVPN-VXLAN-Konfigurationen konfigurieren, ignoriert das Gerät dieses Konfigurationselement. Aktiv-Aktiv: Wenn alle an ein Ethernet-Segment angeschlossenen PE-Router Datenverkehr an und vom Ethernet-Segment weiterleiten dürfen, wird das Ethernet-Segment für den Betrieb im Aktiv-Aktiv-Redundanz-Modus definiert.
Hinweis:In Junos OS Version 14.2 und früher unterstützt der Switch der EX9200-Serie nur den Aktiv-Standby-Modus für EVPN-Multihoming.
Hinweis:Ab Junos OS-Version 14.1x53-D30 für QFX5100-Switches und Junos OS Version 18.2R1 für EX4600-Switches unterstützen diese Switches den aktiv-aktiven Modus für EVPN-Multihoming. In diesem Szenario fungieren QFX5100- und EX4600-Switches als Top-of-Rack -Switches (ToR) im Datencenter für virtuelle Netzwerke. EVPN-Multihoming-Aktiv-Funktionalität wird verwendet, um den Zugriff auf die Bare-Metal-Server zu ermöglichen, die mit den Top-of-Rack-Switches verbunden sind.
Hinweis:Ab Junos OS Version 14.1R4, 14.2, 15.1F6 und 16.1R1 unterstützt Junos OS den aktiv-aktiven Modus für EVPN-Multihoming auf Routern der MX-Serie.
Ab Junos OS-Versionen 16.1R4 und 16.2R2 unterstützen alle EX9200-Switches den aktiv-aktiv-Modus für EVPN-Multihoming.
Ab Junos OS 17.4R1 unterstützen QFX10000-Switches den aktiv-aktiv-Modus für EVPN-Multihoming.
Um den Aktiv-Aktiv-Modus zu konfigurieren, fügen Sie den ESI-Wert und die
all-activeAnweisung auf Der[edit interfaces]Hierarchieebene ein.Abbildung 3 zeigt eine Referenztopologie für EVPN Aktiv-Aktiv-Multihoming. Das Ethernet-Segment ESI1 für Geräte CE2 ist multihomed mit den Routern PE1, PE2 und PE3. Das Ethernet-Segment auf dem CE-Gerät kann entweder als Link Aggregation Group (LAG) oder als ECMP-Pfad konfiguriert werden. Die Geräte CE1 und CE3 sind die Single-Homed-Edge-Geräte des Kunden und haben einen ESI-Wert von 0.
EVPN Multihoming-Implementierung
Der EVPN-Aktiv-Standby-Multihoming-Modus bietet Redundanz für Access-Link-Ausfälle und PE-Knotenausfälle für das Multihomed CE-Gerät und basiert auf dem EVPN draft-ietf-l2VPN-eVPN-03.
Die Junos OS-Implementierung der EVPN-Multihoming-Aktiv-Standby- und Aktiv-Aktiv-Betriebsmodi umfasst folgendes:
- Neue BGP-NLRIs
- Neue erweiterte Communities
- Neue EVPN-Routentypen
- Ankündigung multihomed Proxy MAC und IP Address Route
- Aktualisierung der MAC-Weiterleitungstabelle
- Datenverkehrsfluss
- Aliasing
- EVPN Active-Active Multihoming und Multichassis Link Aggregation
- EVPN Active-Active Multihoming und IRB
- Beispielkonfiguration
Neue BGP-NLRIs
Zur Unterstützung von EVPN-Multihoming wurden die folgenden neuen NLRI-Routen (Network Layer Reachability Information) eingeführt:
Automatische Erkennung von Routen pro Ethernet-Segment
Routenfunktionen für die automatische Erkennung
Zu den Funktionen der automatischen Erkennungsrouten-NLRI gehören:
Dies ist eine obligatorische Route des Typs 1, die für schnelle Konvergenz und für die Werbung für das Split Horizon-Label verwendet wird. Sie wird auch als Massenrückzugsroute bezeichnet.
Routenscheider des Typs 1 werden mit der IP-Adresse (Loopback) des ursprünglichen PE-Routers als Routenscheiderwert verwendet.
Diese Route enthält den ESI im NLRI (nichtzero, wenn es sich um ein Multihomed-PE handelt, andernfalls null).
Das Split Horizon Label ist nur pro ESI und enthält ein explizites NULL (0).
Das Bit im Aktiv-Standby-Flag-Feld in der erweiterten COMMUNITY des ESI-Labels wird für die Signalisierung des Aktiv-Standby-Modus (Bit-Set) verwendet.
Die 3-Byte-Labelwerte im NLRI und dem Ethernet-Tag sind Null.
Diese Route wird von allen Multihomed- und Remote-PE-Routern angekündigt und importiert, die dieselbe EVI im Werbe-ESI verwenden.
Routenankündigung mit automatischer Erkennung
Aktiv-Standby-Modus
Im Aktiv-Standby-Modus kündigt der designierte Weiterleitungsgeber (DF) die AutoDiscovery-Route pro Ethernet-Segment mit einer erweiterten Community mit DEM ESI-MPLS-Label an, die das Standby-Bit auf 1 festgelegt hat. Die Automatische Erkennungsroute wird per ESI angekündigt, und das ESI-Label ist auf 0 festgelegt, wenn der Aktiv-Standby-Modus in Betrieb ist.
Die Automatische Erkennungsroute wird von allen Multihomed- und Remote-PE-Routern importiert, die Teil der EVI sind. Beim Erhalt der automatischen Erkennungsroute erfahren die PE-Router in der Netzwerktopologie, dass der Aktiv-Standby-Multihoming-Modus für den angekündigten ESI in Betrieb ist.
Aktiv-Aktiv-Modus
Im aktiv-aktiv-Modus kündigt jedes multihomed-PE-Gerät eine obligatorische AutoDiscovery-Route pro Ethernet-Segment wie im Aktiv-Standby-Zustand an. Im Aktiv-Aktiv-Zustand wird die AutoDiscovery-Route pro Ethernet-Segment jedoch so modifiziert, dass das in der erweiterten MPLS-Community enthaltene Aktiv-Standby-Bit freigegeben wird, um anzuzeigen, dass der Aktiv-Aktiv-Modus in Betrieb ist. Die Automatische Erkennungsroute pro Ethernet-Segment im Aktiv-Aktiv-Modus enthält auch das Label Split Horizon.
In Abbildung 3 stellen die Router PE1, PE2 und PE3 für das Ethernet-Segment ESI1 die Route zur automatischen Erkennung an. Router PE4 empfängt diese Route zur automatischen Erkennung.
Route-Auszahlung mit automatischer Erkennung
Die automatische Erkennungsroute pro Ethernet-Segmentabzug kann zu einer Massenentzug führen. Die Funktion zum Massenentzug wird verwendet, wenn ein Link im ESI ausfällt oder wenn sich die ESI-Konfiguration ändert.
Wenn die Verbindung zwischen einem multihomed CE-Gerät und einem multihomed PE-Gerät fehlschlägt, zieht das PE-Gerät die automatische Erkennungsroute pro Ethernet-Segment zurück. In einem solchen Fall wird die Funktion zur Massenentzugsfunktion von den anderen PE-Geräten wie folgt gehandhabt:
Pe-Remote-Gerät
Wenn ein Entferntes PE-Gerät das BGP-Update zur Massenentzugung empfängt, wird folgendes am PE-Remote-Gerät durchgeführt:
Der aktuelle nächste Hop, der das Remote-ESI oder CE-Gerät erreicht, wird gelöscht.
Ein neuer Nächster Hop durch die verbleibenden multihomeden PE-Geräte wird erstellt, um das Remote-ESI- oder CE-Gerät zu erreichen.
Alle MAC-Routen hinter dem CE-Gerät werden mit dem neu erstellten nächsten Hop aktualisiert.
Ab Junos OS Version 17.4R1 unterstützt Junos OS Dynamic List Next Hops in einem EVPN-Netzwerk. Wenn jetzt die Verbindung zwischen dem CE-Gerät und einem Multihome-PE-Gerät fehlschlägt, wird der nächste Hop zum ESI oder CE aktualisiert, wodurch die Notwendigkeit einer Massenentzug reduziert wird. Weitere Informationen zur Aktivierung der dynamischen Liste des nächsten Hops finden Sie unter Konfigurieren der dynamischen Liste des nächsten Hops.
Andere multihomed PE-Geräte
Infolge des Massenentzugs erfolgt das Load Balancing auf dem multihomed CE-Gerät aufgrund der folgenden Punkte:
Wenn die anderen multihomed PE-Geräte die gleichen MAC-Adressen auf dem Link zum betreffenden ESI erhalten.
In diesem Fall werden die lokalen Routen bevorzugt. Wenn die Remote-Routen, die vom DF PE-Gerät gelernt wurden, zurückgezogen werden, hat dies keine Auswirkungen auf Routen, die auf den lokalen ESI verweisen.
Wenn die anderen Multihomed-PE-Geräte nicht den gleichen Satz von MAC-Adressen über den Link zum betreffenden ESI erhalten haben.
In diesem Fall installieren die PE-Geräte die MAC-Routen, die auf den betreffenden ESI verweisen, obwohl die MACs aus der Ferne vom DF PE-Gerät gelernt werden. Wenn das DF PE-Gerät diese Routen zurückzieht, werden die zurückgezogenen Routen überspült. Pakete, die für die gespülten MAC-Adressen bestimmt sind, werden in allen lokalen Segmenten überflutet.
Ethernet-Segment-Route
Ethernet-Segment-Route-Funktionen
Zu den Funktionen der Ethernet-Segment-Route-NLRI gehören:
Dies ist eine Typ-4-Route. Der Zweck dieser Route besteht darin, es den mit demselben Ethernet-Segment verbundenen PE-Routern zu ermöglichen, sich beim Austausch dieser Route automatisch mit minimaler Konfiguration gegenseitig zu erkennen.
Diese Route ist mit einer erweiterten ES-Import-Community verbunden, deren ESI-Wert auf 6 Byte verkürzt wird, ähnlich wie ein Routenziel.
Diese Route wird nur von PE-Routern angekündigt und importiert, die im Werbe-Ethernet-Segment multihomed sind.
Ankündigung für Ethernet-Segment-Routen
Die Ethernet-Segment-Route wird zwischen allen PE-Routern innerhalb eines Datencenters mit der erweiterten Community von ES-Import ausgetauscht. Die erweiterte Community für ES-Importe basiert auf den ESI PE-Routern, die multihomed sind, und die Ethernet-Segment-Route überträgt den ESI-Wert in Bezug auf das Ethernet-Segment, in dem die PE-Router multihomed sind.
Die Ethernet-Segment-Routen werden basierend auf der erweiterten Community von ES-import gefiltert, sodass nur PE-Router, die auf demselben Ethernet-Segment multihomed sind, diese Route importieren. Jeder PE-Router, der mit einem bestimmten Ethernet-Segment verbunden ist, erstellt eine Importfilterregel, um eine Route zu importieren, die die erweiterte Community von ES-import enthält.
Automatische Erkennung von Routen pro EVPN-Instanz
Im aktiv-aktiv-Modus kündigt jedes der multihomed PE-Geräte eine AutoDiscovery-Route pro EVPN-Instanz (EVI) mit einem gültigen MPLS-Label an. Diese Route wird per ESI angekündigt und von den Remote-PE-Geräten importiert. Das MPLS-Label, das in der automatischen Erkennungsroute per EVI enthalten ist, wird später für das Aliasing verwendet.
Neue erweiterte Communities
Eine erweiterte Community ist in den meisten Hinsichten einer normalen Community ähnlich. Einige Netzwerkimplementierungen, wie z. B. virtuelle private Netzwerke (VPNs), verwenden erweiterte Communitys, da der regelmäßige Mehrwert der Community mit vier Oktett nicht genug Erweiterung und Flexibilität bietet. Eine erweiterte Community ist ein 8-Oktett-Wert, der in zwei Hauptabschnitte unterteilt ist.
Zur Unterstützung von Aktiv-Standby-Multihoming wurden die folgenden erweiterten Communitys eingeführt:
ESI-Import
Diese erweiterte Community ist an die ES-Route angeschlossen und wird aus dem ESI-Importwert aufgefüllt, der aus dem konfigurierten ESI-Wert unter der Schnittstelle extrahiert wird. Um das Problem eines Konflikts mit einem anderen regulären Routenziel zu lösen, wird der Typ auf 0x06 festgelegt, der von der IANA zugewiesen wurde.
Das esi-import erweiterte Community-Routenziel füllt die Liste der Importroutenziele auf, die für die spezielle Instanz konfiguriert sind, von der aus die ES-Route mit dieser Community angekündigt wird.
Daher werden eingehende ESI-Routen mit dem gleichen ESI-Importwert in der erweiterten Community von den PE-Routern importiert, wenn der PE-Router mit einem Ethernet-Segment mit dem gleichen ESI-Wert konfiguriert ist. Sobald der PE-Router eine Reihe dieser ESI-Routen empfängt, die den gleichen ESI-Import erweiterten Community-Wert haben, kann die DF- und BDF-Wahl lokal durchgeführt werden.
Wenn die ESI-import Extended Community nicht implizit erstellt wird, muss eine Richtlinie so konfiguriert werden, dass alle Routenziele an die automatische Erkennungsroute pro Ethernet-Segment angefügt werden.
Geteilter Horizont
Wenn beispielsweise ein CE-Gerät, das auf zwei oder mehr PE-Geräte in einem Ethernet-Segment (ESI1) multihomed ist und im Aktiv-Aktiv-Redundanz-Modus arbeitet, ein BUM-Paket an eines der nicht-DF PE-Geräte sendet (z. B. PE1), leitet Gerät PE1 dieses Paket an alle oder einen Teilmenge der anderen PE-Geräte in dieser EVPN-Instanz weiter, einschließlich des DF PE-Geräts für dieses Ethernet-Segment. In diesem Fall legt das DF-PE-Gerät, bei dem das CE-Gerät multihomed ist, das Paket ab, ohne es an das CE-Gerät weiterzuleiten. Diese Filterung wird als geteilter Horizont bezeichnet.
Split Horizon-Signalübertragung
Die erweiterte Split Horizon-Community ist an die Automatische Erkennungsroute pro Ethernet-Segment angeschlossen. Der Wert der erweiterten Community ist der geteilte Horizont oder das Poisson-Label selbst, das 3 Bytes beträgt und als undurchsichtiges Attribut angekündigt wird.
Werbung für Split Horizon
Im Aktiv-Standby-Modus wird das Standby-Bit in der Split Horizon Extended Community auf 1 und das ESI Split Horizon Label auf 0 festgelegt.
Im aktiv-aktiv-Modus wird die erweiterte Split Horizon-Community geändert, um das Standby-Bit auf 0 zu löschen und enthält ein gültiges ESI-Label, das für Split Horizon-Zwecke verwendet wird.
Split Horizon MPLS-Routen
Das DF PE-Gerät kündigt eine Automatische Erkennungsroute pro Ethernet-Segment mit einem Split Horizon-Label A und einer integrativen Multicast-Route mit Label B für die Weiterleitung des BUM-Datenverkehrs an. Auf der DF kann das BUM-Paket aus dem Core mit folgenden Labeln versehen werden:
Wenn die NICHT-DF-PE-Geräte ein BUM-Paket auf ihren single-homed ESIs erhalten, wird das BUM-Paket mit dem Multicast-Label B an das DF PE-Gerät gesendet.
Wenn die NICHT-DF-PE-Geräte ein BUM-Paket auf ESI1 empfangen, wird das BUM-Paket mit zwei MPLS-Labeln an das DF PE-Gerät mit zwei MPLS-Labeln gesendet – dem Multicast-Label B als äußerem Label und dem Split Horizon-Label A als innerem Label.
Im EVPN-Multihoming-Szenario hat das Multicast-Label B das S-Bit auf 1 festgelegt, wenn es das einzige Label im Labelstack ist. In diesem Fall muss das BUM-Paket auf alle lokalen ESIs auf dem DF PE-Gerät überflutet werden. Aber das Label B hat das S-Bit auf 0 festgelegt, wenn Split Horizon Label A das innerste Label im Labelstack ist. In diesem Fall müssen die BUM-Pakete auf allen lokalen ESIs auf dem DF-PE-Gerät überflutet werden, mit Ausnahme des ESI, der dem Split Horizon-Label A zuordnet.
Wenn Pakete von einem multihomed CE-Gerät zu einem NICHT-DF PE-Gerät auf multihomed Segment ESI1 stammen, wird das ESI-Label zuerst übertragen, wenn ein nicht-DF PE-Gerät dieses Paket an das DF-PE-Gerät sendet, das df in seiner automatischen Erkennungsroute pro Ethernet-Segment an das nicht-DF PE-Gerät angekündigt hat. Das nicht-DF-PE-Gerät pusht auch das inclusive Multicast-Label, das das DF PE-Gerät in seiner integrativen Multicast-Route angekündigt hat, und drückt das LSP-Label weiter. Der MPLS-Header enthält also zwei Label innerhalb eines 32-Bit-Feldes.
Die Basis-EVPN-Funktionalität verwendet einen Tabellen-Next-Hop, um die MPLS-Tabelle mit der entsprechenden EVPN-EVI-Tabelle zusammenzufügen. In der EVPN-EVI-Tabelle wird die Mac-Suche durchgeführt, um das Paket zu wechseln.
Die folgenden Routen sind in der Mpls.0-Tabelle für EVPN-Multicast programmiert:
Die (Multicast-Label, S=1) Route verweist auf den tabellennächsten EVPN-EVI-Hop.
Die (Multicast-Label, S=0) Route verweist auf den MPLS-Tabellen-Next-Hop. Diese Route schleift das Paket zurück zur MPLS-Tabelle, nachdem das Multicast-Label geknallt wurde.
Die (split horizon-label) Route zeigt auf den EVPN-EVI Table-Next Hop. Dies ist derselbe Tabellen-Next-Hop, der von der Multicast-Label-S=1-Route verwendet wird.
Neue EVPN-Routentypen
Der EVPN-Multihoming-Modus unterstützt die folgenden EVPN-Routentypen:
Automatische Erkennungsroute pro Ethernet-Segment
Automatische Erkennungsroute pro EVPN-Instanz (EVI)
Ethernet-Segment-Route
Diese Routentypen entsprechen der folgenden Benennungskonvention:
<route-type>:<RD>::<esi>::<route-specific>/304
Zum Beispiel:
Automatische Erkennungsroute pro Ethernet-Segment –
1:10.255.0.2:0::112233445566778899::0/304Automatische Erkennungsroute pro EVI –
1:100.100.100.1:1::22222222222222222222::0/304Ethernet-Segment-Route –
4:10.255.0.1:0::112233445566778899:10.255.0.1/304
Wo:
route-type— Typ der EVPN-Route.1 – Automatische Erkennungsroute pro Ethernet-Segment.
1 – Automatische Erkennungsroute pro EVI.
4 – Ethernet-Segment-Route.
5 – Route mit VXLAN/MPLS-Kapselung
RD— Routen-Unterscheidungswert.Der Routenscheiderwert wird auf die IP-Adresse des PE-Routers gefolgt von 0 gesetzt.
esiEthernet-Segment-Kennung. Wird als 10 Bytes hexadezimale Bytes angezeigt, und führende 00 Bytes werden nicht angezeigt.route-specific– Unterscheidet sich je nach Routentyp.Automatische Erkennungsroute pro Ethernet-Segment und Automatische Erkennungsroute pro EVI– Dieser Wert ist ein MPLS-Label.
Hinweis:Das MPLS-Label wird in der umfangreichen Ausgabe angezeigt, obwohl es nicht im Prefix enthalten ist.
Ethernet-Segment-Route: Dieser Wert ist die Ursprungs-IP-Adresse.
304– Maximale Anzahl von Bits in einer EVPN-Route. Dies sind keine sehr nützlichen Informationen und könnten aus der Anzeige entfernt werden. Es kann jedoch nützlich sein, um eine EVPN-Route schnell zu identifizieren, sei es visuell oder mit den Passenden Betreibern.
Ankündigung multihomed Proxy MAC und IP Address Route
Ab Junos OS Version 18.4R1 sendet Junos Proxy-MAC- und IP-Adressrouten-Ankündigung von PEs, die mehrfach vernetzt sind, an ein CE-Gerät. Junos verwendet ein Proxy-Flag in der erweiterten EVPN-Layer-2-Attribute-Community, um die Nachricht als Proxy-MAC und IP-Adressen-Ankündigung zu identifizieren. Ein PE, das von einer MAC- und IP-Adresse lernt, sendet eine normale EVPN-Route-2 -Route-Ankündigung (MAC und IP-Adresse). Die anderen PEs im Ethernet-Segment, die von der neuen Route aus dem Remote-PE lernen, senden jetzt eine MAC- und IP-Adressroutennachricht mit dem Proxy-Bitsatz. Wenn der MAC- und IP-Adresseintrag altert oder die Verbindung zwischen PE und CE fehlschlägt, müssen die Einträge erneut gelernt werden und der Datenverkehr kann verloren gehen. Dies verhindert Datenverkehrsverlust, wenn eine der Verbindungen zu einem Leaf-Gerät ausfällt. Multihomed Proxy MAC wird automatisch aktiviert.
Aktualisierung der MAC-Weiterleitungstabelle
Beim Aktiv-Standby-EVPN-Multihoming werden die MAC-Adressen als routingfähige Adressen behandelt, und das MP-IBGP-Protokoll wird verwendet, um die MAC-Adressen des Kunden zu übertragen. MAC-Lernen an den PE-Routern findet nicht in der Data Plane, sondern in der Steuerungsebene statt. Dies führt zu mehr Kontrolle in Bezug auf den Lernmechanismus.
Ein PE-Router führt MAC-Learning in der Data Plane für Pakete durch, die von einem Kundennetzwerk für eine bestimmte EVI stammen. Für CE-MAC-Adressen, die sich hinter anderen PE-Routern befinden, werden die MAC-Adressen in BGP NLRI mit einem neuen MAC-Ankündigungsroutentyp angekündigt.
Das MAC-Lernen umfasst zwei Arten:
Lokales MAC-Lernen: PE-Router müssen den lokalen MAC-Lernprozess über Standardprotokolle unterstützen.
Remote-MAC-Lernen: Sobald der lokale Lernprozess abgeschlossen ist, können die PE-Router die lokal gelernte MAC-Adresse über MP-IBGP an entfernte PE-Router-Knoten ankündigen. Dieser Prozess des Empfangens der Remote-MAC-Adressen angeschlossener Kunden über MP-IBGP wird als Remote-MAC-Lernprozess bezeichnet.
Der MAC-Ankündigungsroutentyp wird verwendet, um lokal erlernte MAC-Adressen in BGP an entfernte PE-Router anzukündigen. Wenn eine individuelle MAC-Adresse angekündigt wird, entspricht das IP-Adressfeld dieser MAC-Adresse. Wenn der PE-Router eine ARP-Anfrage nach einer IP-Adresse von einem CE-Gerät erkennt und der PE-Router die MAC-Adressbindung für diese IP-Adresse hat, führt der PE-Router einen ARP-Proxy aus und antwortet auf die ARP-Anfrage.
Der ARP-Proxy wird nur für das Gateway und nicht für den Host durchgeführt.
Das MPLS-Label-Feld hängt von der Art der Zuweisung ab. Der PE-Router kann ein einziges MPLS-Label für alle MAC-Adressen pro EVI ankündigen, was die geringste Anzahl von MPLS-Labeln erfordert und den PE-Router-Speicher speichert. Bei der Weiterleitung an das Kundennetzwerk muss der PE-Router jedoch eine MAC-Suche durchführen, die zu einer Verzögerung führen und die Anzahl der CPU-Zyklen erhöhen kann.
Datenverkehrsfluss
Beim EVPN-Multihoming wird der Datenverkehr in der Weiterleitungsebene ausgeführt. Flood-Routen werden für das Überfluten der Pakete erstellt und in den folgenden Szenarien verwendet:
Wenn ein Paket über einen lokalen ESI empfangen wird
Wenn ein Paket vom Core empfangen wird
Die Datenverkehrsströme in EVPN-Multihoming können auf den beiden Datenverkehrstypen basieren:
Unicast-Datenverkehr
Unicast-Datenverkehr ist eine Punkt-zu-Punkt-Kommunikation mit einem Sender und einem Empfänger. In einer multihomed-EVPN wird Unicast-Datenverkehr wie folgt weitergeleitet:
Im Aktiv-Standby-Modus
CE bis Core: Der Datenverkehr wird vom DF PE-Router erlernt und weitergeleitet.
Core to CE: Der entfernte PE-Router lernt die MAC-Adressen vom DF und leitet den gesamten Unicast-Datenverkehr an den DF PE-Router weiter.
Im aktiv-aktiv-Modus
CE bis Core: Der Datenverkehr wird auf alle vernetzten Multihomed-PE-Geräte lastausgleichen.
Core to CE: Der Datenverkehr von den entfernten PE-Geräten wird zu allen multihomeden PE-Geräten, die mit dem Remote-CE-Gerät verbunden sind, lastausgleichen.
BUM-Datenverkehr
Datenverkehr, der an mehrere Ziele gesendet wird, einschließlich Broadcast-Datenverkehr, unbekannter Unicast-Datenverkehr, der im Ethernet-Segment übertragen wird, und Multicast-Datenverkehr wird als BUM-Datenverkehr bezeichnet. In einer multihomed EVPN wird BUM-Datenverkehr wie folgt weitergeleitet:
Im Aktiv-Standby-Modus
CE to Core: Das CE-Gerät überflutet jeden BUM-Datenverkehr an alle Verbindungen im Ethernet-Segment. Der DF PE-Router mit dem aktiven Pfad leitet die BUM-Pakete an den Core weiter. Der BDF-PE-Router im Standby-Modus löscht den gesamten Datenverkehr vom CE-Gerät, da sich der EVPN-Multihomed-Status der Schnittstelle im Blockierungsstatus befindet. Wenn das CE-Gerät jedoch über separate Links oder LAGs mit den PE-Geräten verbunden ist, erreicht der BUM-Datenverkehr sowohl die DF- als auch die BDF-PE-Geräte.
Core to CE: Die remoten PE-Router überfluten den gesamten BUM-Datenverkehr sowohl an die DF- als auch an BDF-PE-Router. Nur der DF leitet den BUM-Datenverkehr an das CE-Gerät weiter. Der BDF-PE-Router löscht den gesamten Datenverkehr, da sich der EVPN-Multihomed-Status der Schnittstelle im Blockierungsstatus befindet.
Im aktiv-aktiv-Modus
Abhängig von den Anforderungen können Flooding und Switching zwischen lokalen ESIs im aktiv-aktiv-Modus aktiviert oder deaktiviert werden. Dies wird als no-local-Switching-Verhalten bezeichnet.
Der Kern des EVPN-Service bietet eine Full-Mesh-Konnektivität zwischen den Multihomed-PE-Geräten. Aus diesem Grund nutzt EVPN einen geteilten Horizont im Core, sodass ein vom Core empfangenes Paket niemals umgestellt oder zurück in den Core überflutet wird. Stattdessen wird die Eingangsreplikation verwendet, um die Pakete auf die entfernten PE-Geräte zu replizieren.
Um Pakete an entfernte PE-Geräte zu überfluten, werden Multicast- und Split Horizon-Next-Hops verwendet. Der Multicast-Next-Hop tunnelt das Paket mit dem inklusiven Multicast-Label, und der Split Horizon Next Hop tunnelt das Paket mit einem Multicast-Label und einem Split Horizon-Label. Ein solcher nächster Hop ist pro Multihomed-ESI pro entferntes PE-Gerät erforderlich.
Im aktiv-aktiv-Modus werden folgende Flood-Routen verwendet:
All-CE-Flood-Route
Dieser Flood-Route wird von den lokalen ESIs für Folgendes verwendet:
Überflutung des Pakets auf die lokalen ESIs (wenn lokales Switching erlaubt ist).
Überflutung des Pakets auf die entfernten PE-Geräte. Die Remote-PE-Geräte überfluten das Paket auf ihre lokalen ESIs.
Da BUM-Datenverkehr nur vom Designated Forwarder (DF) und nicht von den nicht DF-multihomeden PE-Geräten weitergeleitet wird, verwenden die Nicht-DFs den geteilten Horizont neben dem Hop, um dieses Paket an andere PE-Geräte zu überfluten. Die multihomed lokalen ESIs, für die das PE-Gerät ein Nicht-DF ist, nehmen jedoch nicht an der Flooding teil.
Der All-CE-Flood-Pfad wird von den Nicht-DF-ESIs nicht verwendet, und der nächste Hop für diese Flood-Routen wird entsprechend erstellt. In solchen Fällen wird der Nicht-DF-ESI-Flood-Route verwendet.
All-VE-Flood-Route
Diese Flood-Route wird verwendet, wenn das Paket vom Core empfangen wird. Es wird verwendet, um das vom Core empfangene Paket an die lokalen ESIs zu überfluten. Da das vom Core empfangene Paket nur mit Multicast-Label oder mit Multicast-Label und Split Horizon-Label mitkommen kann, müssen geeignete Weiterleitungsregeln befolgt werden, um das Paket auf dem multihomeden ESI zu löschen, der dem Split Horizon-Label zugeordnet ist.
Nicht-DF-Flood-Route
Dieser Flood-Route wird für Folgendes verwendet:
Überflutung des Pakets auf die lokalen ESIs.
Fluten des Pakets auf die entfernten PE-Geräte durch Eingangsreplikation mit SH-Label für die DF für den ESI.
Aliasing
Ab Junos OS Version 15.1 unterstützt Junos OS aliasing in einem EVPN. Aliasing ist die Fähigkeit eines entfernten PE-Geräts, den Layer-2-Unicast-Datenverkehr auf allen anderen PE-Geräten, die dasselbe Ethernet-Segment zu einem CE-Gerät haben, lastausgleichen zu können.
Aliasing im Aktiv-Aktiv-Modus
In Abbildung 3 funktioniert das Aliasing im aktiv-aktiv-Modus wie folgt:
ESI1 ist auf den Routern PE1, PE2 und PE3 konfiguriert. Router PE1, PE2 und PE3 werben für die Automatische Erkennungsroute pro Ethernet-Segment für ESI1.
Das Gerät CE1 sendet Layer-2-Datenverkehr mit Quell-MAC-Adresse (MAC1) an Router PE1.
Router PE1 lernt die MAC1-Adresse auf (ESI1, vlan X) und gibt sie allen PE-Routern mit BGP an.
Router PE4 empfängt die MAC1-Route über BGP.
Da Router PE4 auch die automatische Erkennungsroute per EVI von den Routern PE2 und PE3 empfangen hat, weiß er, dass MAC1 über die Router PE2 und PE3 erreichbar sein muss. Router PE4 baut seinen Weiterleitungsstatus auf, um den Layer-2-Datenverkehr für MAC1 zwischen den Routern PE1, PE2 und PE3 auszugleichen.
Aliasing und Automatische Erkennung von Routen
Die automatische Erkennung von Routen von den Routern PE2 und PE3 kann in beliebiger Reihenfolge kommen. Infolgedessen werden diese Routen durch den Layer-2-Prozess wie folgt installiert:
Nach dem Erhalt von MAC1 von Router PE1 und wenn keine Automatischen Erkennungsrouten von Router PE4 empfangen wurden, wird MAC1 von PE4 programmiert, wobei der nächste Hop auf Router PE1 zeigt. Wenn PE4 die automatische Erkennungsroute von Router PE2 für denselben ESI empfängt, wird der nächste Hop installiert, sodass der Datenverkehr für MAC1 zu den Routern PE1 und PE2 lastausgleicht wird. Wenn PE4 die Automatische Erkennungsroute von Router PE3 für denselben ESI empfängt, wird der nächste Hop aktualisiert, um den Datenverkehr für MAC1 zwischen den Routern PE1, PE2 und PE3 auszugleichen.
Wenn Router PE4 bereits die Routen zur automatischen Erkennung von mehr als einem PE-Gerät (PE1, PE2 und PE3) empfangen hat, installiert PE4 die MAC-Routen mit dem Multi-Destination Next Hop.
Aliasing und Label-Route
Jedes PE-Gerät, das die automatische Erkennungsroute per EVI mit einem gültigen MPLS-Label ankündigen, programmiert das in der Routing-Tabelle mpls.0 angekündigte Label. Wenn Router PE2 beispielsweise die Automatische Erkennungsroute pro EVI mit Label A angekündigt hat, lautet der mpls.0-Eintrag wie folgt:
Label A-Route zeigt auf den tabellennächsten EVPN-EVI-Hop.
Wenn der Remote-Router PE4 ein Unicast-Datenpaket mit diesem Label A an Router PE2 sendet, wird in der Weiterleitungstabelle des Routers PE2 gesucht, und als Ergebnis dieser Suche wird das Paket an ESI1 weitergeleitet.
Aliasing und Unicast Packet Forwarding
Wenn die Unicast-Pakete für MAC1 vom Remote-Router PE4 zum Router PE2 stammen, kann es zwei Fälle geben:
Router PE2 hat auch den gleichen Satz von MACs auf seiner Verbindung zu ESI1 erhalten. In diesem Fall werden lokale Routen bevorzugt, und aufgrund der MAC-Suche werden Pakete an ESI1 weitergeleitet.
Router PE2 hat nicht die gleichen MACs auf seiner Verbindung zu ESI1 erhalten. In diesem Fall installiert Router PE2 immer noch MAC-Routen, die auf ESI1 verweisen, obwohl MACs aus der Ferne von Router PE1 gelernt werden. Infolgedessen werden die Pakete an ESI1 weitergeleitet.
EVPN Active-Active Multihoming und Multichassis Link Aggregation
Wenn ein CE-Gerät mit einer LAG für die PE-Geräte konfiguriert ist, stehen die folgenden beiden Optionen zur Verfügung, um LACP auf den PE-Geräten auszuführen:
Konfigurieren Sie dieselbe LACP-System-ID auf allen PE-Geräten.
Konfigurieren Sie die Multi-Chassis-Link-Aggregation auf den PE-Geräten.
Wenn die Multi-Chassis-Link-Aggregation mit EVPN konfiguriert ist, ist eine reduzierte Reihe von Verfahren für die Aktiv-Aktiv-Multi-Chassis-Link-Aggregation erforderlich. Diese Prozeduren bieten Redundanz auf Link- und Node-Ebene. Die Multi-Chassis-Link-Aggregation ist für das CE-Gerät völlig transparent und wird als reine LAG realisiert. Multichassis Link Aggregation funktioniert auch auf Portebene. Das bedeutet im Wesentlichen, dass alle VLANs auf den Multi-Chassis-Link-Aggregationsports im Aktiv-Aktiv-Multihoming-Modus arbeiten, wenn die Multi-Chassis-Link-Aggregation als aktiv-aktiv konfiguriert ist.
Wenn die Link-Aggregation mit mehreren Chassis zusammen mit EVPN konfiguriert wird, wird Folgendes berücksichtigt:
Sowohl die Multi-Chassis-Link-Aggregation als auch EVPN ESI müssen aktiviert werden, um nur im Aktiv-Aktiv-Modus zu arbeiten.
Die folgenden Funktionen sind für multichassis Link Aggregation mit EVPN nicht erforderlich:
Mac-Synchronisierung: Dies wird in der BGP-Steuerungsebene von EVPN durchgeführt.
ICL-Verknüpfung: Dies wird durch die Aliasing-Funktion von EVPN gehandhabt.
ARP-Synchronisierung: Dies wird von der BGP-Steuerungsebene mit IRB-Funktionalität gehandhabt.
EVPN Active-Active Multihoming und IRB
Wenn IRB konfiguriert ist, enthalten die EVPN-Routen sowohl MAC- als auch IP-Informationen. Das Aktiv-Aktiv-Multihoming erfordert eine ARP-Synchronisierung zwischen den multihomed PE-Geräten, da die ARP-Antworten an ein bestimmtes PE-Gerät hashed werden können.
Beispielkonfiguration
Im Folgenden wird eine Beispielkonfiguration für EVPN-Aktiv-Standby-Multihoming auf den folgenden Schnittstellentypen angeboten:
Ethernet-Schnittstellenkonfiguration
ge-0/1/2 { encapsulation ethernet-bridge; esi XX:XX:XX:XX:XX:XX:XX:XX:XX:XX; unit 0 { family bridge; } }Konfiguration einer einzigen VLAN-Schnittstelle
ge-0/1/3 { encapsulation extended-vlan-bridge; esi XX:XX:XX:XX:XX:XX:XX:XX:XX:XX; vlan-tagging unit 0 { family bridge; vlan-id 1; } }
Ein ESI-Wert von 0 und alle FFs sind reserviert und werden nicht für die Konfiguration eines multihomed Ehernet-Segments verwendet.
Zwei Schnittstellen in derselben EVI können nicht mit demselben ESI-Wert konfiguriert werden.
Im Folgenden wird ein Beispiel für die Routing-Instanzkonfiguration für EVPN-Aktiv-Standby-Multihoming:
Konfiguration der Routing-Instanz
routing-instances { evpn-0 { instance-type evpn; route-distinguisher value; vrf-target value; vlan-id vlan-ID; interface ge-0/1/2.0; interface ge-1/1/1.0; interface ge-2/2/2.0; protocols { evpn { designated-forwarder-election hold-time time; } } } }
Bei der Konfiguration im Aktiv-Standby-Modus wird die Automatische Erkennungsroute pro Ethernet-Segment mit dem Aktiv-Standby-Bit für jedes Ethernet-Segment auf 1 festgelegt.
Designated Forwarder-Wahl
In den folgenden Abschnitten wird die DF-Wahl diskutiert:
- DF-Wahlrollen
- DF-Wahl gemäß RFC 7432
- Präferenzbasierte DF-Wahl
- DF-Wahl für virtuellen Switch
- Handhabung von Failover
DF-Wahlrollen
Der Wahlprozess für den designated forwarder (DF) umfasst die Auswahl des DESIGNATED Forwarder (DF) PE-Routers und des Backup Designated Forwarder (BDF) oder einer nicht-DF (nicht-designated forwarder PE-Routerrollen).
DF— Die MAC-Adresse vom Kundenstandort ist nur über den PE-Router erreichbar, der die zugehörige MAC-Ankündigungsroute ankündigt. Dieser PE-Router ist der primäre PE-Router, der ausgewählt wird, um BUM-Datenverkehr an das multihomed CE-Gerät weiterzuleiten, und wird als designated forwarder (DF) PE-Router bezeichnet.
BDF— Jeder PE-Router in den anderen PE-Routern, die die automatische Erkennungsroute pro Ethernet-Segment für denselben ESI anzeigen und als Backup-Pfad dient, falls der DF einen Fehler auftritt, wird als Backup Designated Forwarder (BDF) oder nicht-DF (nicht designated forwarder) PE-Router bezeichnet.
Als Ergebnis des DF-Wahlvorgangs wird die Multihomed-Schnittstelle, die mit dem Kundenstandort verbunden ist, wenn ein lokaler PE-Router als BDF gewählt wird, in einen Blockierungsstatus für den aktiv-Standby-Modus versetzt. Die Schnittstelle bleibt im blockierenden Zustand, bis der PE-Router als DF für das Ethernet-Segment ausgewählt wird, dem die Schnittstelle angehört.
DF-Wahl gemäß RFC 7432
DF-Wahlverfahren
Das Standardverfahren für die DF-Wahl an der Granularität von ESI und EVI wird als Service-Carving bezeichnet. Mit Dem Service-Carving ist es möglich, mehrere DFs pro Ethernet-Segment (einen pro EVI) zu wählen, um ein Load-Balancing des Multi-Estination-Datenverkehrs durchzuführen, der für ein bestimmtes Ethernet-Segment bestimmt ist. Die Load-Balancing-Verfahren streuen den EVI-Raum zwischen den PE-Knoten gleichmäßig auf, sodass jedes PE der DF für eine unzusammenhängende Reihe von EVIs ist.
Das Verfahren für das Service-Schnitzen ist wie folgt:
Wenn ein PE-Router den ESI des angeschlossenen Ethernet-Segments erkennt, kündigt er eine Automatische Erkennungsroute pro Ethernet-Segment mit dem zugehörigen ES-import erweiterten Community-Attribut an.
Der PE-Router startet dann einen Timer (Standardwert von 3 Sekunden), um den Empfang der automatischen Erkennungsrouten von anderen PE-Knoten zu ermöglichen, die mit demselben Ethernet-Segment verbunden sind. Dieser Timerwert muss für alle PE-Router, die mit demselben Ethernet-Segment verbunden sind, gleich sein.
Der Standard-Wartezeitgeber kann mithilfe der
designated-forwarder-election hold-timeKonfigurationsaussage überschrieben werden.Wenn der Timer abläuft, erstellt jeder PE-Router eine geordnete Liste der IP-Adressen aller PE-Knoten, die mit dem Ethernet-Segment verbunden sind (einschließlich der sich selbst), in steigender numerischer Reihenfolge. Jeder PE-Router erhält dann einen Ordinal, der seine Position in der geordneten Liste anzeigt, beginnend mit 0 als Ordinal für das PE mit der numerisch niedrigsten IP-Adresse. Die Ordinalen werden verwendet, um zu bestimmen, welcher PE-Knoten der DF für eine bestimmte EVI im Ethernet-Segment ist.
Der PE-Router, der für eine bestimmte EVI als DF ausgewählt wird, entsperrt den Datenverkehr für die Ethernet-Tags, die dieser EVI zugeordnet sind. Das DF PE entsperrt den Multidestination-Datenverkehr in Ausgangsrichtung zum Ethernet-Segment. Alle NICHT-DF PE-Router lassen den Multidestination-Datenverkehr (für die zugehörigen EVIs) weiterhin in Ausgangsrichtung in Richtung des Ethernet-Segments fallen.
In Abbildung 3 erfolgt die Wahl des DF für aktiv-aktives Multihoming unter den Routern PE1, PE2 und PE3. Als Ergebnis dieser DF-Wahl kann jeder dieser Router der DF für ein bestimmtes VLAN aus einer Reihe von AUF ESI1 konfigurierten VLANs werden. Die DF ist für die Weiterleitung von BUM-Datenverkehr auf diesem ESI und VLAN verantwortlich, für das es als DF ausgewählt wurde. Die NICHT-DF PE-Router blockieren den BUM-Datenverkehr in diesem bestimmten Ethernet-Segment.
DF-Wahlauslöser
Im Allgemeinen wird ein DF-Wahlprozess unter den folgenden Bedingungen ausgelöst:
Wenn eine Schnittstelle neu mit einem nichtzero ESI konfiguriert wird oder wenn der PE-Router von einem isolierten Vom-Core-Zustand (keine BGP-Sitzung) zu einem Zustand von Connected-to-the-Core (hat BGP-Sitzung eingerichtet) wechselt, wird eine Wartezeit festgelegt. Standardmäßig wird die Schnittstelle in einen blockierenden Zustand versetzt, bis der PE-Router als DF ausgewählt wurde.
Nach Abschluss eines DF-Wahlvorgangs erhält ein PE-Router eine neue Ethernet-Segment-Route oder erkennt die Rücknahme einer vorhandenen Ethernet-Segment-Route, ohne dass eine Wartezeit auferlegt wird.
Wenn eine Schnittstelle eines NICHT-DF-PE-Routers nach einem Verbindungsausfall wiederhergestellt wird, hat der PE-Router keine Kenntnis von der Von anderen PE-Routern auferlegten Wartezeit. Infolgedessen wird keine Wartezeit für den wiederhergestellten PE-Router auferlegt, um Datenverkehrsverluste zu vermeiden.
Präferenzbasierte DF-Wahl
Die DF-Wahl basierend auf RFC 7432 erfüllt nicht einige der betrieblichen Anforderungen, die einige Service Provider benötigen. Als Lösung hierfür kann ab Junos OS Version 17.3 die DF-Wahl in einem EVPN-Multihoming-Netzwerk mithilfe eines administrativen Voreinstellungswerts für einen ESI gesteuert werden.
Im Standard-DF-Wahlverfahren (wie in RFC 7432 angegeben) wird die DF zufällig von einem der Multihoming-Geräte mit modulo-Betrieb gewählt. Bei der vorzugsbasierten DF-Wahl wird die DF manuell über Schnittstellenkonfigurationsoptionen gewählt, wie z. B. den Voreinstellungswert, das DP-Bit (Don't Preempt) und die Router-ID oder Loopback-Adresse.
Präferenzbasiertes DF-Wahlverfahren
Die vorzugsbasierte DF-Wahl wird auf EVPN und PBB-EVPN unterstützt und ermöglicht die manuelle Auswahl eines DF. Dies ist nützlich, wenn die DF basierend auf Schnittstellenattributen wie z. B. der mit einer Schnittstelle verknüpften Bandbreite ausgewählt werden muss.
Die vorzugsbasierte DF-Wahl wird wie folgt ausgeführt:
Der DF-Wahltyp und der Vorzugswert werden unter einem ESI konfiguriert. Standardmäßig basiert der vorzugsbasierte DF-Wahltyp auf dem Modulo-Vorgang (MOD).
Der konfigurierte Vorzugswert und DAS DP-Bit werden den Multihoming-PE-Geräten unter Verwendung der DF-Wahl erweiterten Community in den Typ-4-Routen angekündigt.
Nach dem Erhalt der Route typ 4 erstellt das PE-Gerät die Liste der kandidaten-DF-Geräte in der Reihenfolge des Voreinstellungswerts, des DP-Bits und der IP-Adresse.
Wenn der DF-Timer abläuft, wählt das PE-Gerät den DF basierend auf dem höchsten Präferenzwert aus.
Standardmäßig wird die DF basierend auf der höchsten Präferenz pro EVI ausgewählt. Die vorzugsbasierte DF-Wahl ermöglicht jedoch, den DF auf der Grundlage des niedrigsten Präferenzwerts zu wählen, wenn die
designated-forwarder-preference-leastAussage auf der[edit routing-instances routing-instance-name protocols evpn]Hierarchieebene enthalten ist.Hinweis:Die
designated-forwarder-preference-leastKonfiguration sollte auf den Multihoming-EVIs dieselbe sein; andernfalls kann es zwei DFs geben, die zu Datenverkehrsverlusten oder Schleife führen.Wenn derselbe Voreinstellungswert konfiguriert ist, wählt das PE-Gerät den DF basierend auf dem DP-Bit aus. Wenn auch das DP-Bit gleich ist, wird die DF basierend auf der niedrigsten IP-Adresse ausgewählt.
DF-Wahlalgorithmus-Mismatch
Wenn es eine Mismatche zwischen einem lokal konfigurierten DF-Wahlalgorithmus und dem DF-Wahlalgorithmus eines Entfernten PE-Geräts gibt, sollten alle PE-Geräte auf die in RFC 7432 angegebene Standard-DF-Wahl zurückgreifen.
DF-Wahlalgorithmusmigration
Während der Migration der alten DF-Wahl auf die neue DF-Wahl wird erwartet, dass die Konfiguration während des Wartungsfensters geändert wird, indem der ESI heruntergefahren und der DF-Wahlalgorithmus geändert wird.
Führen Sie die folgenden Schritte aus, um die Migration durchzuführen:
Nach einem Software-Upgrade werden auf dem Nicht-DF-Gerät alle Schnittstellen mit demselben ESI heruntergefahren.
Konfigurieren Sie den neuen DF-Wahlalgorithmus für DF PE.
Konfigurieren Sie den DF-Wahlalgorithmus auf anderen PE-Geräten mit mehreren Komponenten.
Aktivieren Sie alle Schnittstellen auf den NICHT-DF-PE-Geräten.
Ändern der Präferenz für Wartung
Nach der Migration des DF-Wahlalgorithmus und auf dem gesamten PE-Gerät mit Mehrerenhoming wird der vorzugsbasierte DF-Wahlalgorithmus ausgeführt, können die für den vorhandenen DF erforderlichen Wartungsaufgaben einfach durch Ändern des konfigurierten Einstellungswerts ausgeführt werden. Dadurch wird die DF für einen bestimmten ESI geändert.
So ändern Sie die DF für einen bestimmten ESI:
Ändern Sie den Voreinstellungswert auf dem aktuellen Nicht-DF-Gerät in einen höheren Wert.
Ändern Sie den Voreinstellungswert auf dem aktuellen DF-Gerät in einen niedrigeren Wert.
Eine Änderung des Voreinstellungswerts für einen ESI kann während der kurzen Dauer, die erforderlich ist, um die Verzögerung in die aktualisierte BGP-Routenausbreitung mit dem neuen Voreinstellungswert zu integrieren, zu einem Verlust des Datenverkehrs führen.
DF-Wahl für virtuellen Switch
Der virtuelle Switch ermöglicht mehrere Bridge-Domänen in einer einzigen EVPN-Instanz (EVI). Der virtuelle Switch unterstützt auch Trunk- und Access-Ports. Junos OS ermöglicht flexible Ethernet-Services am Port; daher können verschiedene VLANs an einem einzigen Port Teil verschiedener EVIs sein.
Die DF-Wahl für den virtuellen Switch hängt von den folgenden Abfolgen ab:
Port-Modus – Subschnittstelle, Trunk-Schnittstelle und Access-Port
EVI-Modus – Virtueller Switch mit EVPN und EVPN-EVI
Im virtuellen Switch können mehrere Ethernet-Tags mit einer einzigen EVI verknüpft werden, wobei der numerisch niedrigste Ethernet-Tag-Wert im EVI für die DF-Wahl verwendet wird.
Handhabung von Failover
Ein Failover kann auftreten, wenn:
Der DF PE-Router verliert seine DF-Rolle.
Es kommt zu einem Verbindungs- oder Portausfall am DF PE-Router.
Beim Verlust der DF-Rolle wird die kundenorientierte Schnittstelle des DF PE-Routers in den Blockierungsstatus versetzt.
Im Falle eines Verbindungs- oder Portausfalls wird ein DF-Wahlprozess ausgelöst, der dazu führt, dass der BDF-PE-Router als DF ausgewählt wird. Zu diesem Zeitpunkt sind Unicast-Datenverkehr und BUM-Datenverkehr wie folgt betroffen:
Unicast-Datenverkehr
CE bis Core: Das CE-Gerät überflutet weiterhin den Datenverkehr auf allen Verbindungen. Der vorherige BDF-PE-Router ändert den EVPN-Multihomed-Status der Schnittstelle vom Blockierenden in den Weiterleitungsstatus, und der Datenverkehr wird gelernt und über diesen PE-Router weitergeleitet.
Core to CE: Der ausgefallene DF PE-Router zieht die AutoDiscovery-Route pro Ethernet-Segment und die lokal erlernten MAC-Routen zurück, wodurch die entfernten PE-Router den Datenverkehr an das BDF umleiten.
Der Übergang des BDF PE-Routers zur DF-Rolle kann einige Zeit dauern, was dazu führt, dass sich der EVPN-Multihomed-Status der Schnittstelle weiterhin im blockierenden Zustand befindet, was zu Datenverkehrsverlusten führt.
BUM-Datenverkehr
CE bis Core: Der gesamte Datenverkehr wird in Richtung BDF geleitet.
Core to CE: Die entfernten PE-Router überfluten den BUM-Datenverkehr im Core.
ESIs auf physischen, aggregierten Ethernet- und logischen Schnittstellen
In Versionen vor Junos OS Version 15.1F6 und 17.1R1 für Router der MX-Serie und Junos OS Release 17.3R1 für EX9200-Switches können Sie einen ESI nur auf einer physischen oder aggregierten Ethernet-Schnittstelle angeben, set interfaces ae0 esi 00:11:22:33:44:55:66:77:88:99z. B. . . Wenn Sie einen ESI auf einer physischen oder aggregierten Ethernet-Schnittstelle angeben, denken Sie daran, dass ein ESI ein Faktor bei der Auswahl der vorgesehenen Weiterleitung (DF) ist. Nehmen Sie beispielsweise an, dass Sie EVPN Multihoming Aktiv-Standby auf der aggregierten Ethernet-Schnittstelle ae0 konfigurieren, und wenn der ESI auf ae0 und anderen bestimmenden Faktoren konfiguriert ist, befinden sich die DF-Wahlergebnisse in ae0 im Down-Zustand. Darüber hinaus sind alle logischen Schnittstellen, die z. B. auf aggregierter Ethernet-Schnittstelle ae0 konfiguriert sind, set interfaces ae0 unit 1 und set interfaces ae0 unit 2 befinden sich auch im Down-Zustand, wodurch logische Schnittstellen ae0.1 und ae0.2 nicht in der Lage sind, Services für ihre jeweiligen Kundenstandorte (VLANs) bereitzustellen.
Sie können einen ESI auf einer logischen Schnittstelle angeben, um logische Schnittstellen im Aktiv-Standby- oder Aktiv-Aktiv-Modus von EVPN-Multihoming besser zu nutzen, beginnend mit den Junos OS-Versionen 15.1F6 und 17.1R1 für Router der MX-Serie und Junos OS Release 17.3R1 für EX9200-Switches. Selbst wenn es sich bei einer logischen Schnittstelle um eine Nicht-DF handelt, können andere logische Schnittstellen auf derselben physischen oder aggregierten Ethernet-Schnittstelle weiterhin Services für ihre jeweiligen Kundenstandorte (VLANs) bereitstellen.
Weitere Informationen finden Sie unter Beispiel: Konfigurieren eines ESI auf einer logischen Schnittstelle mit EVPN-Multihoming.
Automatisch generierte ESIs
Ab Junos OS Version 18.4R1 können Sie aggregierte Ethernet-Schnittstellen und aggregierte logische Ethernet-Schnittstellen konfigurieren, um automatisch ESIs aus der LACP-Konfiguration abzuleiten. Wir unterstützen diese Funktion in den folgenden Umgebungen:
Auf Geräten von Juniper Networks, die diese Funktion unterstützen und im aktiv-aktiven Modus in einem EVPN-VXLAN-Overlay-Netzwerk multihomed sind.
Auf Geräten von Juniper Networks, die diese Funktion unterstützen und in einem EVPN-MPLS-Overlay-Netzwerk im Aktiv-Standby- oder Aktiv-Aktiv-Modus multihomed sind.
Weitere Informationen finden Sie unter Understanding Automatisch generierte ESIs in EVPN-Netzwerken.
Konvergenz in einem EVPN-Netzwerk
Wenn sich die Netzwerktopologie in einem großen EVPN-System ändert, kann die Konvergenzzeit erheblich sein. Sie können NLRI-Updates priorisieren, die für die Routenauswahl in Routing-Richtlinien wichtig sind, um die Konvergenz zu verbessern. Tabelle 1 listet die NLRI-Routentypen und die Priorität auf, die in der Routingrichtlinie konfiguriert werden muss.
NLRI-Routentyp |
Beschreibung |
Priorität |
|---|---|---|
NLRI-Route Typ 1 |
Ethernet-Route zur automatischen Erkennung: Typ 1 unterstützt schnelle Konvergenz und Aliasing und wird zur Signalisierung von MAC-Massenentzug verwendet. |
Hoch |
NLRI-Route Typ 2 |
MAC/IP-Ankündigungsroute: Typ 2 wird verwendet, um MAC-Adressen und IP-Adressen in EVPN-Netzwerken anzukündigen. |
Niedrig |
NLRI-Route Typ 3 |
Inklusive Multicast-Ethernet-Tag: Typ 3 wird verwendet, um einen Pfad für BUM-Datenverkehr einzurichten. |
Niedrig |
NLRI-Route Typ 4 |
Ethernet-Segment-Route: Bei der Auswahl einer bestimmten Weiterleitung wird Typ 4 verwendet. |
Hoch |
Um den NLRI-Routentyp zu priorisieren, legen Sie das bgp-output-queue-priority priority for nlri-route-type auf [edit policy-options policy-statement] Hierarchieebene auf allen Provider-Edge-Routern und Routenreflektoren im EVPN-Netzwerk fest. In diesem Beispiel wurde für NLRI-Routentyp 1 und NLRI-Routentyp 4 eine hohe Priorität konfiguriert.
user@PE1#show policy-options
policy-statement evpn-rt-priority-policy {
term 1 {
from {
family evpn;
nlri-route-type 1;
}
then {
bgp-output-queue-priority priority 16;
}
}
term 2 {
from {
family evpn;
nlri-route-type 2;
}
then {
bgp-output-queue-priority priority 1;
}
}
term 3 {
from {
family evpn;
nlri-route-type 3;
}
then {
bgp-output-queue-priority priority 2;
}
}
term 4 {
from {
family evpn;
nlri-route-type 4;
}
then {
bgp-output-queue-priority priority 16;
}
}
}
Es gibt 17 priorisierte Ausgabewarteschlangen: eine beschleunigte Warteschlange mit der höchsten Priorität und 16 nummerierte Warteschlangen, für die1 die niedrigste und 16 die höchste Priorität ist.
Weitere Informationen zur Konfiguration von Routing-Richtlinien finden Sie unter Routing-Richtlinien, Firewall-Filter und Traffic Policers-Benutzerhandbuch.