EVPN-Multihoming – Überblick
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. Bei einem CE-Gerät kann es sich um einen Host, einen Router oder einen Switch handeln. Die PE-Geräte bieten virtuelle Layer-2-Bridge-Konnektivität zwischen den CE-Geräten. Im Netzwerk des Anbieters kann es mehrere EVPNs geben. Das Lernen zwischen den PE-Routern erfolgt in der Steuerungsebene mithilfe von BGP, im Gegensatz zum herkömmlichen Bridging, bei dem das Lernen auf der Datenebene stattfindet.
In Versionen vor Junos OS Release 15.1 war die Unterstützung der EVPN-Funktionen auf Routern der MX-Serie auf Router mit MPC- und MIC-Schnittstellen beschränkt. Beginnend mit Junos OS Version 15.1 können Router der MX-Serie mit DPCs genutzt werden, um EVPN-Unterstützung auf der CE-Geräteschnittstelle bereitzustellen.
Die DPC-Unterstützung für EVPN wird unter folgenden Überlegungen bereitgestellt:
DPCs bieten Unterstützung für EVPN im Aktiv-Standby-Betriebsmodus, einschließlich Unterstützung für Folgendes:
EVPN-Instanz (EVI)
Virtueller Switch
Integrierte Routing- und Bridging-Schnittstellen (IRB)
Bei den DPCs, die für die Bereitstellung des EVPN Active-Standby-Supports vorgesehen sind, muss es sich um die CE-Linecard für das Gerät handeln. Bei dem PE-Gerät in der EVPN-Domäne muss es sich um MPC- oder MIC-Schnittstellen handeln.
Mit der EVPN-Multihoming-Funktion können Sie einen Kundenstandort mit zwei oder mehr PE-Geräten verbinden, um redundante Konnektivität bereitzustellen. Ein CE-Gerät kann mit verschiedenen PE-Geräten oder demselben PE-Gerät multihomed verbunden werden. Ein redundantes PE-Gerät kann Netzwerkservices für den Kundenstandort bereitstellen, sobald ein Fehler erkannt wird. Somit hilft EVPN-Multihoming dabei, den EVPN-Dienst und die Datenverkehrsweiterleitung zum und vom Multihomed-Standort im Falle der folgenden Arten von Netzwerkausfällen aufrechtzuerhalten:
Verbindungsfehler von PE-Gerät zu CE-Gerät
Ausfall des PE-Geräts
MPLS-Erreichbarkeitsfehler zwischen dem lokalen PE-Gerät und einem Remote-PE-Gerät
Abbildung 1 zeigt, wie ein CE-Gerät mit zwei PE-Routern multinetworked werden kann. Gerät CE 1 ist multinetworked mit den Routern PE 1 und PE 2. Gerät CE 2 hat zwei mögliche Pfade, um Gerät CE 1 zu erreichen, und je nach Multihoming-Redundanzmodus sind immer nur ein Pfad oder beide Pfade aktiv. Der Multihoming-Betriebsmodus bestimmt auch, welcher PE-Router oder welche Router den Datenverkehr an das CE-Gerät weiterleiten. Der PE-Router, der den Datenverkehr an das CE-Gerät weiterleitet (auch als designierte Weiterleitung bezeichnet), verwendet MPLS, LSP- oder GRE-Tunnel, um Datenverkehr weiterzuleiten. Wenn auf diesem Pfad ein Fehler auftritt, wird ein neuer designierter Weiterleitungsdienst ausgewählt, der den Datenverkehr an Gerät CE 1 weiterleitet.
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. Es wird nur Aktiv-Aktiv-Multihoming unterstützt. Die folgenden Unterfunktionen werden unterstützt:
ESI-Konfiguration (es werden nur manuelle Konfiguration vom Typ 0 und IFD (physische Schnittstellen) unterstützt)
Aliasing und Label-Route
EVPN-Route Typ 4 (Ethernet-Segment-Route)
Erweiterte Communities
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. Es wird nur Aktiv-Aktiv-Multihoming unterstützt. Um EVPN Aktiv-Aktiv-Multihoming auf ACX5448 Router zu aktivieren, fügen Sie die evpn-mh-profile Konfigurationsanweisung auf der Hierarchieebene [edit system packet-forwarding-options firewall-profile] ein.
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
Nachdem Sie das Profil geändert und bestätigt haben, müssen Sie den Chassis-Verwaltungsprozess neu starten, indem Sie den restart chassis-control CLI-Befehl eingeben, um das neue Profil aufzurufen.
Eine Syslog-Warnung wird angezeigt, um PFE neu zu starten.
Grundlegendes zu EVPN-Multihoming-Konzepten
Abbildung 2 zeigt eine einfache EVPN-Netzwerktopologie zur Definition von EVPN-Multihoming-Konzepten.
Ethernet segmentWenn ein CE-Gerät mit zwei oder mehr PE-Routern multinetworked wird, stellt die Gruppe der Ethernet-Verbindungen ein Ethernet-Segment dar. Ein Ethernet-Segment wird dem CE-Gerät als Link Aggregation Group (LAG) angezeigt.
Die Verbindungen von den Routern PE1 und PE2 zu Gerät CE1 bilden ein Ethernet-Segment.
Beim Aktiv-Standby-Multihoming bilden die Verbindungen, aus denen ein Ethernet-Segment besteht, eine Bridge-Domäne. Beim Aktiv-Aktiv-Multihoming wird ein Ethernet-Segment als LAG zum CE-Gerät angezeigt.
ESI—Ein Ethernet-Segment muss eine eindeutige Kennung ungleich Null haben, die als Ethernet-Segment-Identifier (ESI) bezeichnet wird. Die ESI-Datei ist als 10-Oktett-Ganzzahl codiert. Bei der manuellen Konfiguration eines ESI-Werts muss das höchstwertige Oktett, das als Typbyte bezeichnet wird, 00 sein. Wenn ein Single-Homed-CE-Gerät an ein Ethernet-Segment angeschlossen wird, ist der gesamte ESI-Wert Null.
Dem Ethernet-Segment des Multihomed-Geräts CE1 ist 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.
EVIEine 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 auf Kundenbasis konfiguriert. Jedes EVI verfügt über einen eindeutigen Routenunterscheidungsmerkmal und ein oder mehrere Routenziele.
Eine EVI ist auf den Routern PE1, PE2 und PE3 konfiguriert.
Ethernet tagEin Ethernet-Tag identifiziert eine bestimmte Broadcast-Domäne, 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 dieses EVPN zugewiesen. Jeder PE-Router in dieser EVPN-Instanz führt eine Zuordnung zwischen den Broadcast-Domänenkennungen durch, die von jedem seiner angeschlossenen CE-Geräte verstanden werden, und dem entsprechenden Ethernet-Tag.
Ethernet segment route (EVPN Type 4 route)Die PE-Router, die mit einem mehrfach vernetzten CE-Gerät verbunden sind, ermitteln mithilfe von BGP-Ethernet-Segment-Routing-Nachrichten, dass jeder der PE-Router mit demselben Ethernet-Segment verbunden ist. Die PE-Router kündigen die Ethernet-Segment-Route an, die aus einer erweiterten ESI- und ES-Import-Community besteht.
Die Router PE1 und PE2 kündigen eine ES-Route mit einer erweiterten ES-Import-Community an (zusammen mit anderen erweiterten Communitys wie dem Routenziel). Die PE-Router konstruieren auch einen Filter, der auf einer erweiterten ES-Import-Community basiert, die dazu führt, dass nur diese PE-Router die ES-Route importieren und erkennen, dass sie mit demselben Ethernet-Segment verbunden sind.
Extended community— Eine erweiterte Gemeinschaft ähnelt in vielerlei Hinsicht einer normalen Gemeinschaft. EVPNs nutzen erweiterte Communitys, da der reguläre Community-Wert von 4 Oktetten nicht genug Erweiterung und Flexibilität bietet. Eine erweiterte Community ist ein 8-Oktett-Wert, der in zwei Hauptabschnitte unterteilt ist.
BUM trafficDiese Art von Datenverkehr wird an mehrere Ziele gesendet, darunter 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 multihomed ist, werden je nach Multihoming-Betriebsmodus entweder einer oder alle der 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, wird als Designated Forwarder (DF) bezeichnet.
BDF– Jeder Router in der Gruppe anderer PE-Router, der die AutoDiscovery-Route pro Ethernet-Segment für dieselbe ESI ankündigt und als Backup-Pfad dient, falls das DF einen Fehler feststellt, 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 teil, das als "Designated Forwarder Choice" bezeichnet wird, um den DF- und den BDF-PE-Router auszuwählen.
EVPN Multihoming-Betriebsmodus
Zu den verschiedenen Betriebsmodi für EVPN Multihoming gehören:
Einzeln: Wenn ein PE-Router mit einem Single-Homed-Kundenstandort verbunden ist, ist dieser Modus aktiviert. Der Einzelmodus ist der Standardbetriebsmodus und erfordert keine Konfiguration von Ethernet-Segmentwerten.
Aktiv-Standby: Wenn nur ein einzelner PE-Router aus einer Gruppe von PE-Routern, die an ein Ethernet-Segment angeschlossen sind, Datenverkehr zu und von diesem Ethernet-Segment weiterleiten darf, wird das Ethernet-Segment so definiert, dass es im Aktiv-Standby-Redundanzmodus arbeitet.
Um den Aktiv-Standby-Modus zu konfigurieren, fügen Sie den ESI-Wert und die
single-activeAnweisung unter der[edit interfaces]Hierarchieebene ein.Anmerkung:Der Active-Standby-Multihoming-Modus wird auf Switches der QFX-Serie oder in EVPN-Konfigurationen mit VXLAN-Overlays nicht unterstützt. Wenn Sie die Option also auf Switches der
single-activeQFX-Serie oder in EVPN-VXLAN-Konfigurationen konfigurieren, ignoriert das Gerät dieses Konfigurationselement.Aktiv-Aktiv: Wenn alle PE-Router, die an ein Ethernet-Segment angeschlossen sind, Datenverkehr zum und vom Ethernet-Segment weiterleiten dürfen, wird das Ethernet-Segment so definiert, dass es im Aktiv-Aktiv-Redundanzmodus arbeitet.
Anmerkung:In Junos OS Version 14.2 und früher unterstützt der Switch der EX9200-Serie nur den Aktiv-Standby-Betriebsmodus für EVPN-Multihoming.
Anmerkung:Beginnend mit 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-Aktiv-Betriebsmodus für EVPN-Multihoming. In diesem Szenario fungieren QFX5100- und EX4600-Switches als Top-of-Rack (ToR)-Switches im Datencenter für virtuelle Netzwerke. Die EVPN-Multihoming-Aktiv-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.
Anmerkung:Beginnend mit Junos OS Version 14.1R4, 14.2, 15.1F6 und 16.1R1 unterstützt Junos OS den Aktiv-Aktiv-Modus für EVPN-Multihoming auf Routern der MX-Serie.
Beginnend mit den Junos OS-Versionen 16.1R4 und 16.2R2 unterstützen alle EX9200-Switches den Aktiv-Aktiv-Modus für EVPN-Multihoming.
Ab Junos OS Version 17.4R1 unterstützen QFX10000 Switches den Aktiv-Aktiv-Modus für EVPN-Multihoming.
Um den Aktiv/Aktiv-Modus zu konfigurieren, schließen 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 ESI1-Ethernet-Segment für Gerät CE2 ist mit den Routern PE1, PE2 und PE3 multihomediert. 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-Kunden-Edge-Geräte und haben einen ESI-Wert von 0.
Implementierung von EVPN-Multihoming
Der EVPN-Aktiv-Standby-Multihoming-Betriebsmodus bietet Redundanz für Zugriffsverbindungsfehler und PE-Knotenausfälle für das mehrfach vernetzte CE-Gerät und basiert auf dem EVPN-Entwurf EET-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
- Neuere EVPN-Routentypen
- Multihomed Proxy MAC- und IP-Adressroutenankündigung
- Aktualisierung der MAC-Weiterleitungstabelle
- Datenverkehrsstrom
- Aliasing
- EVPN Aktiv-Aktiv-Multihoming und Multichassis Link Aggregation
- EVPN Aktiv-Aktiv-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: Route pro Ethernet-Segment
Routenfunktionen für die automatische Ermittlung
Zu den NLRI-Funktionen der automatischen Erkennungsroute gehören:
Hierbei handelt es sich um eine obligatorische Route vom Typ 1, die für eine schnelle Konvergenz und für die Ankündigung des Split-Horizon-Labels verwendet wird. Sie wird auch als Massenrückzugsroute bezeichnet.
Route Distinguisher vom Typ 1 werden mit der IP-Adresse (Loopback) des ursprünglichen PE-Routers als Wert für die Routenunterscheidung verwendet.
Diese Route trägt die ESI im NLRI (ungleich Null, wenn es sich um eine mehrfach vernetzte PE handelt, andernfalls Null).
Die Beschriftung des geteilten Horizonts gilt nur für ESI und trägt eine explizite NULL (0).
Das Bit im Active-Standby-Flag-Feld in der erweiterten ESI-Label-Community wird zur Signalisierung des Aktiv-Standby-Modus (Bit gesetzt) verwendet.
Die 3-Byte-Label-Werte im NLRI und im Ethernet-Tag sind Null.
Diese Route wird von allen Multihomed- und Remote-PE-Routern angekündigt und importiert, die dieselbe EVI auf der Werbe-ESI verwenden.
Routenankündigung für automatische Ermittlung
Aktiv-Standby-Modus
Im Aktiv-Standby-Modus kündigt der designierte Forwarder (DF) die Autodiscovery-Route pro Ethernet-Segment mit einer erweiterten ESI-MPLS-Bezeichnung an, bei der das Standby-Bit auf 1 festgelegt ist. Die Route für die automatische Erkennung wird pro ESI angekündigt, und die ESI-Bezeichnung wird auf 0 gesetzt, wenn der Aktiv-Standby-Modus aktiv ist.
Die AutoDiscovery-Route wird von allen mehrfach vernetzten und Remote-PE-Routern importiert, die Teil der EVI sind. Beim Empfang der AutoDiscovery-Route erfahren die PE-Router in der Netzwerktopologie, dass der Aktiv-Standby-Multihoming-Modus für die angekündigte ESI in Betrieb ist.
Aktiv-Aktiv-Modus
Im Aktiv-Aktiv-Modus kündigt jedes der mehrfach vernetzten PE-Geräte 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 geändert, dass das Aktiv-Standby-Bit, das in der erweiterten MPLS-Community übertragen wird, gelöscht wird, um anzuzeigen, dass der Aktiv-Aktiv-Modus in Betrieb ist. Die Autodiscovery-Route pro Ethernet-Segment im Aktiv-Aktiv-Modus umfasst auch das Label Split Horizon.
In Abbildung 3 kündigen die Router PE1, PE2 und PE3 für das Ethernet-Segment ESI1 die AutoDiscovery-Route an. Router PE4 empfängt diese AutoDiscovery-Route.
Zurückziehen der Route für die automatische Erkennung
Die Autodiscovery-Route pro Ethernet-Segmententnahme kann zu einer Massenentnahme führen. Die Massenentnahmefunktion wird verwendet, wenn ein Verbindungsausfall auf der ESI auftritt oder wenn sich die ESI-Konfiguration ändert.
Wenn die Verbindung zwischen einem Multihomed-CE-Gerät und einem Multihomed-PE-Gerät ausfällt, zieht das PE-Gerät die AutoDiscovery-Route pro Ethernet-Segment zurück. In einem solchen Fall wird die Massenentnahmefunktion von den anderen PE-Geräten wie folgt gehandhabt:
Remote-PE-Gerät
Wenn ein Remote-PE-Gerät das BGP-Update für die Massenentnahme empfängt, wird auf dem Remote-PE-Gerät Folgendes ausgeführt:
Der aktuelle nächste Hop, um das entfernte ESI- oder CE-Gerät zu erreichen, wird gelöscht.
Es wird ein neuer Next Hop über die verbleibenden mehrfach vernetzten PE-Geräte erstellt, um das entfernte ESI- oder CE-Gerät zu erreichen.
Alle MAC-Routen hinter dem CE-Gerät werden mit dem neu erstellten nächsten Hop aktualisiert.
Beginnend mit Junos OS Version 17.4R1 unterstützt Junos OS die dynamische Liste der nächsten Hops in einem EVPN-Netzwerk. Wenn nun die Verbindung zwischen dem CE-Gerät und einem Multihome-PE-Gerät ausfällt, wird der nächste Hop zum ESI oder CE aktualisiert, wodurch die Notwendigkeit einer Massenentnahme reduziert wird. Weitere Informationen zum Aktivieren von Dynamic List Next Hop finden Sie unter Konfigurieren des Dynamic List Next Hop.
Anderes mehrfach vernetztes PE-Gerät
Infolge der Massenentnahme erfolgt der Load Balancing auf dem mehrfach vernetzten CE-Gerät aus folgenden Gründen:
Wenn die anderen multihomed PE-Geräte denselben Satz von MAC-Adressen auf der Verbindung zur betreffenden ESI erhalten.
In diesem Fall werden die lokalen Routen bevorzugt. Wenn die vom DF PE-Gerät erlernten Remote-Routen zurückgezogen werden, wirkt sich dies nicht auf Routen aus, die auf die lokale ESI-Datei verweisen.
Wenn die anderen multihomed PE-Geräte nicht den gleichen Satz von MAC-Adressen auf der Verbindung zur betreffenden ESI erhalten haben.
In diesem Fall installieren die PE-Geräte die MAC-Routen, die auf die betreffende ESI zeigen, 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 geleert. Pakete, die für die geleerten MAC-Adressen bestimmt sind, werden in allen lokalen Segmenten überflutet.
Ethernet-Segment-Route
Merkmale der Ethernet-Segmentroute
Zu den NLRI-Funktionen der Ethernet-Segmentroute gehören:
Dies ist eine EVPN-Route vom Typ 4. Der Zweck dieser Route besteht darin, dass die PE-Router, die mit demselben Ethernet-Segment verbunden sind, sich gegenseitig mit minimaler Konfiguration beim Austausch dieser Route automatisch erkennen können.
Diese Route ist mit einer erweiterten ES-Import-Community mit einem auf 6 Byte komprimierten ESI-Wert verknüpft, ähnlich einem Routenziel.
Diese Route wird nur von PE-Routern angekündigt und importiert, die auf dem Ethernet-Segment für Werbung multihomed sind.
Ankündigung für Ethernet-Segmentrouten
Die Ethernet-Segmentroute wird zwischen allen PE-Routern innerhalb eines Datencenters mit der erweiterten ES-Import-Community ausgetauscht. Die erweiterte ES-import-Community wird basierend auf den mehrfach vernetzten ESI-PE-Routern erstellt, und die Ethernet-Segmentroute enthält den ESI-Wert, der sich auf das Ethernet-Segment bezieht, auf dem die PE-Router multihomed sind.
Die Ethernet-Segment-Routen werden basierend auf der erweiterten ES-import-Community gefiltert, sodass nur die 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 ES-import trägt.
Automatische Erkennungsroute pro EVPN-Instanz
Im Aktiv-Aktiv-Modus kündigt jedes der mehrfach vernetzten 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 AutoDiscovery-Route per EVI enthalten ist, wird später für das Aliasing verwendet.
Neue, erweiterte Communities
Eine erweiterte Gemeinschaft ähnelt in vielerlei Hinsicht einer normalen Gemeinschaft. Einige Netzwerkimplementierungen, wie z. B. Virtual Private Networks (VPNs), verwenden erweiterte Communitys, da der reguläre Community-Wert von 4 Oktetten 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 Active-Standby-Multihoming wurden die folgenden erweiterten Communities eingeführt:
ESI-Import
Diese erweiterte Community ist an die ES-Route angehängt und wird aus dem ESI-import-Wert 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 gesetzt, der von der IANA zugewiesen wurde.
Das erweiterte Community-Routenziel ESI-import füllt die Liste der Importroutenziele auf, die für die spezielle Instanz konfiguriert sind, von der aus die ES-Route, die diese Community verwendet, 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 konfiguriert ist, das den gleichen ESI-Wert hat. Sobald der PE-Router einen Satz dieser ESI-Routen empfängt, die den gleichen erweiterten Community-Wert für ESI-import haben, kann die DF- und BDF-Auswahl lokal durchgeführt werden.
Wenn die erweiterte ESI-import-Community nicht implizit erstellt wird, muss eine Richtlinie konfiguriert werden, die alle Routenziele pro Ethernet-Segment an die Autodiscovery-Route anhängt.
Geteilte Horizonte
Wenn beispielsweise ein CE-Gerät, das mit zwei oder mehr PE-Geräten auf einem Ethernet-Segment (ESI1) multinetworked ist und im Aktiv-Aktiv-Redundanzmodus arbeitet, ein BUM-Paket an eines der Nicht-DF-PE-Geräte (z. B. PE1) sendet, leitet Gerät PE1 dieses Paket an alle oder eine 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 verwirft das DF PE-Gerät, für das das CE-Gerät multinetworked ist, das Paket, ohne es zurück an das CE-Gerät weiterzuleiten. Diese Filterung wird als geteilter Horizont bezeichnet.
Signalisierung mit geteiltem Horizont
Die erweiterte Community mit geteiltem Horizont ist pro Ethernet-Segment an die Autodiscovery-Route angebunden. Der Wert der erweiterten Community ist der geteilte Horizont oder das Poisson-Label selbst, das 3 Byte groß ist und als undurchsichtiges Attribut angekündigt wird.
Split-Horizon-Anzeige
Im Aktiv-Standby-Modus wird das Standby-Bit in der erweiterten Community für geteilten Horizont auf 1 und die ESI-Beschriftung für den geteilten Horizont auf 0 gesetzt.
Im Aktiv-Aktiv-Modus wird die erweiterte Community für den geteilten Horizont so geändert, dass das Standby-Bit auf 0 gesetzt wird, und enthält eine gültige ESI-Bezeichnung, die für Zwecke des geteilten Horizonts verwendet wird.
MPLS-Routen mit geteiltem Horizont
Das DF PE-Gerät kündigt eine AutoDiscovery-Route pro Ethernet-Segment mit einem geteilten Horizont-Label A und eine inklusive Multicast-Route mit Label B für die BUM-Datenverkehrsweiterleitung an. Auf dem DF kann das BUM-Paket vom Core die folgenden Labels haben:
Wenn die Nicht-DF PE-Geräte ein BUM-Paket auf ihren Single-Homed-ESIs empfangen, wird das BUM-Paket mit 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-Labels an das DF PE-Gerät gesendet: dem Multicast-Label B als äußeres Label und dem Split Horizon-Label A als inneres Label.
Im EVPN-Multihoming-Szenario wird das S-Bit für das Multicast-Label B auf 1 gesetzt, obwohl es das einzige Label im Label-Stack ist. In diesem Fall muss das BUM-Paket auf allen lokalen ESIs auf dem DF PE-Gerät geflutet werden. Bei der Beschriftung B ist das S-Bit jedoch auf 0 gesetzt, wenn die Beschriftung A des geteilten Horizonts die innerste Beschriftung im Beschriftungsstapel ist. In diesem Fall müssen die BUM-Pakete auf allen lokalen ESI-Dateien auf dem DF PE-Gerät überflutet werden, mit Ausnahme der ESI-Datei, die der Split-Horizon-Bezeichnung A zugeordnet ist.
Unter der Annahme, dass Pakete von einem mehrfach vernetzten CE-Gerät an ein Nicht-DF-PE-Gerät auf dem mehrfach vernetzten Segment ESI1 stammen, wird beim Senden dieses Pakets durch das Nicht-DF-PE-Gerät an das DF-PE-Gerät zuerst das ESI-Label gepusht, das das DF dem Nicht-DF-PE-Gerät in seiner AutoDiscovery-Route pro Ethernet-Segment angekündigt hat. Das Nicht-DF-PE-Gerät pusht auch die inklusive Multicast-Bezeichnung, die das DF PE-Gerät in seiner inklusiven Multicast-Route angekündigt hat, und pusht die LSP-Bezeichnung weiter. Der MPLS-Header enthält also zwei Labels innerhalb eines 32-Bit-Feldes.
Die EVPN-Basisfunktionalität verwendet einen Tabellen-Next-Hop, um die MPLS-Tabelle mit der entsprechenden EVPN-EVI-Tabelle zuzuordnen. In der EVPN EVI-Tabelle wird die MAC-Suche durchgeführt, um das Paket zu wechseln.
Folgende Routen sind in der Tabelle mpls.0 für EVPN-Multicast programmiert:
Die Route (multicast-label, S=1) verweist auf den EVPN-EVI table-next hop.
Die Route (multicast-label, S=0) verweist auf den MPLS-Tabellennächsten Hop. Diese Route führt das Paket zurück zur MPLS-Tabelle, nachdem das Multicast-Label geplatzt ist.
Die Route (Split Horizon-Label) verweist auf den EVPN-EVI Table Next Hop. Dies ist derselbe Tabellen-Next-Hop, der von der Multicast-Label-Route S=1 verwendet wird.
Neuere 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 Namenskonvention:
<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: Wert für die Unterscheidung der Route.Der Wert für die Routenunterscheidung wird auf die IP-Adresse des PE-Routers gefolgt von 0 festgelegt.
esi– Ethernet-Segment-ID. Wird als 10 Byte Hexadezimalbyte angezeigt, und führende 00 Byte werden nicht angezeigt.route-specific– Unterscheidet sich je nach Routentyp.AutoDiscovery-Route pro Ethernet-Segment und AutoDiscovery-Route pro EVI: Dieser Wert ist ein MPLS-Label.
Anmerkung:Das MPLS-Label wird in der umfangreichen Ausgabe angezeigt, obwohl es nicht im Präfix enthalten ist.
Ethernet-Segmentroute: Dieser Wert ist die ursprüngliche IP-Adresse.
304– Maximale Anzahl von Bits in einer EVPN-Route. Dies ist keine sehr nützliche Information und könnte aus dem Display entfernt werden. Es kann jedoch nützlich sein, um eine EVPN-Route schnell zu identifizieren, entweder visuell oder mit Match-Operatoren.
Multihomed Proxy MAC- und IP-Adressroutenankündigung
Ab Junos OS Version 18.4R1 sendet Junos Proxy-MAC- und IP-Adress-Routenankündigungen von PEs, die mehrfach an ein CE-Gerät gebunden sind. Junos verwendet ein Proxy-Flag in der erweiterten EVPN Layer 2 Attributes Community, um die Nachricht als Proxy-MAC- und IP-Adressankündigung zu identifizieren. Ein PE, der von einer MAC- und IP-Adresse erfährt, sendet eine normale EVPN-Routenankündigung vom Typ 2 (MAC und IP-Adresse). Die anderen PEs im Ethernet-Segment, die von der Remote-PE von der neuen Route erfahren, senden nun eine MAC- und IP-Adress-Routennachricht, bei der das Proxy-Bit festgelegt ist. Wenn der MAC- und IP-Adresseintrag veraltet ist oder die Verbindung zwischen PE und CE fehlschlägt, müssen die Einträge neu gelernt werden und es kann zu Datenverkehr kommen. Dadurch wird Datenverkehrsverlust vermieden, wenn eine der Verbindungen zu einem Leaf-Gerät ausfällt. Multihomed Proxy MAC wird automatisch aktiviert.
Aktualisierung der MAC-Weiterleitungstabelle
Beim Active-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. Das MAC-Lernen an den PE-Routern findet nicht in der Data Plane, sondern in der Control Plane statt. Dies führt zu mehr Kontrolle in Bezug auf den Lernmechanismus.
Ein PE-Router führt MAC-Lernen auf der Datenebene für Pakete durch, die von einem Kundennetzwerk für eine bestimmte EVI kommen. Für CE-MAC-Adressen, die sich hinter anderen PE-Routern befinden, werden die MAC-Adressen in BGP-NLRI mithilfe eines neuen MAC-Ankündigungsroutentyps angekündigt.
Es gibt zwei Arten des MAC-Lernens:
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 erlernte MAC-Adresse über MP-IBGP an Remote-PE-Routerknoten weitergeben. Dieser Prozess des Empfangens der Remote-MAC-Adressen der angeschlossenen Kunden über MP-IBGP wird als Remote-MAC-Lernprozess bezeichnet.
Der MAC-Ankündigungsroutentyp wird verwendet, um lokal gelernte MAC-Adressen in BGP an Remote-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-Anforderung für eine IP-Adresse von einem CE-Gerät sieht und wenn der PE-Router über die MAC-Adressebindung für diese IP-Adresse verfügt, führt der PE-Router einen ARP-Proxy aus und antwortet auf die ARP-Anforderung.
Der ARP-Proxy wird nur für das Gateway und nicht für den Host ausgeführt.
Das Feld MPLS-Beschriftung hängt von der Art der Zuordnung ab. Der PE-Router kann ein einzelnes MPLS-Label für alle MAC-Adressen pro EVI ankündigen, was die geringste Anzahl von MPLS-Labels erfordert und den PE-Router-Speicher schont. Bei der Weiterleitung an das Kundennetzwerk muss der PE-Router jedoch eine MAC-Suche durchführen, was zu einer Verzögerung und Erhöhung der Anzahl der CPU-Zyklen führen kann.
Datenverkehrsstrom
Beim EVPN-Multihoming wird der Datenverkehrsfluss in der Weiterleitungsebene ausgeführt. Flood-Routen werden für die Überflutung der Pakete erstellt und in den folgenden Szenarien verwendet:
Wenn ein Paket auf einer lokalen ESI-Datei empfangen wird,
Wenn ein Paket vom Core empfangen wird
Die Datenverkehrsflüsse 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 einem mehrfach vernetzten EVPN wird Unicast-Datenverkehr wie folgt weitergeleitet:
Im Aktiv-Standby-Modus
CE zum Core: Der Datenverkehr wird vom DF PE-Router erfasst und weitergeleitet.
Core to CE: Der Remote-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 to Core: Der Datenverkehr wird über einen Lastenausgleich zu allen angeschlossenen Multihomed-PE-Geräten ausgeglichen.
Core to CE: Der Datenverkehr von den Remote-PE-Geräten wird auf alle mehrfach vernetzten PE-Geräte verteilt, die mit dem Remote-CE-Gerät verbunden sind.
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 einem mehrfach vernetzten EVPN wird der BUM-Datenverkehr wie folgt weitergeleitet:
Im Aktiv-Standby-Modus
CE to Core: Das CE-Gerät leitet jeglichen BUM-Datenverkehr an alle Verbindungen im Ethernet-Segment weiter. Der DF PE-Router mit dem aktiven Pfad leitet die BUM-Pakete an den Core weiter. Der BDF PE-Router im Standby-Modus verwirft den gesamten Datenverkehr vom CE-Gerät, da sich der EVPN-Multihomed-Status der Schnittstelle im Blockierungszustand befindet. Wenn das CE-Gerät jedoch über separate Verbindungen 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 Remote-PE-Router leiten den gesamten BUM-Datenverkehr sowohl an den DF- als auch an den BDF-PE-Router. Nur der DF leitet den BUM-Datenverkehr an das CE-Gerät weiter. Der BDF PE-Router verwirft den gesamten Datenverkehr, da sich der EVPN Multihomed-Status der Schnittstelle im Blockierungszustand befindet.
Im Aktiv-Aktiv-Modus
Je nach Anforderung 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-Dienstes bietet eine Full-Mesh-Konnektivität zwischen den Multihomed-PE-Geräten. Aus diesem Grund verwendet EVPN einen geteilten Horizont im Core, sodass ein vom Core empfangenes Paket niemals geswitcht oder zurück zum Core geflutet wird. Stattdessen wird die Eingangsreplikation verwendet, um die Pakete auf die Remote-PE-Geräte zu replizieren.
Um Pakete an Remote-PE-Geräte zu fluten, 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 Next Hop ist pro mehrfach vernetzter ESI und Remote-PE-Gerät erforderlich.
Folgende Flood-Routen werden im Aktiv-Aktiv-Modus verwendet:
All-CE-Überschwemmungsroute
Diese Überschwemmungsroute wird von den lokalen ESI für Folgendes verwendet:
Überflutung des Pakets auf den lokalen ESIs (wenn lokales Switching zulässig ist).
Überfluten des Pakets an die Remote-PE-Geräte. Die Remote-PE-Geräte überfluten das Paket auf ihren lokalen ESIs.
Da der BUM-Datenverkehr nur vom designierten Forwarder (DF) und nicht von den mehrfach vernetzten Nicht-DF-PE-Geräten weitergeleitet wird, verwenden die Nicht-DFs den nächsten Hop des geteilten Horizonts, um dieses Paket an andere PE-Geräte zu senden. Die mehrfach vernetzten lokalen ESI-Einheiten, bei denen es sich bei dem PE-Gerät um ein Nicht-DF handelt, sind jedoch nicht an der Überflutung beteiligt.
Die All-CE-Flood-Route 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 die Nicht-DF-ESI-Flood-Route verwendet.
All-VE-Flutstrecke
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 fluten. Da das vom Core empfangene Paket nur mit multicast-label oder sowohl mit multicast-label als auch mit geteiltem Horizont-Label geliefert werden kann, müssen die entsprechenden Weiterleitungsregeln befolgt werden, um das Paket auf der mehrfach vernetzten ESI-Datei abzulegen, die dem Split-Horizon-Label zugeordnet ist.
Nicht-DF-Überschwemmungsroute
Diese Überschwemmungsroute wird für Folgendes verwendet:
Überflutung des Pakets mit den lokalen ESIs.
Flooding des Pakets an die Remote-PE-Geräte mithilfe der Eingangsreplikation mit SH-Label für den DF für die ESI.
Aliasing
Ab Junos OS Version 15.1 unterstützt Junos OS Aliasing in einem EVPN. Aliasing ist die Fähigkeit eines Remote-PE-Geräts, den Layer-2-Unicast-Datenverkehr auf allen anderen PE-Geräten, die dasselbe Ethernet-Segment zu einem CE-Gerät haben, auszugleichen.
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. Die Router PE1, PE2 und PE3 kündigen die Autodiscovery-Route pro Ethernet-Segment für ESI1 an.
Gerät CE1 sendet Layer-2-Datenverkehr mit Quell-MAC-Adresse (MAC1) an Router PE1.
Router PE1 lernt die MAC1-Adresse (ESI1, VLAN X) und kündigt sie allen PE-Routern über BGP an.
Router PE4 empfängt die MAC1-Route über BGP.
Da Router PE4 auch die AutoDiscovery-Route per EVI von den Routern PE2 und PE3 erhalten hat, weiß er, dass MAC1 über die Router PE2 und PE3 erreichbar sein muss. Router PE4 erstellt seinen Weiterleitungsstatus, um den Lastausgleich des Layer-2-Datenverkehrs für MAC1 zwischen den Routern PE1, PE2 und PE3 vorzunehmen.
Aliasing und automatische Ermittlungsrouten
Die Autodiscovery-Routen der Router PE2 und PE3 können in beliebiger Reihenfolge erfolgen. Daher werden diese Routen durch den Layer-2-Prozess wie folgt installiert:
Nach dem Empfang von MAC1 von Router PE1 und wenn Router PE4 keine AutoDiscovery-Routen empfangen hat, wird MAC1 von PE4 mit einem nächsten Hop programmiert, der auf Router PE1 zeigt. Wenn PE4 die AutoDiscovery-Route von Router PE2 für dieselbe ESI empfängt, wird der nächste Hop installiert, sodass der Datenverkehr für MAC1 auf die Router PE1 und PE2 verteilt wird. Wenn PE4 die AutoDiscovery-Route von Router PE3 für dieselbe ESI empfängt, wird der nächste Hop aktualisiert, um einen Lastenausgleich für den Datenverkehr für MAC1 zwischen den Routern PE1, PE2 und PE3 durchzuführen.
Wenn Router PE4 bereits die AutoDiscovery-Routen von mehr als einem PE-Gerät (PE1, PE2 und PE3) erhalten hat, installiert PE4 die MAC-Routen mit dem Multi-Destination-Next-Hop.
Aliasing und Label-Route
Jedes PE-Gerät, das die Autodiscovery-Route per EVI mit einem gültigen MPLS-Label ankündigt, programmiert das angekündigte Label in der Routing-Tabelle mpls.0. Wenn z. B. Router PE2 die Autodiscovery-Route pro EVI mit der Bezeichnung A angekündigt hat, lautet der Eintrag mpls.0 wie folgt:
Die Route der Bezeichnung A verweist auf den EVPN-EVI Table Next Hop.
Wenn der Remote-Router PE4 ein Unicast-Datenpaket mit dieser Bezeichnung A an Router PE2 sendet, wird eine Suche in der Weiterleitungstabelle von Router PE2 durchgeführt, und als Ergebnis dieser Suche wird das Paket an ESI1 weitergeleitet.
Aliasing und Unicast-Paketweiterleitung
Wenn die Unicastpakete für MAC1 vom Remote-Router PE4 zum Router PE2 kommen, kann es zwei Fälle geben:
Router PE2 hat auf seiner Verbindung zu ESI1 ebenfalls die gleichen MACs erhalten: In diesem Fall werden lokale Routen bevorzugt, und als Ergebnis der MAC-Suche werden die Pakete an ESI1 weitergeleitet.
Router PE2 hat nicht die gleichen MACs für seine 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. Daraufhin werden die Pakete an ESI1 weitergeleitet.
EVPN Aktiv-Aktiv-Multihoming und Multichassis Link Aggregation
Wenn ein CE-Gerät mit einer LAG gegenüber den PE-Geräten konfiguriert ist, stehen die folgenden beiden Optionen zum Ausführen von LACP auf den PE-Geräten zur Verfügung:
Konfigurieren Sie auf allen PE-Geräten dieselbe LACP-System-ID.
Konfigurieren Sie die Multichassis-Link-Aggregation auf den PE-Geräten.
Wenn die Multichassis-Link-Aggregation mit EVPN konfiguriert wird, sind weniger Verfahren für die Aktiv-Aktiv-Multichassis-Link-Aggregation erforderlich. Diese Verfahren bieten Redundanz auf Link- und Knotenebene. Die Multichassis-Link-Aggregation ist für das CE-Gerät völlig transparent und wird als reine LAG realisiert. Die Multichassis-Link-Aggregation funktioniert auch auf Portebene. Dies bedeutet im Wesentlichen, dass bei einer Konfiguration der Multichassis-Link-Aggregation als Aktiv-Aktiv-Aggregation alle VLANs an den Multichassis-Link-Aggregationsports im Aktiv-Aktiv-Multihoming-Modus arbeiten.
Bei der Konfiguration von Multichassis-Link-Aggregation zusammen mit EVPN wird Folgendes berücksichtigt:
Sowohl die Multichassis-Link-Aggregation als auch EVPN ESI müssen aktiviert sein, damit sie nur im Aktiv/Aktiv-Modus funktionieren.
Die folgenden Funktionen sind für die Multichassis-Link-Aggregation mit EVPN nicht erforderlich:
Mac-Synchronisierung: Diese wird in der BGP-Steuerungsebene von EVPN durchgeführt.
ICL-Verknüpfung: Dies wird von der Aliasing-Funktion des EVPN gehandhabt.
ARP-Synchronisierung: Dies wird von der BGP-Steuerungsebene mit IRB-Funktionalität übernommen.
EVPN Aktiv-Aktiv-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 mehrfach vernetzten PE-Geräten, da die ARP-Antworten auf ein bestimmtes PE-Gerät gehasht werden können.
Beispielkonfiguration
Im Folgenden finden Sie eine Beispielkonfiguration für EVPN Aktiv-Standby-Multihoming auf den folgenden Schnittstellentypen:
Konfiguration der Ethernet-Schnittstelle
ge-0/1/2 { encapsulation ethernet-bridge; esi XX:XX:XX:XX:XX:XX:XX:XX:XX:XX; unit 0 { family bridge; } }Konfiguration einer einzelnen 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; } }
Bei einem ESI-Wert von 0 sind alle FFs reserviert und werden nicht für die Konfiguration eines mehrfach vernetzten Ehernet-Segments verwendet.
Zwei Schnittstellen im selben EVI können nicht mit demselben ESI-Wert konfiguriert werden.
Im Folgenden finden Sie ein Beispiel für eine Routing-Instanzkonfiguration für EVPN Active-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 AutoDiscovery-Route pro Ethernet-Segment angekündigt, wobei das Aktiv-Standby-Bit für jedes Ethernet-Segment auf 1 gesetzt ist.
Wahl des designierten Spediteurs
Das Auswahlverfahren für Designated Forwarder (DF) in EVPN bietet einen robusten Mechanismus für die Auswahl eines designierten Forwarders unter den Geräten, die ein Multihomed-Ethernet-Segment bedienen. Die DF-Wahl gewährleistet effiziente und effektive Broadcast-, unbekannte Unicast- und Multicast-Datenverkehrsweiterleitung, Load Balancing, hohe Verfügbarkeit und Datenverkehrsmanagement. Haupteigenschaften:
-
Modulo-basierte oder präferenzbasierte Algorithmen für die DF-Auswahl.
-
Dynamische DF-Neuwahl ausgelöst durch Änderungen des Netzwerkstatus.
-
DF- und Backup-DF-Rollen, um Datenverkehrsschleifen zu vermeiden.
Das System verarbeitet auch ESI-Routen, um die Routenverarbeitung zu optimieren, und verwendet Massenentnahmemechanismen, um die Netzwerkintegrität zu erhalten. Sie können diese Funktionen und ihre CLI-Konfigurationen verwenden, um einen nahtlosen Datenverkehrsfluss zu gewährleisten und Ihre EVPN-Multihoming-Szenarien effektiv zu verwalten.
Weitere Informationen finden Sie unter EVPN Multihoming Designated Forwarder Election.
ESIs auf physischen, aggregierten Ethernet- und logischen Schnittstellen
In Versionen vor Junos OS Release 15.1F6 und 17.1R1 für Router der MX-Serie und Junos OS Release 17.3R1 für EX9200-Switches können Sie eine 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 eine ESI auf einer physischen oder aggregierten Ethernet-Schnittstelle angeben, beachten Sie, dass eine ESI ein Faktor im Auswahlprozess des Designated Forwarders (DF) ist. Angenommen, Sie konfigurieren EVPN Multihoming active/standby auf der aggregierten Ethernet-Schnittstelle ae0, und angesichts der für ae0 konfigurierten ESI und anderer bestimmender Faktoren führt die DF-Wahl dazu, dass sich ae0 im inaktiven Zustand befindet. Darüber hinaus sind alle logischen Schnittstellen, die beispielsweise auf der aggregierten Ethernet-Schnittstelle ae0 konfiguriert sind, ebenfalls im Down-Zustand, set interfaces ae0 unit 1 set interfaces ae0 unit 2 wodurch die logischen Schnittstellen ae0.1 und ae0.2 keine Services für ihre jeweiligen Kundenstandorte (VLANs) bereitstellen können.
Beginnend mit Junos OS Releases 15.1F6 und 17.1R1 für Router der MX-Serie und Junos OS Release 17.3R1 für EX9200-Switches können Sie eine ESI-Adresse für eine logische Schnittstelle angeben, um logische Schnittstellen im EVPN Multihoming active-standby- oder active-active-Modus besser zu nutzen. Selbst wenn es sich bei einer logischen Schnittstelle um eine Nicht-DF-Schnittstelle handelt, können daher 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 einer ESI-Datei 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 so konfigurieren, dass ESIs automatisch aus der LACP-Konfiguration abgeleitet werden. Wir unterstützen diese Funktion in den folgenden Umgebungen:
Auf Geräten von Juniper Networks, die diese Funktion unterstützen und im Aktiv/Aktiv-Modus in einem EVPN-VXLAN-Overlay-Netzwerk mehrfach vernetzt sind.
Auf Geräten von Juniper Networks, die diese Funktion unterstützen und im Aktiv-Standby- oder Aktiv-Aktiv-Modus in einem EVPN-MPLS-Overlay-Netzwerk multihomed sind.
Weitere Informationen finden Sie unter Grundlegendes zu automatisch generierten ESIs in EVPN-Netzwerken.
Konvergenz in einem EVPN-Netzwerk
Wenn es Änderungen in der Netzwerktopologie in einem groß angelegten EVPN-System gibt, kann die Konvergenzzeit erheblich sein. Sie können NLRI-Aktualisierungen, die für die Routenauswahl entscheidend sind, in Routing-Richtlinien priorisieren, um die Konvergenz zu verbessern. Tabelle 1 listet die NLRI-Routentypen und die Priorität auf, die in der Routing-Richtlinie konfiguriert werden müssen.
NLRI-Routentyp |
Beschreibung |
Priorität |
|---|---|---|
NLRI-Route Typ 1 |
Ethernet-Route zur automatischen Erkennung—Typ 1 unterstützt schnelle Konvergenz und Aliasing und wird verwendet, um MAC-Massenentzug zu signalisieren. |
Hoch |
NLRI-Routentyp 2 |
MAC/IP-Ankündigungsroute: Typ 2 wird verwendet, um MAC-Adressen und IP-Adressen in EVPN-Netzwerken anzukündigen. |
Niedrig |
NLRI-Routentyp 3 |
Inklusives Multicast-Ethernet-Tag: Typ 3 wird verwendet, um einen Pfad für BUM-Datenverkehr einzurichten. |
Niedrig |
NLRI-Route Typ 4 |
Ethernet-Segmentroute: Bei der Auswahl eines bestimmten Weiterleitenden wird der EVPN-Typ 4 verwendet. |
Hoch |
Um den NLRI-Routentyp zu priorisieren, legen Sie für bgp-output-queue-priority priority nlri-route-type auf der [edit policy-options policy-statement] Hierarchieebene aller Provider-Edge-Router und Routenreflektoren im EVPN-Netzwerk fest. In diesem Beispiel wurde eine hohe Priorität für NLRI-Routentyp 1 und NLRI-Routentyp 4 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 die 1 die niedrigste und 16 die höchste Priorität hat.
Weitere Informationen zum Konfigurieren von Routing-Richtlinien finden Sie unter Routing-Richtlinien, Firewall-Filter und Benutzerhandbuch für Datenverkehrsrichtlinien.
Tabellarischer Änderungsverlauf
Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie Funktionen entdecken , um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.