In questo documento viene descritto il funzionamento di Auto-RP su Cisco Nexus 9000 con NX-OS e viene spiegato come convalidare e risolvere i problemi relativi al funzionamento del multicast.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Il multicast è un modello di comunicazione uno-a-molti in cui una sorgente invia un singolo flusso di traffico a più ricevitori interessati. Anziché creare una copia separata per ogni destinazione, la rete replica il traffico solo nel punto in cui il percorso di inoltro si suddivide. Ciò rende il multicast più efficiente delle trasmissioni broadcast o ripetute. In IPv4, il traffico multicast utilizza gli indirizzi di destinazione dell'intervallo 224.0.0.0/4.
PIM Sparse Mode è il modello di routing multicast supportato sugli switch Cisco Nexus con NX-OS. Inoltra il traffico solo quando l'interesse del destinatario è stato esplicitamente appreso. In un progetto di multicast Any-Source, i ricevitori inizialmente si uniscono a una struttura condivisa verso il punto di rendering e le fonti si registrano con quel punto di ripristino. Dopo l'inizio del flusso del traffico, il router dell'ultimo hop può spostarsi dalla struttura condivisa al percorso più breve verso l'origine.
È importante definire la terminologia utilizzata nel multicast perché una risoluzione accurata dei problemi dipende dalla comprensione del modo in cui vengono rappresentati gli eventi del control plane, le voci di routing e le decisioni di inoltro. Una terminologia chiara consente di interpretare correttamente l'output dei comandi, distinguere tra il comportamento dell'albero condiviso e dell'albero di origine e identificare il ruolo di ogni componente multicast nel processo di inoltro end-to-end.
| Termine | Definizione |
|---|---|
| Indirizzo gruppo multicast | Indirizzo di destinazione IPv4 nell'intervallo 224.0.0.0/4 utilizzato per identificare un gruppo multicast. |
| Source address | Indirizzo IP unicast del mittente che trasmette il traffico a un gruppo multicast. |
| mroute | Voce di routing multicast che definisce la modalità di gestione del traffico multicast per un gruppo o una combinazione di gruppo di origine. |
| IIF | Interfaccia in ingresso. Interfaccia su cui è previsto l'arrivo del traffico multicast. |
| OIF | Interfaccia in uscita. Interfaccia utilizzata per inoltrare il traffico multicast verso i ricevitori o i vicini a valle. |
| PETROLIO | Elenco interfacce in uscita. Set di interfacce in uscita associate a una voce di routing multicast. |
| RPF | Inoltro percorso inverso. Controllo che verifica se il traffico multicast è arrivato sull'interfaccia corretta in base alla route unicast verso l'origine o l'RP. |
| MDT | Albero di distribuzione multicast. Struttura logica che trasporta il traffico multicast dall'origine a tutti i destinatari. |
| RPT | Struttura RP, denominata anche struttura condivisa. Collega i ricevitori all'RP ed è rappresentato da (*,G). |
| SPT | Albero del percorso più breve, detto anche albero di origine. Collega i ricevitori direttamente all'origine ed è rappresentato da (S,G). |
| FHR | Router del primo hop. Il router multicast è collegato direttamente all'origine e responsabile della registrazione dell'origine con l'RP. |
| LHR | Last-Hop Router. Il router multicast è collegato direttamente ai ricevitori ed è responsabile della creazione dello stato multicast dopo aver appreso l'interesse del ricevitore tramite IGMP. |
| RP | Punto finale. Punto di incontro logico utilizzato in ASM e in modalità sparse PIM per connettere inizialmente le origini e i ricevitori. |
| ASM | Multicast Any-Source. Modello multicast in cui i ricevitori si uniscono a un gruppo senza specificare in anticipo l'origine. |
È importante comprendere gli indirizzi multicast riservati conosciuti, in quanto la risoluzione dei problemi relativi al multicast dipende dall'identificazione rapida del protocollo di controllo che utilizza un determinato gruppo di destinazione e della funzione che il traffico serve nella rete. Questi indirizzi aiutano a distinguere il normale funzionamento del protocollo dal comportamento anormale e rendono più facile convalidare gli scambi IGMP, PIM e Auto-RP. In particolare, per Auto-RP, i gruppi più importanti da riconoscere sono 224.0.1.39 per RP-Annuncio e 224.0.1.40 per RP-Discovery, in quanto contengono le informazioni che consentono ai router di apprendere le mappature RP dinamiche.
| Indirizzo multicast | Scopo |
|---|---|
| 224.0.0.1 | Tutti gli host nella subnet locale |
| 224.0.0.2 | Tutti i router nella subnet locale |
| 224.0.0.13 | Tutti i router PIM |
| 224.0.0.22 | Messaggi IGMPv3 |
| 224.0.1.39 | Messaggi di annuncio RP Cisco utilizzati da Auto-RP |
| 224.0.1.40 | Messaggi Cisco RP-Discovery utilizzati da Auto-RP |
Auto-RP è un meccanismo Cisco utilizzato in modalità di sparsità multicast indipendente dal protocollo per individuare e distribuire dinamicamente le informazioni di Rendezvous Point (RP) nel dominio multicast. Elimina la necessità di una configurazione RP statica utilizzando messaggi del piano di controllo basati su multicast per annunciare, selezionare e apprendere le mappature RP-a-gruppo. I suoi componenti principali sono RP candidati, che offrono servizi RP per intervalli di gruppi specifici, e Agenti mapping, che raccolgono i candidati e decidono l'RP attivo per gruppo.
Il processo ha inizio quando ogni RP candidato invia periodicamente messaggi RP-Annuncio a 224.0.1.39, inclusi i relativi intervalli di indirizzi IP, priorità e gruppi multicast supportati. Questi messaggi vengono trasmessi in tutta la rete utilizzando il listener Auto-RP in NX-OS, garantendo che tutti gli agenti di mapping li ricevano anche prima che la rete sia completamente operativa in modalità sparse.
Gli agenti di mapping ascoltano questi annunci, creano un database RP candidato ed eseguono un processo di selezione deterministica per gruppo (in genere la priorità più alta, quindi l'indirizzo IP più alto). Una volta scelto il miglior RP, l'agente di mapping genera messaggi RP-Discovery e li invia a 24.0.1.40, annunciando i mapping RP-a-gruppo finali a tutti i router del dominio.
Tutti i router PIM ricevono i messaggi RP-Discovery e installano i mapping nelle rispettive tabelle RP locali. Con queste informazioni, i router dell'ultimo hop (connessi ai ricevitori) inviano messaggi di join PIM verso l'RP selezionato per creare l'albero condiviso (RPT), mentre i router del primo hop (connessi alle origini) incapsulano il traffico multicast nei messaggi PIM Register per informare l'RP sulle origini attive.
Quando il traffico attraversa l'RP, i router possono facoltativamente passare dalla struttura ad albero condivisa (RPT) a una struttura ad albero a percorso più breve (SPT) utilizzando ulteriori segnali di unione/eliminazione PIM diretti alla sorgente. Durante questo processo, Auto-RP aggiorna continuamente le mappature tramite messaggi di controllo periodici, garantendo resilienza e adattamento automatico alla topologia o alle modifiche RP.
Operazione Auto-RP in modalità sparsa PIM (flusso di lavoro del piano di controllo)
L'inoltro a percorsi multipli basato su ECMP è abilitato per impostazione predefinita, consentendo al traffico multicast di utilizzare percorsi pari costo per il bilanciamento del carico.
È supportata l'autenticazione dei router adiacenti PIM con IPsec AH-MD5.
Lo snooping PIM non è disponibile.
Auto-RP consente il rilevamento dinamico dell'RP e la distribuzione centralizzata del mapping RP per gli ambienti multicast PIM Sparse Mode. Elimina la necessità di una configurazione RP statica su ogni router multicast, riduce la complessità operativa e migliora la scalabilità multicast. Auto-RP supporta inoltre più candidati RP, consentendo il failover e la ridondanza RP automatici. Questo meccanismo contribuisce a mantenere un comportamento coerente di inoltro multicast, semplifica l'espansione della rete e consente ai router multicast di apprendere automaticamente le informazioni RP nel dominio.
Il processo di selezione in Auto-RP è deterministico e basato principalmente sugli indirizzi IP. A differenza di altri protocolli (ad esempio PIMv2 BSR), Auto-RP non utilizza un valore di "priorità" configurabile; per la risoluzione dei conflitti si basa invece sulla gerarchia degli indirizzi IP.
In Auto-RP, più agenti di mapping possono coesistere all'interno della stessa rete per la ridondanza. Non c'è un processo elettorale formale dove uno si spegne e un altro si accende; tutte sono tecnicamente attive. Tuttavia, gli switch della rete devono decidere quali informazioni considerare attendibili.
Questo processo viene eseguito dall'agente di mapping dopo aver ascoltato tutti i messaggi RP-Annuncio (inviati al gruppo 24.0.1.39) dai candidati.
Quando l'agente mapping riceve più candidati per lo stesso gruppo multicast, applica queste regole nell'ordine indicato di seguito:
Regola A: Corrispondenza Prefisso Più Lunga (Maschera Più Specifica)
Se i candidati annunciano intervalli sovrapposti, l'MA assegna il gruppo all'RP che annuncia l'intervallo più piccolo (la subnet mask più lunga).
Regola B: Indirizzo IP più alto (interrompi tempo)
Se due o più candidati annunciano esattamente lo stesso intervallo di gruppi, l'agente di mapping deve sceglierne solo uno.
Sebbene l'obiettivo di questo articolo sia il multicast di layer 3 che utilizza PIM, il comportamento di layer 2 svolge un ruolo critico nella risoluzione dei problemi e nella progettazione complessiva. Al layer 2, i dispositivi comunicano utilizzando indirizzi MAC, che sono identificatori a 48 bit assegnati alle interfacce di rete, e il traffico multicast richiede uno schema di indirizzamento MAC specifico per differenziarlo dal traffico unicast e broadcast.
Gli indirizzi MAC multicast IPv4 derivano dagli indirizzi di gruppi multicast di layer 3 utilizzando il prefisso riservato `01:00:5E`. Tuttavia, solo 23 bit dell'indirizzo multicast IP vengono mappati nell'indirizzo MAC, creando una sovrapposizione 32:1, il che significa che fino a 32 gruppi IP multicast diversi possono mappare allo stesso indirizzo MAC. Di conseguenza, gli host che ascoltano un determinato indirizzo MAC multicast possono ricevere traffico per più gruppi multicast, anche se sono interessati a uno solo. Ad esempio, 224.1.1.1, 225.1.1.1, 226.1.1.1, 227.1.1.1, 228.1.1.1 e altri.
Questa sovrapposizione ha implicazioni dirette sull'efficienza della rete e sulla risoluzione dei problemi. Poiché le decisioni di inoltro di layer 2 basate esclusivamente su indirizzi MAC non possono distinguere tra gruppi multicast sovrapposti, gli switch possono inviare traffico non necessario agli host. Questi host devono quindi fare affidamento su un filtro di livello superiore (IP/IGMP) per eliminare i pacchetti indesiderati, consumando le risorse della CPU e del buffer.
In Cisco Nexus NX-OS, questa limitazione è mitigata dal comportamento dello snooping IGMP. Per impostazione predefinita, lo snooping IGMP esegue ricerche basate su IP anziché l'inoltro solo MAC, consentendo agli switch di prendere decisioni di inoltro più precise anche quando più gruppi multicast condividono lo stesso indirizzo MAC. Ciò migliora in modo significativo l'efficienza del layer 2 e riduce l'erogazione di traffico non necessario.
Questa sezione fornisce una spiegazione dettagliata della configurazione Auto-RP, utilizzando una semplice implementazione come riferimento. In questa configurazione, una sorgente multicast è collegata a due switch Nexus tramite vPC per consegnare il traffico a un ricevitore. In questo progetto, sia N9K-1 che N9K-2 funzionano contemporaneamente come candidati RP e agenti di mapping.
Attenzione: I vicini PIM non sono supportati su un canale porta vPC.
Flusso del traffico multicast
La stessa configurazione ha 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
| Comando | Scopo/Descrizione |
|---|---|
| feature pim | Abilita il processo PIM (Protocol Independent Multicast) sullo switch. |
| ascolto ip pim auto-rp forward | Abilita il listener Auto-RP. Questo consente allo switch di ricevere e inoltrare messaggi di controllo Auto-RP (224.0.1.39 e 224.0.1.40) anche se non conosce ancora l'identità dell'RP. |
| ip pim modalità sparse | Abilita la modalità sparse PIM su un'interfaccia specifica. In questa modalità, il traffico multicast viene inoltrato solo ai segmenti che lo hanno esplicitamente richiesto tramite messaggi di join PIM. |
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
Questa tabella fornisce una descrizione dettagliata della configurazione PIM per N9K-1. Questa configurazione viene replicata su N9K-2. Entrambi gli switch sono configurati con un doppio ruolo, che agisce sia come candidato RP che come agente mapping per il dominio multicast.
| Comando | Spiegazione tecnica dettagliata |
|---|---|
| feature pim | Attivazione funzionalità: Abilita globalmente il motore PIM (Protocol Independent Multicast) sullo switch Nexus. |
| ip pim auto-rp rp-candidate loopback0 group-list 224.10.20.0/24 intervallo 15 | Ruolo candidato RP: Configura questo switch come "volontario" come Rendezvous Point (RP). Fonte: Utilizza l'indirizzo IP di loopback0 Ambito: e offre di gestire la gamma di gruppi multicast 224.10.20.0/24. Intervallo Invia messaggi di "annuncio" all'agente di mapping ogni 15 secondi. Il timer di attesa è tre volte questo valore. |
| ip pim auto-rp mapping-agent loopback1 | Ruolo agente mapping: Configura lo switch come "amministratore" del processo Auto-RP. Funzione: Ascolta tutti i candidati RP, risolve i conflitti (utilizzando l'indirizzo IP più alto come tie-breaker) e trasmette i messaggi "Discovery" al resto della rete per informarli su chi sia il RP attivo. |
| interfaccia loopback0 / loopback1 | Interfacce logiche: PIM è abilitato su queste interfacce perché fungono da IP di origine per i ruoli Candidato RP e Agente mapping. Devono essere raggiungibili tramite la tabella di routing unicast da tutti i router PIM. |
| interfaccia Ethernet1/3, 1/4, 1/49 | Inoltro fisico: Abilita la modalità sparse PIM sulle porte fisiche. In questo modo, lo switch può formare adiacenze di router adiacenti PIM con altri router e inoltrare il traffico multicast attraverso questi collegamenti specifici. |
| ip pim modalità sparse | Modalità operativa: Applicato a tutte le interfacce indicate sopra. Assicura che il traffico multicast venga inviato solo ai ricevitori che ne hanno fatto esplicita richiesta tramite messaggi di unione PIM, evitando inutili allagamenti della rete. |
Router adiacenti PIM e area OSPF 0
N9K-1 — Configurazione OSPF
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 - Configurazione OSPF
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 — Configurazione OSPF
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
Prima di analizzare il comportamento multicast, è fondamentale verificare che la struttura unicast sottostante (area OSPF 0) sia completamente operativa. I protocolli del control plane multicast, ad esempio PIM e Auto-RP, dipendono dalla raggiungibilità unicast per funzionare correttamente.
Il primo passaggio di convalida consiste nel verificare che l'origine e il ricevitore (o i gateway di layer 3 più vicini): FHR e LHR) sono raggiungibili.
Dalla topologia:
FHR-1 / FHR-2 → La sorgente più vicina al multicast (10.150.1.37 - VLAN 1)
LHR → Il più vicino al ricevitore multicast (192.168.2.37 - VLAN 2)
1. Eseguire i test di raggiungibilità ICMP tra:
FHR †LHR
FHR→ Subnet ricevitore (VLAN 2 gateway)
LHR→ Subnet di origine (VLAN 1 gateway)
2. Verificare la raggiungibilità dell'origine e del destinatario nella tabella di routing. Per le installazioni vPC, garantire la coerenza tra entrambi i peer Nexus. Il ricevitore ha un percorso ECMP, mentre l'origine è raggiungibile tramite il layer 2.
FHR-1 — Route to Source
FHR-1# show ip route 10.150.1.37
10.150.1.37/32, ubest/mbest: 1/0, attached
*via 10.150.1.37, Vlan1, [250/0], 06:57:19, am
FHR-1 — Route to Receiver
FHR-1# show ip route 192.168.2.37
192.168.2.0/24, ubest/mbest: 2/0
*via 10.4.0.6, Eth1/3, [110/45], 04:11:08, ospf-UNDERLAY, intra
*via 10.4.0.10, Eth1/1, [110/45], 04:11:08, ospf-UNDERLAY, intra
FHR-2 — Route to Source
FHR-2# show ip route 10.150.1.37
10.150.1.37/32, ubest/mbest: 1/0, attached
*via 10.150.1.37, Vlan1, [250/0], 07:03:45, am
FHR-2 — Route to Receiver
FHR-2# show ip route 192.168.2.37
192.168.2.0/24, ubest/mbest: 2/0
*via 10.4.0.13, Eth1/3, [110/45], 04:16:16, ospf-UNDERLAY, intra
*via 10.4.0.18, Eth1/4, [110/45], 04:16:16, ospf-UNDERLAY, intra
LHR — Route to Source
LHR(config)# show ip route 10.150.1.37
10.150.1.0/24, ubest/mbest: 2/0
*via 10.4.0.22, Eth1/49, [110/45], 04:14:52, ospf-UNDERLAY, intra
*via 10.4.0.26, Eth1/50, [110/45], 04:14:52, ospf-UNDERLAY, intra
LHR — Route to Receiver
LHR(config)# show ip route 192.168.2.37
192.168.2.37/32, ubest/mbest: 1/0, attached
*via 192.168.2.37, Vlan2, [250/0], 06:47:21, am
L'esito negativo di questo test indica un problema di underlay.
Il multicast non può funzionare correttamente senza raggiungibilità unicast, poiché:
I vicini PIM utilizzano il routing unicast
Gli indirizzi RP (loopback) devono essere raggiungibili
I controlli RPF (Reverse Path Forwarding) dipendono dalla tabella di routing
Se il ping ha esito positivo, il multicast non può funzionare perché:
Quando il multicast è bloccato, è possibile autorizzare l'ICMP
PIM o Auto-RP possono essere configurati in modo errato
Suggerimento: Prima di analizzare Auto-RP, le adiacenze PIM o la selezione RP, assicurarsi sempre che il dominio di routing sottostante sia stabile, coerente e completamente raggiungibile.
Il passaggio successivo consiste nell'identificare chiaramente il ruolo di ogni dispositivo coinvolto nell'inoltro del traffico multicast. Questo passaggio è obbligatorio, in quanto la risoluzione dei problemi multicast dipende interamente dalla comprensione del flusso di traffico e del comportamento previsto nella topologia.
Tali elementi devono essere almeno identificati:
Origine Multicast (S): 10.150.1.37 (VLAN 1)
Multicast Group (G): 224.10.20.10
Ricevitore: 192.168.2.37 (VLAN 2)
FHR (First Hop Router): FHR-1 / FHR-2 (più vicino all'origine)
LHR (Last Hop Router): LHR (più vicino al destinatario)
Inoltre, è necessario identificare i ruoli del control plane:
Candidati RP: N9K-1 e N9K-2 (Loopback0)
Agenti mapping: N9K-1 e N9K-2 (loopback1)
Per procedere con la risoluzione dei problemi multicast, è necessario specificare una topologia di rete dettagliata. Ciò include:
Connettività fisica (interfacce utilizzate tra dispositivi)
Topologia logica (VLAN, collegamenti instradati, relazioni vPC)
Protocollo di routing in uso (area OSPF 0 in questo progetto)
Limiti del dominio di routing (IGP singolo o protocolli misti, ad esempio OSPF, EIGRP o BGP)
Interfacce di loopback utilizzate per i ruoli RP e Agente mapping
Interfacce abilitate per PIM e relazioni adiacenti
Il percorso esatto dalla sorgente → FHR → RP → LHR → Receiver
Quali dispositivi sono responsabili di:
Invio del registro PIM (FHR)
Edificio (*,G) o (S,G) alberi (LHR)
Pubblicità delle informazioni RP (agente mapping)
In che modo il routing (OSPF) garantisce la raggiungibilità di:
Subnet di origine
Subnet ricevitore
Indirizzi di loopback RP
Attenzione: La risoluzione dei problemi con il multicast senza una topologia chiara equivale al debug senza visibilità, pertanto comporta presupposti errati e diagnosi errate.
Il passaggio successivo consiste nel verificare che Auto-RP sia configurato correttamente su ciascun dispositivo in base al relativo ruolo nella topologia multicast. Ciò include la conferma che:
I candidati RP (N9K-1 / N9K-2) sono configurati correttamente per annunciare il loro Loopback0 come RP per l'intervallo di gruppi multicast.
Gli agenti di mapping (N9K-1 / N9K-2) sono configurati per raccogliere i messaggi RP-Annuncio e generare messaggi RP-Discovery utilizzando Loopback1.
In FHR e LHR la modalità sparsa PIM è abilitata su tutte le interfacce rilevanti per la partecipazione all'Auto-RP e la ricezione dei mapping RP.
È essenziale garantire che tutte le interfacce richieste (inclusi loopback e collegamenti indirizzati) siano abilitate per la modalità sparse PIM e che non vi siano configurazioni mancanti che impediscano lo scambio di messaggi RP-Annuncio (24.0.1.39) e RP-Discovery (24.0.1.40).
Nota: N9K-1 e N9K-2 sono configurati come RP-Candidati e agenti di mapping all'interno del dominio multicast.
Attenzione: Qualsiasi configurazione Auto-RP mancante o incoerente può impedire ai router di apprendere l'RP, determinando un traffico multicast non inoltrato correttamente.
Il primo passaggio di convalida consiste nel verificare che tutti i router adiacenti PIM previsti siano stabiliti correttamente nella topologia multicast.
N9K-1 — Verifica dei vicini PIM
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 — Verifica dei vicini PIM
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
Punti di convalida
In questa topologia:
Il passaggio successivo consiste nel verificare che tutte le interfacce che partecipano ad Auto-RP siano abilitate per PIM.
Questa convalida è particolarmente importante per:
N9K-1 — Verifica delle interfacce PIM
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 — Verifica delle interfacce PIM
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
Punti di convalida:
Assegnazione ruolo di loopback:
| Sul dispositivo bootflash o slot0: | Funzione | Loopback |
|---|---|---|
| N9K-1 | Candidato RP | 10.2.0.1 |
| N9K-1 | Agente mapping | 10.2.1.5 |
| N9K-2 | Candidato RP | 10.2.0.4 |
| N9K-2 | Agente mapping | 10.2.1.4 |
I loopback vengono visualizzati correttamente come interfacce PIM attive anche se non formano vicini PIM. Questo comportamento è previsto perché le interfacce di loopback non stabiliscono direttamente le adiacenze multicast.
La presenza di questi loopback conferma che:
Questo comando convalida:
N9K-1 — Informazioni RP
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)
Spiegazione riga per riga
BSR disabilitato
BSR disabled
Ciò conferma che:
Questo comportamento è previsto in questa topologia.
Auto-RP RPA: 10.2.1.5*
Auto-RP RPA: 10.2.1.5*
Ciò significa che:
Messaggio individuazione successiva in
next Discovery message in: 00:00:39
Se il timer si blocca o scade in modo imprevisto, gli annunci Auto-RP non possono essere propagati correttamente.
Campi criteri
BSR RP Candidate policy: None BSR RP policy: None Auto-RP Announce policy: None Auto-RP Discovery policy: None
Prima voce RP
RP: 10.2.0.1*, (0),
Ciò conferma che N9K-1 è configurato come RP-Candidato.
Tempi di attività e priorità
uptime: 22:18:44 priority: 255,
Origine RP
RP-source: 10.2.0.1 (A),
Intervallo gruppo
224.10.20.0/24
Seconda voce RP
RP: 10.2.0.4, (0),
N9K-2 — Informazioni RP
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)
Differenze principali su N9K-2
Auto-RP RPA: 10.2.1.5
Differenza RP importante
RP-source: 10.2.1.5 (A),
Ciò conferma che:
Auto-RP utilizza due diverse funzioni del piano di controllo multicast:
L'interazione di queste funzioni è fondamentale per la convalida del funzionamento multicast in un ambiente PIM Sparse Mode.
In questa topologia:
Operazione candidato RP
Un candidato RP si annuncia come un punto di rendering valido per uno o più intervalli di gruppi multicast.
Ogni candidato RP invia periodicamente messaggi di annuncio RP automatici a:
Questi annunci contengono:
In questa topologia:
N9K-1 — Informazioni sul candidato RP
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 — Informazioni sul candidato RP
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)
Entrambi i dispositivi annunciano lo stesso intervallo di gruppi multicast:
Entrambi i candidati RP utilizzano inoltre:
Questa operazione è importante in quanto Auto-RP utilizza la priorità e l'indirizzo RP durante la selezione RP.
Identificazione agente mapping attivo
L'agente mapping seleziona l'RP attivo per un gruppo multicast a partire dalla seguente logica:
In questa topologia:
Poiché entrambi i candidati RP hanno la stessa priorità:
Pertanto:
Convalida RP selezionata
N9K-2 — RP selezionata
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
Perché N9K-1 visualizza ancora entrambe le voci RP
In N9K-1:
N9K-1# show ip pim rp <snip> RP: 10.2.0.1*, (0), RP: 10.2.0.4, (0),
Questo comportamento è previsto perché:
Attenzione: Sull'agente mapping devono essere visualizzati tutti i candidati RP all'interno dello stesso dominio multicast. Se manca un candidato RP, verificare la raggiungibilità inviando un ping all'indirizzo IP del candidato RP originato dall'indirizzo IP dell'agente di mapping, in genere un'interfaccia di loopback.
Tutti i router multicast che fanno parte del dominio PIM in modalità sparse devono mantenere una raggiungibilità IP stabile per:
Questa convalida è critica perché la modalità sparse PIM si basa sul routing unicast per:
Se la raggiungibilità verso l'RP o l'agente di mapping non riesce:
La tabella di routing deve contenere route unicast stabili verso:
Le route devono rimanere continuamente installate senza interruzioni delle route o eventi di riconversione eccessivi.
Verifica:
FHR-1 — Rotta verso RP-Candidato 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 — Rotta verso RP-Candidato 10.2.0.4
FHR-1# show ip route 10.2.0.4
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.0.4/32, ubest/mbest: 1/0
*via 10.4.0.10, Eth1/1, [110/5], 1d02h, ospf-UNDERLAY, intra
FHR-1 — Route to Mapping Agent 10.2.1.5
FHR-1# show ip route 10.2.1.5
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.1.5/32, ubest/mbest: 1/0
*via 10.4.0.6, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra
FHR-1 — Route to Mapping Agent 10.2.1.4
FHR-1# show ip route 10.2.1.4
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.1.4/32, ubest/mbest: 1/0
*via 10.4.0.10, Eth1/1, [110/5], 1d02h, ospf-UNDERLAY, intra
FHR-2 — Rotta verso RP-Candidato 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 — Rotta verso RP-Candidato 10.2.0.4
FHR-2# show ip route 10.2.0.4
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.0.4/32, ubest/mbest: 1/0
*via 10.4.0.18, Eth1/4, [110/5], 1d02h, ospf-UNDERLAY, intra
FHR-2 — Route to Mapping Agent 10.2.1.5
FHR-2# show ip route 10.2.1.5
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.1.5/32, ubest/mbest: 1/0
*via 10.4.0.13, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra
FHR-2 — Route to Mapping Agent 10.2.1.4
FHR-2# show ip route 10.2.1.4
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.1.4/32, ubest/mbest: 1/0
*via 10.4.0.18, Eth1/4, [110/5], 1d02h, ospf-UNDERLAY, intra
LHR — Rotta verso RP-Candidato 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 — Rotta verso RP-Candidato 10.2.0.4
LHR# show ip route 10.2.0.4
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.0.4/32, ubest/mbest: 1/0
*via 10.4.0.26, Eth1/50, [110/2], 1d02h, ospf-UNDERLAY, intra
LHR — Route to Mapping Agent 10.2.1.5
LHR# show ip route 10.2.1.5
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.1.5/32, ubest/mbest: 1/0
*via 10.4.0.22, Eth1/49, [110/2], 1d02h, ospf-UNDERLAY, intra
LHR — Route to Mapping Agent 10.2.1.4
LHR# show ip route 10.2.1.4
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.1.4/32, ubest/mbest: 1/0
*via 10.4.0.26, Eth1/50, [110/2], 1d02h, ospf-UNDERLAY, intra
Dopo aver convalidato la tabella di routing, verificare la raggiungibilità IP end-to-end per:
Il ping deve avere origine da:
Questa convalida è importante perché i router multicast utilizzano questi indirizzi di origine durante:
Suggerimento: Se si usano interfacce senza numero, dove più interfacce di layer 3 condividono lo stesso indirizzo IP da un'interfaccia di loopback, la verifica della raggiungibilità diventa più semplice perché un unico indirizzo IP di origine può essere usato in modo coerente.
| Sul dispositivo bootflash o slot0: | IP di origine | Destinazione | Funzione | Risultato |
|---|---|---|---|---|
| FHR-1 | 10.4.0.5 | 10.2.0.1 | Candidato RP | Operazione riuscita |
| FHR-1 | 10.4.0.5 | 10.2.0.4 | Candidato RP | Operazione riuscita |
| FHR-1 | 10.4.0.5 | 10.2.1.5 | Agente mapping | Operazione riuscita |
| FHR-1 | 10.4.0.5 | 10.2.1.4 | Agente mapping | Operazione riuscita |
| FHR-2 | 10.4.0.9 | 10.2.0.1 | Candidato RP | Operazione riuscita |
| FHR-2 | 10.4.0.9 | 10.2.0.4 | Candidato RP | Operazione riuscita |
| FHR-2 | 10.4.0.9 | 10.2.1.5 | Agente mapping | Operazione riuscita |
| FHR-2 | 10.4.0.9 | 10.2.1.4 | Agente mapping | Operazione riuscita |
| LHR | 10.4.0.5 | 10.2.0.1 | Candidato RP | Operazione riuscita |
| LHR | 10.4.0.5 | 10.2.0.4 | Candidato RP | Operazione riuscita |
| LHR | 10.4.0.5 | 10.2.1.5 | Agente mapping | Operazione riuscita |
| LHR | 10.4.0.5 | 10.2.1.4 | Agente mapping | Operazione riuscita |
Il passaggio successivo della convalida consiste nel verificare che:
Prima di convalidare lo stato di inoltro multicast, verificare che tutti i router multicast abbiano appreso l'RP previsto per il gruppo multicast da convalidare.
Questo passaggio è critico perché:
In questa topologia:
FHR-1 - Verifica RP appresa
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 - Verifica RP appresa
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 — Verifica RP appresa
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)
Analisi di apprendimento RP
I risultati confermano che:
Questo comportamento è previsto perché:
In questa fase, il control-plane multicast funziona correttamente e tutti i router hanno una mappatura RP coerente per 224.10.20.0/24
Il passaggio successivo consiste nel convalidare la tabella di routing multicast prima di avviare la trasmissione del traffico multicast.
In questo scenario:
Questo stato è importante perché convalida:
FHR-1 — Tabella di routing multicast
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 — Tabella di routing multicast
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)
Analisi stato multicast FHR
Gli FHR non contengono ancora:
Questo comportamento è previsto perché:
L'unica voce multicast presente è:
Corrisponde all'intervallo SSM predefinito e viene installato automaticamente dal sistema.
Sono previsti i seguenti valori:
Questa voce non indica l'inoltro multicast attivo.
LHR — Tabella di routing multicast
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)
Analisi stato multicast LHR
A differenza degli FHR, l'LHR contiene una voce attiva (*,G) per:
Questo comportamento è previsto perché:
La tabella di routing multicast conferma:
Ciò indica che:
A questo punto:
N9K-1 — Tabella di routing multicast dell'agente mapping
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)
Analisi stato multicast agente mapping
N9K-1 funziona solo come agente di mapping e non partecipa all'inoltro multicast per 24.10.20.10
Si prevede pertanto l'assenza di voci (* ,G) e voci (S,G).
L'agente mapping distribuisce solo le informazioni di mapping RP e non partecipa necessariamente all'inoltro dati multicast, a meno che il traffico multicast non attraversi direttamente il dispositivo.
N9K-2 — Tabella di routing multicast RP
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)
Analisi stato multicast RP
N9K-2 funziona come RP attivo per:
Pertanto, l'RP contiene lo stato shared-tree (*,G) per 224.10.20.10
Sono previsti i seguenti valori:
Ciò indica che:
A questo punto:
Una volta avviata la trasmissione del traffico multicast, la tabella di routing multicast passa dallo stato della struttura ad albero condivisa allo stato di inoltro attivo specifico dell'origine.
In questo scenario:
Considerazioni importanti sul multicast vPC
La sorgente multicast si connette tramite un dominio vPC formato da FHR-1 e FHR-2.
Poiché l'origine si connette tramite un canale porta membro vPC:
In questo scenario specifico:
FHR-1 — Tabella di routing multicast
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: ruolo vPC
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
Analisi stato multicast FHR-1
FHR-1 contiene una voce attiva (S,G) per:
La voce di routing multicast conferma:
Questo comportamento è previsto perché il flusso multicast non ha eseguito l'hash verso FHR-1 per l'inoltro in uscita.
Di conseguenza:
FHR-2 — Tabella di routing multicast
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: ruolo vPC
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
Analisi stato multicast FHR-2
A differenza di FHR-1, FHR-2 contiene:
Ciò indica che:
Comportamento di inoltro ECMP e multicast
L'interfaccia in uscita Ethernet1/3 corrisponde alla tabella di routing unicast verso il ricevitore 192.168.2.37
FHR-2 — Indirizza al ricevitore multicast
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 contiene due route a costo uguale verso la subnet del ricevitore multicast:
Ciò conferma che:
Sebbene esistano due route a costo uguale, l'inoltro multicast utilizza un singolo percorso RPF per ogni flusso multicast.
In questa topologia, il flusso multicast utilizza:
Questo comportamento corrisponde alla tabella di routing multicast osservata in precedenza:
(10.150.1.37/32, 224.10.20.10/32)
Outgoing interface list:
Ethernet1/3
I ruoli operativi vPC influenzano in modo diverso il comportamento dell'inoltro multicast per:
In questa topologia:
Entrambi gli switch Nexus possono:
Tuttavia:
Questa distinzione è importante perché:
Pertanto:
LHR — Tabella di routing multicast
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)
L'LHR ora contiene entrambi:
Ciò conferma:
La voce (S,G) conferma:
Questo comportamento conferma l'esito positivo:
N9K-1 — Tabella di routing multicast transit
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)
Analisi stato transito N9K-1
N9K-1 funziona come router multicast di transito per il flusso multicast attivo.
La voce di routing multicast conferma:
Conferma riuscita:
N9K-2 — Tabella di routing multicast RP
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 funziona come RP attivo per il gruppo multicast.
L'RP contiene sia:
È prevista l'assenza di interfacce in uscita nella voce (S,G) per i seguenti motivi:
L'elenco dei comandi fornisce la raccolta di dati multicast minima consigliata necessaria per eseguire una corretta RCA (Root Cause Analysis) o diagnostica dell'integrità multicast sugli switch Cisco Nexus serie 9000 con NX-OS. Questi output acquisiscono lo stato del control plane multicast, la programmazione MRIB, le informazioni di inoltro, lo stato operativo vPC e i dettagli di inoltro hardware. Tuttavia, a seconda dello scenario di errore, è possibile che siano ancora necessarie ulteriori informazioni. Ad esempio, la perdita di pacchetti multicast, le interruzioni del traffico, i problemi di replica dei pacchetti, le incoerenze nell'inoltro hardware o l'inoltro multicast non ordinato spesso richiedono l'acquisizione diretta dei pacchetti sullo switch Nexus con Ethanalyzer, SPAN o le acquisizioni a livello di hardware. Analogamente, possono verificarsi incoerenze RPF transitorie, modifiche all'inoltro ECMP, errori di programmazione ASIC o eventi di soppressione IGMP senza generazione di log persistente.
Di conseguenza, la combinazione di show tech output con l'acquisizione e la convalida dei pacchetti migliora sensibilmente l'accuratezza della diagnostica e la qualità RCA. Anche se queste informazioni forniscono una solida base operativa per la risoluzione dei problemi multicast, non garantiscono che un RCA possa sempre essere identificato esclusivamente da questi output. Alcuni errori multicast richiedono ulteriori procedure di risoluzione dei problemi, analisi del traffico in tempo reale, convalida a livello di hardware, correlazione della topologia o acquisizioni estese dei pacchetti per isolare la root cause esatta.
Suggerimento: La raccolta di queste informazioni durante le attività lavorative e non lavorative fornisce un'istantanea chiara di come il problema appare dalla prospettiva di Nexus e migliora in modo significativo la capacità di identificare la causa principale.
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
Dopo aver generato i file show tech, consolidarli in un unico archivio TAR per l'esportazione e l'analisi. Il comando è a riga singola.
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
L'esportazione di un singolo archivio TAR semplifica:
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
1.0 |
13-May-2026
|
Versione iniziale |