Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
AUF DIESER SEITE
 

Optimiertes Intersubnet Multicast (OISM) mit Assisted Replication (AR) für Edge-Routed Bridging-Overlays

Dieses Beispiel zeigt, wie unsere ursprüngliche optimierte Intersubnet Multicast (OISM)-Implementierung mit assistierter Replikation (AR) in einer großen EVPN-VXLAN Edge-Routed Bridging (ERB)-Overlay-Fabric konfiguriert wird.

In EVPN ERB-Overlay-Fabric-Designs leiten die Leaf-Geräte den Datenverkehr zwischen Mandanten-VLANs sowie den Datenverkehr innerhalb von 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 RFC9625 EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding basiert. OISM kombiniert die besten Aspekte von ERB- und CRB-Overlay-Designs für Multicast-Datenverkehr, um den effizientesten Multicast-Datenverkehrsfluss in ERB-Overlay-Fabrics zu ermöglichen, insbesondere in skalierten Umgebungen.

OISM ermöglicht ERB-Overlay-Fabrics:

  • Unterstützung von Multicast-Datenverkehr mit Quellen und Empfängern innerhalb und außerhalb der Fabric.

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

Unsere ursprüngliche OISM-Implementierung, reguläres OISM genannt, verwendet ein symmetrisches Bridge-Domain-Modell. Bei diesem Modell konfigurieren Sie alle Mandanten-VLANs in der Fabric symmetrisch auf allen OISM-Geräten. Dieses Beispiel zeigt eine reguläre OISM-Konfiguration.

Auf einigen Plattformen unterstützen wir auch eine erweiterte Version von OISM, die ein asymmetrisches Bridge-Domain-Modell verwendet, bei dem Sie nicht alle Mandanten-VLANs auf allen OISM-Geräten symmetrisch konfigurieren müssen. Die OISM-Konfigurationselemente und -schritte sind für reguläre und erweiterte OISM fast gleich. Der Hauptunterschied besteht neben der Einstellung eines der beiden OISM-Modi darin, wie Sie die Mandanten-VLANs in jedem Modus konfigurieren. Enhanced OISM weist auch einige wichtige betriebliche Unterschiede auf, um das asymmetrische Bridge-Domain-Modell zu unterstützen. Eine erweiterte OISM-Konfiguration finden Sie unter Enhanced Optimized Intersubnet Multicast (OISM) Implementation .

Reguläre OISM kann auch mit der AR-Funktion (Assisted Replication) zusammenarbeiten, um die Multicast-Replikation in der Fabric auf die Geräte zu entlasten und auszugleichen, die für die Last besser gerüstet sind. Weitere Informationen zur Funktionsweise von AR finden Sie unter Assisted Replication Multicast Optimization in EVPN Networks und Optimized Intersubnet Multicast for ERB Overlay Networks weiter oben in diesem Handbuch für eine kurze Zusammenfassung der Funktionsweise von OISM mit AR. Dieses Beispiel umfasst die Konfiguration von AR mit regulärem OISM.

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

Hinweis:

Ab Junos OS Version 24.4R1 haben wir regelmäßiges OISM in großem Umfang in Umgebungen getestet, die auch Konfigurationen für die folgenden Funktionen enthalten:

Wir haben diese Funktionen mit OISM qualifiziert, aber ohne AR-Aktivierung. In den hier beschriebenen regulären OISM-Anwendungsfällen sind keine Konfigurationsanweisungen für diese Features enthalten.
Abbildung 1: Edge-Routed Bridging Overlay Fabric mit OISM und AR Edge-Routed Bridging Overlay Fabric with OISM and AR

Im Folgenden 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 Intersubnetz-Multicast in EVPN-Netzwerken.

  • In diesem Beispiel übernehmen die OISM-Geräte eine der folgenden Geräterollen:

    • 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 mit einer externen PIM-Domäne verbunden sind, 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 einfach als schlanke Spines fungieren.

  • In diesem Beispiel konfigurieren Sie OISM mit einer MAC-VRF EVPN-Instanz mit dem VLAN-fähigen Diensttyp (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.

  • In diesem Beispiel wird reguläres OISM konfiguriert, das ein symmetrisches Bridge-Domänenmodell verwendet. Mit diesem Modell konfigurieren Sie alle Mandanten-VLANs (auch Revenue Bridge Domains oder Revenue VLANs genannt) 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 Intrasubnetz-Bridging durch und verwenden ein lokales Routing-Modell für Intersubnetz-Multicast-Datenverkehr (Layer 3 [L3]), um Bandbreite zu sparen und Hairpining im EVPN-Core 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 den Datenverkehr von externen Multicast-Quellen in den EVPN-Core nur auf einer zusätzlichen Bridge-Domäne namens SBD an interne Empfänger weiter. Das SBD-Design ermöglicht das lokale Routing-Modell und löst andere Probleme mit externem Datenverkehr. Für jede VRF-Instanz des Mandanten weisen Sie dem SBD ein VLAN und eine entsprechende IRB-Schnittstelle zu.

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

  • Wir unterstützen OISM mit IGMPv2 (nur Any-Source Multicast [ASM]-Berichte) oder IGMPv3 (nur quellenspezifische Multicast [SSM]-Berichte). 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 verschiedenen 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 VRF-Instanz des Mandanten zu.

    Weitere Informationen zu den erforderlichen Konfigurationsüberlegungen finden Sie unter Überlegungen zu OISM-Konfigurationen . Die hier getestete Konfiguration unterstützt 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 selektive SMET-Weiterleitung (Multicast Ethernet Tag). Mit SMET leiten OISM-Geräte den Datenverkehr für eine Multicast-Gruppe 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 regulären OISM-Modell kündigen OISM-Geräte EVPN-Typ-6-Routen nur auf dem 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) mehrfach vernetzt sind, um mehr als ein OISM-Leaf-Gerät zu verbinden. Sie konfigurieren einen ES-Identifikator (ESI) für die Links 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 ein ES bedienen.

In dieser Umgebung validieren wir OISM und AR zusammen in großem Umfang 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ärt mehr darüber, wie AR in diesem Beispiel funktioniert. Wenn die AR-Replikatorrolle nicht wie in diesem Beispiel mit einer OISM-Grenzblattrolle auf demselben Gerät verbunden ist, 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 RNVE-Geräte (Network Virtualisierung Edge). Die Testumgebung umfasst ein SL-Gerät (siehe SL-3 in Abbildung 1), auf dem wir die AR-Leaf-Rolle nicht konfigurieren, um ein RNVE-Gerät zu simulieren. 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 die Konfiguration und Verifizierung für eine kleine Teilmenge der skalierten Umgebung, in der wir OISM und AR zusammen validieren. Obwohl die skalierte Testumgebung mehr Geräte, konfigurierte Elemente, Multicastquellen und abonnierte Empfänger umfasst, zeigen wir in diesem Beispiel die Konfigurations- und Überprüfungsausgabe für die folgenden Elemente:

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

  • Multicast-Stream-Anwendungsszenarien, die Folgendes umfassen:

    • IGMPv2- oder IGMPv3-Datenverkehr.

    • Interne oder externe Multicast-Quellen.

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

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

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

      Im OISM-Design bezeichnen wir die Mandanten-VLANs als Revenue-Bridge-Domänen oder Revenue-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) 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 Multicast-Stream hat mehrere Empfänger, die den Datenverkehr von jeder Quelle abonniert haben. Die Befehle zur Überprüfung des Multicast-Datenverkehrs 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 jedes der Mandanten-VRFs in der Tabelle.

Tabelle 1: OISM-Ströme und -Elemente in diesem Beispiel

Multicast-Stream

VRF für Mandanten

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 für SL-1 und SL-2)

TOR-4 (Multihomed für SL-4 und SL-5)

Andere Empfänger:

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

TOR-3 (Multihomed für SL-4 und SL-5)

TOR-5 (Single-Homed 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-Domain)

TOR-1 auf VLAN-1 (Multihomed für SL-1 und SL2)

Andere Empfänger:

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

TOR-3 (Multihomed für SL-4 und SL-5)

TOR-4 (Multihomed für SL-4 und SL-5)

TOR-5 (Single-Homed 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 Verbindungsparameter des BL-Geräts und des externen PIM-Routers L3. In diesem Beispiel verwenden beide BL-Geräte die aggregierte Ethernet-Schnittstelle ae3 für die externe L3-Verbindung mit unterschiedlichen Subnetzen pro BL-Gerät. In der skalierten Testumgebung verwendet die Konfiguration einen Bereich logischer Einheiten auf der ae3-Schnittstelle mit entsprechenden VLANs pro Mandanten-VRF, beginnend mit Einheit 0 und VLAN-3001 für VRF-1. Wir konzentrieren uns in diesem Beispiel auf die VRF-Instanzen VRF-1 und VRF-101.

Tabelle 2: Parameter der externen Multicast-L3-Schnittstelle

BL-Gerät

VRF-Instanz für Mandanten

Logische Einheit externer L3-Schnittstelle

Zugehöriges VLAN

BL L3 – IP-Adresse der logischen Schnittstelle

Logische Schnittstelle und IP-Adresse des PIM-Routers

Logische Einheit und IP-Adresse von PIM RP

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 (mit EBGP) und das Overlay (mit IBGP)

Wir verwenden eBGP für das Underlay und iBGP für das Overlay, indem wir den Referenzarchitekturen in IP Fabric Underlay, Netzwerkdesign und -implementierung folgen und IBGP für das Overlay konfigurieren.

In diesem Beispiel werden AE-Schnittstellen mit jeweils einer oder zwei Mitgliedsverbindungen für alle Verbindungen zur Redundanz verwendet.

Abbildung 2: OISM BL-Geräteverbindungen mit S-ARR-Geräten und externem PIM-Router OISM BL Device Links to S-ARR Devices and External PIM Router
Abbildung 3: OISM SL-Geräteverbindungen mit S-ARR-Geräten und TOR-Geräten OISM SL Device Links to S-ARR Devices and TOR Devices
  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 die Anweisungen 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 Geräte-IP-Adressen, AS-Nummern sowie die AE-Schnittstellennamen und 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 Network Design and Implementation.

    In Abbildung 2 und Abbildung 3 finden Sie die Geräte-IP-Adressen, AS-Nummern sowie die AE-Schnittstellennamen und 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 IBGP für das Overlay konfigurieren.

    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 IP-Adresse des Geräte-Loopback. 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 die Timerwerte für MAC-Alterung, ARP (Address Resolution Protocol) und NDP (Neighbor Discovery Protocol) fest, um das Lernen von MAC-Adressen und das Lernen von IPv4- und IPv6-Routen zu unterstützen. Diese Parameter sind gängige Einstellungen in EVPN-VXLAN-Fabrics und nicht spezifisch für die OISM- oder AR-Funktionskonfigurationen.

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

    Stellen Sie den veralteten NDP-Timer auf allen IRB-Schnittstellen für die IPv6-Neighbor-Reachability-Bestätigung auf allen SL- und BL-Geräten für IPv6-Unicast-Datenverkehr ein.

    Hinweis:

    Sie wenden diese Einstellung auf alle IRB-Schnittstellen an, die IPv6-Unicast-Datenverkehr verarbeiten könnten, daher 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 verlangen, dass Sie die Funktion "Freigegebene Tunnel" auf der QFX5000 Reihe von Switches aktivieren, die Junos OS mit einer MAC-VRF-Instanzkonfiguration ausführen. Diese Funktion verhindert Probleme mit der VTEP-Skalierung auf dem Gerät, wenn die Konfiguration mehrere MAC-VRF-Instanzen verwendet. Wenn Sie freigegebene Tunnel konfigurieren, minimiert das Gerät die Anzahl der Next-Hop-Einträge, die Remote-VTEPs erreichen. Sie aktivieren freigegebene VXLAN-Tunnel global 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 Aussage ist für die QFX10000-Reihe von Switches mit Junos OS optional, die eine höhere VTEP Skalierung verarbeiten können als die QFX5000 von Switches. 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 beinhaltet 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 regulären 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. 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 auf den Spine-Geräten nicht konfigurieren.
  1. Konfigurieren Sie MACVRF-1, eine EVPN MAC-VRF-Instanz mit dem VLAN-fähigen Servicetyp. Geben Sie die Quellschnittstelle des VXLAN Tunnel Endpoint (VTEP) als Geräte-Loopback-Schnittstelle an. Legen Sie eine Routenunterscheidung und ein Routenziel (mit automatischer Routenzielableitung) für die Instanz fest. Aktivieren Sie außerdem alle VNIs in der Instanz, um in die EVPN-BGP-Domäne erweitert zu werden.

    Zum Beispiel:

    SL-1:

    Wiederholen Sie diesen Schritt auf den verbleibenden SL-Geräten 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 für alle Geräte 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 arbeiten.

    1. Schließen Sie auf Junos OS Geräten der QFX5000 Switch-Reihe die Konfigurationsanweisung für global freigegebene Tunnel ein. 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 das Gerät nach dem Commit der Konfiguration neu starten, damit die Einstellung für freigegebene Tunnel wirksam wird.

      Die Funktion "Freigegebene Tunnel" ist standardmäßig auf Geräten eingestellt, auf denen Junos OS Evolved ausgeführt wird.

    2. Konfigurieren Sie auf QFX5130- und QFX5700-Switches die Option für ein host-profile einheitliches Weiterleitungsprofil, um eine EVPN-VXLAN-Umgebung zu unterstützen (weitere Informationen finden Sie unter Layer-2-Weiterleitungstabellen ):

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

      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 einen SBD und das entsprechende IRB für jedes VRF.

    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 auf ihnen 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) 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 verwenden IGMP-Snooping, um die Weiterleitung des Datenverkehrs zu optimieren.

    In EVPN-VXLAN-Fabrics unterstützen wir IGMPv2-Datenverkehr nur mit ASM-Berichten. Wir unterstützen IGMPv3-Datenverkehr nur mit SSM-Berichten. Wenn Sie IGMP-Snooping für IGMPv3-Datenverkehr aktivieren, schließen Sie die SSM-spezifische Konfigurationsoption evpn-ssm-reports-only 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 auf allen VLANs:

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

  6. Aktivieren Sie IGMP auf den IRB-Schnittstellen, die den Multicast-Datenverkehr auf den 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 sind die IGMPv3-IRB-Schnittstellen irb.1, irb.2, irb.3 und irb.4, die mit VRF-1 verbunden sind:

  7. (Erforderlich auf allen Geräten, die als AR-Replikatoren mit OISM konfiguriert sind, sowie auf den Switches der QFX10000-Reihe und der Router der PTX10000-Reihe 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 Packet Forwarding 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 Latenz- und Skalierungskompromisse bei der Installation von Multicast-Routen mit OISM (install-star-g-routes Option).

    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 der QFX10000-Reihe. Wenn also auf diesen Geräten frühere Versionen als Junos OS oder Junos OS Evolved Version 23.4R1 ausgeführt werden, sollten Sie diese Anweisung auch auf diesen Geräten konfigurieren.

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

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

  • VRF-1 für IGMPv3-Datenverkehr aus einer internen Quelle.

  • VRF-101 für IGMPv2-Datenverkehr, der von einer externen Quelle bezogen 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, daher müssen Sie auch alle VRF-Einstellungen des Mandanten auf ihnen konfigurieren. 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 VRF-Instanzen des Mandanten unterschiedliche PIM-Optionen für SL-Geräte im Vergleich zu BL-Geräten. Weitere Informationen finden Sie unter Konfigurieren von OSPF und 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 für diese Konfigurationsschritte. Sie müssen PIM nicht auf den S-ARR-Geräten konfigurieren.

  1. Konfigurieren Sie die VRF-Instanzen des Mandanten.

    Schließen Sie die IRB-Schnittstellen ein, die jeder VRF-Instanz des Mandanten 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 auf den verbleibenden SL-Geräten BL-1, BL-2, S-ARR-1 und S-ARR-2. Konfigurieren Sie auf jedem Gerät die route-distinguisher so, dass sie für alle Geräte und Mandanten-VRFs eindeutig sind. Ersetzen Sie die IP-Adresse des Geräts aus Abbildung 2 oder Abbildung 3 und die VRF-Instanznummer für jedes 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. Schließen Sie in jede VRF-Instanz die entsprechenden IRB-Schnittstellen für die OISM-Umsatz-VLANs und das mit dieser Instanz verknüpfte SBD gemäß Tabelle 1 ein:

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

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

    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 mit einer einzigen Routing-Engine die Funktion für den ordnungsgemäßen Neustart für jedes Mandanten-VRF:

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

Die TOR-Geräte hosten die Multicast-Quellen und -Empfänger innerhalb der Fabric. Diese Geräte verfügen über Single-Homed- oder Multihomed-Verbindungen zu den SL-Geräten im EVPN-Core. In Abbildung 3 finden Sie die Topologie in diesem Beispiel. TOR-1, TOR-3 und TOR-4 sind jeweils auf zwei SL-Geräte ausgerichtet, und TOR-2 und TOR-5 sind Single-Homed. Abbildung 3 zeigt, dass:

  • Die SL-Geräte verwenden alle die Schnittstelle ae3, um eine Verbindung zu den TOR-Geräten herzustellen.

  • 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.

  • Aus Gründen der Konsistenz in der Konfiguration verwenden die Single-Homed TORs (TOR-2 und TOR-5) ebenfalls die Schnittstellen ae1 und ae2, jedoch als redundante Verbindungen zu einem einzigen SL-Gerät.

Außerdem können Sie ab Junos OS und Junos OS Evolved Version 23.2R2 zusätzlich die Netzwerkisolationsfunktion auf den mehrfach vernetzten TOR-Schnittstellen der SL-Geräte 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 angezeigt werden, können Sie die Netzwerkisolationsfunktion für alle solchen Schnittstellen auf BL-Geräten auf ähnliche Weise konfigurieren.
  1. Konfigurieren Sie den Server-Leaf zu TOR-Schnittstellen und Ethernet-Segmentbezeichnern (ESIs) für EVPN-Multihoming.

    Konfigurieren Sie auf Multihoming-Peer-SL-Geräten dieselbe ESI für die AE-Schnittstellenverbindungen mit dem mehrfach vernetzten TOR-Gerät. Aktivieren Sie auch LACP- und LACP-Hold-Timer auf den Schnittstellen. Weitere Informationen zur Konfiguration dieser Schnittstellen und der entsprechenden Ethernet Segment Identifier (ESIs) finden Sie unter Multihoming an Ethernet-Connected End System Design and Implementation .

    Hinweis:

    In Schritt 4 dieses Abschnitts wird das Gerät so konfiguriert, dass Netzwerkisolationsereignisse auf diesen Schnittstellen erkannt und entsprechende Maßnahmen ergriffen werden. Wenn Sie diese Konfiguration einbeziehen, stellen Sie sicher, dass der hier in diesem Schritt konfigurierte Haltetimer für "Up" größer ist als der Haltetimer für "Up" im Profil der Netzwerkisolationsgruppe 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 von 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 für jedes entsprechende Multihoming-Peer-SL-Gerätepaar einen anderen ESI. 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 sich mit TOR-3 zu verbinden, und verwenden zusätzlich ae5, um mit TOR-4 zu verknüpfen. Infolgedessen legen Sie einen ESI für die ae3-Verbindungen und einen anderen ESI für die ae5-Verbindungen 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 entspricht der Nummer des mehrfach vernetzten TOR.

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

    Zum Beispiel:

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

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

    TOR-2 ist Single-Homed für SL-3, sodass Sie keine ESI auf der ae3-Schnittstelle auf SL-3 konfigurieren.

    Ebenso ist TOR-5 Single-Homed zu SL-6, sodass Sie keine ESI auf der ae3-Schnittstelle von SL-6 konfigurieren.

    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 den Unicast-Datenverkehr verwendet. Wir zeigen hier nur die Konfiguration der Multicast-ESIs.
  3. Schließen Sie die Schnittstellen zu den TOR-Geräten in die 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):

    Zu 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 Release 23.2R2 mit dieser OISM-Konfiguration) Konfigurieren Sie die Funktion zur Überwachung des Netzwerkisolationsdienstes auf SL-1 und SL-2 für die Schnittstellen ae3 zu TOR-1. Mit dieser Funktion ändert das Gerät den Schnittstellenstatus, wenn es ein Core-Isolationsereignis erkennt und wiederherstellt. 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 eine Netzwerkisolationsgruppe net-isolation-grp-1 mit Core-Isolationsdienstverfolgung mithilfe der network-isolation-Anweisung ein.

    • Fügen Sie eine "Up"-Haltezeit (in ms) hinzu, die das Gerät nach der Erkennung 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"-Hold-Timer auf den Schnittstellen für die ESI in Schritt 1. In diesem Schritt beträgt der "Up"-Hold-Timer der Schnittstelle beispielsweise 300000 ms. Hier haben wir den "Up"-Hold-Timer für die Netzwerkisolationsgruppe auf 100000 ms eingestellt.

    • Konfigurieren Sie das Gerät so, dass entweder lacp-out-of-sync der Status oder link-down der Status auf der Schnittstelle als Kernisolationsaktion 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 Verfolgung des Core-Isolationsservice die Konvergenzzeit für die ESI-Routen verbessert, müssen wir keine Verzögerung in die Overlay-BGP-Routenankündigungen einbeziehen. Daher entfernen wir auf Geräten, auf denen wir die Netzwerkisolationsfunktion auf TOR-orientierten Schnittstellen konfigurieren, die delay-route-advertisements Einstellungen aus Schritt 4 unter Konfigurieren des Underlay (mit EBGP) und des Overlays (mit IBGP).

    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 Netzwerkisolationsgruppenprofilparametern.

    Sie können dieselben oder ähnliche Netzwerkisolationsgruppenprofile auf den anderen Multihoming-Peer-SL-Geräten (SL-4 und SL-5) einrichten, die ae3 für ESI zu TOR-3 und ae5 für 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 Overlay-Routenankündigungsverzögerung 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 unter Konfigurieren des Underlay (mit EBGP) und des Overlays (mit IBGP) beibehalten. Mit der im Netzwerk konfigurierten Netzwerkisolationsfunktion beobachteten wir jedoch bessere Testergebnisse mit einer höheren Einstellung auf den S-ARR-Geräten als die Einstellung in diesem Schritt. Daher empfehlen wir in diesem Fall, auch Folgendes zu ändern:

    Auf S-ARR-1 und S-ARR-2 ab Schritt 4 in Konfigurieren des Underlay (mit EBGP) und des Overlays (mit IBGP):

    Ändern Sie diese Konfiguration in:

Konfigurieren von OSPF und 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 Mandanten-VRF-Instanzen in diesem Beispiel – VRF-1 und VRF-101. Konfigurieren Sie diese Schritte auf allen SL-Geräten.

  1. (Optional) Konfigurieren Sie einen OSPF-Bereich für jedes Mandanten-VRF, jedoch mit allen Schnittstellen auf den SL-Geräten im passiven OSPF-Modus, damit die Geräte Routen ankündigen, aber keine OSPF-Angrenzungen bilden können.
  2. Konfigurieren Sie PIM im passiven Modus auf den SL-Geräten für alle Schnittstellen in jeder der VRF-Routing-Instanzen.
  3. Legen Sie die accept-remote-source PIM-Option fest, damit die SL-Geräte Multicast-Datenverkehr von der SBD IRB-Schnittstelle als Quellschnittstelle akzeptieren können. Beim regulären symmetrischen OISM-Bridge-Domain-Modell kommt jeder Multicast-Datenverkehr, der von externen Quellen kommt, bei den SL-Geräten auf dem SBD an.

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 eine Verbindung mit dem externen PIM-Router über klassische L3-Schnittstellenverbindungen hergestellt. OISM unterstützt je nach Plattform des BL-Geräts zusätzliche Methoden zur Verbindung mit der externen Domain. 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 zwischen den BL-Geräten 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-Schnittstelle.

    BL-1:

    BL-2:

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

    BL-1 und BL-2:

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

    BL-1 und BL-2:

  4. Konfigurieren Sie PIM in den VRF-Instanzen des Mandanten, einschließlich der folgenden Punkte für jedes VRF-Mandanteninstanz in diesem Beispiel:

    • Legen Sie in dieser Umgebung eine statische PIM-RP-Adresse fest, die dem externen PIM-Router und dem RP-Router entspricht (eine für jede logische Einheit und das zugehörige Mandanten-VRF).

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

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

      Wenn PIM auf der SBD IRB-Schnittstelle vorhanden ist, können Sie die BL-Geräte aktivieren accept-remote-source , um Multicast-Datenverkehr von der SBD IRB-Schnittstelle als Quellschnittstelle zu akzeptieren. Diese Option behandelt Situationen, in denen sich die BL-Geräte gegenseitig Quelldatenverkehr auf dem SBD 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 Bidirectional Forwarding Detection (BFD) und die Option stickydr . Die BFD-Einstellungen verbessern die Konvergenzzeit mit Schnittstellenproblemen, um Datenverkehrsverluste zu vermeiden. Diese stickydr Option eliminiert die Verzögerung der Konvergenz des Routers während eines Neustarts.

    Fügen Sie dieselbe Konfiguration auf BL-1 und BL-2 hinzu.

    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 Mandanten-VRF-Instanz, der die externe logische Multicast-L3-Schnittstelle und die SBD-IRB-Schnittstelle umfasst, beide im aktiven OSPF-Modus. In diesem Schritt wird eine OSPF-Routingdomäne mit diesen Schnittstellen als Nachbarn im Mandanten-VRF eingerichtet, um das Routing zwischen ihnen zu unterstützen. Schließen Sie die anderen Schnittstellen des Geräts in den OSPF-Bereich, aber im passiven OSPF-Modus ein, damit sie Routen ankündigen, aber keine OSPF-Angrenzungen bilden können.

    Sie definieren und binden auch die export-direct Exportrichtlinie ein, die Adressen der direkt verbundenen 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 des externen Multicast-PIM-Routers und PIM-RP-Routers

In diesem Beispiel fungiert ein Router der MX-Serie als externer PIM-Domänen-Router und PIM-RP-Gerät. In diesem Verfahren schließen wir die Konfiguration auf diesem Gerät ein, die der BL-Gerätekonfiguration entspricht , unter Konfigurieren der Border Leaf-Geräte für externe Multicast-Konnektivität, PIM-EVPN-Gateway-Rolle und PIM-Optionen. Diese Informationen helfen Ihnen bei der Interpretation der show-Befehlsausgabe, 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 des PIM-Routers und des RP-Routers umfasst:

  • Verbindungen zu BL-1 auf Schnittstelle ae1 und zu BL-2 auf Schnittstelle ae2, mit aktiviertem VLAN-Tagging.

  • Routinginstanzen vom Typ virtual-router (PIM-GW-VR-),n die jedem Mandanten-VRF-n in der OISM-Konfiguration auf den BL-Geräten 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 Punkte 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 zu 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 mit den BL-Geräten verbunden sind (ae1 zu BL-1 und ae2 zu BL-2).
  2. Konfigurieren Sie die Routing-Instanzen des virtuellen Routers, die den VRFs und VLANs des OISM-Mandanten entsprechen, in diesem Beispiel.

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

  3. Konfigurieren Sie in jeder der Routinginstanzen PIM, eine statische IP-Adresse für den 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 Rolle des AR-Replikators 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-Replikatormodus. Dies bedeutet, dass die AR-Replikatorrolle nicht mit der OISM-Grenzblattrolle 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-Replikator-Gerä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, deren Empfänger den Multicast-Stream abonniert haben. AR-Replikatoren verwenden 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 gleichen die Last der AR-Replikator-Anforderungen je nach Leaf-Geräteplattform mit einer von zwei Methoden auf die verfügbaren AR-Replikator-Geräte aus:

  • QFX5000 Reihe von Switches (Modelle, die entweder Junos OS oder Junos OS Evolved laufen) – Diese Geräte weisen ein bestimmtes AR-Replikatorgerät für den Datenverkehr zu, der mit jedem VLAN oder VNI verbunden 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).

  • Switches der QFX10000-Reihe – Diese Geräte führen einen aktiven Lastausgleich zwischen den AR-Replikatoren auf der Grundlage des Datenstroms innerhalb eines VNI durch. Das Gerät legt nicht für jeden VNI einen bestimmten AR-Replikator fest.

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 auf dem Quell-VLAN VLAN-1 für den Datenverkehr zu Empfängern im Mandanten-VRF VRF-1.

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

    3. S-ARR-1 repliziert und leitet den Stream im Quell-VLAN 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 Anwendungsszenario für externe Quellen:

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

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

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

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

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

Weitere Details zu AR-Geräterollen, zur Funktionsweise von AR und zu anderen Anwendungsszenarien neben den in diesem Beispiel finden Sie unter Multicast-Optimierung mit assistierter 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 meldet diese IP-Adresse in EVPN-Typ-3-AR-Tunnel-Routen an das Netzwerk.

      Wir fügen hier auch die Konfigurationsanweisungen für primäre Loopback-Adressen hinzu, damit Sie die einzelnen S-ARR-Geräte 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 mithilfe der sekundären AR-Loopback-Schnittstelle, 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 konfigurieren diese Elemente in früheren Schritten in diesem Beispiel. 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.

    Schließen Sie die replicator-activation-delay Option wie gezeigt ein. Standardmäßig verzögern AR-Leaf-Geräte 10 Sekunden nach dem Empfang einer AR-Replikator-Werbung, bevor sie Datenverkehr an dieses AR-Replikator-Gerät senden. In einer skalierten Umgebung empfehlen wir, die Verzögerung zu verlängern, 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 hochfährt.

    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.

OISM- und AR-Konfiguration und -Betrieb überprüfen

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

  1. Überprüfen Sie die Underlay- und Overlay-Konfigurationen und bestätigen Sie, 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-Mode der Ausgabe dieses Befehls wie folgt

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

    • Die sekundäre Loopback-IP-Adresse, die Sie für die Rolle des AR-Replikators 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 die Rolle "Leaf" oder "RNVE" an, die der primären Loopback-IP-Adresse für diese Geräte in der Spalte RVTEP-IP entspricht.

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

  3. Überprüfen Sie die Verbindungen zwischen SL Gerät und TOR-Gerät. 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 zu TOR-1:

    SL-2 zu TOR-1:

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

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

    BL-1:

    BL-2:

  5. Überprüfen Sie die PIM-Router- und RP-Geräteverbindungen vom externen PIM-Router und RP-Gerät zu den BL-Geräten.
  6. Überprüfen Sie das AR-Leaf-Overlay-Tunnel-Load Balancing auf die verfügbaren AR-Replikatorgeräte.

    Die AR-Leaf-Geräte erkennen die beworbenen AR-Replikatorgeräte und sorgen für einen Lastausgleich zwischen ihnen mit verschiedenen Methoden, die auf der Leaf-Geräteplattform basieren. (Weitere Informationen finden Sie unter AR Leaf Device Load Balancing mit mehreren Replikatoren .)

    In diesem Beispiel ist SL-1 ein QFX5120-Switch, also als AR-Leaf-Gerät gleicht SL-1 die Last aus, indem jedem VLAN oder VNI ein AR-Replikator-Gerä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 Lastausgleich der nächsten Hops zu den verfügbaren AR-Replikatoren anzuzeigen. Auf SL-Geräten, die AR-Replikatoren nach VNI bestimmen, 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 Lastausgleich auf der Grundlage des aktiven Datenverkehrsflusses durchführen.

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

    • 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-Join- und Multicast-Gruppenstatus für einen Multicast-Stream von einer Quelle innerhalb der Fabric hinter TOR-1. TOR-1 ist mehrfach vernetzt mit SL-1 und SL-2 (siehe Abbildung 1). Die 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. Der Datenstrom, den wir hier überprüfen, ist 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 vorgesehenen AR-Replikator weiter. Siehe Abbildung 4. Der AR-Replikator leitet Kopien an die SL-Geräte mit abonnierten Empfängern auf dem Quell-VLAN-1 weiter. Dann leiten die SL-Geräte den Datenverkehr an die Empfänger auf VLAN-1 weiter.

    In diesem Schritt führen Sie die Befehle nur für VRF-1 aus, das ist die Mandanten-VRF, die in diesem Beispiel den internen Multicast-Quelldatenverkehr hostet. Außerdem ist dieser Stream ein IGMPv3-Stream mit SSM-Berichten, sodass nur (S,G)-Multicast-Routen 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 mehrfach auf SL-4 und SL-5 ausgerichtet 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 Joins auf beiden Geräten zusammen (3 auf jedem Gerät) entspricht der Gesamtzahl der Joins im show pim join summary Ausgang (6).

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

      Wenn die show pim join extensive Ausgaben von SL-4 und SL-5 dieselbe Upstream- und Downstream-IRB-Schnittstelle anzeigen, überbrückt das Gerät den Multicast-Stream innerhalb desselben VLANs. Wenn sich die nachgelagerten IRB-Schnittstellen von der vorgelagerten 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 Multihomed TOR-4 weiterzuleiten.

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

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

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

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

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

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

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

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

    Denken Sie daran, dass wir in der SL-Gerätekonfiguration ae5 als Verbindung von SL-4 und SL5 zu TOR-4 zuweisen. Wir setzen ESI 00:00:00:ff:00:04:00:01:00:05 auf diese Links. Die folgende Ausgabe zeigt, dass SL-4 nicht der designierte Spediteur für diese ESI ist.

    SL-5: Überprüfen Sie den vorgesehenen Forwarder 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-Join- und Multicast-Gruppenstatus für einen Multicast-Stream von einer Quelle außerhalb der Fabric in der externen PIM-Domäne. Siehe Abbildung 1. Die 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 zum SBD-VLAN (IN DIESEM FALL VLAN-2101).

    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 an den designierten AR-Replikator oder an einen AR-Replikator basierend auf dem Load-Balancing des Datenverkehrs). Siehe Abbildung 4. Der AR-Replikator leitet Kopien auf dem 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 auf den Mandanten-VLANs.

    In diesem Schritt führen Sie die Befehle nur für VRF-101 aus, das ist das Mandanten-VRF, das in diesem Beispiel externen Multicast-Quelldatenverkehr hostet. Außerdem ist dieser Stream ein IGMPv2-Stream mit ASM-Berichten, sodass nur (*,G) Multicast-Routen angezeigt werden.

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

    • PIM-Join-Status auf BL-1 und BL-2 als Eingangsgeräte für die externe Multicast-Quelle.

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

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

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

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

    SL-1: Empfänger – Multicast-Gruppenmitgliedschaftsstatus für VLANs, die mit VRF-101 (VLAN-401 bis VLAN-404) verknüpft sind:

    SL-2: Empfänger: Multicast-Gruppenmitgliedschaftsstatus für VLANs, die mit VRF-101 (VLAN-401 bis VLAN-404) verknüpft sind:

    SL-1: Empfänger – PIM-Beitrittsstatus 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-Core 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 an, die als AR-Replikatoren fungieren. Routen des Typs 6 werden nur im SBD-VLAN angekündigt.

    Hier sehen wir uns zum Beispiel Typ-6-Routen für interessierte Empfänger hinter TOR-4 an, das für 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 über 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 empfingen Typ-6-Routen von SL-4 und SL-5 auf dem SBD (VLAN-2001 VNI 992001).

    • SL-4 (lo0: 192.168.0.4) und SL-5 (lo0: 192.168.0.5) erhielten 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 verbindet sich mit SL-4 auf ae4 (172.16.7.0/31).

    S-ARR-1 Links zu 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 verbindet sich mit 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 als Remote-Routen von den anderen SL-Geräten, die auch Empfänger für dieselben Gruppen im selben Mandanten-VRF für die interne Quelle auf TOR-1 (Multihomed für SL-1 und SL-2) bedienen.

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

  10. Überprüfen Sie, ob die Peer-Geräte für Multihoming ESs EVPN-Typ-7-Routen verwenden, um Multicast-Join-Status zu synchronisieren.

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

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

    Diese Befehle zeigen:

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

    • SL-5 erhielt von SL-4 Typ-7-Routenankündigungen für Joins, die TOR-4 auf SL-4 hashte

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

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

    Beachten Sie, dass der ESI, den 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 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 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 Typ-7-Routenankündigungen von SL-4 für Joins auf VLAN-3 (VNI 110003) für Multicast Gruppen 233.252.0.121 bis 233.252.0.123 erhalten hat.

    Führen Sie diese Befehle auf SL-4 aus, um Typ-7-Routen auf diesem Gerät anzuzeigen. Übereinstimmung mit dem Präfix 7:192.168.0.5, um die Typ-7-Routen des Multihoming-Peers SL-5 anzuzeigen. Übereinstimmung mit Präfix 7:192.168.0.4, um die lokal generierten Typ-7-Routen anzuzeigen, die SL-4 an SL-5 ankündigt.

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

Zugehörige Dokumentation