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.
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.
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 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)
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.
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.
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.
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.
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).
Regel B: Hoogste IP-adres (tie-breaker)
Als twee of meer kandidaten exact hetzelfde groepsbereik aankondigen, moet de Mapping Agent er slechts één kiezen.
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.
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.
Let op: PIM-buren worden niet ondersteund via een vPC-poortkanaal.
multicast-verkeersstroom
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. |
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. |
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
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)
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
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
Tip: Voordat u Auto-RP, PIM-aangrenzende gebieden of RP-selectie analyseert, moet u er altijd voor zorgen dat het onderliggende routeringsdomein stabiel, consistent en volledig bereikbaar is.
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)
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
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
Let op: het oplossen van problemen met multicast zonder een duidelijke topologie is gelijk aan foutopsporing zonder zichtbaarheid - het leidt tot onjuiste aannames en verkeerde diagnoses.
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.
N9K-1 en N9K-2 zijn geconfigureerd als RP-kandidaten en Mapping Agents binnen het multicast-domein.
Let op: elke ontbrekende of inconsistente Auto-RP-configuratie kan voorkomen dat routers de RP leren, waardoor multicast-verkeer niet correct wordt doorgestuurd.
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
In deze topologie:
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:
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:
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:
Met deze opdracht wordt gevalideerd:
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:
Dit gedrag wordt verwacht in deze topologie.
Auto-RP RPA: 10.2.1.5*
Auto-RP RPA: 10.2.1.5*
Dit betekent:
Volgende opsporingsbericht in
next Discovery message in: 00:00:39
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
Eerste RP-vermelding
RP: 10.2.0.1*, (0),
Dit bevestigt dat N9K-1 is geconfigureerd als een RP-kandidaat.
Uptime en prioriteit
uptime: 22:18:44 priority: 255,
RP-bron
RP-source: 10.2.0.1 (A),
groepsbereik
224.10.20.0/24
Tweede RP-vermelding
RP: 10.2.0.4, (0),
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
Belangrijk verschil in RP
RP-source: 10.2.1.5 (A),
Dit bevestigt het volgende:
Auto-RP maakt gebruik van twee verschillende multicast control-plane functies:
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:
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:
Deze aankondigingen bevatten:
In deze topologie:
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:
Beide RP-kandidaten gebruiken ook:
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:
In deze topologie:
Omdat beide RP-kandidaten dezelfde prioriteit hebben:
Daarom:
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:
Let op: op de Mapping Agent moeten alle RP-Kandidaten binnen hetzelfde multicast-domein verschijnen. Als een RP-Candidate ontbreekt, controleer dan de bereikbaarheid door een ping te sturen naar het RP-Candidate IP-adres dat afkomstig is van het IP-adres van de Mapping Agent, meestal een loopback-interface.
Alle multicast-routers die deelnemen aan het domein PIM Sparse Mode moeten een stabiele IP-bereikbaarheid behouden om:
Deze validatie is van cruciaal belang omdat PIM Sparse Mode afhankelijk is van unicast-routering naar:
Als de bereikbaarheid naar de RP of Mapping Agent mislukt:
De routeringstabel moet stabiele unicastroutes bevatten naar:
De routes moeten continu geïnstalleerd blijven zonder routeflapperen of buitensporige reconvergentie-gebeurtenissen.
Verifiëren:
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
Controleer na het valideren van de routeringstabel de end-to-end IP-bereikbaarheid in de richting van:
De ping moet afkomstig zijn van:
Deze validatie is belangrijk omdat multicast-routers deze bronadressen gebruiken tijdens:
Tip: Als niet-genummerde interfaces worden gebruikt, waarbij meerdere Layer 3-interfaces hetzelfde IP-adres delen vanuit een loopback-interface, wordt de verificatie van de bereikbaarheid eenvoudiger omdat een enkel bron-IP-adres consistent kan worden gebruikt.
| 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 |
De volgende validatiestap is om na te gaan of:
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:
In deze topologie:
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:
Dit gedrag wordt verwacht omdat:
In dit stadium werkt het multicast-besturingsvlak correct en hebben alle routers een consistente RP-toewijzing voor 224.10.20.0/24
De volgende stap is het valideren van de multicast-routeringstabel voordat multicast-verkeerstransmissie begint.
In dit scenario:
Deze status is belangrijk omdat het valideert:
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:
Dit gedrag wordt verwacht omdat:
De enige multicast-ingang die aanwezig is, is:
Dit komt overeen met het standaard SSM-bereik en wordt automatisch door het systeem geïnstalleerd.
Deze waarden worden verwacht:
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:
Dit gedrag wordt verwacht omdat:
De multicast-routeringstabel bevestigt:
Dit wijst erop dat:
In deze fase:
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:
Daarom bevat de RP de gedeelde-boomstatus (*,G) voor 224.10.20.10
Deze waarden worden verwacht:
Dit wijst erop dat:
In deze fase:
Zodra multicast-verkeerstransmissie begint, gaat de multicast-routeringstabel over van gedeelde boomstatus naar actieve bronspecifieke doorstuurstatus.
In dit scenario:
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:
In dit specifieke scenario:
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:
De vermelding voor multicast-routering bevestigt:
Dit gedrag wordt verwacht omdat de multicast flow niet hash richting FHR-1 voor uitgaande doorsturen.
Als gevolg hiervan:
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:
Dit wijst erop dat:
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:
Dit bevestigt het volgende:
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:
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
De operationele vPC-rollen beïnvloeden het doorstuurgedrag van multicast op verschillende manieren voor:
In deze topologie:
Beide Nexus-switches kunnen:
Echter:
Dit onderscheid is belangrijk omdat:
Daarom:
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)
De LHR bevat nu beide:
Dit bevestigt:
De vermelding (S, G) bevestigt:
Dit gedrag bevestigt succes:
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:
Dit bevestigt het succes:
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)
N9K-2 werkt als de actieve RP voor de multicast-groep.
De RP bevat beide:
De afwezigheid van uitgaande interfaces in de (S, G)-vermelding wordt verwacht omdat:
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.
Tip: Het verzamelen van deze informatie tijdens het werken en niet-werken geeft een duidelijk beeld van hoe het probleem zich voordoet vanuit het Nexus-perspectief en verbetert de mogelijkheid om de oorzaak te identificeren aanzienlijk.
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
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:
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
1.0 |
13-May-2026
|
Eerste vrijgave |