Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Optimiertes Intersubnet-Multicast (OISM) mit unterstützter Replikation (AR) für Edge-Routing-Bridging-Overlays

In diesem Kapitel wird beschrieben, wie Sie die optimierte Intersubnetz-Multicast-Funktion (OISM) in einer großen EVPN-VXLAN-ERB-Overlay-Fabric (Edge-Routing-Bridging) konfigurieren. OISM kann auch mit der AR-Funktion (Assisted Replication) zusammenarbeiten (siehe Unterstützte Replikations-Multicast-Optimierung in EVPN-Netzwerken), um die Multicast-Replikation in der Fabric auf die Geräte auszulagern und auszugleichen, die für die Last besser gerüstet sind.

In EVPN ERB-Overlay-Fabric-Designs leiten die Leaf-Geräte den Datenverkehr zwischen den Mandanten-VLANs weiter und leiten den Datenverkehr innerhalb der Mandanten-VLANs weiter. Zur Unterstützung eines effizienten Multicast-Datenverkehrsflusses in einer skalierten ERB-Overlay-Fabric mit internen und externen Multicast-Quellen und -Empfängern stellen wir ein Multicast-Konfigurationsmodell bereit, das auf dem IETF-Spezifikationsentwurf draft-ietf-bess-evpn-irb-mcast, EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding, basiert. OISM kombiniert die besten Aspekte von ERB- und CRB-Overlay-Designs für Multicast-Datenverkehr miteinander, um den effizientesten Multicast-Datenverkehrsfluss in ERB-Overlay-Fabrics bereitzustellen.

Eine kurze Zusammenfassung der Funktionsweise von OISM mit AR finden Sie weiter oben in diesem Handbuch unter Optimierter Intersubnet-Multicast für Edge-Routing-Bridging-Overlay-Netzwerke .

OISM ermöglicht ERB-Overlay-Fabrics:

  • Unterstützt Multicast-Datenverkehr mit Quellen und Empfängern sowohl innerhalb als auch außerhalb der Fabric.

  • Minimieren Sie die Multicast-Steuerung und den Datenverkehrsfluss im EVPN-Kern, um die Leistung in skalierten Umgebungen zu optimieren.

Abbildung 1 zeigt die ERB-Overlay-Referenzarchitektur, in der wir OISM und AR auf unterstützten Geräten in diesem Beispiel validiert haben.

Abbildung 1: Edge-Routing-Bridging-Overlay-Fabric mit OISM und AR Edge-Routed Bridging Overlay Fabric with OISM and AR

Hier finden Sie eine Zusammenfassung der OISM-Komponenten, Konfigurationselemente und des Betriebs in dieser Umgebung. Ausführliche Informationen zur Funktionsweise von OISM in verschiedenen Szenarien und zur verfügbaren OISM-Unterstützung auf verschiedenen Plattformen finden Sie unter Optimiertes Intersubnet-Multicast in EVPN-Netzwerken.

  • In diesem Beispiel nehmen die OISM-Geräte eine der folgenden Geräterollen an:

    • Server Leaf (SL): Leaf-Geräte, die mit den zugriffsseitigen (internen) Top-of-Rack-Geräten (TOR) verbunden sind, die die Multicast-Server und -Empfänger innerhalb der Fabric hosten. Die SL-Geräte können als AR-Leaf-Geräte fungieren.

    • Border Leaf (BL): Leaf-Geräte, die eine Verbindung zu einer externen PIM-Domäne herstellen, um den Multicast-Fluss zu und von externen Multicast-Quellen und -Empfängern zu verwalten. Die BL-Geräte können auch als AR-Leaf-Geräte fungieren.

    • AR Replicator Spine (S-ARR) – IP-Fabric-Transitgeräte, die als Routenreflektoren in der ERB-Overlay-Fabric und auch als AR-Replikatorgeräte dienen, die mit OISM arbeiten. Wenn die Spine-Geräte in einem ERB-Overlay als AR-Replikatoren fungieren, müssen sie EVPN-VXLAN ausführen und dürfen nicht mehr nur als Lean-Spines fungieren.

  • In diesem Beispiel konfigurieren Sie OISM mit einer MAC-VRF-EVPN-Instanz mit dem Servicetyp VLAN-fähig (unterstützt mehrere VLANs in der MAC-VRF-Instanz) auf allen SL-, BL- und S-ARR-Geräten. Sie müssen keine EVPN-Instanz auf dem externen PIM-Router konfigurieren.

  • Wir unterstützen OISM mit einem symmetrischen Bridge-Domains-Modell. Mit diesem Modell konfigurieren Sie alle Mandanten-VLANs (auch als Umsatz-Bridge-Domänen oder Umsatz-VLANs bezeichnet) und virtuelle Routing- und Weiterleitungsinstanzen (VRF) in der Fabric auf allen OISM-Leaf-Geräten. Wenn Sie OISM mit AR konfigurieren, konfigurieren Sie diese Elemente auch auf den Spine-Geräten, die als AR-Replikatoren fungieren.

  • OISM-Leaf-Geräte führen eine Überbrückung innerhalb des Subnetzes durch und verwenden ein lokales Routing-Modell für Multicast-Datenverkehr zwischen Subnetzen (Layer 3 [L3]), um Bandbreite zu sparen und Hairpining im EVPN-Kern zu vermeiden. Weitere Informationen finden Sie unter Lokales Routing auf OISM-Geräten .

    • SL-Geräte leiten Multicast-Quelldatenverkehr nur im Quell-VLAN an den EVPN-Core weiter.

    • BL-Geräte leiten Datenverkehr von externen Multicast-Quellen in den EVPN-Kern nur zu internen Empfängern in einer zusätzlichen Bridge-Domäne namens SBD weiter. Das SBD-Design ermöglicht das lokale Routing-Modell und löst andere Probleme mit extern bezogenem Datenverkehr. Für jede Mandanten-VRF-Instanz weisen Sie ein VLAN und eine entsprechende IRB-Schnittstelle für die SBD zu.

    • OISM SL-Geräte empfangen Multicast-Datenverkehr von internen Quellen im Quell-VLAN oder von externen Quellen über die BL-Geräte auf der SBD. Bei internem Datenverkehr überbrücken die SL-Geräte den Datenverkehr lokal zu Empfängern im Quell-VLAN und verwenden IRB-Schnittstellen, um den Datenverkehr lokal an Empfänger in anderen VLANs weiterzuleiten. Beim Empfang von Datenverkehr von außerhalb der Fabric verwenden die SL-Geräte IRB-Schnittstellen, um den Datenverkehr lokal von der SBD zu den Mandanten-VLANs und dann zu ihren lokal angeschlossenen Empfängern weiterzuleiten.

  • Wir unterstützen OISM mit IGMPv2 (nur Any-Source-Multicast-Berichte [ASM]) oder IGMPv3 (nur quellenspezifische Multicast-Berichte [SSM]). OISM erfordert, dass Sie IGMP-Snooping mit einer der beiden IGMP-Versionen aktivieren. Wir verwenden Protocol Independent Multicast (PIM) im Sparse-Modus für Multicast-Routing mit unterschiedlichen Optionen auf SL- und BL-Geräten entsprechend ihrer Funktionen.

    Hinweis:

    Um sowohl IGMPv2- als auch IGMPv3-Empfänger auf demselben Gerät zu unterstützen, müssen Sie Folgendes tun:

    • Verwenden Sie unterschiedliche Mandanten-VRF-Instanzen, um die Empfänger für jede IGMP-Version zu unterstützen.

    • Konfigurieren Sie verschiedene VLANs und entsprechende IRB-Schnittstellen, die die Empfänger für jede IGMP-Version unterstützen.

    • Ordnen Sie die IRB-Schnittstellen für jede Version der entsprechenden Mandanten-VRF-Instanz zu.

    Weitere Informationen zu den erforderlichen Konfigurationsüberlegungen finden Sie unter Überlegungen zu OISM-Konfigurationen . Die Konfiguration, die wir hier getestet haben, beherbergt Empfänger für beide Versionen auf demselben Gerät.

  • Mit IGMP-Snooping optimiert OISM auch den Multicast-Datenverkehr mithilfe von EVPN-Typ-6-Routen für die selektive Weiterleitung von Multicast-Ethernet-Tags (SMET). Mit SMET leiten OISM-Geräte den Datenverkehr für eine Multicastgruppe nur an andere Geräte in der Fabric mit Empfängern weiter, die Interesse am Empfang dieses Datenverkehrs zeigen. (Multicastempfänger senden IGMP-Join-Nachrichten, um Datenverkehr für eine Multicast-Gruppe anzufordern.)

    Im hier verwendeten symmetrischen OISM-Bridge-Domänenmodell kündigen OISM-Geräte EVPN-Typ-6-Routen nur auf der SBD an.

  • OISM unterstützt EVPN-Multihoming mit Multicast-Datenverkehr. Die Fabric kann Empfänger hinter TOR-Geräten enthalten, die in einem Ethernet-Segment (ES) mit mehr als einem OISM-Leaf-Gerät multivernetzt sind. Sie konfigurieren einen ES-Identifikator (ESI) für die Verknüpfungen im ES.

    OISM-Geräte verwenden EVPN-Routen vom Typ 7 (Join Sync) und Typ 8 (Leave Sync), um den Multicast-Status zwischen den Multihoming-Peer-Geräten zu synchronisieren, die einen ES bedienen.

In dieser Umgebung validieren wir OISM und AR gemeinsam in großem Maßstab mit der AR-Replikatorrolle auf den Spine-Geräten. AR-Replikatorrolle auf OISM-Spine-Geräten konfigurieren und AR-Leaf-Rolle auf OISM-Leaf-Geräten erklären in diesem Beispiel mehr über die Funktionsweise von AR. Wenn die AR-Replikatorrolle nicht mit einer OISM-Border-Leaf-Rolle auf demselben Gerät zusammengeschaltet ist, wie in diesem Beispiel, wird der AR-Replikator im eigenständigen AR-Replikatormodus ausgeführt. Die OISM SL- und BL-Geräte fungieren als AR-Leaf-Geräte.

Geräte, die AR nicht unterstützen, nennen wir reguläre Network Virtualization Edge (RNVE)-Geräte. Die Testumgebung umfasst ein SL-Gerät (siehe SL-3 in Abbildung 1), auf dem wir die AR-Leaf-Rolle nicht so konfigurieren, dass ein RNVE-Gerät simuliert wird. Mit RNVE-Geräten in der Fabric:

  • Die RNVE-Geräte verwenden die Eingangsreplikation, um Multicast-Datenverkehr an andere Leaf-Geräte in der Fabric weiterzuleiten.

  • Die AR-Replikatoren verwenden die Eingangsreplikation anstelle von AR, um Multicast-Quelldaten an die RNVE-Geräte weiterzuleiten.

In diesem Kapitel zeigen wir Konfiguration und Verifikation für eine kleine Teilmenge der skalierten Umgebung, in der wir OISM und AR gemeinsam validieren. Obwohl die skalierte Testumgebung mehr Geräte, konfigurierte Elemente, Multicastquellen und abonnierte Empfänger umfasst, zeigen wir in diesem Beispiel die Konfigurations- und Verifizierungsausgabe für die folgenden Elemente:

  • Eine EVPN-Instanz, MACVRF-1, eine MAC-VRF-Instanz mit VLAN-fähigem Servicetyp und VXLAN-Kapselung.

  • Multicast-Stream-Anwendungsfälle, die Folgendes umfassen:

    • IGMPv2- oder IGMPv3-Datenverkehr.

    • Interne oder externe Multicast-Quellen.

  • Zwei Mandanten-VRF-Instanzen, eine für IGMPv3-Empfänger und eine für IGMPv2-Empfänger.

    Für jede Mandanten-VRF-Instanz definieren wir:

    • Vier Mandanten-VLANs mit VXLAN-VNI-Zuordnungen (Tunnel Network Identifier) und entsprechenden IRB-Schnittstellen in der VRF-Instanz des Mandanten.

      Im OISM-Design bezeichnen wir die Mandanten-VLANs als Umsatzüberbrückungsdomänen oder Umsatz-VLANs.

    • Ein SBD-VLAN, das einem VNI zugeordnet ist, und eine entsprechende IRB-Schnittstelle in der VRF-Instanz des Mandanten.

  • Eine Multicast-Quelle innerhalb des Datencenters und eine Multicast-Quelle außerhalb des Datencenters in der externen PIM-Domäne.

    Sie konfigurieren die BL-Geräte so, dass sie als PIM-EVPN-Gateway-Geräte (PEG)-Geräte für die EVPN-Fabric fungieren. In diesem Beispiel verbinden wir PEG-Geräte über klassische L3-Schnittstellen mit einem externen PIM-Router und einem PIM-Rendezvous-Point (RP). Die L3-Schnittstellen auf jedem der BL PEG-Geräte sind mit dem externen PIM-Router in verschiedenen Subnetzen verbunden.

  • Multicastempfänger, die eine oder mehrere Multicastgruppen abonnieren.

    Hinweis:

    Jeder Multicaststream verfügt über mehrere Empfänger, die den Datenverkehr von jeder Quelle abonniert haben. Die Befehle zur Überprüfung des Multicastdatenverkehrs in diesem Beispiel konzentrieren sich auf das erste Empfängergerät in der Spalte "Empfänger" in Tabelle 1.

In Tabelle 1 finden Sie eine Zusammenfassung dieser Elemente und ihrer Werte. Abbildung 1 zeigt die Geräterollen und die ersten beiden entsprechenden IRB-Schnittstellen, VLANs und VNI-Zuordnungen für die einzelnen Mandanten-VRFs in der Tabelle.

Tabelle 1: OISM-Streams und -Elemente in diesem Beispiel

Multicast-Stream

Mandanten-VRF

VLANs, IRB-Schnittstellen und VNI-Zuordnungen

Quelle

Empfänger

Multicast-Gruppen

Interne Quelle, interne Empfänger mit IGMPv3 – nur SSM-Berichte

VRF-1

VLAN-1, IRB.1

VNI-110001

TOR-1 auf VLAN-1 (Multihomed auf SL-1 und SL-2)

TOR-4 (Multihomed auf SL-4 und SL-5)

Andere Empfänger:

TOR-2 (Single-homed zu SL-3)

TOR-3 (Multihomed auf SL-4 und SL-5)

TOR-5 (Einseitig zu SL-6)

233.252.0.21 bis 233.252.0.23

233.252.0.121 bis 233.252.0.123

VLAN-2, IRB.2

VNI-110002

VLAN-3, IRB.3

VNI-110003

VLAN-4, IRB.4

VNI-110004

(SBD) VLAN-2001, IRB.2001

VNI-992001

Externe Quelle, interne Empfänger mit IGMPv2 – nur ASM-Berichte

VRF-101

VLAN-401, IRB.401

VNI-110401

Externe Quelle (in externer PIM-Domäne)

TOR-1 auf VLAN-1 (Multihomed auf SL-1 und SL2)

Andere Empfänger:

TOR-2 (Single-homed zu SL-3)

TOR-3 (Multihomed auf SL-4 und SL-5)

TOR-4 (Multihomed auf SL-4 und SL-5)

TOR-5 (Einseitig zu SL-6)

233.252.0.1 bis 233.252.0.3

233.252.0.101 bis 233.252.0.103

VLAN-402, IRB.402

VNI-110402

VLAN-403, IRB.403

VNI-110403

VLAN-404, IRB.404

VNI-110404

(SBD) VLAN-2101, IRB.2101

VNI-992101

In Tabelle 2 finden Sie eine Zusammenfassung der L3-Verbindungsparameter des BL-Geräts und des externen PIM-Routers. In diesem Beispiel verwenden beide BL-Geräte die aggregierte Ethernet-Schnittstelle (AE) ae3 für die externe L3-Verbindung mit unterschiedlichen Subnetzen pro BL-Gerät. In der horizontal skalierten Testumgebung verwendet die Konfiguration eine Reihe logischer Einheiten auf der ae3-Schnittstelle mit entsprechenden VLANs pro Mandanten-VRF, beginnend mit Einheit 0 und VLAN-3001 für VRF-1. In diesem Beispiel konzentrieren wir uns auf die Mandanten-VRF-Instanzen VRF-1 und VRF-101.

Tabelle 2: Externe Multicast-L3-Schnittstellenparameter

BL-Gerät

VRF-Instanz des Mandanten

Externe L3-Schnittstelle Logische Einheit

Zugeordnetes VLAN

BL L3 IP-Adresse der logischen Schnittstelle

Logische Schnittstelle und IP-Adresse des PIM-Routers

Logische Einheit PIM RP und IP-Adresse

BL-1

VRF-1

Einheit 0: AE3.0

VLAN-3001

172.30.0.1

ae1.0: 172.30.0.0

lo0.1: 172.22.2.1

VRF-101

Einheit 100: AE3.100

VLAN-3101

172.30.100.1

ae1.100: 172.30.100.0

lo0.101: 172.22.102.1

BL-2

VRF-1

Einheit 0: AE3.0

VLAN-3001

172.31.0.1

ae2.0: 172.31.0.0

lo0.1: 172.22.2.1

VRF-101

Einheit 100: AE3.100

VLAN-3101

172.31.100.1

ae2.100: 172.31.100.0

lo0.101: 172.22.102.1

Sie konfigurieren diese Parameter unter Konfigurieren der Border Leaf-Geräte für externe Multicast-Konnektivität, PIM EVPN-Gateway-Rolle und PIM-Optionen.

Wir unterteilen die Konfiguration in mehrere Abschnitte.

Konfigurieren Sie das Underlay und das Overlay

Wir verwenden eBGP für das Underlay und iBGP für das Overlay gemäß den Referenzarchitekturen in IP Fabric Underlay Network Design and Implementation und konfigurieren IBGP für das Overlay.

In diesem Beispiel werden AE-Schnittstellen mit jeweils einer oder zwei Mitgliedsverknüpfungen für alle Verbindungen verwendet, um Redundanz zu gewährleisten.

  1. Konfigurieren Sie die ungefähre Anzahl der aggregierten Ethernet-Schnittstellen (AE) in der Konfiguration.

    Zum Beispiel:

    Alle SL- und BL-Geräte:

    S-ARR-Geräte:

  2. Befolgen Sie das Verfahren unter Konfigurieren der aggregierten Ethernet-Schnittstellen Verbinden von Spine-Geräten mit Leaf-Geräten, um die AE-Schnittstellen für das Underlay auf allen BL-, SL- und S-ARR-Geräten zu konfigurieren.

    In Abbildung 2 und Abbildung 3 finden Sie die IP-Adressen des Geräts, die AS-Nummern sowie die Namen und IP-Adressen der AE-Schnittstelle und die IP-Adressen in diesem Beispiel.

  3. Konfigurieren Sie das eBGP-Underlay auf den BL- und SL-Geräten. Legen Sie auf jedem BL- und SL-Gerät S-ARR-1 (AS: 4200000021) und S-ARR-2 (AS: 4200000022) als BGP-Nachbarn fest. Legen Sie auf ähnliche Weise auf jedem S-ARR-Gerät jedes BL- und SL-Gerät als BGP-Nachbarn fest. Weitere Informationen finden Sie unter IP Fabric Underlay-Netzwerkdesign und -implementierung.

    In Abbildung 2 und Abbildung 3 finden Sie die IP-Adressen des Geräts, die AS-Nummern sowie die Namen und IP-Adressen der AE-Schnittstelle und die IP-Adressen in diesem Beispiel.

    Zum Beispiel:

    SL-1 (Gerät AS: 4200000011):

  4. Konfigurieren Sie das iBGP-Overlay mit einer Overlay-AS-Nummer und EVPN-Signalisierung auf den SL-, BL- und S-ARR-Geräten. Weitere Informationen finden Sie unter Konfigurieren von IBGP für das Overlay.

    Legen Sie auf jedem SL- und BL-Gerät die Spine-Geräte S-ARR-1 (lo0:192.168.2.1) und S-ARR-2 (192.168.2.2) im Overlay-AS als BGP-Nachbarn fest. Zum Beispiel:

    SL-1 (Gerät lo0: 192.168.0.1):

    Wiederholen Sie diesen Schritt für jedes SL- und BL-Gerät und ersetzen Sie die local-address Option durch die Loopback-IP-Adresse dieses Geräts. Siehe Abbildung 2 und Abbildung 3.

    Legen Sie auf jedem S-ARR-Gerät alle SL- und BL-Geräte im Overlay-AS als BGP-Nachbarn fest. Zum Beispiel:

    S-ARR-1 (Gerät lo0: 192.168.2.1):

  5. Legen Sie Timer-Werte für MAC-Alterung, Address Resolution Protocol (ARP) und Neighbor Discovery Protocol (NDP) fest, um das Erlernen von MAC-Adressen und IPv4- und IPv6-Routen zu unterstützen. Bei diesen Parametern handelt es sich um allgemeine Einstellungen in EVPN-VXLAN-Fabrics, die nicht spezifisch für die OISM- oder AR-Funktionskonfigurationen sind.

    Stellen Sie diese Werte auf allen SL- und BL-Geräten ein.

    Legen Sie den NDP-Timer für veraltete IPv6-Verbindungen auf allen IRB-Schnittstellen für die Bestätigung der IPv6-Erreichbarkeit von Nachbarn auf allen SL- und BL-Geräten für IPv6-Unicast-Datenverkehr fest.

    Hinweis:

    Wenn Sie diese Einstellung auf alle IRB-Schnittstellen anwenden, die IPv6-Unicast-Datenverkehr verarbeiten können, fügen Sie diese Anweisung in der Regel einer Konfigurationsgruppe allgemeiner Anweisungen hinzu und wenden die Gruppe auf alle Schnittstellen an.

Konfigurieren einer OISM-fähigen EVPN MAC-VRF-Instanz

Die skalierte Testumgebung umfasst mehrere MAC-VRF-EVPN-Instanzen. Wir zeigen hier eine Instanz namens MACVRF-1, die wir für OISM- und AR-Datenverkehr verwenden.

Hinweis:

Wir erfordern, dass Sie die Funktion "Shared Tunnels" auf der QFX5000-Reihe von Switches aktivieren, auf denen Junos OS mit einer MAC-VRF-Instanzkonfiguration ausgeführt wird. Diese Funktion verhindert Probleme mit der VTEP-Skalierung auf dem Gerät, wenn die Konfiguration mehrere MAC-VRF-Instanzen verwendet. Wenn Sie gemeinsam genutzte Tunnel konfigurieren, minimiert das Gerät die Anzahl der Next-Hop-Einträge, um Remote-VTEPs zu erreichen. Sie aktivieren global freigegebene VXLAN-Tunnel auf dem Gerät, indem Sie die shared-tunnels Anweisung auf Hierarchieebene [edit forwarding-options evpn-vxlan] verwenden. Sie müssen das Gerät neu starten, damit diese Einstellung wirksam wird.

Diese Anweisung ist optional für die QFX10000 Reihe von Switches mit Junos OS, die eine höhere VTEP-Skalierung verarbeiten können als die Switches der QFX5000-Reihe. Auf Geräten, auf denen Junos OS Evolved in EVPN-VXLAN-Fabrics ausgeführt wird, sind freigegebene Tunnel standardmäßig aktiviert.

Konfigurieren Sie die Elemente in diesen Schritten auf allen SL-, BL- und S-ARR-Geräten.

Hinweis:

Dieses Beispiel enthält die AR-Multicast-Optimierung mit OISM. Die Spine-Geräte (S-ARR-1 und S-ARR-2) in der Fabric dienen als eigenständige AR-Replikatorgeräte. Damit AR mit dem symmetrischen OISM-Bridge-Domänenmodell funktioniert, müssen Sie auch alle gängigen OISM SL- und BL-Elemente auf den eigenständigen AR-Replikatorgeräten konfigurieren, z. B. DIE MAC-VRF-Instanz, VLANs, Mandanten-VRFs und IRB-Schnittstellen.

Wenn die Spine-Geräte nicht als AR-Replikatoren ausgeführt werden, müssen Sie diese Elemente nicht auf den Spine-Geräten konfigurieren.

  1. Konfigurieren Sie MACVRF-1, eine EVPN MAC-VRF-Instanz mit dem Servicetyp VLAN-fähig. Geben Sie die VXLAN Tunnel Endpoint (VTEP)-Quellschnittstelle als Geräte-Loopback-Schnittstelle an. Legen Sie einen Routenunterscheidungsmerkmal und ein Routenziel (mit automatischer Routenzielableitung) für die Instanz fest. Aktivieren Sie außerdem alle VNIs in der Instanz, um sich in die EVPN-BGP-Domäne zu erstrecken.

    Zum Beispiel:

    SL-1:

    Wiederholen Sie diesen Schritt für die verbleibenden SL-Geräte, BL-1, BL-2, S-ARR-1 und S-ARR-2. Ersetzen Sie in der Konfiguration auf jedem Gerät die IP-Adresse dieses Geräts als Teil des route-distinguisher Anweisungswerts, damit diese Werte auf allen Geräten eindeutig sind.

  2. Konfigurieren Sie plattformspezifische Einstellungen, die in skalierten EVPN-VXLAN-Umgebungen erforderlich sind. Sie konfigurieren diese Optionen auf den Geräten in der Fabric, die in einer beliebigen OISM- oder AR-Rolle betrieben werden.
    1. Fügen Sie auf Junos OS-Geräten der QFX5000-Reihe von Switches die Konfigurationsanweisung "Global Shared Tunnels" hinzu. Diese Einstellung unterstützt VXLAN-Tunneling mit MAC-VRF-Instanzen auf diesen Geräten in skalierten Umgebungen:

      Hinweis:

      Wenn Sie die Einstellung für freigegebene Tunnel hier konfigurieren müssen, müssen Sie nach dem Commit der Konfiguration das Gerät neu starten, damit die Einstellung für freigegebene Tunnel wirksam wird.

      Die Funktion für gemeinsam genutzte Tunnel ist auf Geräten, auf denen Junos OS Evolved ausgeführt wird, standardmäßig festgelegt.

    2. Konfigurieren Sie auf Geräten mit Junos OS Evolved Folgendes, um skalierte EVPN-VXLAN-Umgebungen zu unterstützen:

    3. Konfigurieren Sie auf QFX5110- und QFX5120-Switches die Einstellungen für den nächsten Hop für skalierte Umgebungen, um sicherzustellen, dass die Tabellengröße der nächsten Hops proportional zur Gerätekapazität ist, und zwar wie folgt:

      QFX5110 Switches:

      QFX5120 Switches:

  3. Konfigurieren Sie die OISM-Umsatz-VLANs und SBD-VLANs in der EVPN-MACVRF-1-Instanz. Ordnen Sie jedes VLAN einem VXLAN-VNI-Wert zu. Erstellen Sie außerdem IRB-Schnittstellen für jedes VLAN. In Tabelle 1 finden Sie die VLANs und VNI-Werte, die wir in diesem Beispiel verwenden. Sie konfigurieren für jede VRF eine SBD und den entsprechenden IRB.

    Konfigurieren Sie diese Elemente auf allen SL-, BL- und S-ARR-Geräten.

  4. Aktivieren Sie OISM global auf allen SL-, BL- und S-ARR-Geräten.
    Hinweis:

    Die S-ARR-Spine-Geräte in diesem Beispiel dienen als eigenständige AR-Replikatorgeräte, daher müssen Sie OISM auch für sie aktivieren. Wenn die Spine-Geräte nicht als AR-Replikatoren ausgeführt werden, müssen Sie OISM auf diesen Geräten nicht aktivieren.

  5. Aktivieren Sie IGMP-Snooping in der MAC-VRF-Instanz für alle OISM-Mandanten-VLANs (Umsatz-VLANs) und SBD-VLANs auf allen SL-, BL- und S-ARR-Geräten.
    Hinweis:

    Sie aktivieren IGMP-Snooping auf den S-ARR-Geräten, da diese als AR-Replikatorgeräte fungieren. AR-Replikatoren nutzen IGMP-Snooping, um die Weiterleitung des Datenverkehrs zu optimieren.

    In EVPN-VXLAN-Fabrics unterstützen wir IGMPv2-Datenverkehr nur mit ASM-Berichten. IGMPv3-Datenverkehr wird nur mit SSM-Berichten unterstützt. Wenn Sie IGMP-Snooping für IGMPv3-Datenverkehr aktivieren, schließen Sie die SSM-spezifische Option evpn-ssm-reports-only configuration option ein, wie unten gezeigt. Weitere Informationen zur ASM- und SSM-Unterstützung mit EVPN-VXLAN finden Sie unter Unterstützte IGMP- oder MLD-Versionen und Berichtsmodi für die Gruppenmitgliedschaft .

    IGMP-Snooping mit IGMPv2 in allen VLANs:

    IGMP-Snooping in VLANs mit IGMPv3-Empfängern (VLAN-1 bis VLAN-4, gemäß Tabelle 1):

  6. Aktivieren Sie IGMP auf den IRB-Schnittstellen, die Multicast-Datenverkehr auf SL-, BL- und S-ARR-Geräten verarbeiten.

    IGMPv2 ist standardmäßig aktiviert, wenn Sie PIM konfigurieren, aber Sie müssen IGMPv3 explizit auf den IRB-Schnittstellen aktivieren, die IGMPv3-Datenverkehr verarbeiten. Gemäß Tabelle 1 handelt es sich bei den IGMPv3-IRB-Schnittstellen um irb.1, irb.2, irb.3 und irb.4, die VRF-1 zugeordnet sind:

  7. (Erforderlich auf allen Geräten, die als AR-Replikatoren mit OISM konfiguriert sind, sowie auf der QFX10000-Reihe von Switches und der PTX10000-Reihe von Routern in jeder OISM-Rolle nur in Versionen vor Junos OS oder Junos OS Evolved Version 23.4R1) Um Datenverkehrsverluste zu Beginn von Multicast-Datenströmen zu vermeiden, legen Sie die install-star-g-routes Option in der [edit routing-instances name multicast-snooping-options oism] Hierarchie fest. Sie legen diesen Parameter in der MAC-VRF-Instanz fest. Mit dieser Option installiert die Routing-Engine (*,G) Multicast-Routen auf der Paketweiterleitungs-Engine für alle OISM-Umsatz-VLANs in der Routing-Instanz, sobald sie von einem interessierten Empfänger erfährt. Weitere Informationen zur Verwendung dieser Option finden Sie unter Kompromisse bei der Latenz und Skalierung bei der Installation von Multicast-Routen mit OISM (Option install-star-g-routes).

    In dieser Testumgebung sind S-ARR-1 und S-ARR-2 beispielsweise AR-Replikatoren, daher konfigurieren wir diese Anweisung in der MAC-VRF-Routing-Instanz auf diesen Geräten. Außerdem sind SL-4 und SL-5 Switches in den QFX10000-Line-Switches. Wenn auf diesen Geräten also frühere Versionen als Junos OS oder Junos OS Evolved Version 23.4R1 ausgeführt werden, konfigurieren Sie diese Anweisung auch auf diesen Geräten.

Konfigurieren der Mandanten-VRF-Instanzen für IGMPv2- und IGMPv3-Multicastempfänger

Die skalierte Testumgebung umfasst viele mandantenfähige L3-VRF-Instanzen. In Tabelle 1 sind die VRF-Instanzen für die beiden Multicast-Anwendungsfälle dargestellt:

  • VRF-1 für IGMPv3-Datenverkehr, der von einer internen Quelle abgerufen wird.

  • VRF-101 für IGMPv2-Datenverkehr, der von einer externen Quelle abgerufen wird.

Konfigurieren Sie die Elemente in diesen Schritten in diesen VRF-Instanzen auf allen SL-, BL- und S-ARR-Geräten.

Hinweis:

Die S-ARR-Spine-Geräte in diesem Beispiel dienen auch als eigenständige AR-Replikatorgeräte, sodass Sie auch alle Mandanten-VRF-Einstellungen für sie konfigurieren müssen. Wenn die Spine-Geräte nicht als AR-Replikatoren ausgeführt werden, müssen Sie diese Schritte nicht auf diesen Geräten ausführen.

Außerdem konfigurieren Sie in den Mandanten-VRF-Instanzen unterschiedliche PIM-Optionen für SL-Geräte im Vergleich zu BL-Geräten. Diese Konfigurationsschritte finden Sie unter Konfigurieren von PIM auf den Server-Leaf-Geräten und Konfigurieren der Border-Leaf-Geräte für externe Multicast-Konnektivität, PIM EVPN-Gateway-Rolle und PIM-Optionen . Sie müssen PIM auf den S-ARR-Geräten nicht konfigurieren.

  1. Konfigurieren Sie die VRF-Instanzen des Mandanten.

    Schließen Sie die IRB-Schnittstellen ein, die jeder Mandanten-VRF-Instanz zugeordnet sind. Legen Sie eine Routenunterscheidung basierend auf der IP-Adresse des Geräts und ein Routenziel für die Instanz fest.

    Zum Beispiel:

    SL-1:

    Wiederholen Sie diesen Schritt für die verbleibenden SL-Geräte, BL-1, BL-2, S-ARR-1 und S-ARR-2. Konfigurieren Sie sie auf jedem Gerät so, dass sie für alle Geräte und Mandanten-VRFs eindeutig ist. Ersetzen Sie die route-distinguisher Geräte-IP-Adresse aus Abbildung 2 oder Abbildung 3 und die VRF-Instanznummer für jede Mandanten-VRF wie folgt:

    • Verwenden Sie route-distinguisher auf SL-2 192.168.0.2:1 für VRF-1 und 192.168.0.2:101 für VRF-101.

      Verwenden Sie route-distinguisher auf SL-3 192.168.0.3:1 für VRF-1 und 192.168.0.3:101 für VRF-101.

      Und so weiter für die restlichen SL-Geräte.

    • Verwenden Sie route-distinguisher auf BL-1 192.168.5.1:1 für VRF-1 und 192.168.5.1:101 für VRF-101.

      Verwenden Sie route-distinguisher auf BL-2 192.168.5.2:1 für VRF-1 und 192.168.5.2:101 für VRF-101.

    • Verwenden Sie route-distinguisher auf S-ARR-1 192.168.2.1:1 für VRF-1 und 192.168.2.1:101 für VRF-101.

      Verwenden Sie route-distinguisher auf S-ARR-2 192.168.2.2:1 für VRF-1 und 192.168.2.2:101 für VRF-101.

  2. Fügen Sie in jeder VRF-Instanz die entsprechenden IRB-Schnittstellen für die OISM-Umsatz-VLANs und die SBD hinzu, die dieser Instanz zugeordnet sind, gemäß Tabelle 1:

    Wiederholen Sie die gleiche Konfiguration für alle SL-, BL- und S-ARR-Geräte.

  3. Geben Sie die IRB-Schnittstelle für die OISM SBD an, die jeder Mandanten-VRF-Instanz zugeordnet ist, wie in Tabelle 1 beschrieben:

    Wiederholen Sie die gleiche Konfiguration für alle SL-, BL- und S-ARR-Geräte.

  4. Konfigurieren Sie auf allen SL-, BL- und S-ARR-Geräten, die über eine einzelne Routing-Engine verfügen, die Funktion für einen ordnungsgemäßen Neustart für jede Mandanten-VRF:

Konfigurieren von Server-Leaf-to-TOR-Schnittstellen und Ethernet Segment Identifiers (ESIs) für EVPN-Multihoming

Die TOR-Geräte hosten die Multicastquellen und -empfänger innerhalb der Fabric. Diese Geräte verfügen über Single-Homed- oder Multihomed-Verbindungen zu den SL-Geräten im EVPN-Kern. Abbildung 3 zeigt die Topologie in diesem Beispiel. TOR-1, TOR-3 und TOR-4 sind jeweils auf zwei SL-Geräte multihomed, und TOR-2 und TOR-5 sind Single-Homed. Abbildung 3 zeigt Folgendes:

  • Die SL-Geräte verwenden alle die Schnittstelle ae3, um sich mit den TOR-Geräten zu verbinden.

  • SL4 und SL-5 verwenden die Schnittstellen ae3 und ae5 für redundante Verbindungen zu TOR-3 bzw. TOR-4.

  • Jedes mehrfach vernetzte TOR-Gerät verwendet die Schnittstellen ae1 und ae2, um eine Verbindung zu seinen Peer-SL-Geräten herzustellen.

  • Um die Konsistenz in der Konfiguration zu gewährleisten, verwenden die Single-Homed-TORs (TOR-2 und TOR-5) ebenfalls die Schnittstellen ae1 und ae2, jedoch als redundante Verbindungen zu einem einzelnen SL-Gerät.

Außerdem können Sie ab Junos OS und Junos OS Evolved Version 23.2R2 zusätzlich die Netzwerkisolationsfunktion für die mehrfach vernetzten TOR-Schnittstellen auf den SL-Geräten konfigurieren, um Datenverkehrsverluste während Core-Isolationsereignissen auf diesen Schnittstellen zu minimieren. In diesem Beispiel wird in Schritt 4 gezeigt, wie die Netzwerkisolationsfunktion auf den Schnittstellen von SL-1 und SL-2 auf das mehrfach vernetzte Gerät TOR-1 konfiguriert wird.

Hinweis:

Obwohl in diesem Beispiel keine mehrfach vernetzten Server- oder TOR-Schnittstellen auf den BL-Geräten gezeigt werden, können Sie die Netzwerkisolationsfunktion für alle derartigen Schnittstellen auf BL-Geräten ebenfalls konfigurieren.

  1. Konfigurieren Sie den Server-Leaf für TOR-Schnittstellen und Ethernet Segment Identifiers (ESIs) für EVPN-Multihoming.

    Konfigurieren Sie auf Multihoming-Peer-SL-Geräten dieselbe ESI auf den AE-Schnittstellenverbindungen mit dem Multihomed-TOR-Gerät. Aktivieren Sie außerdem LACP- und LACP-Haltetimer auf den Schnittstellen. Weitere Informationen zur Konfiguration dieser Schnittstellen und der entsprechenden Ethernet-Segmentbezeichner (ESIs) finden Sie unter Multihoming an Ethernet-Connected End System Design and Implementation .

    Hinweis:

    In Schritt 4 dieses Abschnitts erfahren Sie, wie Sie das Gerät so konfigurieren, dass Netzwerkisolationsereignisse auf diesen Schnittstellen erkannt werden und entsprechende Maßnahmen ergriffen werden. Wenn Sie diese Konfiguration einschließen, stellen Sie sicher, dass der hier in diesem Schritt konfigurierte "Up"-Haltetimer größer ist als der "Up"-Haltetimer im Netzwerkisolationsgruppenprofil in diesem Schritt.

    Zum Beispiel:

    Auf SL-1 für die Multihoming-Schnittstellen zu TOR-1:

    Wiederholen Sie diese Konfiguration auf SL-2, dem Multihoming-Peer zu SL-1. Verwenden Sie die entsprechende Schnittstelle für die Verbindung von SL-2 zu TOR-1 und dieselbe ESI.

    Auf SL-2 für die Multihoming-Schnittstellen zu TOR-1:

  2. Wiederholen Sie die Konfiguration in Schritt 1 oben auf den anderen SL-Geräten, die Multihomed TOR-Geräte bedienen.

    Verwenden Sie eine andere ESI für jedes entsprechende Multihoming-Peer-SL-Gerätepaar. Siehe Abbildung 3. In diesem Beispiel verwenden alle SL-Geräte ae3, um eine Verbindung zu den TOR-Geräten herzustellen. SL-4 und SL-5 verwenden ae3, um mit TOR-3 zu verbinden, und zusätzlich ae5, um mit TOR-4 zu verbinden. Als Ergebnis legen Sie eine ESI für die ae3-Links und eine andere ESI für die ae5-Links auf diesen beiden SL-Geräten fest.

    Hier weisen wir ESI-Werte mit den folgenden Konventionen zu:

    • Das 6. Segment von rechts im ESI-Wert stimmt mit der Nummer des mehrfach vernetzten TOR überein.

    • Das letzte Segment des ESI-Werts stimmt mit der AE-Schnittstellennummer überein.

    Zum Beispiel:

    • Auf SL-4 und SL-5 für die Schnittstellen zum mehrfach vernetzten TOR-3 (Link ist ae3 auf beiden SL-Geräten):

    • Auf SL-4 und SL-5 für die Schnittstellen zum mehrfach vernetzten TOR-4 (Link ist ae5 auf beiden SL-Geräten):

    TOR-2 ist Single-Homed zu SL-3, so dass Sie keine ESI auf der ae3-Schnittstelle auf SL-3 konfigurieren müssen.

    In ähnlicher Weise ist TOR-5 Single-Homed zu SL-6, sodass Sie keine ESI auf der ae3-Schnittstelle auf SL-6 konfigurieren müssen.

    Hinweis:

    Die Testumgebung umfasst auch separate AE-Schnittstellen (ae4 auf jedem SL-Gerät) und ESIs (für die mehrfach vernetzten TOR-Geräte), die die Fabric für Unicast-Datenverkehr verwendet. Wir zeigen hier nur die Konfiguration der Multicast-ESIs.

  3. Fügen Sie die Schnittstellen zu den TOR-Geräten in der MAC-VRF-Instanz auf jedem SL-Gerät ein – ae3 auf allen SL-Geräten und auch ae5 auf SL-4 und SL-5.

    Zum Beispiel:

    Auf SL-1 für die Schnittstelle zu TOR-1 (und wiederholen Sie diese Konfiguration auf SL-2 für die Schnittstelle zu TOR-1, SL-3 für die Schnittstelle zu TOR-2 und SL-6 für die Schnittstelle zu TOR-5):

    Bei SL-4 und SL-5 für die Schnittstellen zu TOR-3 und TOR-4:

  4. (Optional in Versionen ab Junos OS und Junos OS Evolved Version 23.2R2 mit dieser OISM-Konfiguration) Konfigurieren Sie die Netzwerkisolations-Service-Tracking-Funktion auf SL-1 und SL-2 für die Schnittstelle ae3 bis TOR-1. Mit dieser Funktion ändert das Gerät den Schnittstellenstatus, sobald ein Core-Isolationsereignis erkannt und wiederhergestellt wird. Weitere Informationen zur Funktionsweise dieser Funktion finden Sie unter Layer 2 Interface Status Tracking and Shutdown Actions for EVPN Core Isolation Conditions, network-isolation und network-isolation-profile . Um diese Funktion zu aktivieren, gehen wir wie folgt vor:
    • Richten Sie mithilfe der network-isolation-Anweisung eine Netzwerkisolationsgruppe net-isolation-grp-1 mit Nachverfolgung des Kernisolationsdiensts ein.

    • Geben Sie eine "Up"-Haltezeit (in ms) an, die das Gerät nach Erkennen der Wiederherstellung aus der Netzwerkisolation wartet, bevor es die Schnittstelle wieder hochfährt.

      Hinweis:

      Die "up"-Haltezeit, die Sie hier für die Erkennung von Core-Isolationsereignissen konfigurieren, sollte kleiner sein als der allgemeine "up"-Haltetimer auf den Schnittstellen für die ESI in Schritt 1. In diesem Schritt beträgt der "Up"-Haltetimer der Schnittstelle beispielsweise 300000 ms. Hier stellen wir den "Up"-Haltetimer für die Netzwerkisolationsgruppe auf 100000 ms ein.

    • Konfigurieren Sie das Gerät so, dass entweder lacp-out-of-sync der Status "Oder link-down " auf der Schnittstelle als Core-Isolationsaktion festgelegt wird. Hier legen wir zum Beispiel die lacp-out-of-sync Aktion fest.

    • Wenden Sie die Netzwerkisolationsgruppe mithilfe der network-isolation-profile-Anweisung auf die Schnittstelle an.

    • Da die Nachverfolgung des Core-Isolationsdiensts die Konvergenzzeit für die ESI-Routen verbessert, müssen wir keine Verzögerung in die Ankündigungen der Overlay-BGP-Route einbeziehen. Daher entfernen wir auf Geräten, auf denen wir die Netzwerkisolierungsfunktion auf TOR-Schnittstellen konfigurieren, die delay-route-advertisements Einstellungen aus Schritt 4 in Konfigurieren des Underlay und des Overlays.

    Zum Beispiel:

    Auf SL-1 für die Multihoming-Schnittstelle(n) zu TOR-1:

    Wiederholen Sie diese Konfiguration auf SL-2 für ae3 mit den gleichen Profilparametern für die Netzwerkisolationsgruppe.

    Sie können die gleichen oder ähnliche Netzwerkisolationsgruppenprofile auf den anderen Multihoming-Peer-SL-Geräten SL-4 und SL-5 einrichten, die ae3 für die ESI zu TOR-3 und ae5 für die ESI zu TOR-4 verwenden.

    Wenn wir die Netzwerkisolationsfunktion auf den SL-Geräteschnittstellen aktivieren, entfernen wir mit dieser Konfiguration die Einstellung für die Verzögerungsverzögerung der Overlay-Routenankündigung auf dem Gerät. Wir müssen noch die Overlay-Einstellung delay-route-advertisements minimum-delay routing-uptime für S-ARR-1 und S-ARR-2 aus Schritt 4 in Konfigurieren des Underlay und des Overlays beibehalten. Wenn die Netzwerkisolierungsfunktion jedoch im Netzwerk konfiguriert war, beobachteten wir bessere Testergebnisse mit einer höheren Einstellung auf den S-ARR-Geräten als mit der Einstellung in diesem Schritt. Daher empfehlen wir Ihnen in diesem Fall, auch Folgendes zu ändern:

    Bei S-ARR-1 und S-ARR-2 aus Schritt 4 unter Konfigurieren des Underlays und des Overlays:

    Ändern Sie diese Konfiguration wie folgt:

Konfigurieren von PIM auf den Server-Leaf-Geräten

In diesem Verfahren konfigurieren Sie die OISM-Elemente, die für Server-Leaf-Funktionen spezifisch sind, z. B. PIM, in den VRF-Instanzen des Mandanten in diesem Beispiel – VRF-1 und VRF-101. Konfigurieren Sie diese Schritte auf allen SL-Geräten.

  1. Konfigurieren Sie PIM im passiven Modus auf den SL-Geräten für alle Schnittstellen in jeder der VRF-Routing-Instanzen.
  2. Legen Sie die PIM-Option accept-remote-source fest, damit die SL-Geräte Multicast-Datenverkehr von der SBD-IRB-Schnittstelle als Quellschnittstelle akzeptieren können. Mit dem symmetrischen OISM-Modell für Bridge-Domänen gelangt jeglicher Multicast-Datenverkehr, der von externen Quellen kommt, zu den SL-Geräten auf der SBD.

Konfigurieren der Border Leaf-Geräte für externe Multicast-Konnektivität, PIM EVPN-Gateway-Rolle und PIM-Optionen

In diesem Verfahren konfigurieren Sie die OISM-Elemente, die für Border-Leaf-Funktionen spezifisch sind, einschließlich der Schritte zum Herstellen einer Verbindung mit der externen PIM-Domäne. Konfigurieren Sie die Anweisungen in dieser Prozedur auf jedem BL-Gerät.

Hinweis:

In diesem Beispiel wird die Verbindung zum externen PIM-Router über klassische L3-Schnittstellenverbindungen hergestellt. OISM unterstützt je nach Plattform des BL-Geräts zusätzliche Methoden, um eine Verbindung zur externen Domäne herzustellen. Eine Liste der unterstützten externen Multicast-Methoden pro Plattform finden Sie unter Externe Multicast-Verbindungsmethoden im EVPN-Benutzerhandbuch .

  1. Konfigurieren Sie die L3-Schnittstellen, die eine Verbindung zum externen PIM-Router herstellen.

    In diesem Beispiel verwenden beide BL-Geräte zu diesem Zweck die Schnittstelle ae3 mit einem anderen Subnetz für jede BL-Geräteverbindung pro Mandanten-VRF. Die physischen Schnittstellen im AE-Schnittstellenpaket können sich je nach BL-Gerät unterscheiden. Abbildung 2 zeigt das BL-Gerät und die Verbindungsinformationen für dieses Beispiel.

    Die externe L3-Multicast-Verbindung verwendet die ae3-Schnittstelle mit aktiviertem VLAN-Tagging. In der skalierten Umgebung konfigurieren wir logische Einheiten auf der ae3-Schnittstelle und entsprechende VLANs pro Mandanten-VRF, beginnend mit Einheit 0 und VLAN-3001 für VRF-1. In diesem Beispiel zeigen wir die Konfiguration von ae3.0 in VRF-1 und ae3.100 in VRF-101 auf beiden BL-Geräten. In Tabelle 2 finden Sie eine Zusammenfassung der Konfigurationsparameter für die externe L3-Schnittstellenverbindung.

    BL-1:

    BL-2:

  2. Schließen Sie die logischen L3-Schnittstellen in die VRF-Mandanteninstanzen ein. Beide BL-Geräte verwenden ae3 für die externe Multicast-Verbindung, verwenden Sie also auf beiden Geräten die gleiche Konfiguration.

    BL-1 und BL-2:

  3. Konfigurieren Sie jedes der BL-Geräte mit der OISM PEG-Rolle in jeder Mandanten-VRF.

    BL-1 und BL-2:

  4. Konfigurieren Sie PIM in den VRF-Instanzen des Mandanten, einschließlich des Folgenden für jede Mandanten-VRF in diesem Beispiel:
    • Legen Sie in dieser Umgebung eine statische PIM-RP-Adresse fest, die dem externen PIM-Router und RP-Router entspricht (eine für jede logische Einheit und die zugeordnete Mandanten-VRF).

    • Konfigurieren Sie PIM auf den IRB-Schnittstellen des OISM-Umsatz-VLAN, und schließen Sie die PIM-Option distributed-dr ein.

    • Konfigurieren Sie klassisches PIM (keine distributed-dr Option) auf der SBD-IRB-Schnittstelle, der L3-Schnittstelle der logischen Einheit und der logischen Loopback-Schnittstelle.

      Fügen Sie bei PIM auf der SBD-IRB-Schnittstelle die accept-remote-source Option hinzu, die BL-Geräte so zu aktivieren, dass sie Multicast-Datenverkehr von der SBD-IRB-Schnittstelle als Quellschnittstelle akzeptieren. Diese Option behandelt Situationen, in denen die BL-Geräte möglicherweise Quelldatenverkehr auf der SBD aneinander senden. Weitere Informationen zu diesen Situationen finden Sie unter Multicast-Datenverkehr von einer externen Quelle zu Empfängern innerhalb des EVPN-Datencenters – L3-Schnittstellenmethode oder Nicht-EVPN-IRB-Methode im EVPN-Benutzerhandbuch .

    • Aktivieren Sie mit PIM auf der SBD-IRB-Schnittstelle die Bidirectional Forwarding Detection (BFD) und die stickydr-Option . Die BFD-Einstellungen verbessern die Konvergenzzeit bei Schnittstellenproblemen, um Datenverkehrsverluste zu vermeiden. Diese stickydr Option eliminiert die Verzögerung der Switchover-Konvergenz des Routers bei Neustartereignissen.

    Beziehen Sie die gleiche Konfiguration auf BL-1 und BL-2 ein.

    Für VRF-1:

    Für VRF-101:

    Weitere Informationen dazu, warum wir diese PIM-Optionen auf den BL-Geräten konfigurieren, finden Sie unter OISM-Komponenten im EVPN-Benutzerhandbuch .

  5. Konfigurieren Sie einen OSPF-Bereich für jede VRF-Mandanteninstanz, der die logische L3-Schnittstelle, die logische Loopback-Schnittstelle und die SBD-IRB-Schnittstelle enthält. In diesem Schritt wird eine OSPF-Routingdomäne mit diesen Schnittstellen als Nachbarn in der Mandanten-VRF eingerichtet, um das Routing zwischen ihnen zu unterstützen.

    Sie schließen auch die export export-direct Richtlinienoption ein, die direkt verbundene IRB-Schnittstellen auf einem bestimmten BL-Gerät in das OSPF-Routing-Protokoll exportiert.

    Die Konfiguration ist auf beiden BL-Geräten gleich.

    BL-1 und BL-2:

Konfigurieren eines externen Multicast-PIM-Routers und eines PIM-RP-Routers

In diesem Beispiel fungiert ein Router der MX-Serie als externer PIM-Domänenrouter und PIM-RP-Gerät. In diesem Verfahren fügen wir die Konfiguration auf diesem Gerät, die mit der BL-Gerätekonfiguration übereinstimmt, in Konfigurieren der Border Leaf-Geräte für externe Multicast-Konnektivität, PIM EVPN-Gateway-Rolle und PIM-Optionen ein. Anhand dieser Informationen können Sie die Ausgabe des Befehls show interpretieren, um die Einrichtung, Konnektivität und Gruppenmitgliedschaften zu überprüfen, die für die OISM- und AR-Geräte in der Fabric eingerichtet wurden.

Die Konfiguration von PIM-Router und RP-Router umfasst:

  • Verbindungen zu BL-1 auf Schnittstelle ae1 und zu BL-2 auf Schnittstelle ae2, wobei VLAN-Tagging aktiviert ist.

  • Routing-Instanzen des Typs virtual-router (PIM-GW-VR-), die jedem Mandanten-VRF-n in der OISM-Konfiguration auf den BL-Gerätenn entsprechen.

  • Logische Einheiten auf ae1 und ae2 mit entsprechenden VLANs pro virtuellem Router-VRF, beginnend mit Einheit 0 und VLAN-3001 für VRF-1.

  • Eine PIM-RP-IP-Adresse für jede VRF-Instanz des virtuellen Routers.

Dieses Verfahren zeigt die Konfiguration der folgenden Elemente auf dem PIM-Router und dem RP-Router, wie in Tabelle 2 aufgeführt:

  • PIM-GW-VR-1 (entspricht VRF-1) und VLAN 3001 mit:

    • Schnittstelle ae1.0 bis BL-1.

    • Schnittstelle ae2.0 zu BL-2.

  • PIM-GW-VR-101 (entspricht VRF-101) und VLAN-3101 mit:

    • Schnittstelle ae1.100 zu BL-1.

    • Schnittstelle ae2.100 zu BL-2.

  1. Konfigurieren Sie die L3-Schnittstellen auf dem PIM-Router, die eine Verbindung zu den BL-Geräten herstellen (ae1 bis BL-1 und ae2 bis BL-2).
  2. Konfigurieren Sie virtuelle Router-Routing-Instanzen, die in diesem Beispiel den VRFs und VLANs des OISM-Mandanten entsprechen.

    Fügen Sie die L3-Schnittstellen zu BL-1 und BL-2 sowie die logische Loopback-Schnittstelle des Geräts und die logischen Schnittstellen, die für jede Routing-Instanz eine Verbindung zur externen Quelle herstellen, in die Routing-Instanzen ein.

  3. Konfigurieren Sie in jeder der Routing-Instanzen PIM, eine statische IP-Adresse für die PIM-RP und einen OSPF-Bereich für PIM für die Schnittstellen.

    In Tabelle 2 finden Sie die statischen PIM-RP-Adressen, die wir in diesem Beispiel verwenden.

Konfigurieren der AR-Replikatorrolle auf OISM-Spine-Geräten und der AR-Leaf-Rolle auf OISM-Leaf-Geräten

In einer ERB-Overlay-Fabric können Sie OISM mit AR aktivieren. Sie können die AR-Replikatorrolle einem oder mehreren Spine-Geräten in der Fabric zuweisen. Wenn ein Spine-Gerät als AR-Replikator ausgeführt wird, arbeitet der AR-Replikator im eigenständigen AR-Replikator-Modus. Dies bedeutet, dass die AR-Replikatorrolle nicht mit der OISM-Border-Leaf-Rolle auf dem Gerät verbunden ist.

Wenn ein eingehendes AR-Leaf-Gerät Multicast-Datenverkehr an andere AR-Leaf-Geräte weiterleiten muss, verwendet es einen AR-Overlay-VXLAN-Tunnel, um stattdessen nur eine Kopie des Datenverkehrs an ein verfügbares AR-Replikatorgerät zu senden. Anschließend repliziert das AR-Replikatorgerät ebenfalls mithilfe von AR-Overlay-VXLAN-Tunneln den Datenverkehr und leitet ihn an die anderen AR-Leaf-Geräte mit Empfängern weiter, die den Multicast-Stream abonniert haben. AR-Replikatoren verwenden die Eingangsreplikation anstelle von AR, um Multicast-Datenverkehr direkt an Leaf-Geräte weiterzuleiten, die AR nicht unterstützen (sogenannte RNVE-Geräte).

AR-Leaf-Geräte verteilen die Last der AR-Replikator-Anforderungen auf die verfügbaren AR-Replikator-Geräte mit einer von zwei Methoden, abhängig von der Leaf-Geräteplattform:

  • QFX5000-Reihe von Switches (Modelle, auf denen entweder Junos OS oder Junos OS Evolved ausgeführt wird): Diese Geräte bezeichnen ein bestimmtes AR-Replikator-Gerät für den Datenverkehr, der jedem VLAN oder VNI zugeordnet ist. In diesem Fall zeigt die show evpn multicast-snooping assisted-replication next-hops CLI-Befehlsausgabe den designierten AR-Replikator für jeden VNI als (Designated Node).

  • QFX10000 Reihe von Switches: Diese Geräte sorgen für einen aktiven Lastenausgleich zwischen den AR-Replikatoren basierend auf dem Datenverkehrsfluss innerhalb eines VNI. Das Gerät weist nicht für jeden VNI einen bestimmten AR-Replikator zu.

In diesem Beispiel haben wir Multicast-Flows von einer internen und einer externen Quelle. Die ERB-Overlay-Fabric-Spine-Geräte (S-ARR-1 und S-ARR-2) fungieren als AR-Replikatorgeräte. Die OISM SL- und BL-Geräte fungieren als AR-Leaf-Geräte, mit Ausnahme von SL-3, das ein RNVE-Gerät simuliert (wir aktivieren die AR-Leaf-Rolle auf diesem Gerät nicht). Abbildung 4 zeigt, wie AR funktioniert, wenn wir die Multicast-Streams und die entsprechenden Fabric-Parameter in diesem Beispiel aus Tabelle 1 betrachten.

Abbildung 4: AR mit internen und externen OISM-Multicast-Quellen AR with OISM Internal and External Multicast Sources
  • Im Anwendungsfall der internen Quelle:

    1. SL-1 ist das Eingangsgerät für einen internen Multicast-Stream von mehrfach vernetztem TOR-1 im Quell-VLAN-VLAN-1 für Datenverkehr zu Empfängern im Mandanten-VRF VRF-1.

    2. SL-1 (ein QFX5120-Switch) leitet den Datenverkehr an den für VLAN-1 (VNI 110001) vorgesehenen AR-Replikator weiter. Der designierte AR-Replikator ist in diesem Fall S-ARR-1.

    3. S-ARR-1 repliziert den Stream im Quell-VLAN und leitet ihn an die AR-Leaf-Geräte weiter, die TOR-Geräte mit abonnierten Empfängern hosten.

    4. Die Ziel-SL-Geräte leiten den Datenverkehr an ihre abonnierten Empfänger weiter oder leiten ihn lokal weiter.

  • Im Anwendungsfall der externen Quelle:

    1. BL-1 ist das Eingangsgerät für einen externen Multicast-Stream von der externen PIM-Domäne für Datenverkehr zu Empfängern im Mandanten-VRF VRF-101.

    2. BL-1 (ein QFX5130-Switch) leitet den Datenverkehr an den für das SBD-VLAN VLAN-2101 (VNI 992101) vorgesehenen AR-Replikator weiter. Der designierte AR-Replikator ist in diesem Fall S-ARR-2.

    3. S-ARR-2 repliziert und leitet den Stream im SBD-VLAN mithilfe von AR-Tunneln an die AR-Leaf-Geräte weiter, die TORs mit abonnierten Empfängern hosten.

    4. S-ARR-2 repliziert den Stream ebenfalls und verwendet einen Ingress Replication (IR)-Tunnel, um den Stream an SL-3 weiterzuleiten, ein RNVE-Leaf-Gerät, das ein TOR-Gerät mit einem abonnierten Empfänger hostet.

    5. Die SL-Zielgeräte leiten den Datenverkehr weiter oder leiten ihn lokal an ihre abonnierten Empfänger weiter.

Weitere Informationen zu AR-Geräterollen, zur Funktionsweise von AR und zu anderen Anwendungsfällen außer den in diesem Beispiel beschriebenen finden Sie unter Multicast-Optimierung der unterstützten Replikation in EVPN-Netzwerken.

So konfigurieren Sie AR in diesem Beispiel:

  1. Konfigurieren Sie die AR-Replikatorrolle auf den S-ARR-Geräten.
    1. Konfigurieren Sie die Geräte-Loopback-Schnittstelle lo0 mit einer sekundären IP-Adresse speziell für AR-Funktionen. Der AR-Replikator kündigt diese IP-Adresse dem Netzwerk in EVPN-AR-Tunnelrouten vom Typ 3 an.

      Wir fügen hier auch die Konfigurationsanweisungen für die primäre Loopback-Adresse hinzu, damit Sie jedes S-ARR-Gerät leichter identifizieren können.

      S-ARR-1:

      S-ARR-2:

    2. Konfigurieren Sie die AR-Replikatorrolle auf S-ARR-1 und S-ARR-2 in der MAC-VRF-Instanz, indem Sie die sekundäre AR-Loopback-Schnittstelle verwenden, die Sie im vorherigen Schritt konfiguriert haben.

      S-ARR-1:

      S-ARR-2:

    3. Auf AR-Replikatorgeräten im Standalone-Modus müssen Sie auch die allgemeinen OISM-Elemente konfigurieren, die Sie auf den OISM SL- und BL-Geräten konfigurieren. Sie haben diese Elemente in den vorherigen Schritten in diesem Beispiel konfiguriert. Siehe:

      Sie müssen keines der PIM- oder externen Multicast-Elemente konfigurieren, die für OISM BL- oder SL-Geräte spezifisch sind.

  2. Konfigurieren Sie die AR-Leaf-Rolle in der MAC-VRF-Instanz auf den OISM-BL-Geräten und allen SL-Geräten mit Ausnahme des RNVE-Geräts in diesem Beispiel, SL-3.

    Fügen Sie die replicator-activation-delay Option wie gezeigt hinzu. Standardmäßig warten AR-Leaf-Geräte 10 Sekunden nach dem Empfang einer AR-Replikator-Ankündigung, bevor sie mit dem Senden von Datenverkehr an dieses AR-Replikator-Gerät beginnen. In einer skalierten Umgebung empfehlen wir, die Verzögerung länger zu gestalten, um sicherzustellen, dass die AR-Replikatorgeräte den aktuellen EVPN-Status vollständig aus dem Netzwerk gelernt haben. Die Verzögerung hilft auch in Fällen, in denen ein AR-Replikator ausfällt und wieder auftaucht.

    BL-1, BL-2, SL-1, SL-2, SL-4, SL-5 und SL-6:

    Wir überspringen diese Konfiguration auf SL-3, das als Gerät fungiert, das AR nicht unterstützt.

Überprüfen der OISM- und AR-Konfiguration und des Betriebs

Sie können die show-Befehle in den folgenden Schritten verwenden, um die OISM- und AR-Konfiguration und den Betrieb zu überprüfen.

  1. Überprüfen Sie die Underlay- und Overlay-Konfigurationen, und vergewissern Sie sich, dass die Fabric den BGP-Status und die Datenverkehrspfade zwischen den Geräten eingerichtet hat.

    SL-1 (Gerät lo0: 192.168.0.1):

    Führen Sie diesen Befehl auf jedem SL-, BL- und S-ARR-Gerät in der Fabric aus.

  2. Überprüfen Sie die konfigurierten VTEPs in der MAC-VRF-EVPN-Instanz auf den SL-, BL- und S-ARR-Geräten.

    Sie können den show ethernet-switching vxlan-tunnel-end-point remote Befehl oder seinen Alias ( show mac-vrf forwarding vxlan-tunnel-end-point remote command sofern unterstützt) verwenden.

    Zum Beispiel:

    SL-1:

    Hinweis:

    Sie sehen auch die AR-Rolle des Geräts auf jedem Remote-VTEP in der Spalte RVTEP-Modus der Ausgabe dieses Befehls wie folgt

    • Die primäre Loopback-IP-Adresse auf einem AR-Replikatorgerät ist die Eingangsreplikations-IP-Adresse (Ingress Replication, IR), die das Gerät verwendet, um Datenverkehr an RNVE-Geräte weiterzuleiten. Aus diesem Grund wird in der Spalte RVTEP-IP "RNVE" als die Rolle angezeigt, die den primären Loopbackadressen des S-ARR-Geräts entspricht.

    • Die sekundäre Loopback-IP-Adresse, die Sie der AR-Replikatorrolle zuweisen, ist die AR-IP-Adresse. In dieser Ausgabe wird "Replikator" als Rolle für diese RVTEP-IP-Adressen angezeigt.

    • Die AR-Leaf-Geräte und das RNVE-Gerät verwenden nur IR-Tunnel, daher zeigt dieser Befehl in der Spalte RVTEP-IP die Rolle "Leaf" oder "RNVE" an, die der primären Loopback-IP-Adresse für diese Geräte entspricht.

    Führen Sie diesen Befehl auf jedem SL-, BL- und S-ARR-Gerät in der Fabric aus.

  3. Überprüfen Sie, ob das SL-Gerät mit dem TOR-Gerät verknüpft ist. Diese Links sind ae3 auf jedem SL-Gerät. Außerdem sind SL-4 und SL-5 Multihoming-Peers für TOR-3 und TOR-4 und verwenden ae5 für diese zusätzlichen TOR-Geräteverbindungen. (Siehe Abbildung 3.)

    Zum Beispiel:

    SL-1 bis TOR-1:

    SL-2 bis TOR-1:

    Wiederholen Sie diesen Befehl auf jedem SL-Gerät für die Schnittstelle ae3 und auf SL-4 und SL-5 für ae5.

  4. Überprüfen Sie die Erreichbarkeit des OSPF-Nachbarn der externen L3-Schnittstelle auf den BL-Geräten für jede VRF-Instanz des Mandanten.

    BL-1:

    BL-2:

  5. Überprüfen Sie die Verbindungen des PIM-Routers und des RP-Geräts vom externen PIM-Router und RP-Gerät zu den BL-Geräten.
  6. Überprüfen Sie den AR-Leaf-Overlay-Tunnel-Lastausgleich für die verfügbaren AR-Replikatorgeräte.

    Die AR-Leaf-Geräte erkennen die beworbenen AR-Replikator-Geräte und führen einen Lastenausgleich zwischen ihnen mit verschiedenen Methoden basierend auf der Leaf-Geräteplattform durch. (Weitere Informationen finden Sie unter AR Leaf Device Load Balancing mit mehreren Replikatoren .)

    In diesem Beispiel ist SL-1 ein QFX5120-Switch, sodass SL-1 als AR-Leaf-Gerät einen Lastenausgleich durchführt, indem jedem VLAN oder VNI ein AR-Replikatorgerät zugewiesen wird.

    Führen Sie den show evpn multicast-snooping assisted-replication next-hops instance mac-vrf-instance Befehl auf den AR-Leaf-Geräten aus, um die Overlay-Tunnel und den Lastenausgleich der nächsten Hops zu den verfügbaren AR-Replikatoren anzuzeigen. Auf SL-Geräten, die AR-Replikatoren nach VNI festlegen, kennzeichnet die Ausgabe dieses Befehls den AR-Replikator als (Designated Node). Die Ausgabe enthält dieses Tag nicht auf AR-Leaf-Geräten, die einen Lastenausgleich basierend auf dem aktiven Datenverkehrsfluss durchführen.

    Die Ausgabe hier für SL-1 zeigt beispielsweise, dass das zugewiesene Gerät:

    • S-ARR-1 als designierter Replikator für konfigurierte VNIs 110001 und 110003 (entspricht VLAN-1 bzw. VLAN-3)

    • S-ARR-2 als designierter Replikator für konfigurierte VNI-110002 und -110004 (die VLAN-2 bzw. VLAN-4 entsprechen)

    SL-1:

    Führen Sie diesen Befehl auf den SL- und BL-Geräten in der Fabric aus.

  7. Überprüfen Sie den PIM-Beitritts- und Multicast-Gruppenstatus für einen Multicast-Stream von einer Quelle innerhalb der Fabric hinter TOR-1. TOR-1 ist mit SL-1 und SL-2 multivernetzt (siehe Abbildung 1). Empfänger auf den TOR-Geräten, die mit den anderen SL-Geräten verbunden sind, abonnieren Multicast-Gruppen, die von dieser Quelle gehostet werden, wie in Tabelle 1 aufgeführt. Bei dem Stream, den wir hier verifizieren, handelt es sich um Intra-VLAN- und Inter-VLAN-Datenverkehr mit Quell-VLAN-VLAN-1 und Empfänger-VLANs VLAN-2, VLAN-3 und VLAN-4.

    Wenn AR aktiviert ist, leitet das Eingangs-SL-Gerät den Multicast-Quelldatenverkehr an den angegebenen AR-Replikator weiter. Siehe Abbildung 4. Der AR-Replikator leitet Kopien an die SL-Geräte mit abonnierten Empfängern im Quell-VLAN, VLAN-1, weiter. Dann leiten die SL-Geräte den Datenverkehr an die Empfänger in VLAN-1 weiter.

    In diesem Schritt führen Sie die Befehle nur für VRF-1 aus, bei dem es sich um die Mandanten-VRF handelt, die in diesem Beispiel den internen Multicast-Quelldatenverkehr hostet. Außerdem handelt es sich bei diesem Stream um einen IGMPv3-Stream mit SSM-Berichten, sodass nur (S,G)-Multicastrouten angezeigt werden. In diesem Fall zeigt die Ausgabe, dass die Quelle hinter TOR-1 die Quell-IP-Adresse 10.0.1.12 hat.

    In diesem Schritt zeigen wir laufende Überprüfungsbefehle für:

    • PIM-Join-Status auf SL-1 und SL-2 für die Quelle auf dem mehrfach vernetzten Gerät TOR-1.

      Die show pim join summary Ausgabe zeigt, dass die SL-Geräte, die TOR-1 bedienen, Joins für insgesamt 6 Multicast-Gruppen sahen.

    • IGMP-Snooping-Multicast-Gruppenmitgliedschaftsstatus für den Empfänger hinter dem Gerät TOR-4, das auf SL-4 und SL-5 multihomed ist.

      Die show igmp snooping membership Ausgabe zeigt die Multicast-Gruppenbeitritte vom Empfänger hinter TOR-4. TOR-4 hasht die Join-Nachrichten an eines der Multihoming-Peer-SL-Geräte. Die Anzahl der Verknüpfungen auf beiden Geräten zusammen (3 auf jedem Gerät) entspricht der Gesamtzahl der Verknüpfungen in der show pim join summary Ausgabe (6).

    • Zusammenfassung des PIM-Beitrittsstatus und Details zu SL-4 und SL-5 für den Empfänger hinter dem Multihomed-Gerät TOR-4.

      Wenn die show pim join extensive Ausgabe auf SL-4 und SL-5 dieselbe Upstream- und Downstream-IRB-Schnittstelle anzeigt, überbrückt das Gerät den Multicast-Stream innerhalb desselben VLANs. Wenn sich die Downstream-IRB-Schnittstellen von der Upstream-IRB-Schnittstelle unterscheiden, leitet das Gerät den Multicast-Stream zwischen VLANs weiter.

    • Der designierte Forwarder unter den Multihoming-Peers SL-4 und SL-5, den das Gerät ausgewählt hat, um den Datenverkehr an den Empfänger hinter dem mehrfach vernetzten TOR-4 weiterzuleiten.

      Wir führen den show evpn instance MACVRF-1 designated-forwarder esi Befehl für die von Ihnen konfigurierte ESI auf den ae5-Schnittstellen von SL-4 und SL-5 bis TOR-4 aus.

    SL-1: Interne Quelle – PIM-Join-Status für VRF-1:

    SL-2: Interne Quelle – PIM-Join-Status für VRF-1:

    SL-4: Receiver - Multicast-Gruppenmitgliedschaftsstatus auf Quell-VLAN-VLAN-1 und Empfänger-VLANs VLAN-1 bis VLAN-4::

    SL-5: Receiver - Multicast-Gruppenmitgliedschaftsstatus auf Quell-VLAN-VLAN-1 und Empfänger-VLANs VLAN-1 bis VLAN-4:

    SL-4: Empfänger – PIM-Join-Status für VRF-1:

    SL-5: Empfänger – PIM-Beitrittsstatus für VRF-1:

    SL-4: Überprüfen Sie den vorgesehenen Weiterleitungsempfänger zum Empfänger hinter TOR-4:

    Denken Sie daran, dass wir in der SL-Gerätekonfiguration ae5 als Bindeglied von SL-4 und SL5 zu TOR-4 zuweisen. Wir haben ESI 00:00:00:ff:00:04:00:01:00:05 für diese Links festgelegt. Die folgende Ausgabe zeigt, dass SL-4 nicht die vorgesehene Weiterleitung für diese ESI ist.

    SL-5: Überprüfen Sie den vorgesehenen Weiterleitung zum Empfänger hinter TOR-4:

    Die folgende Ausgabe bestätigt, dass SL-5 (lo0.0 192.168.0.5) die designierte Weiterleitung für ESI 00:00:00:ff:00:04:00:01:00:05 ist.

  8. Überprüfen Sie den PIM-Beitritts- und Multicastgruppenstatus für einen Multicast-Stream von einer Quelle außerhalb der Fabric in der externen PIM-Domäne. Siehe Abbildung 1. Empfänger hinter den TOR-Geräten, die mit den SL-Geräten verbunden sind, abonnieren Multicast-Gruppen, die von dieser Quelle gehostet werden, wie in Tabelle 1 aufgeführt. Das eingehende BL-Gerät leitet den externen Quelldatenverkehr von der L3-Schnittstellenverbindung an das SBD-VLAN (in diesem Fall VLAN-2101) weiter.

    Wenn AR aktiviert ist, leitet das BL-Gerät den Datenverkehr im SBD-VLAN an einen AR-Replikator weiter (je nach BL-Geräteplattform entweder den designierten AR-Replikator oder einen AR-Replikator basierend auf dem Datenverkehrslastenausgleich). Siehe Abbildung 4. Der AR-Replikator leitet Kopien auf der SBD an die SL-Geräte mit abonnierten Empfängern weiter. Dann leiten die SL-Geräte den Datenverkehr weiter oder leiten ihn lokal zu den Empfängern in den Mandanten-VLANs weiter.

    In diesem Schritt führen Sie die Befehle nur für VRF-101 aus, bei dem es sich um die Mandanten-VRF handelt, die in diesem Beispiel externen Multicast-Quelldatenverkehr hostet. Außerdem handelt es sich bei diesem Stream um einen IGMPv2-Stream mit ASM-Berichten, sodass nur (*,G)-Multicastrouten angezeigt werden.

    In diesem Schritt führen Sie Überprüfungsbefehle aus für:

    • PIM-Beitrittsstatus auf BL-1 und BL-2 als Eingangsgeräte für die externe Multicastquelle.

    • IGMP-Snooping-Multicast-Gruppenmitgliedschaftsstatus für einen Empfänger hinter dem Gerät TOR-1, das auf SL-1 und SL-2 multihomediert ist.

    • PIM-Join-Status auf SL-1 und SL-2 für den Empfänger auf dem Multihomed-Gerät TOR-1.

    BL-1: Eingangs-BL-Gerät für externe Quelle – PIM-Join-Status für VRF-101:

    BL-2: Eingangs-BL-Gerät für externe Quelle – PIM-Join-Status für VRF-101:

    SL-1: Receiver - Multicast-Gruppenmitgliedschaftsstatus für VLANs, die VRF-101 zugeordnet sind (VLAN-401 bis VLAN-404):

    SL-2: Receiver - Multicast-Gruppenmitgliedschaftsstatus für VLANs, die VRF-101 zugeordnet sind (VLAN-401 bis VLAN-404):

    SL-1: Empfänger – PIM-Join-Status für VRF-101:

    SL-2: Empfänger – PIM-Beitrittsstatus für VRF-101:

  9. Stellen Sie sicher, dass die OISM-Geräte EVPN Typ 6 (SMET)-Routen verwenden, um den Multicast-Datenverkehrsfluss im EVPN-Kern zu optimieren. Zeigen Sie die Typ-6-Routen in den EVPN-Routing-Tabellen (bgp.evpn.0 und MACVRF-1.evpn.0) auf OISM-Leaf-Geräten und den Spine-Geräten, die als AR-Replikatoren fungieren, an. Routen vom Typ 6 werden nur im SBD-VLAN angekündigt.

    Hier sehen wir zum Beispiel Typ-6-Routen für interessierte Empfänger hinter TOR-4, das auf die Peer-SL-Geräte SL-4 und SL-5 multihomed ist. Wir zeigen die Ergebnisse für die Parameter des vorgestellten Multicast-Streams in Tabelle 1 für den Mandanten VRF-1 mit IGMPv3-Datenverkehr zwischen einer internen Quelle und internen Empfängern:

    • VLANs: VLAN-1 bis VLAN-4, die VNIs 110001 bis 110004 zugeordnet sind

    • SBD-VLAN: VLAN-2001, das VNI-992001 zugeordnet ist

    • Interne Quelle: Hinter SL-1 und SL-2 auf TOR-1, mit interner IP-Adresse 10.0.1.12

    • Multicast-Gruppen: 233.252.0.121 bis 233.252.0.123

    Diese Befehle zeigen:

    • S-ARR-1 und SL-ARR-2 erhielten Typ-6-Routen von SL-4 und SL-5 auf der SBD (VLAN-2001 VNI 992001).

    • SL-4 (lo0: 192.168.0.4) und SL-5 (lo0: 192.168.0.5) empfingen Joins von einem Empfänger hinter dem mehrfach vernetzten TOR-4 für die Multicast-Gruppen 233.252.0.121 bis 233.252.0.123.

    • Quell- (10.0.1.12) und Gruppeninformationen, da die Empfänger IGMPv3-Joins senden.

    Für S-ARR-1 – Typ 6 Routen von SL-4 und SL-5:

    S-ARR-1 verlinkt auf SL-4 auf ae4 (172.16.7.0/31).

    S-ARR-1 verlinkt auf SL-5 auf ae5 (172.16.8.0/31):

    Führen Sie die gleichen Befehle auf S-ARR-2 aus, um eine ähnliche Ausgabe auf diesem Gerät anzuzeigen. S-ARR-2 verlinkt auf SL-4 auf ae4 (172.16.9.0/31) und SL-5 auf ae5 (172.16.10.0/31).

    SL-4 - Lokal generierte Typ-6-Routen und Typ-6-Routen von anderen SL-Geräten über S-ARR-1 und S-ARR-2:

    Sie sehen ähnliche Typ-6-Routen wie Remote-Routen von den anderen SL-Geräten, die auch Empfänger für dieselben Gruppen in derselben Mandanten-VRF für die interne Quelle auf TOR-1 bedienen (Multihomed auf SL-1 und SL-2).

    Führen Sie diese Befehle auf SL-5 aus, um die Typ-6-Routen auf diesem Gerät anzuzeigen. Übereinstimmung mit dem Präfix 6:192.168.0.5, um die lokal generierten Typ-6-Routen für SL-5 anzuzeigen. Gleichen Sie andere Gerätepräfixe ab (z. B. 6*192.168.0.4 für SL-4), um die remote generierten Typ-6-Routen anzuzeigen.

  10. Stellen Sie sicher, dass die Peer-Geräte für Multihoming-ESs EVPN-Routen vom Typ 7 verwenden, um Multicast-Join-Zustände zu synchronisieren.

    Verwenden Sie den show route table __default_evpn__.evpn.0 Befehl, um die Routenpräfixe vom Typ 7 anzuzeigen.

    Hier zeigen wir zum Beispiel Typ-7-Routen, die von den Peer-SL-Geräten SL-4 und SL-5 für den Empfänger hinter TOR-4 mit einer internen Quelle und IGMPv3-Joins generiert wurden (siehe die Parameter in Tabelle 1 für VRF-1). TOR-4-Hashes verbinden Nachrichten von ihren Empfängern entweder mit SL-4 oder SL-5. Die Geräte kündigen jeweils Typ-7-Routen für die empfangenen Joins an ihre Multihoming-Peers an, um den Join-Status zwischen ihnen zu synchronisieren.

    Diese Befehle zeigen:

    • SL-5 lokal generierte Typ-7-Routen zur Ankündigung für SL-4

    • SL-5 empfing Type 7 Routenankündigungen von SL-4 für Joins, die TOR-4 zu SL-4 gehasht hat

    • OISM-Geräte kündigen Routen vom Typ 7 und Typ 8 in den OISM-Umsatz-VLANs an, nicht in der SBD.

      In diesem Fall traten die Empfänger Gruppen auf VLAN-2 (VNI-110002, gehasht auf SL-5) und VLAN-3 (VNI-110003, gehasht auf SL-4) bei.

    Beachten Sie, dass die ESI, die wir für die SL-4- und SL-5-Verbindungen zu TOR-4 konfiguriert haben, 00:00:00:ff:00:04:00:01:00:05 ist, was Sie im Routeneintrag Typ 7 in der Routing-Tabelle sehen.

    SL-5 — Lokal generierte Typ-7-Routen, die für SL-4 angekündigt werden sollen:

    Diese Ausgabe zeigt, dass SL-5 lokal drei Typ-7-Routen für Joins auf VLAN-2 (VNI 110002) für die Multicast-Gruppen 233.252.0.121 bis 233.252.0.123 generiert hat. .

    SL-5 – Typ 7 Routen von SL-4:

    Diese Ausgabe zeigt, dass SL-5 drei Routenankündigungen vom Typ 7 von SL-4 für Joins auf VLAN-3 (VNI 110003) für die Multicast-Gruppen 233.252.0.121 bis 233.252.0.123 empfangen hat.

    Führen Sie diese Befehle auf SL-4 aus, um Typ-7-Routen auf diesem Gerät anzuzeigen. Gleichen Sie das Präfix 7:192.168.0.5 ab, um die Typ-7-Routen von seinem Multihoming-Peer SL-5 anzuzeigen. Übereinstimmung mit dem Präfix 7:192.168.0.4, um die lokal generierten Typ-7-Routen anzuzeigen, die SL-4 für SL-5 ankündigt.

    Sie können diese Befehle verwenden, um Typ-7-Routen auf den anderen Multihoming-Peer-SL-Gerätepaaren anzuzeigen.