Problemen met Multicast Auto-RP op Nexus 9000 met NX-OS oplossen

Inleiding

In dit document wordt beschreven hoe Auto-RP werkt op Cisco Nexus 9000 met NX-OS en hoe u de werking van multicast kunt valideren en problemen kunt oplossen.

Voorwaarden

Vereisten

• Basiskennis van IP multicast
• Basiskennis van IGMP en PIM Sparse Mode
• Ervaring met Cisco Nexus 9000 en NX-OS CLI
• Inzicht in unicast routing en RPF concepten

Gebruikte componenten

• Cisco Nexus 9000-serie switches
• Cisco NX-OS-software
• PIM-spaarstand
• Statische RP en Auto-RP

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Overzicht van Multicast

Multicast is een één-op-veel communicatiemodel waarbij een bron één verkeersstroom naar meerdere geïnteresseerde ontvangers stuurt. In plaats van een afzonderlijke kopie voor elke bestemming te maken, repliceert het netwerk het verkeer alleen waar het doorstuurpad vertakt. Dit maakt multicast efficiënter dan uitzending of herhaalde unicast-uitzendingen. In IPv4 gebruikt multicast-verkeer bestemmingsadressen uit het bereik 224.0.0.0/4.

PIM Sparse Mode is het multicast-routeringsmodel dat wordt ondersteund op Cisco Nexus-switches met NX-OS. Het stuurt alleen verkeer door wanneer de interesse van de ontvanger expliciet is geleerd. In een Any-Source Multicast ontwerp, ontvangers in eerste instantie lid worden van een gedeelde boom in de richting van de Rendezvous Point, en bronnen registreren met die RP. Nadat het verkeer begint te stromen, kan de last-hop router van de gedeelde boom naar de kortste pad boom naar de bron.

Het is belangrijk om de terminologie te definiëren die in multicast wordt gebruikt, omdat nauwkeurige probleemoplossing afhankelijk is van inzicht in de manier waarop gebeurtenissen in het besturingsvlak, routeringsitems en doorstuurbeslissingen worden weergegeven. Heldere terminologie helpt bij het correct interpreteren van opdrachtuitvoer, het onderscheid maken tussen gedeeld boomstructuur- en bronboomgedrag en het identificeren van de rol van elke multicast-component in het end-to-end doorstuurproces.

Begrip	Definitie
Multicast-groepsadres	Een IPv4-bestemmingsadres in het bereik 224.0.0.0/4 dat wordt gebruikt om een multicastgroep te identificeren.
Bronadres	Het unicast IP-adres van de afzender die verkeer naar een multicast-groep verzendt.
omleiden	Het multicast-routeringsitem dat definieert hoe multicast-verkeer voor een combinatie van een groep of brongroep wordt afgehandeld.
IIF	Inkomende interface. De interface waarop multicast-verkeer naar verwachting zal aankomen.
OIF	Uitgaande interface. Een interface die wordt gebruikt om multicast-verkeer door te sturen naar ontvangers of downstream-buren.
OLIE	Lijst met uitgaande interfaces. De set uitgaande interfaces die zijn gekoppeld aan een multicast-routeringsitem.
RPF	Pad omkeren doorsturen. Een controle die verifieert of multicast-verkeer op de juiste interface is aangekomen op basis van de unicast-route naar de bron of de RP.
MDT	Multicast Distribution Tree. De logische boom die multicast-verkeer van de bron naar alle ontvangers vervoert.
RPT	RP Tree, ook wel de gedeelde boom genoemd. Het verbindt ontvangers met de RP en wordt vertegenwoordigd door (*, G).
SPT	De kortste padstructuur, ook wel de bronstructuur genoemd. Het verbindt ontvangers rechtstreeks met de bron en wordt vertegenwoordigd door (S, G).
FHR	Eerste-hop router. De multicast-router is rechtstreeks verbonden met de bron en verantwoordelijk voor de bronregistratie bij de RP.
LHR	Last-hop router. De multicast-router is rechtstreeks verbonden met ontvangers en verantwoordelijk voor het maken van multicast-status na het leren van de interesse van de ontvanger via IGMP.
RP	Het rendez-vous punt. Het logische ontmoetingspunt dat in ASM- en PIM Sparse-modus wordt gebruikt om bronnen en ontvangers aanvankelijk aan te sluiten.
ASM	Elke bron-multicast. Een multicast-model waarbij ontvangers zich bij een groep aansluiten zonder de bron vooraf op te geven.

Het is belangrijk om de bekende gereserveerde multicast-adressen te begrijpen, omdat het oplossen van problemen met multicast afhankelijk is van het snel identificeren van welk controleprotocol een bepaalde bestemmingsgroep gebruikt en welke functie dat verkeer in het netwerk dient. Deze adressen helpen bij het onderscheiden van normale protocolwerking van abnormaal gedrag en maken het gemakkelijker om IGMP-, PIM- en Auto-RP-uitwisselingen te valideren. Voor Auto-RP specifiek, de belangrijkste groepen te herkennen zijn 224.0.1.39 voor RP-Announce en 224.0.1.40 voor RP-Discovery, omdat ze de informatie die routers in staat stelt om de dynamische RP mappings te leren dragen.

multicast-adres	Doel
224.0.0.1	Alle hosts op het lokale subnet
224.0.0.2	Alle routers op het lokale subnet
224.0.0.13	Alle PIM-routers
224.0.0.22	IGMPv3-berichten
224.0.1.39	Cisco RP-Announce berichten gebruikt door Auto-RP
224.0.1.40	Cisco RP-Discovery-berichten gebruikt door Auto-RP

Auto-RP-bewerking in PIM Sparse-modus (werkstroom van besturingsvlak)

Auto-RP is een Cisco-mechanisme dat wordt gebruikt in de Protocol Independent Multicast Sparse Mode om dynamisch informatie over het Rendezvous Point (RP) te ontdekken en te distribueren over het multicast-domein. Het elimineert de noodzaak van statische RP-configuratie door multicast-gebaseerde control-plane-berichten te gebruiken om te adverteren, selecteren en leren RP-to-group mappings. De belangrijkste componenten zijn kandidaat-RP's, die RP-services aanbieden voor specifieke groepsbereiken, en Mapping Agents, die kandidaten verzamelen en de actieve RP per groep bepalen.

Het proces begint wanneer elke kandidaat-RP periodiek RP-Announce-berichten verzendt naar 224.0.1.39, inclusief het IP-adres, de prioriteit en de ondersteunde multicast-groepsbereiken. Deze berichten worden door het hele netwerk overspoeld met behulp van Auto-RP-listener in NX-OS, zodat alle mappingagents ze ontvangen, zelfs voordat het netwerk volledig in de spaarzame modus werkt.

Mapping Agents luisteren naar deze aankondigingen, bouwen een kandidaat-RP-database en voeren een deterministisch selectieproces uit per groep (meestal de hoogste prioriteit, dan het hoogste IP-adres). Zodra de beste RP is gekozen, genereert de Mapping Agent RP-Discovery-berichten en verzendt deze naar 224.0.1.40, waarbij de laatste RP-to-group-mappings naar alle routers in het domein worden geadverteerd.

Alle PIM-routers ontvangen de RP-Discovery-berichten en installeren de toewijzingen in hun lokale RP-tabellen. Met deze informatie sturen last-hop routers (verbonden met ontvangers) PIM Join-berichten naar de geselecteerde RP om de gedeelde structuur (RPT) te bouwen, terwijl first-hop routers (verbonden met bronnen) multicast-verkeer inkapselen in PIM Register-berichten om de RP te informeren over actieve bronnen.

Terwijl het verkeer door de RP stroomt, kunnen routers optioneel van de gedeelde structuur (RPT) naar een kortste-padstructuur (SPT) switches met behulp van extra PIM Join / Prune-signalering rechtstreeks naar de bron. Gedurende dit proces vernieuwt Auto-RP voortdurend mappings via periodieke controleberichten, waardoor veerkracht en automatische aanpassing aan topologie- of RP-veranderingen worden gewaarborgd.

Auto-RP-bewerking in PIM Sparse-modus (werkstroom van besturingsvlak)

Auto-RP-beperkingen en operationele beperkingen

• Auto-RP werkt alleen met IPv4 multicast en wordt niet ondersteund voor IPv6 (PIM6), dus IPv6-implementaties vereisen een ander RP-detectiemechanisme.
• Auto-RP kan niet naast BSR bestaan binnen hetzelfde PIM-domein, omdat slechts één RP-detectiemechanisme kan worden geconfigureerd om conflicten tussen besturingsvlakken te voorkomen.
• Auto-RP-berichten worden niet standaard verwerkt of doorgestuurd op NX-OS-apparaten, dus expliciete configuratie is vereist voor een goede werking.
• De verspreiding van Auto-RP-controleberichten is afhankelijk van het inschakelen van de Auto-RP-listener; anders bereikt RP-toewijzingsinformatie niet alle routers.
• Het RP-aankondigingsinterval heeft een minimumdrempel van 15 seconden, waardoor de snelheid waarmee RP-updates kunnen worden geadverteerd en de convergentietijd beïnvloedt.
• Automatisch RP-berichtfiltering via routekaarten kan de werking beïnvloeden, omdat onjuiste beleidsregels RP-naar-groepstoewijzingen kunnen blokkeren.
• Auto-RP is standaard uitgeschakeld in VRF-contexten, dus het moet expliciet zijn ingeschakeld in multi-VRF-implementaties.

• ECMP-gebaseerde multipath-forwarding is standaard ingeschakeld, waardoor multicast-verkeer gelijke paden kan gebruiken voor taakverdeling.

• Verificatie van PIM-buren met IPsec AH-MD5 wordt ondersteund.

• PIM-snooping is niet beschikbaar.

Voordelen van Auto-RP

Auto-RP biedt dynamische RP-detectie en gecentraliseerde RP-toewijzingsdistributie voor PIM Sparse Mode multicast-omgevingen. Het elimineert de behoefte aan statische RP-configuratie op elke multicast-router, vermindert de operationele complexiteit en verbetert de schaalbaarheid van multicast. Auto-RP ondersteunt ook meerdere RP-kandidaten, waardoor automatische RP-failover en redundantie mogelijk zijn. Dit mechanisme helpt consistent multicast-doorstuurgedrag te behouden, vereenvoudigt netwerkuitbreiding en maakt het mogelijk dat multicast-routers automatisch RP-informatie in het hele domein kunnen leren.

Auto-RP Mapping Agent en RP-selectieproces

Het selectieproces in Auto-RP is deterministisch en voornamelijk gebaseerd op IP-adressen. In tegenstelling tot andere protocollen (zoals PIMv2 BSR) gebruikt Auto-RP geen configureerbare "prioriteit"-waarde; in plaats daarvan vertrouwt het op de IP-adreshiërarchie om conflicten op te lossen.

Selectie van toewijzende agent (MA)

In Auto-RP kunnen meerdere Mapping Agents naast elkaar bestaan binnen hetzelfde netwerk voor redundantie. Er is geen formeel verkiezingsproces waarbij de ene wordt uitgeschakeld en de andere wordt ingeschakeld; ze zijn allemaal technisch actief. De switches in het netwerk moeten echter beslissen welke informatie ze vertrouwen.

• Selectiecriterium: hoogste IP-adres.
• Het proces:
  1. Alle mappingagents sturen hun RP-Discovery-berichten naar de multicastgroep 224.0.1.40.
  2. Switches van klanten ontvangen deze berichten.
  3. Als een switch detectieberichten ontvangt van twee verschillende toewijzende agents die tegenstrijdige informatie bevatten, accepteert de switch de informatie van de toewijzende agent met het hoogste bron-IP-adres.
  4. Nexus-gedrag: Een Mapping Agent met een lager IP-adres voert meestal een "passieve" of "suppressie" -status in bij het detecteren van een andere MA met een hoger IP-adres om dubbel controleverkeer in het netwerk te voorkomen.

Selectie rendez-vous-punt (RP)

Dit proces wordt uitgevoerd door de Mapping Agent na het luisteren naar alle RP-Announce berichten (verzonden naar groep 224.0.1.39) van de kandidaten.

Wanneer de Mapping Agent meerdere kandidaten ontvangt voor dezelfde multicast-groep, past deze deze regels toe in volgorde van:

Regel A: langste voorvoegselovereenkomst (meest specifieke masker)

Als kandidaten overlappende bereiken aankondigen, wijst de MA de groep toe aan de RP die het kleinste bereik heeft aangekondigd (het langste subnetmasker).

• Voorbeeld:
  • Kandidaat A kondigt 224.0.0.0/4 aan (het volledige multicast-assortiment).
  • Kandidaat B kondigt 224.10.20.0/24 aan.
  • Resultaat: Voor groep 224.10.20.5 wint Kandidaat B omdat het bereik specifieker is.

Regel B: Hoogste IP-adres (tie-breaker)

Als twee of meer kandidaten exact hetzelfde groepsbereik aankondigen, moet de Mapping Agent er slechts één kiezen.

• Criterium: de kandidaat met het hoogste IP-adres wint.
• Voorbeeld:
  • Kandidaat 1: 10.2.0.1 voor bereik 224.10.20.0/24.
  • Kandidaat 2: 10.2.0.4 voor bereik 224.10.20.0/24.
  • Resultaat: De Mapping Agent selecteert 10.2.0.4 als de officiële RP voor dat bereik en dit wordt geadverteerd in zijn Discovery-berichten.

Overwegingen voor Layer 2: Multicast MAC en Snooping

Hoewel de focus van dit artikel ligt op Layer 3 multicast met behulp van PIM, speelt Layer 2-gedrag een cruciale rol bij het oplossen van problemen en het algehele ontwerp. In Layer 2 communiceren apparaten met behulp van MAC-adressen, 48-bits identificatoren die zijn toegewezen aan netwerkinterfaces, en multicast-verkeer vereist een specifiek MAC-adresseringsschema om het te onderscheiden van unicast- en uitzendverkeer.

IPv4 multicast MAC-adressen zijn afgeleid van Layer 3 multicast-groepsadressen met het gereserveerde voorvoegsel `01:00:5E`. Slechts 23 bits van het IP-multicastadres worden echter toegewezen aan het MAC-adres, waardoor een overlapping van 32:1 ontstaat, wat betekent dat maximaal 32 verschillende multicast-IP-groepen aan hetzelfde MAC-adres kunnen worden toegewezen. Als gevolg hiervan kunnen hosts die naar een bepaald multicast-MAC-adres luisteren verkeer ontvangen voor meerdere multicast-groepen, zelfs als ze geïnteresseerd zijn in slechts één. Bijvoorbeeld 224.1.1.1, 225.1.1.1, 226.1.1.1, 227.1.1.1, 228.1.1.1 en meer.

Deze overlapping heeft directe gevolgen voor de efficiëntie van het netwerk en het oplossen van problemen. Aangezien Layer 2-forwardingbeslissingen die uitsluitend op MAC-adressen zijn gebaseerd, geen onderscheid kunnen maken tussen overlappende multicastgroepen, kunnen switches overbodig verkeer naar hosts leveren. Deze hosts moeten dan vertrouwen op hogere laag filtering (IP/IGMP) om ongewenste pakketten te verwijderen, waarbij CPU- en bufferbronnen worden verbruikt.

In Cisco Nexus NX-OS wordt deze beperking beperkt door het gedrag van IGMP-snooping. Standaard voert IGMP-snooping IP-gebaseerde opzoekingen uit in plaats van alleen MAC-doorsturen, waardoor switches preciezere doorstuurbeslissingen kunnen nemen, zelfs wanneer meerdere multicastgroepen hetzelfde MAC-adres delen. Dit verbetert de efficiëntie van Layer 2 aanzienlijk en vermindert onnodige verkeersoverdracht.

Auto-RP-configuratie

Deze sectie geeft een gedetailleerde uitleg van de Auto-RP-configuratie, met behulp van een eenvoudige implementatie als referentie. In deze configuratie wordt een multicast-bron via vPC verbonden met twee Nexus-switches om verkeer naar een ontvanger te leveren. In dit ontwerp functioneren zowel N9K-1 als N9K-2 tegelijkertijd als RP-kandidaten en Mapping Agents.

multicast-verkeersstroom

Eerste Hop Router

Dezelfde configuratie heeft 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

Opdracht	Doel / beschrijving
Kenmerk PIM	Maakt het PIM-proces (Protocol Independent Multicast) op de switch mogelijk.
IP PIM Auto-RP Forward Luister	Hiermee schakelt u de Auto-RP Listener in. Hierdoor kan de switch Auto-RP-controleberichten (224.0.1.39 en 224.0.1.40) ontvangen en doorsturen, zelfs als hij de identiteit van de RP nog niet kent.
IP PIM sparse-mode	Hiermee wordt de spaarmodus voor PIM ingeschakeld op een specifieke interface. In deze modus wordt multicast-verkeer alleen doorgestuurd naar segmenten die er expliciet om hebben gevraagd via PIM Join-berichten.

Mapping Agent en RP Candidate

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

Deze tabel bevat een gedetailleerde technische uitsplitsing van de PIM-configuratie voor N9K-1. Deze configuratie is gerepliceerd op N9K-2. Beide switches zijn geconfigureerd met een dubbele rol, die fungeert als zowel een RP-kandidaat als een Mapping Agent voor het multicastdomein.

Opdracht	Gedetailleerde technische uitleg
Kenmerk PIM	Activering van functies: maakt wereldwijd de PIM-engine (Protocol Independent Multicast) op de Nexus-switch mogelijk.
IP PIM Auto-RP-Candidate Loopback0 Group-List 224.10.20.0/24 Interval 15	RP Candidate Role: Configureert deze switch naar "vrijwilliger" als het Rendezvous Point (RP). Bron: Gebruikt het IP-adres van loopback0 Bereik: Het biedt aan om het multicast-groepsbereik 224.10.20.0/24 te behandelen. Interval: stuurt elke 15 seconden "Aankondigen"-berichten naar de Mapping Agent. Hold timer is drie keer deze waarde.
IP PIM Auto-RP Mapping-Agent Loopback1	Mapping Agent Role: Configureert de switch als de "administrator" van het Auto-RP-proces. Functie: Het luistert naar alle RP-kandidaten, lost conflicten op (met behulp van het hoogste IP-adres als een tie-breaker) en verzendt de "Discovery" -berichten naar de rest van het netwerk om hen te informeren wie de actieve RP is.
Interface loopback0 / loopback1	Logische interfaces: PIM is ingeschakeld op deze interfaces omdat ze dienen als de bron-IP's voor de rollen RP-kandidaat en Mapping Agent. Ze moeten bereikbaar zijn via de unicast-routeringstabel van alle PIM-routers.
Ethernet-interface 1/3, 1/4, 1/49	Physical Forwarding: maakt PIM Sparse Mode mogelijk op fysieke poorten. Dit stelt de switch in staat om PIM-buurbuurten te vormen met andere routers en multicast-verkeer door te sturen via deze specifieke links.
IP PIM sparse-mode	Operationele modus: toegepast op alle interfaces hierboven. Het zorgt ervoor dat multicast-verkeer alleen wordt verzonden naar ontvangers die het expliciet hebben aangevraagd via PIM Join-berichten, waardoor onnodige netwerkoverstromingen worden voorkomen.

Routeringsconfiguratie voor IPv4-bereikbaarheid

• In deze topologie nemen alle Nexus-switches deel aan een enkel OSPF-proces met de naam UNDERLAY, dat binnen Area 0 (0.0.0.0) opereert om volledige routeringsbereikbaarheid over het netwerk te bieden.
• Op de LHR is OSPF ingeschakeld op VLAN 2, dat dient als de gateway voor de multicast-ontvanger, en op de uplinkinterfaces Ethernet1/49 en Ethernet1/50, beide geconfigureerd als point-to-point. Dit zorgt voor een efficiënte aangrenzende formatie naar de stroomopwaartse N9K-switches zonder DR / BDR-verkiezingen.
• De FHR-laag (FHR-1 en FHR-2) deelt een identieke configuratie. OSPF is ingeschakeld op VLAN 1, dat fungeert als de gateway voor de multicast-bron, en op de gerouteerde uplinks (Ethernet1/1 en Ethernet1/3) naar de aggregatielaag. Deze koppelingen worden ook geconfigureerd als point-to-point, waardoor convergentie en aangrenzend gedrag worden geoptimaliseerd.
• Ook N9K-1 en N9K-2 hebben identieke OSPF-configuraties, met de toevoeging van Loopback0 en Loopback1 advertentie in OSPF.
  • Deze loopbacks zijn van cruciaal belang, omdat ze later worden gebruikt voor PIM RP Candidate- en Mapping Agent-rollen.

PIM-buren en OSPF-gebied 0

N9K-1 — OSPF-configuratie

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-configuratie

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-configuratie

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

Verifieer de operationele status en los problemen met Auto-RP op

Stap 1: Verifieer de bereikbaarheid van de basis-IP (Unicast Underlay Validation)

Voordat multicast-gedrag wordt geanalyseerd, is het van cruciaal belang om te valideren dat de unicast-onderlaag (OSPF Area 0) volledig operationeel is. Multicast control-plane-protocollen zoals PIM en Auto-RP zijn afhankelijk van de bereikbaarheid van unicast om correct te functioneren.

De eerste validatiestap is om te bevestigen dat de bron en ontvanger (of hun dichtstbijzijnde Layer 3-gateways: FHR en LHR) bereikbaar zijn.

Uit de topologie:

• FHR-1 / FHR-2 → Dichtst bij multicastbron (10.150.1.37 – VLAN 1)

• LHR → Dichtst bij multicast-ontvanger (192.168.2.37 – VLAN 2)

Validatiebenadering

1. ICMP-bereikbaarheidstests uitvoeren tussen:

• FHR ↔ LHR

• FHR ↔ Ontvangersubnet (VLAN 2-gateway)

• LHR ↔ Bronsubnet (VLAN 1-gateway)

2. De bereikbaarheid van de bron en ontvanger valideren in de routeringstabel. Zorg voor consistentie tussen beide Nexus-peers voor vPC-implementaties. Merk op dat de ontvanger een ECMP-pad heeft, terwijl de bron bereikbaar is via Layer 2.

FHR-1 — Route naar de bron

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 naar ontvanger

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 naar de bron

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 naar ontvanger

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 naar de bron

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 naar ontvanger

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

Belangrijke overwegingen

• Het falen van deze test duidt sterk op een onderliggend probleem.

• Multicast kan niet goed functioneren zonder unicast-bereikbaarheid, omdat:

  • PIM-buren vertrouwen op unicast-routering

  • RP-adressen (Loopback) moeten bereikbaar zijn

  • RPF-controles (Reverse Path Forwarding) zijn afhankelijk van de routeringstabel

• Een succesvolle ping garandeert niet dat multicast kan werken, omdat:

  • ICMP kan worden toegestaan terwijl multicast is geblokkeerd

  • PIM of Auto-RP kunnen nog steeds verkeerd worden geconfigureerd

Stap 2: Multicast-rollen en end-to-end topologie identificeren

De volgende stap is het duidelijk identificeren van de rol van elk apparaat dat betrokken is bij het doorsturen van multicast-verkeer. Dit is een verplichte stap, omdat het oplossen van problemen met multicast volledig afhankelijk is van het begrijpen van de verkeersstroom en het verwachte gedrag in de topologie.

Deze elementen moeten ten minste worden geïdentificeerd:

• Multicastbron (S): 10.150.1.37 (VLAN 1)

• Multicast Groep (G): 224.10.20.10

• Ontvanger: 192.168.2.37 (VLAN 2)

• Eerste Hop Router (FHR): FHR-1 / FHR-2 (het dichtst bij de bron)

• Last Hop Router (LHR): LHR (het dichtst bij de ontvanger)

Daarnaast is het noodzakelijk om de rollen van het besturingsvlak te identificeren:

• Kandidaten voor RP: N9K-1 en N9K-2 (Loopback0)

• Mapping Agents: N9K-1 en N9K-2 (Loopback1)

Topologie en Control-Plane Bewustzijn

Een gedetailleerde netwerktopologie is verplicht om door te gaan met elke multicast-probleemoplossing. Dit omvat:

• Fysieke connectiviteit (interfaces tussen apparaten)

• Logische topologie (VLAN's, gerouteerde koppelingen, vPC-relaties)

• Routeringsprotocol in gebruik (OSPF-gebied 0 in dit ontwerp)

• Routering van domeingrenzen (enkelvoudige IGP versus gemengde protocollen zoals OSPF, EIGRP of BGP)

• Loopback-interfaces die worden gebruikt voor RP- en Mapping Agent-rollen

• PIM-compatibele interfaces en buurrelaties

Wat duidelijk moet worden begrepen

• Het exacte pad vanaf Source → FHR → RP → LHR → Ontvanger

• Welke apparaten zijn verantwoordelijk voor:

  • PIM-register verzenden (FHR)

  • Bouw (*, G) of (S, G) bomen (LHR)

  • Reclame RP informatie (Mapping Agent)

• Hoe routering (OSPF) de bereikbaarheid waarborgt van:

  • Bronsubnet

  • Ontvangersubnet

  • RP-loopbackadressen

  • Loopback-adressen van mapping agents

Stap 3: Auto-RP-configuratie valideren op basis van apparaatrol

De volgende stap is om te controleren of Auto-RP correct is geconfigureerd op elk apparaat op basis van zijn rol in de multicast-topologie. Dit omvat de bevestiging dat:

• RP-kandidaten (N9K-1 / N9K-2) zijn correct geconfigureerd om hun Loopback0 te adverteren als de RP voor het multicast-groepsbereik.

• Mapping Agents (N9K-1 / N9K-2) zijn geconfigureerd om RP-Announce-berichten te verzamelen en RP-Discovery-berichten te genereren met behulp van Loopback1.

• FHR en LHR hebben PIM Sparse Mode ingeschakeld op alle relevante interfaces om deel te nemen aan Auto-RP en RP-mappings te ontvangen.

Het is van essentieel belang ervoor te zorgen dat alle vereiste interfaces (inclusief loopbacks en gerouteerde koppelingen) zijn ingeschakeld voor de spaarstand van PIM en dat er geen configuraties ontbreken die de uitwisseling van RP-Announce (224.0.1.39) en RP-Discovery (224.0.1.40)-berichten zouden voorkomen.

Stap 4: De werking van alle RP-kandidaten en alle Mapping Agents valideren

Stap 4.1 Verifieer aangrenzende PIM-buren

De eerste validatiestap is om te bevestigen dat alle verwachte PIM-buren correct zijn vastgesteld in de multicast-topologie.

N9K-1 — Controleer PIM-buren

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 — Verifieer PIM-buren

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

Validatiepunten

• Controleer of alle verwachte buren op elke gerouteerde interface worden weergegeven.
• Controleer of de uptime van de buren stabiel is en voortdurend toeneemt.
• Controleer of de timer Verloopt regelmatig wordt vernieuwd.
• Controleer of er geen onverwachte aangrenzende flappen voorkomen.
• Controleer of de juiste optie voor de toegewezen router (DR) is geselecteerd.
• Controleer of multicast-interfaces PIM-adjacencies vormen.

In deze topologie:

• N9K-1 heeft drie PIM-buren.
• N9K-2 vestigt ook drie PIM-buren.
• Alle aangrenzende delen blijven meer dan 23 uur stabiel, wat duidt op een stabiele werking van het multicast-besturingsvlak.

---

Stap 4.2 Verifieer PIM-compatibele interfaces

De volgende stap is om te bevestigen dat alle interfaces die deelnemen aan Auto-RP zijn ingeschakeld voor PIM.

Deze validatie is vooral belangrijk voor:

• RP-Candidate loopbacks
• Loopbacks van toewijzende agent

N9K-1 — Verifieer PIM-interfaces

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 — Verifieer PIM-interfaces

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

Valideringspunten:

• Controleer of alle gerouteerde multicast-interfaces in de uitvoer worden weergegeven.
• Controleer of RP-Candidate loopbacks PIM-enabled zijn.
• Controleer of de loopbacks van de toewijzende agent PIM-ingeschakeld zijn.
• Controleer of het aantal buren correct is op de doorvoerinterfaces.
• Controleer of de loopback-interfaces het aantal buren = 0 correct weergeven.

Loopback-roltoewijzing:

Apparaat	functie	loopback
N9K-1	RP-kandidaat	10.2.0.1
N9K-1	kaartagent	10.2.1.5
N9K-2	RP-kandidaat	10.2.0.4
N9K-2	kaartagent	10.2.1.4

De loopbacks worden correct weergegeven als actieve PIM-interfaces, ook al vormen ze geen PIM-buren. Dit gedrag wordt verwacht omdat loopback-interfaces niet direct multicast-adjacencies vaststellen.

De aanwezigheid van deze loopbacks bevestigt dat:

• PIM kan Auto-RP-controleberichten op de juiste manier ontvangen.
• RP-advertenties kunnen met succes worden geïnitieerd.
• De functionaliteit van Mapping Agent kan goed werken.

---

Stap 4.3 Analyse tonen ip pim rp

Met deze opdracht wordt gevalideerd:

• RP-detectie
• Auto-RP advertenties
• Mapping Agent-bewerking
• Groep-naar-RP-toewijzingen

N9K-1 — RP-informatie

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)

Line-by-Line-uitleg

BSR uitgeschakeld

BSR disabled

Dit bevestigt het volgende:

• Bootstrap Router (BSR) wordt niet gebruikt.
• Het multicast-domein is uitsluitend gebaseerd op Auto-RP.

Dit gedrag wordt verwacht in deze topologie.

Auto-RP RPA: 10.2.1.5*

Auto-RP RPA: 10.2.1.5*

• 10.2.1.5 komt overeen met loopback1 op N9K-1.
• De * geeft aan dat de lokale switch zelf de actieve toewijzende agent is.

Dit betekent:

• N9K-1 is de bron van RP-Discovery-berichten.
• N9K-1 verzamelt RP-aankondigingen van RP-Kandidaten.
• N9K-1 verspreidt RP-toewijzingsinformatie naar het multicast-domein.

Volgende opsporingsbericht in

next Discovery message in: 00:00:39

• Controleer of de timer voortdurend wordt vernieuwd.
• Controleer of Discovery-berichten periodiek worden verzonden.

Als deze timer vastloopt of onverwacht verloopt, kunnen Auto-RP-advertenties niet correct worden weergegeven.

Beleidsgebieden

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

• Er wordt geen filterbeleid toegepast.
• Alle RP-aankondigingen en Discovery-advertenties worden geaccepteerd.

Eerste RP-vermelding

RP: 10.2.0.1*, (0),

• RP-adres = 10.2.0.1
• De * geeft aan dat deze RP lokaal is voor N9K-1.
• 10.2.0.1 komt overeen met loopback0 op N9K-1.

Dit bevestigt dat N9K-1 is geconfigureerd als een RP-kandidaat.

Uptime en prioriteit

uptime: 22:18:44   priority: 255,

• Stabiele uptime duidt op stabiele RP-advertentiebewerking.
• Prioriteit 255 is de hoogste prioriteit.

RP-bron

RP-source: 10.2.0.1 (A),

• De RP-advertentie is rechtstreeks afkomstig van de RP zelf.
• (A) Geeft Auto-RP aangeleerde informatie aan.

groepsbereik

224.10.20.0/24

• Controleer of het juiste multicast-bereik wordt geadverteerd.
• Controleer of het groepsbereik overeenkomt met de configuratie.

Tweede RP-vermelding

RP: 10.2.0.4, (0),

• Een andere RP bestaat in de topologie.
• 10.2.0.4 komt overeen met loopback0 op N9K-2.
• * wordt weergegeven omdat deze RP is verwijderd van N9K-1.

N9K-2 — RP-informatie

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)

Belangrijkste verschillen op N9K-2

Auto-RP RPA: 10.2.1.5

• Nee * wordt weergegeven omdat N9K-2 niet de Mapping Agent is.
• N9K-2 leert op afstand informatie over Mapping Agent van N9K-1.

Belangrijk verschil in RP

RP-source: 10.2.1.5 (A),

• N9K-2 leert RP-informatie van de Mapping Agent.
• De mapping agent is 10.2.1.5.

Dit bevestigt het volgende:

• De berichten voor automatische RP-detectie werken correct.
• Mapping Agent-advertenties verspreiden zich met succes via het multicast-domein.

Stap 4.4 Auto-RP-verkiezingsproces en RP-selectie valideren

Auto-RP maakt gebruik van twee verschillende multicast control-plane functies:

• RP-kandidaat
• kaartagent

Begrijpen hoe deze functies op elkaar inwerken is van cruciaal belang bij het valideren van multicast-werking in een PIM Sparse Mode-omgeving.

In deze topologie:

• N9K-1 en N9K-2 werken als RP-kandidaten.
• N9K-1 werkt als de actieve Mapping Agent.

RP-Candidate-operatie

Een RP-Candidate adverteert zichzelf als een geldig Rendezvous Point voor een of meer multicast-groepsbereiken.

Elke RP-Kandidaat stuurt periodiek Auto-RP Announce berichten naar:

• 224.0.1.39 — Auto-RP-groep Aankondigen
  
  

Deze aankondigingen bevatten:

• RP-adres
• Groepsbereik
• Prioriteit
• Wachtstandtijd

In deze topologie:

• 10.2.0.1 op N9K-1 adverteert zichzelf als een RP.
• 10.2.0.4 op N9K-2 adverteert zichzelf als een RP.

N9K-1 — Informatie over 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 — Informatie over 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 apparaten adverteren hetzelfde multicast-groepsbereik:

• 224.10.20.0/24

Beide RP-kandidaten gebruiken ook:

• Prioriteit 255

Dit is belangrijk omdat Auto-RP prioriteit en RP-adres gebruikt tijdens RP-selectie.

Active Mapping Agent-identificatie

De Mapping Agent selecteert de actieve RP voor een multicast-groep, te beginnen met deze logica:

1. De hoogste RP-prioriteit wint.
2. Als de prioriteiten gelijk zijn, wint het hoogste RP IP-adres.

In deze topologie:

• N9K-1 RP-adres = 10.2.0.1
• N9K-2 RP-adres = 10.2.0.4
• Beide RP-kandidaten gebruiken prioriteit 255

Omdat beide RP-kandidaten dezelfde prioriteit hebben:

• Het hoogste RP IP-adres wordt het geselecteerde RP.

Daarom:

• 10.2.0.4 wordt de actieve RP voor 224.10.20.0/24.

Geselecteerde RP-validatie

N9K-2 — Geselecteerde 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

Waarom N9K-1 nog steeds beide RP-vermeldingen weergeeft

Op N9K-1:

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

Dit gedrag wordt verwacht omdat:

• N9K-1 werkt als de Mapping Agent.
• De Mapping Agent behoudt de zichtbaarheid van alle RP-kandidaten.
• De uitvoer geeft alle geleerde RP-aankondigingen weer voordat de definitieve RP-selectie wordt verspreid.

Stap 5: Verifieer de bereikbaarheid van RP-kandidaten en mapping agents

Alle multicast-routers die deelnemen aan het domein PIM Sparse Mode moeten een stabiele IP-bereikbaarheid behouden om:

• Alle RP-kandidaten
• Alle mapping agents

Deze validatie is van cruciaal belang omdat PIM Sparse Mode afhankelijk is van unicast-routering naar:

• Bereik het rendez-vous punt (RP)
• Bouw de gedeelde multicaststructuur (RPT)
• Lever PIM-registerberichten van de eerste Hop Router (FHR)
• Ontvang advertenties voor automatische RP-detectie
• Reverse Path Forwarding (RPF)-validatie uitvoeren

Als de bereikbaarheid naar de RP of Mapping Agent mislukt:

• Multicast-bronnen kunnen zich niet succesvol registreren.
• Ontvangers kunnen zich niet aansluiten bij multicast-groepen.
• Auto-RP-advertenties konden niet correct worden verspreid.
• RPF-fouten kunnen optreden.
• Het doorsturen van multicast-verkeer kan onstabiel of intermitterend worden.

---

Stabiele routeringsitems controleren

De routeringstabel moet stabiele unicastroutes bevatten naar:

• Alle RP-loopbacks
• Alle loopbacks van Mapping Agent
• Alle multicast-doorvoerinterfaces

De routes moeten continu geïnstalleerd blijven zonder routeflapperen of buitensporige reconvergentie-gebeurtenissen.

Verifiëren:

• Selectie voor volgende hop corrigeren
• Juiste uitgaande interface
• Stabiele route-uptime
• Verwachte bron routeringsprotocol
• Consistente unicast-bereikbaarheid in het multicast-domein

---

FHR-1 — Route naar RP-kandidaat 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 naar RP-kandidaat 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 naar 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 naar 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 naar RP-kandidaat 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 naar RP-kandidaat 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 naar 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 naar 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 naar RP-kandidaat 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 naar RP-kandidaat 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 naar 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 naar 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

---

Ping-bereikbaarheid controleren via PIM-interfaces

Controleer na het valideren van de routeringstabel de end-to-end IP-bereikbaarheid in de richting van:

• Alle RP-kandidaten
• Alle mapping agents

De ping moet afkomstig zijn van:

• PIM-compatibele interfaces
• Loopback-interfaces die deelnemen aan multicast-routering

Deze validatie is belangrijk omdat multicast-routers deze bronadressen gebruiken tijdens:

• PIM-buurbedrijf
• RPF-berekeningen
• Inkapseling PIM-register
• Auto-RP-communicatie

Overzicht van Ping-validatie

Apparaat	Bron-IP	Bestemming	functie	resultaat
FHR-1	10.4.0.5	10.2.0.1	RP-kandidaat	Geslaagd
FHR-1	10.4.0.5	10.2.0.4	RP-kandidaat	Geslaagd
FHR-1	10.4.0.5	10.2.1.5	kaartagent	Geslaagd
FHR-1	10.4.0.5	10.2.1.4	kaartagent	Geslaagd
FHR-2	10.4.0.9	10.2.0.1	RP-kandidaat	Geslaagd
FHR-2	10.4.0.9	10.2.0.4	RP-kandidaat	Geslaagd
FHR-2	10.4.0.9	10.2.1.5	kaartagent	Geslaagd
FHR-2	10.4.0.9	10.2.1.4	kaartagent	Geslaagd
LHR	10.4.0.5	10.2.0.1	RP-kandidaat	Geslaagd
LHR	10.4.0.5	10.2.0.4	RP-kandidaat	Geslaagd
LHR	10.4.0.5	10.2.1.5	kaartagent	Geslaagd
LHR	10.4.0.5	10.2.1.4	kaartagent	Geslaagd

Verifieer de operationele status en de multicast-doorgifte van verkeer op de FHR en LHR

De volgende validatiestap is om na te gaan of:

• De FHR en LHR leerden de verwachte RP met succes.
• De multicast-routeringstabel bevat de verwachte multicast-toestanden.
• Het multicast-besturingsvlak werkt correct voordat de multicast-verkeerstransmissie begint.
• In de spaarmodus van PIM wordt de verwachte gedeelde boomstatus gemaakt.

---

Stap 1 Verifieer RP Learning op de FHR en LHR

Controleer voordat u de status voor het doorsturen van multicast valideert of alle multicast-routers de verwachte RP hebben geleerd voor de multicast-groep die wordt gevalideerd.

Deze stap is van cruciaal belang omdat:

• De FHR moet weten waar PIM Register-berichten naartoe moeten worden gestuurd.
• De LHR moet weten welke RP moet worden gebruikt bij het bouwen van de gedeelde boom.
• Het multicast-domein moet een consistente RP-toewijzing behouden.

In deze topologie:

• De gekozen RP is 10.2.0.4.
• De mapping agent is 10.2.1.5.
• Het multicast-groepsbereik is 224.10.20.0/24.

---

FHR-1 — Verifieer aangeleerde 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 — Verifieer aangeleerde 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 — Verifieer aangeleerde RP

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-leeranalyse

De resultaten bevestigen dat:

• Alle multicast-routers leerden consistent dezelfde RP.
• De gekozen RP is 10.2.0.4.
• De RP-mapping werd geleerd door middel van Auto-RP.
• De Mapping Agent die de RP-informatie verspreidt, is 10.2.1.5.
• De RP-mapping blijft langer dan één dag stabiel.
• De vervaltijden voor Discovery worden correct vernieuwd.

Dit gedrag wordt verwacht omdat:

• 10.2.0.4 werd geselecteerd als de actieve RP tijdens het Auto-RP-selectieproces.
• 10.2.1.5 werkt als de Mapping Agent.
• Alle multicast-routers ontvangen met succes advertenties voor automatische RP-detectie.

In dit stadium werkt het multicast-besturingsvlak correct en hebben alle routers een consistente RP-toewijzing voor 224.10.20.0/24

---

Stap 2 Controleer de status van de multicast-routering voordat actief multicast-verkeer plaatsvindt

De volgende stap is het valideren van de multicast-routeringstabel voordat multicast-verkeerstransmissie begint.

In dit scenario:

• De multicast-ontvanger is al lid geworden van de multicast-groep.
• Er stroomt nog geen actief multicast-bronverkeer.

Deze status is belangrijk omdat het valideert:

• IGMP-lidmaatschapsoperatie
• Creatie van gedeelde PIM-structuur
• Begintoestand (*,G) multicast
• propagatie van de ontvangerrente

FHR-1 — Multicast Routing Table

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 Table

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-toestandsanalyse

De FHR’s bevatten nog niet:

• (*, G) staat voor 224.10.20.10
• (S, G) staat voor de multicast-bron

Dit gedrag wordt verwacht omdat:

• Er is nog geen multicast-bronverkeer actief.
• Er zijn geen PIM Register-berichten gegenereerd.
• De FHR is niet begonnen met het doorsturen van multicast.

De enige multicast-ingang die aanwezig is, is:

• 232.0.0.0/8

Dit komt overeen met het standaard SSM-bereik en wordt automatisch door het systeem geïnstalleerd.

Deze waarden worden verwacht:

• Inkomende interface: Null
• RPF-buur: 0.0.0.0
• Aantal uitgaande interfaces: 0

Dit item geeft geen actieve multicast-doorgifte aan.

---

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-toestandsanalyse

In tegenstelling tot de FHR's bevat de LHR een actieve (*,G) vermelding voor:

• 224.10.20.10

Dit gedrag wordt verwacht omdat:

• De multicast-ontvanger heeft zich al bij de groep aangesloten.
• IGMP-lidmaatschapsinformatie werd geleerd op Vlan2.
• De LHR initieerde de gedeelde-boomverbinding naar de RP.

De multicast-routeringstabel bevestigt:

• De Incoming Interface (IIF) is Ethernet1/50.
• De RPF-buur is 10.4.0.26.
• De Outgoing Interface List (OIL) bevat Vlan2.

Dit wijst erop dat:

• De LHR heeft de gedeelde boom correct gebouwd in de richting van de RP.
• De multicast-ontvanger verspreidde zich met succes stroomopwaarts.
• PIM Join-berichten zijn correct verzonden.

In deze fase:

• Er is nog geen multicast-bronverkeer actief.
• Er bestaat nog geen (S, G) staat.
• Alleen de status van de gedeelde structuur bestaat.

---

N9K-1 — Mapping Agent Multicast Routing Table

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)

Multicast-toestandsanalyse van Mapping Agent

N9K-1 werkt alleen als de Mapping Agent en neemt niet deel aan multicast-forwarding voor 224.10.20.10

Daarom wordt verwacht dat (* ,G) vermeldingen en (S, G) vermeldingen ontbreken.

De Mapping Agent verspreidt alleen RP-toewijzingsinformatie en neemt niet noodzakelijkerwijs deel aan multicast-gegevensdoorgifte, tenzij multicast-verkeer het apparaat rechtstreeks doorkruist.

---

N9K-2 — RP Multicast Routing Table

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 State Analysis

N9K-2 werkt als de actieve RP voor:

• 224.10.20.0/24

Daarom bevat de RP de gedeelde-boomstatus (*,G) voor 224.10.20.10

Deze waarden worden verwacht:

• Inkomende interface = loopback0
• RPF-buur = 10,2,0,4
• Uitgaande interface = Ethernet1/49

Dit wijst erop dat:

• De RP installeerde de gedeelde-boomstatus met succes.
• De RP ontving PIM Join-berichten van downstream routers.
• De gedeelde multicast-boom naar ontvangers is correct gebouwd.

In deze fase:

• De RP bevat alleen de status shared-tree.
• Er is nog geen multicast-bronverkeer actief.
• Er bestaan nog geen (S, G) vermeldingen.

---

Stap 3 Controleer de status van de multicast-routering met actief multicast-verkeer

Zodra multicast-verkeerstransmissie begint, gaat de multicast-routeringstabel over van gedeelde boomstatus naar actieve bronspecifieke doorstuurstatus.

In dit scenario:

• De multicast-bron is 10.150.1.37.
• De multicast-groep is 224.10.20.10.
• De actieve RP is 10.2.0.4 op N9K-2.
• De multicast-bron maakt verbinding via vPC-poortkanaal 78.

---

Belangrijke overwegingen voor vPC Multicast

De multicast-bron maakt verbinding via een vPC-domein dat wordt gevormd door FHR-1 en FHR-2.

Omdat de bron verbinding maakt via een vPC-ledenpoortkanaal:

• Verkeershashing kan multicastpakketten doorsturen naar een van beide Nexus-switches.
• Beide FHR's vereisen een identieke multicast-configuratie.
• Beide FHR's vereisen consistente unicast-routeringsinformatie.
• Beide FHR's moeten identieke RP-mappings behouden.
• Beide FHR's moeten stabiele PIM-nabijheid behouden.

In dit specifieke scenario:

• De multicast-stroom hashes naar FHR-2.
• FHR-2 wordt de actieve forwarding FHR voor de multicast-bron.

FHR-1 — Multicast Routing Table

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-rol

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-toestandsanalyse

FHR-1 bevat een actieve (S, G) vermelding voor:

• Bron = 10 150 1 37
• Groep = 224 10 20 10

De vermelding voor multicast-routering bevestigt:

• De bron werd geleerd op Vlan1.
• De RPF-buur is de direct aangesloten multicast-bron.
• Er bestaan geen uitgaande interfaces in de OIL.

Dit gedrag wordt verwacht omdat de multicast flow niet hash richting FHR-1 voor uitgaande doorsturen.

Als gevolg hiervan:

• FHR-1 installeert alleen lokale bronstatus.
• FHR-1 stuurt geen multicast-verkeer stroomopwaarts door via PIM.

FHR-2 — Multicast Routing Table

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-rol

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-toestandsanalyse

In tegenstelling tot FHR-1 bevat FHR-2:

• Een actieve lijst met uitgaande interfaces
• Een actief PIM-doorstuurpad

Dit wijst erop dat:

• FHR-2 werd de operationele forwarding FHR voor de multicast flow.
• De multicast-pakketten hashten naar FHR-2 via het vPC-ledenpoortkanaal.
• FHR-2 vatte het multicast-verkeer samen in PIM Register-berichten.
• FHR-2 stuurde multicast-verkeer stroomopwaarts naar de RP.

ECMP- en Multicast-doorstuurgedrag

De uitgaande interface Ethernet1/3 komt overeen met de unicast-routeringstabel naar de ontvanger 192.168.2.37

FHR-2 — Route naar Multicast-ontvanger

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 bevat twee routes met gelijke kosten naar het multicast-ontvangersubnet:

• 10.4.0.13 via Ethernet1/3
• 10.4.0.18 via Ethernet1/4

Dit bevestigt het volgende:

• ECMP-routering is actief in de multicast-transporttopologie.
• Er bestaan meerdere geldige unicast-doorstuurpaden naar het ontvangernetwerk.
• PIM kan het door de MRIB geselecteerde RPF-pad gebruiken voor beslissingen over het doorsturen van multicast.
• Pakketduplicatie over parallelle ECMP-paden vindt niet plaats.

Hoewel er twee routes met gelijke kosten bestaan, maakt multicast-forwarding gebruik van één RPF-pad voor elke multicast-stroom.

In deze topologie gebruikt de multicast flow:

• Ethernet1/3 naar 10.4.0.13

Dit gedrag komt overeen met de multicast-routeringstabel die eerder werd waargenomen:

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

---

vPC operationeel primair en secundair gedrag

De operationele vPC-rollen beïnvloeden het doorstuurgedrag van multicast op verschillende manieren voor:

• PIM-verkeer
• IGMP-verwerking

In deze topologie:

• FHR-1 is de primaire operationele vPC.
• FHR-2 is de operationele vPC secundair.

Beide Nexus-switches kunnen:

• Process PIM control-plane traffic
• Multicast-routeringsstatus bouwen
• Voorwaarts multicastverkeer via PIM

Echter:

• Alleen de operationele primaire vPC verwerkt IGMP-ontvangstverkeer naar de toegangslaag.

Dit onderscheid is belangrijk omdat:

• PIM-doorsturen naar het gerouteerde netwerk blijft actief op beide peers.
• IGMP-forwarding naar Layer 2-ontvangersegmenten blijft gecentraliseerd op de operationele primaire.

Daarom:

• Multicastverkeer van de bron naar het gerouteerde multicastdomein kan via een vPC-peer worden afgesloten.
• Multicast-verkeer naar IGMP-ontvangers is afhankelijk van het primaire operationele gedrag.

---

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-toestandsanalyse

De LHR bevat nu beide:

• (* ,G) shared-tree status
• (S, G) source-tree staat

Dit bevestigt:

• De multicast-ontvanger heeft zich met succes aangesloten.
• De multicast-bron werd actief.
• De LHR is overgegaan van shared-tree forwarding naar source-tree forwarding.

De vermelding (S, G) bevestigt:

• Het multicast-bronpad is met succes aangeleerd.
• De RPF-buur is 10.4.0.22.
• Het multicast-verkeer komt via Ethernet1/49.
• Het multicast-verkeer wordt doorgestuurd naar Vlan2-ontvangers.

Dit gedrag bevestigt succes:

• PIM-doorsturen
• RPF-validatie
• Bronboomconstructie
• Multicast-verkeerslevering

---

N9K-1 — Transit Multicast Routing Table

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-doorvoertoestandsanalyse

N9K-1 werkt als een transit multicast-router voor de actieve multicast-stroom.

De vermelding voor multicast-routering bevestigt:

• Het multicast-verkeer komt van Ethernet1/4.
• Het multicast-verkeer wordt doorgestuurd naar Ethernet1/49.
• Het multicast-doorstuurpad naar de LHR is operationeel.

Dit bevestigt het succes:

• PIM-buuroperatie
• RPF-validatie
• Multicast-forwarding via het doorvoernetwerk

---

N9K-2 — RP Multicast Routing Table

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 State Analysis

N9K-2 werkt als de actieve RP voor de multicast-groep.

De RP bevat beide:

• (* ,G) shared-tree status
• (S, G) source-tree staat

De afwezigheid van uitgaande interfaces in de (S, G)-vermelding wordt verwacht omdat:

• De RP schakelde al ontvangers in de richting van de kortste pad boom.
• Het gedeelde boomdoorstuurpad is niet langer vereist voor actieve multicast-doorgifte.

Minimale multicast-informatie vereist voor RCA en gezondheidsdiagnostiek

De lijst met opdrachten bevat de minimaal aanbevolen multicast-gegevensverzameling die vereist is voor het uitvoeren van een goede Root Cause Analysis (RCA)- of multicast-diagnose op Cisco Nexus 9000 Series-switches met NX-OS. Deze uitgangen registreren de status van het multicast-controlevlak, de MRIB-programmering, het doorsturen van informatie, de operationele status van vPC en details over het doorsturen van hardware. Er kan echter nog aanvullende informatie nodig zijn, afhankelijk van het storingsscenario. Bijvoorbeeld, multicast-pakketverlies, intermitterende verkeersdalingen, problemen met pakketreplicatie, inconsistenties in het doorsturen van hardware of out-of-order multicast-doorsturen vereisen vaak directe pakketopnames op de Nexus-switch met behulp van Ethanalyzer, SPAN of vastleggingen op hardwareniveau. Evenzo kunnen voorbijgaande RPF-inconsistenties, ECMP-doorstuurwijzigingen, ASIC-programmeringsfouten of IGMP-suppressiegebeurtenissen optreden zonder aanhoudende loggeneratie.

Als gevolg hiervan verbetert de combinatie van showtech-outputs met pakketopnames en forwarding-validatie de diagnostische nauwkeurigheid en RCA-kwaliteit aanzienlijk. Hoewel deze informatie een sterke operationele basis biedt voor het oplossen van problemen met multicast, garandeert deze niet dat een RCA altijd uitsluitend op basis van deze outputs kan worden geïdentificeerd. Bepaalde multicast-fouten vereisen extra probleemoplossing, analyse van live verkeer, validatie op hardwareniveau, topologiecorrelatie of uitgebreide pakketopnames om de exacte hoofdoorzaak te isoleren.

Opdrachten voor minimale verzameling van multicast-gegevens

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

Een TAR-archief voor export maken

Nadat u de technische showbestanden hebt gegenereerd, consolideert u deze in één TAR-archief voor export en analyse. Het commando bestaat uit één regel.

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

Het exporteren van één TAR-archief vereenvoudigt:

• Uploads TAC-geval
• RCA-workflows
• Gecentraliseerde loganalyse
• Multicast-forwardingcorrelatie
• Historisch falen behoud

Revisiegeschiedenis

Revisie	Publicatiedatum	Opmerkingen
1.0	13-May-2026	Eerste vrijgave