Fehlerbehebung bei Multicast Auto-RP auf Nexus 9000 mit NX-OS

Einleitung

In diesem Dokument wird die Funktionsweise von Auto-RP auf dem Cisco Nexus 9000 mit NX-OS sowie die Validierung und Fehlerbehebung für den Multicast-Betrieb beschrieben.

Voraussetzungen

Anforderungen

• Grundkenntnisse von IP-Multicast
• Grundkenntnisse von IGMP und PIM Sparse Mode
• Erfahrung mit Cisco Nexus 9000 und NX-OS CLI
• Verständnis der Konzepte von Unicast-Routing und RPF

Verwendete Komponenten

• Cisco Nexus Switches der Serie 9000
• Cisco NX-OS-Software
• PIM Sparse Mode
• Statischer RP und automatischer RP

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Multicast im Überblick

Multicast ist ein One-to-Many-Kommunikationsmodell, bei dem eine Quelle einen einzelnen Datenverkehrsstrom an mehrere interessierte Empfänger sendet. Anstatt für jedes Ziel eine separate Kopie zu erstellen, repliziert das Netzwerk den Datenverkehr nur dort, wo sich der Weiterleitungspfad verzweigt. Dadurch wird Multicast effizienter als Broadcast- oder wiederholte Unicast-Übertragungen. Bei IPv4 verwendet der Multicast-Datenverkehr Zieladressen aus dem Bereich 224.0.0.0/4.

Der PIM Sparse Mode ist das Multicast-Routing-Modell, das von Cisco Nexus-Switches mit NX-OS unterstützt wird. Er leitet Datenverkehr nur weiter, wenn die Interessen des Empfängers explizit ermittelt wurden. Bei einem Any-Source-Multicast-Design werden Empfänger zunächst in einen Shared Tree zum Rendezvous Point hinzugefügt, und die Quellen werden bei diesem RP registriert. Wenn der Datenverkehr zu fließen beginnt, kann der Last-Hop-Router vom Shared Tree zum kürzesten Pfad zur Quelle wechseln.

Die bei Multicast verwendete Terminologie muss definiert werden, da eine präzise Fehlerbehebung davon abhängt, wie Ereignisse auf Kontrollebene, Routing-Einträge und Weiterleitungsentscheidungen dargestellt werden. Eine klare Terminologie hilft, die Befehlsausgabe korrekt zu interpretieren, zwischen Shared-Tree- und Source-Tree-Verhalten zu unterscheiden und die Rolle jeder Multicast-Komponente im End-to-End-Weiterleitungsprozess zu identifizieren.

Begriff	Definition
Multicast-Gruppenadresse	Eine IPv4-Zieladresse im Bereich 224.0.0.0/4 zur Identifizierung einer Multicast-Gruppe.
Quelladresse	Die Unicast-IP-Adresse des Senders, der Datenverkehr an eine Multicast-Gruppe überträgt.
mroute	Der Multicast-Routing-Eintrag, der definiert, wie Multicast-Datenverkehr für eine Gruppe oder eine Quellgruppen-Kombination behandelt wird.
IIF	Eingehende Schnittstelle. Die Schnittstelle, an der der Multicast-Datenverkehr erwartet wird.
OIF	Ausgangsschnittstelle. Eine Schnittstelle für die Weiterleitung von Multicast-Datenverkehr an Empfänger oder Downstream-Nachbarn.
ÖL	Liste der ausgehenden Schnittstellen Der Satz ausgehender Schnittstellen, die einem Multicast-Routing-Eintrag zugeordnet sind.
RP	Umgekehrte Pfadweiterleitung. Mit dieser Prüfung wird auf Basis der Unicast-Route zur Quelle oder zum RP überprüft, ob Multicast-Datenverkehr an der richtigen Schnittstelle eingegangen ist.
MDT	Multicast Distribution Tree Der logische Tree, der Multicast-Datenverkehr von der Quelle an alle Empfänger überträgt.
RPT	RP Tree, auch Shared Tree genannt. Er verbindet die Empfänger mit dem RP und wird durch (*,G) dargestellt.
SPT	Shortest Path Tree, auch Source Tree genannt. Es verbindet Empfänger direkt mit der Quelle und wird durch (S,G) dargestellt.
FHR	First-Hop-Router Der Multicast-Router ist direkt mit der Quelle verbunden und für die Quellregistrierung beim RP verantwortlich.
LHR	Last-Hop-Router Der Multicast-Router wurde direkt mit den Empfängern verbunden und ist für die Erstellung des Multicast-Zustands zuständig, nachdem er über IGMP die Relevanz für den Empfänger ermittelt hat.
RP	Rendezvous Point Der logische Meeting Point, der im ASM- und PIM Sparse Mode zum Verbinden von Quellen und Empfängern verwendet wird.
ASM	Any-Source-Multicast. Ein Multicast-Modell, bei dem Empfänger einer Gruppe beitreten, ohne zuvor die Quelle anzugeben.

Es ist wichtig, die bekannten reservierten Multicast-Adressen zu kennen, da die Fehlerbehebung bei Multicast davon abhängt, dass schnell ermittelt wird, welches Steuerungsprotokoll eine bestimmte Zielgruppe verwendet und welche Funktion dieser Datenverkehr im Netzwerk hat. Diese Adressen erleichtern die Unterscheidung zwischen normalem Protokollbetrieb und ungewöhnlichem Verhalten und erleichtern die Validierung von IGMP-, PIM- und Auto-RP-Austauschvorgängen. Insbesondere für Auto-RP sind die wichtigsten zu erkennenden Gruppen 224.0.1.39 für RP-Announce und 224.0.1.40 für RP-Discovery, da sie die Informationen enthalten, die es Routern ermöglichen, die dynamischen RP-Zuordnungen zu erlernen.

Multicast-Adresse	Zweck
224.0.0.1	Alle Hosts im lokalen Subnetz
224.0.0.2	Alle Router im lokalen Subnetz
224.0.0.13	Alle PIM-Router
224.0.0.22	IGMPv3-Nachrichten
224.0.1.39	Von Auto-RP verwendete Cisco RP-Announce-Nachrichten
224.0.1.40	Von Auto-RP verwendete Cisco RP-Discovery-Nachrichten

Automatischer RP-Betrieb im PIM Sparse Mode (Workflow auf Steuerungsebene)

Auto-RP ist ein Mechanismus von Cisco, der im Protocol Independent Multicast Sparse Mode verwendet wird, um Rendezvous Point (RP)-Informationen dynamisch zu ermitteln und über die Multicast-Domäne zu verteilen. Durch die Verwendung von Multicast-basierten Kontrollebenenmeldungen zum Anzeigen, Auswählen und Lernen von Zuordnungen zwischen RP und Gruppen ist eine statische RP-Konfiguration nicht mehr erforderlich. Seine Hauptkomponenten sind Kandidaten-RPs, die RP-Services für bestimmte Gruppenbereiche anbieten, und Mapping Agents, die Kandidaten sammeln und den aktiven RP pro Gruppe bestimmen.

Der Prozess beginnt, wenn jeder RP-Kandidat regelmäßig RP-Announce-Nachrichten an 224.0.1.39 sendet, einschließlich der zugehörigen IP-Adresse, Priorität und unterstützten Multicast-Gruppenbereiche. Diese Meldungen werden mithilfe des Auto-RP-Listeners in NX-OS über das Netzwerk geflutet, um sicherzustellen, dass alle Zuordnungsagenten sie erhalten, noch bevor das Netzwerk im Sparse-Mode voll betriebsbereit ist.

Zuordnungs-Agenten überwachen diese Ankündigungen, erstellen eine RP-Datenbank für Kandidaten und führen einen deterministischen Auswahlprozess pro Gruppe durch (normalerweise höchste Priorität, dann höchste IP-Adresse). Sobald der beste RP ausgewählt wurde, generiert der Zuordnungs-Agent RP-Discovery-Nachrichten und sendet sie an 224.0.1.40, um die endgültigen Zuordnungen von RP zu Gruppen an alle Router in der Domäne anzugeben.

Alle PIM-Router erhalten die RP-Discovery-Nachrichten und installieren die Zuordnungen in ihren lokalen RP-Tabellen. Anhand dieser Informationen senden Last-Hop-Router (die mit Empfängern verbunden sind) PIM Join-Nachrichten an den ausgewählten RP, um den Shared Tree (RPT) zu erstellen, während First-Hop-Router (die mit Quellen verbunden sind) Multicast-Verkehr in PIM-Registrierungsnachrichten kapseln, um den RP über aktive Quellen zu informieren.

Wenn der Datenverkehr durch den RP fließt, können Router optional vom Shared Tree (RPT) zu einem Shortest Path Tree (SPT) wechseln. Hierzu wird eine zusätzliche PIM Join/Prune-Signalisierung direkt zur Quelle verwendet. Während dieses Prozesses aktualisiert Auto-RP Zuordnungen kontinuierlich über regelmäßige Kontrollnachrichten. Dadurch wird die Ausfallsicherheit gewährleistet und eine automatische Anpassung an Topologie- oder RP-Änderungen gewährleistet.

Automatischer RP-Betrieb im PIM Sparse Mode (Workflow auf Steuerungsebene)

Auto-RP-Einschränkungen und betriebliche Einschränkungen

• Auto-RP funktioniert nur mit IPv4-Multicast und wird für IPv6 (PIM6) nicht unterstützt. IPv6-Bereitstellungen erfordern daher einen anderen RP-Erkennungsmechanismus.
• Auto-RP kann nicht gleichzeitig mit BSR innerhalb derselben PIM-Domäne verwendet werden, da nur ein RP-Erkennungsmechanismus konfiguriert werden kann, um Konflikte auf der Kontrollebene zu vermeiden.
• Auto-RP-Nachrichten werden auf NX-OS-Geräten standardmäßig nicht verarbeitet oder weitergeleitet. Aus diesem Grund ist für den ordnungsgemäßen Betrieb eine explizite Konfiguration erforderlich.
• Die Weitergabe von Auto-RP-Kontrollmeldungen hängt von der Aktivierung des Auto-RP-Listeners ab. Andernfalls werden nicht alle Router von den RP-Zuordnungsinformationen erreicht.
• Das RP-Ankündigungsintervall umfasst einen Mindestwert von 15 Sekunden. Dieser Wert begrenzt, wie schnell RP-Updates angekündigt werden können, und wirkt sich auf die Konvergenzzeit aus.
• Die automatische RP-Nachrichtenfilterung über Routenzuordnungen kann den Betrieb beeinträchtigen, da falsche Richtlinien Zuordnungen zwischen RP und Gruppen blockieren können.
• Auto-RP ist in VRF-Kontexten standardmäßig deaktiviert und muss daher in Bereitstellungen mit mehreren VRFs explizit aktiviert werden.

• ECMP-basierte Multipath-Weiterleitung ist standardmäßig aktiviert, sodass für Multicast-Datenverkehr Pfade mit gleichen Kosten für den Lastenausgleich verwendet werden können.

• Die PIM-Nachbarauthentifizierung mit IPsec AH-MD5 wird unterstützt.

• PIM-Snooping ist nicht verfügbar.

Vorteile der Verwendung von Auto-RP

Auto-RP ermöglicht eine dynamische RP-Erkennung und eine zentralisierte RP-Mapping-Verteilung für PIM Sparse Mode-Multicast-Umgebungen. Dadurch ist keine statische RP-Konfiguration auf jedem Multicast-Router erforderlich, der Betrieb wird vereinfacht, und die Multicast-Skalierbarkeit wird verbessert. Auto-RP unterstützt auch mehrere RP-Kandidaten und ermöglicht so automatische RP-Ausfallsicherung und Redundanz. Dieser Mechanismus trägt dazu bei, ein konsistentes Multicast-Weiterleitungsverhalten zu gewährleisten, vereinfacht die Netzwerkerweiterung und ermöglicht es Multicast-Routern, RP-Informationen automatisch in der gesamten Domäne abzurufen.

Auto-RP-Zuordnungs-Agent und RP-Auswahlprozess

Der Auswahlprozess in Auto-RP ist deterministisch und basiert hauptsächlich auf IP-Adressen. Im Gegensatz zu anderen Protokollen (z. B. PIMv2 BSR) verwendet Auto-RP keinen konfigurierbaren Wert für die "Priorität". Stattdessen setzt sie bei der Konfliktlösung auf die IP-Adresshierarchie.

Auswahl des Zuordnungsagenten (MA)

In Auto-RP können aus Redundanzgründen mehrere Zuordnungs-Agents im gleichen Netzwerk gleichzeitig vorhanden sein. Es gibt keinen formellen Wahlprozess, bei dem sich der eine abschaltet und der andere; alle sind technisch aktiv. Die Switches im Netzwerk müssen jedoch entscheiden, welchen Informationen sie vertrauen.

• Auswahlkriterium: Höchste IP-Adresse
• Der Prozess:
  1. Alle Zuordnungs-Agents senden ihre RP-Discovery-Nachrichten an die Multicast-Gruppe 224.0.1.40.
  2. Client-Switches erhalten diese Meldungen.
  3. Wenn ein Switch Discovery-Nachrichten von zwei verschiedenen Zuordnungs-Agents empfängt, die in Konflikt stehende Informationen enthalten, akzeptiert der Switch die Informationen vom Zuordnungs-Agent mit der höchsten Quell-IP-Adresse.
  4. Nexus-Verhalten: Ein Zuordnungs-Agent mit einer niedrigeren IP-Adresse wechselt in der Regel in den Status "passiv" oder "unterdrückt", wenn ein anderer MA mit einer höheren IP-Adresse erkannt wird, um doppelten Kontrollverkehr im Netzwerk zu verhindern.

Rendezvous Point (RP)-Auswahl

Dieser Prozess wird vom Zuordnungs-Agent nach dem Abhören aller RP-Announce-Nachrichten (gesendet an Gruppe 224.0.1.39) der Kandidaten durchgeführt.

Wenn der Zuordnungs-Agent mehrere Kandidaten für dieselbe Multicast-Gruppe empfängt, wendet er diese Regeln in der folgenden Reihenfolge an:

Regel A: Längste Präfixübereinstimmung (spezifischste Maske)

Wenn Kandidaten überlappende Bereiche bekannt geben, weist der MA die Gruppe dem RP zu, der den kleinsten Bereich (die längste Subnetzmaske) angekündigt hat.

• Beispiel:
  • Kandidat A kündigt 224.0.0.0/4 (the für den gesamten Multicast-Bereich an).
  • Kandidat B kündigt 224.10.20.0/24 an.
  • Ergebnis: Für die Gruppe 224.10.20.5 gewinnt Kandidat B, weil sein Bereich spezifischer ist.

Regel B: Höchste IP-Adresse (Tie-Breaker)

Wenn zwei oder mehr Kandidaten genau denselben Gruppenbereich ankündigen, muss der Zuordnungs-Agent nur einen auswählen.

• Kriterium: Der Kandidat mit der höchsten IP-Adresse gewinnt.
• Beispiel:
  • Kandidat 1: 10.2.0.1 für Bereich 224.10.20.0/24.
  • Kandidat 2: 10.2.0.4 für Bereich 224.10.20.0/24.
  • Ergebnis: Der Zuordnungs-Agent wählt 10.2.0.4 als offiziellen RP für diesen Bereich aus, und dies wird in den Erkennungsmeldungen angekündigt.

Layer-2-Überlegungen: Multicast-MAC und Snooping

Obwohl der Schwerpunkt dieses Artikels auf Layer-3-Multicast mit PIM liegt, spielt das Layer-2-Verhalten eine entscheidende Rolle bei der Fehlerbehebung und dem allgemeinen Design. Auf Layer 2 kommunizieren Geräte mithilfe von MAC-Adressen, d. h. 48-Bit-IDs, die Netzwerkschnittstellen zugewiesen sind. Multicast-Datenverkehr erfordert ein bestimmtes MAC-Adressierungsschema, um ihn vom Unicast- und Broadcast-Datenverkehr zu unterscheiden.

IPv4-Multicast-MAC-Adressen werden von Layer-3-Multicast-Gruppenadressen abgeleitet, wobei das reservierte Präfix "01:00:5E" verwendet wird. Allerdings werden nur 23 Bit der IP-Multicast-Adresse der MAC-Adresse zugeordnet, wodurch eine Überlappung von 32:1 entsteht. Das bedeutet, dass bis zu 32 verschiedene Multicast-IP-Gruppen derselben MAC-Adresse zugeordnet werden können. So können Hosts, die eine bestimmte Multicast-MAC-Adresse überwachen, Datenverkehr für mehrere Multicast-Gruppen empfangen, selbst wenn diese nur an einer Multicast-Adresse interessiert sind. Beispiel: 224.1.1.1, 225.1.1.1, 226.1.1.1, 227.1.1.1, 228.1.1.1 und mehr.

Diese Überschneidung hat direkte Auswirkungen auf die Netzwerkeffizienz und die Fehlerbehebung. Da Entscheidungen zur Layer-2-Weiterleitung, die ausschließlich auf MAC-Adressen basieren, nicht zwischen überlappenden Multicast-Gruppen unterscheiden können, können Switches unnötigen Datenverkehr an Hosts weiterleiten. Diese Hosts müssen dann durch eine Filterung auf höherer Ebene (IP/IGMP) unerwünschte Pakete verwerfen, was CPU- und Pufferressourcen beansprucht.

In Cisco Nexus NX-OS wird diese Einschränkung durch das IGMP-Snooping abgeschwächt. IGMP-Snooping führt standardmäßig IP-basierte Suchvorgänge statt einer reinen MAC-Weiterleitung durch, sodass die Switches präzisere Weiterleitungsentscheidungen treffen können, selbst wenn mehrere Multicast-Gruppen dieselbe MAC-Adresse verwenden. Dadurch wird die Layer-2-Effizienz deutlich verbessert, und es wird weniger unnötiger Datenverkehr übertragen.

Automatische RP-Konfiguration

Dieser Abschnitt enthält eine detaillierte Erläuterung der Auto-RP-Konfiguration unter Verwendung einer einfachen Implementierung als Referenz. In dieser Konfiguration wird eine Multicast-Quelle über vPC mit zwei Nexus-Switches verbunden, um Datenverkehr an einen Empfänger zu übertragen. Bei diesem Design fungieren N9K-1 und N9K-2 gleichzeitig als RP-Kandidaten und Zuordnungsagenten.

Multicast-Datenverkehrsfluss

First-Hop-Router

Dieselbe Konfiguration hat FHR-2.

FHR-1# show running-config pim
feature pim
ip pim auto-rp forward listen

interface Vlan1
  ip pim sparse-mode

interface Ethernet1/1
  ip pim sparse-mode

interface Ethernet1/3
  ip pim sparse-mode

Command	Zweck/Beschreibung
Feature-PIM	Aktiviert den PIM-Prozess (Protocol Independent Multicast) auf dem Switch.
ip pim auto-rp forward listen	Aktiviert den automatischen RP-Listener. Auf diese Weise kann der Switch Auto-RP-Kontrollnachrichten (224.0.1.39 und 224.0.1.40) empfangen und weiterleiten, auch wenn er die Identität des RP noch nicht kennt.
ip pim sparse-mode	Aktiviert den PIM Sparse Mode auf einer bestimmten Schnittstelle. In diesem Modus wird Multicast-Datenverkehr nur an Segmente weitergeleitet, die ihn explizit über PIM Join-Nachrichten angefordert haben.

Zuordnungsagent und RP-Kandidat

N9K-1# show running-config pim
feature pim

ip pim auto-rp rp-candidate loopback0 group-list 224.10.20.0/24 interval 15
ip pim auto-rp mapping-agent loopback1

interface loopback0
  ip pim sparse-mode

interface loopback1
  ip pim sparse-mode

interface Ethernet1/3
  ip pim sparse-mode

interface Ethernet1/4
  ip pim sparse-mode

interface Ethernet1/49
  ip pim sparse-mode

Diese Tabelle enthält eine detaillierte technische Aufschlüsselung der PIM-Konfiguration für N9K-1. Diese Konfiguration wird auf N9K-2 repliziert. Beide Switches werden mit einer dualen Rolle konfiguriert und fungieren sowohl als RP-Kandidat als auch als Zuordnungs-Agent für die Multicast-Domäne.

Command	Detaillierte technische Erläuterung
Feature-PIM	Feature-Aktivierung: Aktiviert global die Protocol Independent Multicast (PIM)-Engine auf dem Nexus-Switch.
ip pim auto-rp rp-candidate loopback0 group-list 224.10.20.0/24 interval 15	RP-Kandidatenrolle: Konfiguriert diesen Wechsel auf "Freiwillig" als Rendezvous Point (RP). Quelle: Verwendet die IP-Adresse von loopback0 Geltungsbereich: Es bietet die Verarbeitung des Multicast-Gruppenbereichs 224.10.20.0/24. Intervall: Sendet alle 15 Sekunden "Announce"-Nachrichten an den Zuordnungs-Agent. Der Wert für die Haltezeit ist dreimal so hoch.
ip pim auto-rp mapping-agent loopback1	Agent-Rolle zuordnen: Konfiguriert den Switch als "Administrator" des Auto-RP-Prozesses. Funktion: Er hört alle RP-Kandidaten ab, löst Konflikte (unter Verwendung der höchsten IP-Adresse als Verbindungsunterbrecher) und sendet die "Discovery"-Nachrichten an den Rest des Netzwerks, um ihn darüber zu informieren, wer der aktive RP ist.
interface loopback0 / loopback1	Logische Schnittstellen: PIM ist auf diesen Schnittstellen aktiviert, da sie als Quell-IPs für die RP-Kandidat- und Zuordnungs-Agent-Rollen dienen. Sie müssen über die Unicast-Routing-Tabelle aller PIM-Router erreichbar sein.
interface Ethernet1/3, 1/4, 1/49	Physische Weiterleitung: Aktiviert den PIM Sparse Mode auf physischen Ports. Auf diese Weise kann der Switch Nachbarumgebungen zu PIM mit anderen Routern aufbauen und Multicast-Datenverkehr über diese speziellen Verbindungen weiterleiten.
ip pim sparse-mode	Betriebsmodus: Wird auf alle oben genannten Schnittstellen angewendet. Dadurch wird sichergestellt, dass Multicast-Datenverkehr nur an Empfänger gesendet wird, die dies explizit über PIM Join-Nachrichten angefordert haben, wodurch unnötiges Netzwerkfluten verhindert wird.

Routing-Konfiguration für IPv4-Erreichbarkeit

• In dieser Topologie werden alle Nexus Switches in einem einzigen OSPF-Prozess mit dem Namen UNDERLAY zusammengefasst, der innerhalb von Bereich 0 (0.0.0.0) betrieben wird, um eine umfassende Routing-Erreichbarkeit im gesamten Netzwerk zu ermöglichen.
• Auf dem LHR ist OSPF in VLAN 2, das als Gateway für den Multicast-Empfänger dient, sowie an den Uplink-Schnittstellen Ethernet1/49 und Ethernet1/50 aktiviert, die beide als Point-to-Point-Verbindungen konfiguriert sind. Dadurch wird eine effiziente Adjacency-Bildung zu den Upstream-N9K-Switches ohne DR/BDR-Auswahl sichergestellt.
• Die FHR-Schicht (FHR-1 und FHR-2) weist dieselbe Konfiguration auf. OSPF wird im VLAN 1, das als Gateway für die Multicast-Quelle fungiert, und auf den gerouteten Uplinks (Ethernet1/1 und Ethernet1/3) zum Aggregations-Layer aktiviert. Diese Verbindungen werden auch als Punkt-zu-Punkt-Verbindungen konfiguriert, um das Konvergenz- und Adjacency-Verhalten zu optimieren.
• Ebenso verfügen N9K-1 und N9K-2 über identische OSPF-Konfigurationen, mit der Hinzufügung von Loopback0- und Loopback1-Advertisement-Nachrichten in OSPF.
  • Diese Loopbacks sind kritisch, da sie später für PIM RP Candidate- und Mapping Agent-Rollen verwendet werden.

PIM Neighbors und OSPF Area 0

N9K-1 - OSPF-Konfiguration

N9K-1(config)# show running-config ospf
feature ospf

router ospf UNDERLAY
  router-id 10.2.0.1

interface loopback0
  ip router ospf UNDERLAY area 0.0.0.0

interface loopback1
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/3
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/4
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/49
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

FHR-1 - OSPF-Konfiguration

FHR-1(config)# show running-config ospf
feature ospf

router ospf UNDERLAY

interface Vlan1
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/1
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/3
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

LHR - OSPF-Konfiguration

LHR(config)# show running-config ospf
feature ospf

router ospf UNDERLAY

interface Vlan2
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/49
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/50
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

Überprüfung des Betriebsstatus und Fehlerbehebung bei Auto-RP

Schritt 1: Überprüfung der grundlegenden IP-Erreichbarkeit (Unicast Underlay-Validierung)

Vor der Analyse des Multicast-Verhaltens muss unbedingt überprüft werden, ob das Unicast-Underlay (OSPF Area 0) vollständig betriebsbereit ist. Multicast-Kontrollebenenprotokolle wie PIM und Auto-RP sind für eine korrekte Funktion von der Unicast-Verfügbarkeit abhängig.

Im ersten Validierungsschritt wird überprüft, ob die Quelle und der Empfänger (oder deren nächstgelegene Layer-3-Gateways): FHR und LHR) erreichbar sind.

Aus der Topologie:

• FHR-1/FHR-2 → In der Nähe der Multicast-Quelle (10.150.1.37 - VLAN 1)

• LHR → Nah am Multicast-Empfänger (192.168.2.37 - VLAN 2)

Validierungsansatz

1. Führen Sie ICMP-Erreichbarkeitstests durch zwischen:

• HR ↔ LHR

• FHR ↔ Receiver-Subnetz (VLAN 2-Gateway)

• LHR ↔ Quell-Subnetz (VLAN 1-Gateway)

2. Überprüfen Sie die Verfügbarkeit von Quelle und Empfänger in der Routing-Tabelle. Bei vPC-Bereitstellungen müssen Sie die Konsistenz für beide Nexus-Peers sicherstellen. Beachten Sie, dass der Empfänger über einen ECMP-Pfad verfügt, während die Quelle über Layer 2 erreichbar ist.

FHR-1 - Route-to-Source

FHR-1# show ip route 10.150.1.37

10.150.1.37/32, ubest/mbest: 1/0, attached
    *via 10.150.1.37, Vlan1, [250/0], 06:57:19, am

FHR-1 — Route to Receiver

FHR-1# show ip route 192.168.2.37

192.168.2.0/24, ubest/mbest: 2/0
    *via 10.4.0.6, Eth1/3, [110/45], 04:11:08, ospf-UNDERLAY, intra
    *via 10.4.0.10, Eth1/1, [110/45], 04:11:08, ospf-UNDERLAY, intra

FHR-2 - Route-to-Source

FHR-2# show ip route 10.150.1.37

10.150.1.37/32, ubest/mbest: 1/0, attached
    *via 10.150.1.37, Vlan1, [250/0], 07:03:45, am

FHR-2 — Route to Receiver

FHR-2# show ip route 192.168.2.37

192.168.2.0/24, ubest/mbest: 2/0
    *via 10.4.0.13, Eth1/3, [110/45], 04:16:16, ospf-UNDERLAY, intra
    *via 10.4.0.18, Eth1/4, [110/45], 04:16:16, ospf-UNDERLAY, intra

LHR - Route-to-Source

LHR(config)# show ip route 10.150.1.37

10.150.1.0/24, ubest/mbest: 2/0
    *via 10.4.0.22, Eth1/49, [110/45], 04:14:52, ospf-UNDERLAY, intra
    *via 10.4.0.26, Eth1/50, [110/45], 04:14:52, ospf-UNDERLAY, intra

LHR - Route to Receiver

LHR(config)# show ip route 192.168.2.37

192.168.2.37/32, ubest/mbest: 1/0, attached
    *via 192.168.2.37, Vlan2, [250/0], 06:47:21, am

Wichtige Überlegungen

• Der Ausfall dieses Tests deutet auf ein Underlay-Problem hin.

• Multicast kann ohne Unicast-Erreichbarkeit nicht ordnungsgemäß funktionieren, da:

  • PIM-Nachbarn vertrauen auf Unicast-Routing

  • RP-Adressen (Loopback) müssen erreichbar sein

  • RPF-Prüfungen (Reverse Path Forwarding) hängen von der Routing-Tabelle ab.

• Ein erfolgreicher Ping-Test garantiert aus folgenden Gründen nicht, dass Multicast funktionieren kann:

  • ICMP kann zugelassen werden, während Multicast blockiert wird.

  • PIM oder Auto-RP kann weiterhin falsch konfiguriert werden.

Phase 2: Identifizieren von Multicast-Rollen und End-to-End-Topologie

Der nächste Schritt besteht darin, die Rolle der einzelnen Geräte, die an der Weiterleitung von Multicast-Verkehr beteiligt sind, eindeutig zu identifizieren. Dies ist ein obligatorischer Schritt, da die Multicast-Fehlerbehebung vollständig vom Verständnis des Datenverkehrsflusses und des erwarteten Verhaltens in der Topologie abhängt.

Diese Elemente müssen mindestens gekennzeichnet sein:

• Multicast-Quelle (S): 10.150.1.37 (VLAN 1)

• Multicast-Gruppe (G): 224.10.20.10

• Empfänger: 192.168.2.37 (VLAN 2)

• First Hop Router (FHR): FHR-1/FHR-2 (quellennah)

• Last Hop Router (LHR): LHR (dem Empfänger am nächsten)

Darüber hinaus müssen die Rollen auf Kontrollebene identifiziert werden:

• RP-Kandidaten: N9K-1 und N9K-2 (Loopback0)

• Agenten zuordnen: N9K-1 und N9K-2 (Loopback1)

Erkennung von Topologie und Kontrollebene

Zur Fehlerbehebung bei Multicast-Problemen ist eine detaillierte Netzwerktopologie erforderlich. Dazu gehören:

• Physische Verbindungen (zwischen Geräten verwendete Schnittstellen)

• Logische Topologie (VLANs, geroutete Verbindungen, vPC-Beziehungen)

• Verwendetes Routing-Protokoll (OSPF-Bereich 0 in diesem Design)

• Routing-Domänengrenzen (Einzel-IGP und gemischte Protokolle wie OSPF, EIGRP oder BGP)

• Loopback-Schnittstellen für RP- und Zuordnungs-Agent-Rollen

• PIM-fähige Schnittstellen und Nachbar-Beziehungen

Was genau verstanden werden muss

• Der genaue Pfad von Quelle → FHR → RP → LHR → Receiver

• Welche Geräte sind verantwortlich für:

  • PIM-Register senden (FHR)

  • Gebäude (*,G) oder (S,G) Bäume (LHR)

  • Anzeigen von RP-Informationen (Zuordnungsagent)

• Routing (OSPF) stellt die Erreichbarkeit folgender Elemente sicher:

  • Quell-Subnetz

  • Empfänger-Subnetz

  • RP-Loopback-Adressen

  • Zuordnung von Agent-Loopback-Adressen

Schritt 3: Validierung der Auto-RP-Konfiguration auf Basis der Geräterolle

Der nächste Schritt besteht darin, zu überprüfen, ob Auto-RP auf jedem Gerät entsprechend seiner Rolle in der Multicast-Topologie richtig konfiguriert ist. Dazu gehört die Bestätigung, dass:

• RP-Kandidaten (N9K-1 / N9K-2) sind ordnungsgemäß konfiguriert, um ihr Loopback0 als RP für den Multicast-Gruppenbereich anzukündigen.

• Zuordnungs-Agents (N9K-1/N9K-2) sind so konfiguriert, dass sie RP-Announce-Nachrichten sammeln und RP-Discovery-Nachrichten mithilfe von Loopback 1 generieren.

• Bei FHR und LHR ist der PIM Sparse Mode auf allen relevanten Schnittstellen aktiviert, um an Auto-RP teilzunehmen und RP-Zuordnungen zu empfangen.

Es muss unbedingt sichergestellt werden, dass alle erforderlichen Schnittstellen (einschließlich Loopbacks und gerouteten Verbindungen) für den PIM Sparse-Mode aktiviert sind und dass keine Konfigurationen fehlen, die den Austausch von RP-Announce- (224.0.1.39) und RP-Discovery-Nachrichten (224.0.1.40) verhindern würden.

Schritt 4: Validierung des Betriebs aller RP-Kandidaten und aller Zuordnungsagenten

Schritt 4.1 Überprüfen der PIM Neighbor-Adjacencies

Im ersten Validierungsschritt wird überprüft, ob alle erwarteten PIM-Nachbarn in der Multicast-Topologie korrekt eingerichtet wurden.

N9K-1 - PIM-Nachbarn überprüfen

N9K-1# show ip pim neighbor

PIM Neighbor Status for VRF "default"
Neighbor        Interface            Uptime    Expires   DR       Bidir-  BFD    ECMP Redirect
                                                         Priority Capable State     Capable
10.4.0.5        Ethernet1/3          23:19:45  00:01:20  1        yes     n/a     no
10.4.0.14       Ethernet1/4          23:19:45  00:01:38  1        yes     n/a     no
10.4.0.21       Ethernet1/49         23:19:45  00:01:38  1        yes     n/a     no

N9K-2 - PIM-Nachbarn überprüfen

N9K-2# show ip pim neighbor

PIM Neighbor Status for VRF "default"
Neighbor        Interface            Uptime    Expires   DR       Bidir-  BFD    ECMP Redirect
                                                         Priority Capable State     Capable
10.4.0.9        Ethernet1/3          23:21:18  00:01:29  1        yes     n/a     no
10.4.0.17       Ethernet1/4          23:21:18  00:01:23  1        yes     n/a     no
10.4.0.25       Ethernet1/49         23:21:18  00:01:44  1        yes     n/a     no

Validierungspunkte

• Überprüfen Sie, ob alle erwarteten Nachbarn auf jeder gerouteten Schnittstelle angezeigt werden.
• Stellen Sie sicher, dass die Betriebszeit der Nachbarn stabil ist und kontinuierlich zunimmt.
• Überprüfen Sie, ob der Zeitgeber für abgelaufene Nachrichten regelmäßig aktualisiert wird.
• Stellen Sie sicher, dass keine unerwarteten Adjacency-Flaps auftreten.
• Überprüfen Sie die Auswahl des richtigen designierten Routers (DR).
• Überprüfen Sie, ob die Multicast-Schnittstellen erfolgreich PIM-Adjacencies bilden.

In dieser Topologie gilt Folgendes:

• N9K-1 richtet drei PIM-Nachbarn ein.
• N9K-2 stellt außerdem drei PIM-Nachbarn her.
• Alle Adjacencies bleiben länger als 23 Stunden stabil, was auf einen stabilen Multicast-Betrieb auf Kontrollebene hindeutet.

---

Schritt 4.2 Überprüfen von PIM-fähigen Schnittstellen

Im nächsten Schritt wird überprüft, ob alle am automatischen RP teilnehmenden Schnittstellen für PIM aktiviert sind.

Diese Validierung ist besonders wichtig für:

• RP-Candidate-Loopbacks
• Zuordnung von Agent-Loopbacks

N9K-1 - Überprüfung der PIM-Schnittstellen

N9K-1# show ip pim interface brief

PIM Interface Status for VRF "default"
Interface            IP Address      PIM DR Address  Neighbor  Border
                                                     Count     Interface
Ethernet1/3          10.4.0.6        10.4.0.6        1         no
Ethernet1/4          10.4.0.13       10.4.0.14       1         no
Ethernet1/49         10.4.0.22       10.4.0.22       1         no
loopback0            10.2.0.1        10.2.0.1        0         no
loopback1            10.2.1.5        10.2.1.5        0         no

N9K-2 - Überprüfung der PIM-Schnittstellen

N9K-2# show ip pim interface brief

PIM Interface Status for VRF "default"
Interface            IP Address      PIM DR Address  Neighbor  Border
                                                     Count     Interface
Ethernet1/3          10.4.0.10       10.4.0.10       1         no
Ethernet1/4          10.4.0.18       10.4.0.18       1         no
Ethernet1/49         10.4.0.26       10.4.0.26       1         no
loopback0            10.2.0.4        10.2.0.4        0         no
loopback1            10.2.1.4        10.2.1.4        0         no

Prüfpunkte:

• Überprüfen Sie, ob alle gerouteten Multicast-Schnittstellen in der Ausgabe angezeigt werden.
• Stellen Sie sicher, dass RP-Candidate-Loopbacks PIM-aktiviert sind.
• Überprüfen Sie, ob die Zuordnung von Agent-Loopbacks PIM-aktiviert ist.
• Überprüfen Sie, ob die Nachbar-Zählung an den Transit-Schnittstellen korrekt ist.
• Überprüfen Sie, ob für Loopback-Schnittstellen die Nachbaranzahl = 0 richtig angezeigt wird.

Loopback-Rollenzuweisung:

"Slot0:"	Funktion	Loopback
N9K-1	RP-Kandidat	10.2.0.1
N9K-1	Zuordnungs-Agent	10.2.1.5
N9K-2	RP-Kandidat	10.2.0.4
N9K-2	Zuordnungs-Agent	10.2.1.4

Die Loopbacks werden korrekt als aktive PIM-Schnittstellen angezeigt, obwohl sie keine PIM-Nachbarn bilden. Dieses Verhalten wird erwartet, da Loopback-Schnittstellen Multicast-Adjacencies nicht direkt erstellen.

Das Vorhandensein dieser Loopbacks bestätigt Folgendes:

• PIM kann Meldungen zur automatischen RP-Steuerung korrekt ausgeben.
• RP-Werbemaßnahmen können erfolgreich gestartet werden.
• Die Zuordnungs-Agent-Funktion kann ordnungsgemäß ausgeführt werden.

---

Schritt 4.3 Analyse show ip pim rp

Dieser Befehl validiert:

• RP-Erkennung
• Auto-RP-Werbung
• Zuordnen - Agent-Vorgang
• Zuordnungen von Gruppen zu RP

N9K-1 - RP-Informationen

N9K-1# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5*, next Discovery message in: 00:00:39
BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

RP: 10.2.0.1*, (0),
 uptime: 22:18:44   priority: 255,
 RP-source: 10.2.0.1 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:00:37 (A)

RP: 10.2.0.4, (0),
 uptime: 23:00:32   priority: 255,
 RP-source: 10.2.0.4 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:00:44 (A)

Detaillierte Erläuterung

BSR deaktiviert

BSR disabled

Dies bestätigt Folgendes:

• Bootstrap Router (BSR) wird nicht verwendet.
• Die Multicast-Domäne basiert ausschließlich auf Auto-RP.

Dieses Verhalten wird in dieser Topologie erwartet.

Auto-RP RPA: 10.2.1.5*

Auto-RP RPA: 10.2.1.5*

• 10.2.1.5 entspricht dem Loopback 1 auf N9K-1.
• Das Sternchen * zeigt an, dass der lokale Switch selbst der aktive Zuordnungs-Agent ist.

Das bedeutet:

• N9K-1 generiert RP-Discovery-Nachrichten.
• N9K-1 sammelt RP-Ankündigungen von RP-Kandidaten.
• N9K-1 verteilt RP-Zuordnungsinformationen an die Multicast-Domäne.

Nächste Erkennungsmeldung in

next Discovery message in: 00:00:39

• Überprüfen Sie, ob der Timer ständig aktualisiert wird.
• Vergewissern Sie sich, dass die Erkennungsmeldungen regelmäßig gesendet werden.

Wenn dieser Timer nicht mehr reagiert oder unerwartet abläuft, können Auto-RP-Meldungen nicht richtig weitergegeben werden.

Richtlinienfelder

BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

• Es werden keine Filterrichtlinien angewendet.
• Alle RP-Ankündigungen und Discovery-Werbeanzeigen werden akzeptiert.

Erster RP-Eintrag

RP: 10.2.0.1*, (0),

• RP address = 10,2.0,1
• Das Sternchen (*) zeigt an, dass dieser RP lokal auf N9K-1 basiert.
• 10.2.0.1 entspricht loopback0 auf N9K-1.

Dadurch wird bestätigt, dass N9K-1 als RP-Kandidat konfiguriert ist.

Verfügbarkeit und Priorität

uptime: 22:18:44   priority: 255,

• Stabile Betriebszeit zeigt stabilen RP-Werbevorgang an.
• Die Priorität 255 ist standardmäßig die höchste Priorität.

RP-Quelle

RP-source: 10.2.0.1 (A),

• Die RP-Werbung stammt direkt vom RP selbst.
• (A) gibt die Auto-RP-bezogenen Informationen an.

Gruppenbereich

224.10.20.0/24

• Überprüfen Sie, ob der richtige Multicast-Bereich angekündigt wurde.
• Überprüfen Sie, ob der Gruppenbereich mit der Konfiguration übereinstimmt.

Zweiter RP-Eintrag

RP: 10.2.0.4, (0),

• Ein weiterer RP ist in der Topologie vorhanden.
• 10.2.0.4 entspricht Loopback0 auf N9K-2.
• Es wird kein * angezeigt, da dieser RP von N9K-1 entfernt ist.

N9K-2 - RP-Informationen

N9K-2# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5, uptime: 22:19:10, expires: 00:02:28

RP: 10.2.0.4*, (0),
 uptime: 23:14:14   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:02:28 (A)

Wichtigste Unterschiede auf N9K-2

Auto-RP RPA: 10.2.1.5

• Es wird kein * angezeigt, da N9K-2 nicht der Zuordnungs-Agent ist.
• N9K-2 erhält Informationen zum Zuordnungsagenten remote von N9K-1.

Wichtiger RP-Unterschied

RP-source: 10.2.1.5 (A),

• N9K-2 empfängt RP-Informationen vom Zuordnungs-Agent.
• Der Zuordnungsagent lautet 10.2.1.5.

Dies bestätigt Folgendes:

• Meldungen zur automatischen RP-Erkennung funktionieren ordnungsgemäß.
• Die Zuordnungsagentenankündigungen werden erfolgreich über die Multicast-Domäne verteilt.

Schritt 4.4 Validierung des automatischen RP-Auswahlprozesses und der RP-Auswahl

Auto-RP verwendet zwei unterschiedliche Multicast-Funktionen auf Kontrollebene:

• RP-Kandidat
• Zuordnungs-Agent

Die Interaktion dieser Funktionen ist bei der Validierung des Multicast-Betriebs in einer PIM Sparse Mode-Umgebung von entscheidender Bedeutung.

In dieser Topologie gilt Folgendes:

• N9K-1 und N9K-2 fungieren als RP-Kandidaten.
• N9K-1 fungiert als aktiver Zuordnungsagent.

RP-Kandidatenbetrieb

Ein RP-Kandidat gibt sich selbst als gültigen Rendezvous Point für einen oder mehrere Multicast-Gruppenbereiche an.

Jeder RP-Kandidat sendet regelmäßig Auto-RP Announce-Nachrichten an:

• 224.0.1.39 — Auto-RP Announce-Gruppe
  
  

Diese Ankündigungen beinhalten:

• RP-Adresse
• Gruppenbereich
• Priorität
• Haltefrist

In dieser Topologie gilt Folgendes:

• 10.2.0.1 auf N9K-1 meldet sich selbst als RP an.
• 10.2.0.4 auf N9K-2 meldet sich selbst als RP an.

N9K-1 — Informationen zu RP-Kandidaten

N9K-1# show ip pim rp
<snip>
RP: 10.2.0.1*, (0),
 uptime: 23:11:22 priority: 255,
 RP-source: 10.2.0.1 (A),
 group ranges:
 224.10.20.0/24 , expires: 00:00:38 (A)

RP: 10.2.0.4, (0),
 uptime: 23:53:09 priority: 255,
 RP-source: 10.2.0.4 (A),
 group ranges:
 224.10.20.0/24 , expires: 00:00:43 (A)

N9K-2 — Informationen zu RP-Kandidaten

N9K-2# show ip pim rp
<snip>
RP: 10.2.0.4*, (0),
 uptime: 1d00h priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24 , expires: 00:02:52 (A)

Beide Geräte kündigen den gleichen Multicast-Gruppenbereich an:

• 224.10.20.0/24

Beide RP-Kandidaten verwenden außerdem:

• Schwerpunkt 255

Dies ist wichtig, da der automatische RP bei der RP-Auswahl Priorität und RP-Adresse verwendet.

Aktive Zuordnungs-Agent-Identifizierung

Der Mapping-Agent wählt den aktiven RP für eine Multicast-Gruppe aus und beginnt dabei mit folgender Logik:

1. Höchste RP-Priorität gewinnt.
2. Bei identischen Prioritäten erhält der Kunde die höchste RP-IP-Adresse.

In dieser Topologie gilt Folgendes:

• N9K-1 RP-Adresse = 10.2.0.1
• N9K-2 RP-Adresse = 10.2.0.4
• Beide RP-Kandidaten verwenden die Priorität 255.

Da beide RP-Kandidaten die gleiche Priorität haben:

• Die höchste RP-IP-Adresse wird zur ausgewählten RP.

Daher:

• 10.2.0.4 wird zum aktiven RP für 224.10.20.0/24.

Ausgewählte RP-Validierung

N9K-2 - Ausgewählter RP

N9K-2# show ip pim rp
<snip>
RP: 10.2.0.4*, (0),
 uptime: 23:14:14   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24

Warum N9K-1 immer noch beide RP-Einträge anzeigt

Auf N9K-1:

N9K-1# show ip pim rp
<snip>
RP: 10.2.0.1*, (0),
RP: 10.2.0.4, (0),

Dieses Verhalten wird aus folgenden Gründen erwartet:

• N9K-1 fungiert als Zuordnungsagent.
• Der Zuordnungs-Agent sorgt für die Transparenz aller RP-Kandidaten.
• Die Ausgabe zeigt alle gelernten RP-Ankündigungen an, bevor die endgültige RP-Auswahl verteilt wird.

Schritt 5: Überprüfen der Erreichbarkeit für RP-Kandidaten und Zuordnen von Agenten

Alle Multicast-Router, die zur Domäne im PIM Sparse Mode gehören, müssen eine stabile IP-Erreichbarkeit aufrecht erhalten, um:

• Alle RP-Kandidaten
• Alle Zuordnungs-Agents

Diese Validierung ist kritisch, da der PIM Sparse Mode auf Unicast-Routing für Folgendes beruht:

• Den Rendezvous Point (RP) erreichen
• Erstellen des Shared Multicast Tree (RPT)
• Übermittlung von PIM-Registrierungsnachrichten vom First Hop Router (FHR)
• Auto-RP Discovery-Meldungen empfangen
• Durchführen einer RPF-Validierung (Reverse Path Forwarding)

Wenn die Erreichbarkeit zum RP oder Mapping Agent fehlschlägt:

• Fehler bei der Registrierung der Multicast-Quellen.
• Empfänger können den Multicast-Gruppen nicht beitreten.
• Auto-RP-Meldungen konnten nicht richtig propagiert werden.
• Es können RPF-Fehler auftreten.
• Die Weiterleitung von Multicast-Datenverkehr kann instabil oder unregelmäßig werden.

---

Überprüfen von stabilen Routing-Einträgen

Die Routing-Tabelle muss stabile Unicast-Routen zu folgenden Punkten enthalten:

• Alle RP-Loopbacks
• Alle Mapping Agent-Loopbacks
• Alle Multicast-Übertragungsschnittstellen

Die Routen müssen kontinuierlich installiert bleiben, ohne dass es zu Fluktuationen oder übermäßigen Rekonvergenzen kommt.

Überprüfung:

• Korrigieren der Next-Hop-Auswahl
• Korrekte ausgehende Schnittstelle
• Stabile Verfügbarkeit der Route
• Quelle für erwartetes Routing-Protokoll
• Konsistente Unicast-Erreichbarkeit in der gesamten Multicast-Domäne

---

FHR-1 — Route nach RP-Candidate 10.2.0.1

FHR-1# show ip route 10.2.0.1

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.1/32, ubest/mbest: 1/0
    *via 10.4.0.6, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-1 — Route nach RP-Candidate 10.2.0.4

FHR-1# show ip route 10.2.0.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.4/32, ubest/mbest: 1/0
    *via 10.4.0.10, Eth1/1, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-1 — Route to Mapping Agent 10.2.1.5

FHR-1# show ip route 10.2.1.5

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.5/32, ubest/mbest: 1/0
    *via 10.4.0.6, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-1 — Route to Mapping Agent 10.2.1.4

FHR-1# show ip route 10.2.1.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.4/32, ubest/mbest: 1/0
    *via 10.4.0.10, Eth1/1, [110/5], 1d02h, ospf-UNDERLAY, intra

---

FHR-2 — Route nach RP-Candidate 10.2.0.1

FHR-2# show ip route 10.2.0.1

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.1/32, ubest/mbest: 1/0
    *via 10.4.0.13, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-2 — Route nach RP-Candidate 10.2.0.4

FHR-2# show ip route 10.2.0.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.4/32, ubest/mbest: 1/0
    *via 10.4.0.18, Eth1/4, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-2 — Route to Mapping Agent 10.2.1.5

FHR-2# show ip route 10.2.1.5

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.5/32, ubest/mbest: 1/0
    *via 10.4.0.13, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-2 — Route to Mapping Agent 10.2.1.4

FHR-2# show ip route 10.2.1.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.4/32, ubest/mbest: 1/0
    *via 10.4.0.18, Eth1/4, [110/5], 1d02h, ospf-UNDERLAY, intra

---

LHR — Route nach RP-Candidate 10.2.0.1

LHR# show ip route 10.2.0.1

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.1/32, ubest/mbest: 1/0
    *via 10.4.0.22, Eth1/49, [110/2], 1d02h, ospf-UNDERLAY, intra

LHR — Route nach RP-Candidate 10.2.0.4

LHR# show ip route 10.2.0.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.4/32, ubest/mbest: 1/0
    *via 10.4.0.26, Eth1/50, [110/2], 1d02h, ospf-UNDERLAY, intra

LHR - Route to Mapping Agent 10.2.1.5

LHR# show ip route 10.2.1.5

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.5/32, ubest/mbest: 1/0
    *via 10.4.0.22, Eth1/49, [110/2], 1d02h, ospf-UNDERLAY, intra

LHR — Route to Mapping Agent 10.2.1.4

LHR# show ip route 10.2.1.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.4/32, ubest/mbest: 1/0
    *via 10.4.0.26, Eth1/50, [110/2], 1d02h, ospf-UNDERLAY, intra

---

Überprüfung der Ping-Erreichbarkeit von PIM-Schnittstellen

Überprüfen Sie nach der Validierung der Routing-Tabelle die End-to-End-IP-Erreichbarkeit für:

• Alle RP-Kandidaten
• Alle Zuordnungs-Agents

Der Ping muss von folgenden Quellen stammen:

• PIM-fähige Schnittstellen
• Loopback-Schnittstellen, die am Multicast-Routing teilnehmen

Diese Validierung ist wichtig, da Multicast-Router die folgenden Quelladressen verwenden:

• PIM-Nachbarbetrieb
• RPF-Berechnungen
• PIM-Registerkapselung
• Automatische RP-Kommunikation

Zusammenfassung der Ping-Validierung

"Slot0:"	Quell-IP	Ziel	Funktion	Ergebnis
FHR-1	10.4.0.5	10.2.0.1	RP-Kandidat	Erfolgreich
FHR-1	10.4.0.5	10.2.0.4	RP-Kandidat	Erfolgreich
FHR-1	10.4.0.5	10.2.1.5	Zuordnungs-Agent	Erfolgreich
FHR-1	10.4.0.5	10.2.1.4	Zuordnungs-Agent	Erfolgreich
FHR-2	10.4.0.9	10.2.0.1	RP-Kandidat	Erfolgreich
FHR-2	10.4.0.9	10.2.0.4	RP-Kandidat	Erfolgreich
FHR-2	10.4.0.9	10.2.1.5	Zuordnungs-Agent	Erfolgreich
FHR-2	10.4.0.9	10.2.1.4	Zuordnungs-Agent	Erfolgreich
LHR	10.4.0.5	10.2.0.1	RP-Kandidat	Erfolgreich
LHR	10.4.0.5	10.2.0.4	RP-Kandidat	Erfolgreich
LHR	10.4.0.5	10.2.1.5	Zuordnungs-Agent	Erfolgreich
LHR	10.4.0.5	10.2.1.4	Zuordnungs-Agent	Erfolgreich

Überprüfung des Betriebsstatus und der Multicast-Datenverkehrsweiterleitung in der FHR und LHR

Im nächsten Validierungsschritt wird geprüft, ob:

• Der FHR und der LHR lernten den erwarteten RP erfolgreich kennen.
• Die Multicast-Routing-Tabelle enthält die erwarteten Multicast-Zustände.
• Die Multicast-Kontrollebene funktioniert ordnungsgemäß, bevor die Übertragung des Multicast-Datenverkehrs beginnt.
• Der PIM Sparse Mode erstellt den erwarteten Status des Shared Tree.

---

Schritt 1 Überprüfen der RP-Schulung für FHR und LHR

Überprüfen Sie vor der Überprüfung des Multicast-Weiterleitungsstatus, ob alle Multicast-Router den erwarteten RP für die zu validierende Multicast-Gruppe ermittelt haben.

Dieser Schritt ist aus folgenden Gründen von entscheidender Bedeutung:

• Der FHR muss wissen, wohin PIM-Registrierungsnachrichten gesendet werden sollen.
• Der LHR muss wissen, welcher RP beim Erstellen des Shared Tree verwendet werden soll.
• Die Multicast-Domäne muss eine konsistente RP-Zuordnung beibehalten.

In dieser Topologie gilt Folgendes:

• Der ausgewählte RP ist 10.2.0.4.
• Der Zuordnungsagent lautet 10.2.1.5.
• Der Multicast-Gruppenbereich ist 224.10.20.0/24.

---

FHR-1 — Geprüfter RP

FHR-1# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5, uptime: 1d02h, expires: 00:02:30
BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

RP: 10.2.0.4, (0),
 uptime: 1d03h   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:02:30 (A)

FHR-2 — Geprüfter RP

FHR-2# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5, uptime: 1d02h, expires: 00:02:15
BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

RP: 10.2.0.4, (0),
 uptime: 1d03h   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:02:15 (A)

LHR - Gelernten RP überprüfen

LHR# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5, uptime: 1d02h, expires: 00:02:07
BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

RP: 10.2.0.4, (0),
 uptime: 1d03h   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:02:07 (A)

---

RP-Lernanalyse

Die Ausgänge bestätigen:

• Alle Multicast-Router erhielten konsistent denselben RP.
• Der ausgewählte RP ist 10.2.0.4.
• Die RP-Zuordnung wurde über Auto-RP ermittelt.
• Der Zuordnungsagent, der die RP-Informationen verteilt, lautet 10.2.1.5.
• Die RP-Zuordnung bleibt länger als einen Tag stabil.
• Die Zeitgeber für die Erkennung werden ordnungsgemäß aktualisiert.

Dieses Verhalten wird aus folgenden Gründen erwartet:

• 10.2.0.4 wurde während der Auto-RP-Auswahl als aktiver RP ausgewählt.
• 10.2.1.5 fungiert als Mapping Agent.
• Alle Multicast-Router erhalten erfolgreich Auto-RP Discovery-Meldungen.

Zu diesem Zeitpunkt funktioniert die Multicast-Kontrollebene ordnungsgemäß, und alle Router verfügen über eine konsistente RP-Zuordnung für 224.10.20.0/24

---

Schritt 2 Überprüfen des Multicast-Routing-Zustands vor aktivem Multicast-Datenverkehr

Im nächsten Schritt wird die Multicast-Routing-Tabelle validiert, bevor die Übertragung des Multicast-Datenverkehrs beginnt.

In diesem Szenario gilt:

• Der Multicast-Empfänger ist bereits der Multicast-Gruppe beigetreten.
• Es fließt noch kein aktiver Multicast-Quelldatenverkehr.

Dieser Status ist wichtig, da er Folgendes validiert:

• IGMP-Zugehörigkeitsoperation
• Erstellung des PIM Shared Tree
• Ursprünglicher (*,G) Multicast-Status
• Zinsverteilung beim Empfänger

FHR-1: Multicast-Routing-Tabelle

FHR-1# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 232.0.0.0/8), uptime: 23:07:34, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

FHR-2 - Multicast-Routing-Tabelle

FHR-2# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 232.0.0.0/8), uptime: 23:07:37, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

---

FHR-Multicast-Zustandsanalyse

Die FHR enthalten noch nicht:

• (*,G) Status für 24.10.20.10
• (S,G) für die Multicast-Quelle

Dieses Verhalten wird aus folgenden Gründen erwartet:

• Es ist noch kein Multicast-Quelldatenverkehr aktiv.
• Es wurden keine PIM-Registrierungsnachrichten generiert.
• Der FHR hat die Multicast-Weiterleitung nicht gestartet.

Es ist nur folgender Multicast-Eintrag vorhanden:

• 232.0.0.0/8

Dies entspricht dem Standard-SSM-Bereich und wird automatisch vom System installiert.

Diese Werte werden erwartet:

• Eingehende Schnittstelle: Null
• RPF-Nachbar: 0.0.0.0
• Anzahl ausgehender Schnittstellen: 0

Dieser Eintrag zeigt keine aktive Multicast-Weiterleitung an.

---

LHR = Multicast Routing Table

LHR# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 224.10.20.10/32), uptime: 23:07:39, igmp ip pim
  Incoming interface: Ethernet1/50, RPF nbr: 10.4.0.26
  Outgoing interface list: (count: 1)
    Vlan2, uptime: 23:07:39, igmp

(*, 232.0.0.0/8), uptime: 23:07:39, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

LHR-Multicast-Zustandsanalyse

Im Gegensatz zu den FHRs enthält die LHR einen aktiven (*,G) Eintrag für:

• 224.10.20.10

Dieses Verhalten wird aus folgenden Gründen erwartet:

• Der Multicast-Empfänger ist der Gruppe bereits beigetreten.
• Die IGMP-Mitgliedschaftsinformationen wurden für Vlan2 ermittelt.
• Der LHR initiierte den Shared Tree-Join zum RP.

Die Multicast-Routing-Tabelle bestätigt Folgendes:

• Die Eingangsschnittstelle (IIF) ist Ethernet1/50.
• Der RPF-Nachbar ist 10.4.0.26.
• Die Liste der ausgehenden Schnittstellen (OIL) enthält VLAN2.

Dies deutet darauf hin, dass

• Der Shared Tree wurde vom LHR korrekt in Richtung RP erstellt.
• Die Zinsen des Multicast-Empfängers wurden erfolgreich im Upstream weitergeleitet.
• PIM-Join-Nachrichten wurden richtig übertragen.

Zu diesem Zeitpunkt:

• Es ist noch kein Multicast-Quelldatenverkehr aktiv.
• Es ist noch kein (S,G)-Status vorhanden.
• Es ist nur der Status der gemeinsamen Struktur vorhanden.

---

N9K-1 - Zuordnung der Multicast-Routing-Tabelle des Agenten

N9K-1# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 232.0.0.0/8), uptime: 1d03h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

Zustandsanalyse für den Agent-Multicast

N9K-1 agiert nur als Mapping-Agent und ist nicht an der Multicast-Weiterleitung für 24.10.20.10 beteiligt.

Es wird daher erwartet, dass keine (*,G)-Einträge und (S,G)-Einträge vorhanden sind.

Der Mapping-Agent verteilt nur RP-Zuordnungsinformationen und ist nicht notwendigerweise an der Multicast-Datenweiterleitung beteiligt, es sei denn, Multicast-Datenverkehr durchläuft das Gerät direkt.

---

N9K-2 - RP-Multicast-Routing-Tabelle

N9K-2# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 224.10.20.10/32), uptime: 1d01h, pim ip
  Incoming interface: loopback0, RPF nbr: 10.2.0.4
  Outgoing interface list: (count: 1)
    Ethernet1/49, uptime: 1d01h, pim

(*, 232.0.0.0/8), uptime: 1d03h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

RP Multicast-Zustandsanalyse

N9K-2 fungiert als aktiver RP für:

• 224.10.20.0/24

Daher enthält der RP den Shared-Tree-Status (*,G) für 224.10.20.10.

Diese Werte werden erwartet:

• Eingehende Schnittstelle = Loopback0
• RPF neighbor = 10,2.0,4
• Ausgangsschnittstelle = Ethernet 1/49

Dies deutet darauf hin, dass

• Der RP hat den Status des Shared Tree erfolgreich installiert.
• Der RP hat PIM-Join-Nachrichten von Downstream-Routern empfangen.
• Der Shared Multicast Tree zu den Empfängern wurde korrekt erstellt.

Zu diesem Zeitpunkt:

• Der RP enthält nur den Status "Shared Tree".
• Es ist noch kein Multicast-Quelldatenverkehr aktiv.
• Es sind noch keine (S,G)-Einträge vorhanden.

---

Schritt 3 Überprüfen des Multicast-Routing-Zustands mit aktivem Multicast-Datenverkehr

Sobald die Übertragung des Multicast-Datenverkehrs beginnt, wechselt die Multicast-Routing-Tabelle vom Shared-Tree-Status in den quellenspezifischen Weiterleitungsstatus.

In diesem Szenario gilt:

• Die Multicast-Quelle ist 10.150.1.37.
• Die Multicast-Gruppe ist 224.10.20.10.
• Der aktive RP ist 10.2.0.4 auf N9K-2.
• Die Multicast-Quelle ist über den vPC-Port-Channel 78 verbunden.

---

Wichtige Überlegungen zu vPC-Multicast

Die Multicast-Quelle ist über eine vPC-Domäne verbunden, die aus FHR-1 und FHR-2 besteht.

Da die Quelle über einen vPC-Member-Port-Channel verbunden ist:

• Traffic-Hashing kann Multicast-Pakete an einen der Nexus-Switches weiterleiten.
• Beide FHRs erfordern identische Multicast-Konfigurationen.
• Beide FHRs benötigen konsistente Unicast-Routing-Informationen.
• Beide FHRs müssen identische RP-Zuordnungen beibehalten.
• Beide FHRs müssen stabile PIM-Nachbarschaften aufrechterhalten.

In diesem speziellen Szenario:

• Der Multicast-Fluss hasht in Richtung FHR-2.
• FHR-2 wird zum aktiven weiterleitenden FHR für die Multicast-Quelle.

FHR-1: Multicast-Routing-Tabelle

FHR-1# show ip mroute

IP Multicast Routing Table for VRF "default"

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:03:58, ip pim
  Incoming interface: Vlan1, RPF nbr: 10.150.1.37
  Outgoing interface list: (count: 0)

(*, 232.0.0.0/8), uptime: 1d00h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

FHR-1 - vPC-Rolle

FHR-1# show vpc role

vPC Role status
----------------------------------------------------
vPC role                        : primary <<<
Dual Active Detection Status    : 0
vPC system-mac                  : 00:23:04:ee:be:01
vPC system-priority             : 32667
vPC local system-mac            : 00:6b:f1:84:02:97
vPC local role-priority         : 32667
vPC local config role-priority  : 32667
vPC peer system-mac             : 6c:b2:ae:ee:5a:97
vPC peer role-priority          : 32667
vPC peer config role-priority   : 32667

FHR-1 Multicast-Zustandsanalyse

FHR-1 enthält einen aktiven (S,G) Eintrag für:

• Quelle = 10.150.1.37
• Gruppe = 224.10.20.10

Der Multicast-Routing-Eintrag bestätigt Folgendes:

• Die Quelle wurde über Vlan1 ermittelt.
• Der RPF-Nachbar ist die direkt verbundene Multicast-Quelle.
• Im OIL sind keine ausgehenden Schnittstellen vorhanden.

Dieses Verhalten wird erwartet, da der Multicast-Fluss für die ausgehende Weiterleitung keinen Hash in Richtung FHR-1 durchgeführt hat.

Das Ergebnis:

• FHR-1 installiert nur den lokalen Quellstatus.
• FHR-1 leitet Multicast-Verkehr nicht upstream über PIM weiter.

FHR-2 - Multicast-Routing-Tabelle

FHR-2# show ip mroute

IP Multicast Routing Table for VRF "default"

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:16:35, ip pim
  Incoming interface: Vlan1, RPF nbr: 10.150.1.37
  Outgoing interface list: (count: 1)
    Ethernet1/3, uptime: 00:16:35, pim

(*, 232.0.0.0/8), uptime: 1d00h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

FHR-2 - vPC-Rolle

FHR-2# show vpc role

vPC Role status
----------------------------------------------------
vPC role                        : secondary <<<
Dual Active Detection Status    : 0
vPC system-mac                  : 00:23:04:ee:be:01
vPC system-priority             : 32667
vPC local system-mac            : 6c:b2:ae:ee:5a:97
vPC local role-priority         : 32667
vPC local config role-priority  : 32667
vPC peer system-mac             : 00:6b:f1:84:02:97
vPC peer role-priority          : 32667
vPC peer config role-priority   : 32667

FHR-2 Multicast-Zustandsanalyse

Im Gegensatz zu FHR-1 enthält FHR-2:

• Eine Liste der aktiven ausgehenden Schnittstellen
• Ein aktiver PIM-Weiterleitungspfad

Dies deutet darauf hin, dass

• FHR-2 wurde zum operativen Forwarding FHR für den Multicast-Fluss.
• Die Multicast-Pakete werden über den vPC-Teilnehmer-Port-Channel in Richtung FHR-2 gehasht.
• FHR-2 kapselte den Multicast-Datenverkehr in PIM-Registrierungsnachrichten.
• FHR-2 leitete Multicast-Datenverkehr upstream an den RP weiter.

ECMP- und Multicast-Weiterleitungsverhalten

Die Ausgangsschnittstelle Ethernet1/3 stimmt mit der Unicast-Routing-Tabelle in Richtung Empfänger überein 192.168.2.37

FHR-2 - Route to Multicast Receiver

FHR-2# show ip route 192.168.2.37

IP Route Table for VRF "default"

'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.168.2.0/24, ubest/mbest: 2/0
    *via 10.4.0.13, Eth1/3, [110/45], 1d02h, ospf-UNDERLAY, intra
    *via 10.4.0.18, Eth1/4, [110/45], 1d02h, ospf-UNDERLAY, intra

FHR-2 enthält zwei Routen zu gleichen Kosten zum Multicast-Empfänger-Subnetz:

• 10.4.0.13 bis Ethernet1/3
• 10.4.0.18 über Ethernet1/4

Dies bestätigt Folgendes:

• ECMP-Routing ist in der Multicast-Transporttopologie aktiv.
• In Richtung des Empfängernetzwerks existieren mehrere gültige Unicast-Weiterleitungspfade.
• PIM kann den von MRIB ausgewählten RPF-Pfad für Multicast-Weiterleitungsentscheidungen verwenden.
• Paketduplizierung über parallele ECMP-Pfade hinweg findet nicht statt.

Obwohl zwei Routen zu gleichen Kosten vorhanden sind, verwendet die Multicast-Weiterleitung einen einzigen RPF-Pfad für jeden Multicast-Fluss.

In dieser Topologie verwendet der Multicast-Fluss Folgendes:

• Ethernet1/3 zu 10.4.0.13

Dieses Verhalten entspricht der zuvor beobachteten Multicast-Routing-Tabelle:

(10.150.1.37/32, 224.10.20.10/32)
  Outgoing interface list:
    Ethernet1/3

---

vPC - Betriebsverhalten (primär und sekundär)

Die vPC-Betriebsrollen beeinflussen das Multicast-Weiterleitungsverhalten unterschiedlich für:

• PIM-Datenverkehr
• IGMP-Verarbeitung

In dieser Topologie gilt Folgendes:

• FHR-1 ist der primäre betriebsbereite vPC.
• FHR-2 ist das betriebsbereite sekundäre vPC.

Beide Nexus Switches können:

• Verarbeitung von PIM-Datenverkehr auf Kontrollebene
• Multicast-Routing-Status erstellen
• Weiterleitung von Multicast-Datenverkehr über PIM

Allerdings:

• Nur der betriebsbereite primäre vPC verarbeitet den IGMP-Empfängerdatenverkehr zum Access Layer.

Diese Unterscheidung ist aus folgenden Gründen wichtig:

• Die PIM-Weiterleitung zum gerouteten Netzwerk bleibt auf beiden Peers aktiv.
• Die IGMP-Weiterleitung an Layer-2-Empfängersegmente wird weiterhin zentral über die primäre Betriebsschnittstelle abgewickelt.

Daher:

• Der Multicast-Datenverkehr von der Quelle zur gerouteten Multicast-Domäne kann über einen der vPC-Peers geleitet werden.
• Der Multicast-Datenverkehr zu IGMP-Empfängern hängt vom primären Betriebsverhalten ab.

---

LHR = Multicast Routing Table

LHR# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 224.10.20.10/32), uptime: 1d00h, igmp ip pim
  Incoming interface: Ethernet1/50, RPF nbr: 10.4.0.26
  Outgoing interface list: (count: 1)
    Vlan2, uptime: 1d00h, igmp

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:06:31, ip mrib pim
  Incoming interface: Ethernet1/49, RPF nbr: 10.4.0.22
  Outgoing interface list: (count: 1)
    Vlan2, uptime: 00:06:31, mrib

(*, 232.0.0.0/8), uptime: 1d00h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

LHR-Multicast-Zustandsanalyse

Die LHR enthält nun beide:

• (*,G) Shared-Tree-Status
• (S,G) Source-Tree-Status

Dies bestätigt:

• Der Multicast-Empfänger wurde erfolgreich hinzugefügt.
• Die Multicast-Quelle wurde aktiviert.
• Der LHR wechselte von der Weiterleitung im Shared Tree zur Weiterleitung im Source Tree.

Der Eintrag (S,G) bestätigt:

• Der Multicast-Quellpfad wurde erfolgreich ermittelt.
• Der RPF-Nachbar ist 10.4.0.22.
• Der Multicast-Datenverkehr gelangt über Ethernet1/49.
• Der Multicast-Datenverkehr wird an VLAN2-Empfänger weitergeleitet.

Dieses Verhalten bestätigt den Erfolg:

• PIM-Weiterleitung
• RPF-Validierung
• Quellbaumkonstruktion
• Multicast-Datenverkehrsbereitstellung

---

N9K-1 - Transit-Multicast-Routing-Tabelle

N9K-1# show ip mroute

IP Multicast Routing Table for VRF "default"

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:06:42, pim ip
  Incoming interface: Ethernet1/4, RPF nbr: 10.4.0.14
  Outgoing interface list: (count: 1)
    Ethernet1/49, uptime: 00:06:42, pim

(*, 232.0.0.0/8), uptime: 1d04h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

N9K-1 - Analyse des Transitstatus

N9K-1 fungiert als Transit-Multicast-Router für den aktiven Multicast-Fluss.

Der Multicast-Routing-Eintrag bestätigt Folgendes:

• Der Multicast-Datenverkehr kommt über Ethernet1/4.
• Der Multicast-Datenverkehr wird an Ethernet1/49 weitergeleitet.
• Der Multicast-Weiterleitungspfad zum LHR ist betriebsbereit.

Dies bestätigt den Erfolg:

• PIM-Nachbaroperation
• RPF-Validierung
• Multicast-Weiterleitung über das Transit-Netzwerk

---

N9K-2 - RP-Multicast-Routing-Tabelle

N9K-2# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 224.10.20.10/32), uptime: 1d02h, pim ip
  Incoming interface: loopback0, RPF nbr: 10.2.0.4
  Outgoing interface list: (count: 1)
    Ethernet1/49, uptime: 1d02h, pim

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:06:50, ip pim mrib
  Incoming interface: Ethernet1/4, RPF nbr: 10.4.0.17, internal
  Outgoing interface list: (count: 0)

(*, 232.0.0.0/8), uptime: 1d04h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

RP Multicast-Zustandsanalyse

N9K-2 fungiert als aktiver RP für die Multicast-Gruppe.

Der RP enthält beides:

• (*,G) Shared-Tree-Status
• (S,G) Source-Tree-Status

Das Fehlen ausgehender Schnittstellen im (S,G)-Eintrag wird aus folgenden Gründen erwartet:

• Der RP hat die Empfänger bereits auf den Baum mit dem kürzesten Pfad umgeschaltet.
• Der Shared-Tree-Weiterleitungspfad ist für die aktive Multicast-Weiterleitung nicht mehr erforderlich.

Mindestanzahl an Multicast-Informationen, die für RCA und Diagnose erforderlich sind

Die Liste der Befehle enthält die empfohlene Mindestsammlung von Multicast-Daten, die erforderlich ist, um eine ordnungsgemäße Ursachenanalyse (Root Cause Analysis, RCA) oder Multicast-Diagnose auf Cisco Nexus Switches der Serie 9000 mit NX-OS durchzuführen. Diese Ausgänge erfassen den Multicast-Steuerungsebenenstatus, MRIB-Programmierung, Weiterleitungsinformationen, den vPC-Betriebsstatus und Details zur Hardware-Weiterleitung. Abhängig vom Fehlerszenario können jedoch weitere Informationen erforderlich sein. So erfordern z. B. Multicast-Paketverluste, zeitweilige Datenverluste, Probleme mit der Paketreplikation, inkonsistente Hardwareweiterleitungen oder Multicast-Weiterleitungen außerhalb der normalen Arbeitsumgebung häufig eine direkte Paketerfassung auf dem Nexus-Switch mithilfe von EtherAnalyzer, SPAN oder hardwarebasierten Erfassungen. Ebenso können vorübergehende RPF-Inkonsistenzen, ECMP-Weiterleitungsänderungen, ASIC-Programmierungsfehler oder IGMP-Unterdrückungsereignisse ohne ständige Protokollgenerierung auftreten.

Durch die Kombination von Show-Tech-Outputs mit Paketerfassung und Weiterleitungsvalidierung werden die Diagnosegenauigkeit und die RCA-Qualität erheblich verbessert. Obwohl diese Informationen eine solide Betriebsgrundlage für die Multicast-Fehlerbehebung darstellen, können sie nicht garantieren, dass eine RCA immer ausschließlich anhand dieser Ergebnisse identifiziert werden kann. Bestimmte Multicast-Fehler erfordern zusätzliche Fehlerbehebung, Live-Datenverkehrsanalyse, Validierung auf Hardwareebene, Topologiekorrelation oder erweiterte Paketerfassung, um die genaue Ursache zu isolieren.

Minimale Multicast-Datensammlungsbefehle

N9K-1# show tech-support multicast >> bootflash:$(SWITCHNAME)-sh-tech-multicast.txt

N9K-1# show tech-support details >> bootflash:$(SWITCHNAME)-sh-tech-det.txt

N9K-1# show tech-support vpc >> bootflash:$(SWITCHNAME)-sh-tech-vpc.txt

N9K-1# show tech-support forwarding multicast >> bootflash:$(SWITCHNAME)-sh-tech-fwd-multicast.txt

N9K-1# show tech-support forwarding l3 multicast detail vdc-all >> bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-multicast.txt

N9K-1# show tech-support forwarding l3 unicast detail vdc-all >> bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-unicast-det.txt

TAR-Archiv für Export erstellen

Nach der Generierung der Show-Tech-Dateien, konsolidieren Sie sie in einem einzigen TAR-Archiv für Export und Analyse. Der Befehl besteht aus einer einzelnen Zeile.

N9K-1# tar create bootflash:$(SWITCHNAME)-multicast-logs
bootflash:$(SWITCHNAME)-sh-tech-multicast.txt
bootflash:$(SWITCHNAME)-sh-tech-det.txt
bootflash:$(SWITCHNAME)-sh-tech-vpc.txt
bootflash:$(SWITCHNAME)-sh-tech-fwd-multicast.txt
bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-multicast.txt
bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-unicast-det.txt

Das Exportieren eines einzelnen TAR-Archivs vereinfacht Folgendes:

• Uploads von TAC-Tickets
• RCA-Workflows
• Zentrale Protokollanalyse
• Multicast-Weiterleitungskorrelation
• Erhaltung historischer Fehler

Revisionsverlauf

Überarbeitung	Veröffentlichungsdatum	Kommentare
1.0	13-May-2026	Erstveröffentlichung