Risoluzione dei problemi di Multicast Auto-RP su Nexus 9000 con NX-OS

Introduzione

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.

Prerequisiti

Requisiti

• Conoscenze base di multicast IP
• Conoscenze base di IGMP e PIM Sparse Mode
• Esperienza con Cisco Nexus 9000 e NX-OS CLI
• Informazioni sui concetti relativi a routing unicast e RPF

Componenti usati

• Cisco Nexus serie 9000 switch
• Software Cisco NX-OS
• PIM Sparse Mode
• RP statica e Auto-RP

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.

Panoramica del multicast

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

Operazione Auto-RP in modalità sparsa PIM (flusso di lavoro del piano di controllo)

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)

Limitazioni e vincoli operativi Auto-RP

• Auto-RP funziona solo con multicast IPv4 e non è supportato per IPv6 (PIM6), quindi le distribuzioni IPv6 richiedono un meccanismo di rilevamento RP diverso.
• Auto-RP non può coesistere con BSR all'interno dello stesso dominio PIM, poiché è possibile configurare un solo meccanismo di rilevamento RP per evitare conflitti tra i control plane.
• I messaggi Auto-RP non vengono elaborati o inoltrati per impostazione predefinita sui dispositivi NX-OS, pertanto per il corretto funzionamento è necessaria una configurazione esplicita.
• La propagazione dei messaggi di controllo Auto-RP dipende dall'attivazione del listener Auto-RP; in caso contrario, le informazioni di mapping RP non raggiungono tutti i router.
• L'intervallo di annuncio RP ha una soglia minima di 15 secondi, che limita la velocità con cui gli aggiornamenti RP possono essere annunciati e influisce sul tempo di convergenza.
• Il filtro automatico dei messaggi RP tramite route-map può influire sul funzionamento, poiché criteri non corretti possono bloccare i mapping RP-a-gruppo.
• Auto-RP è disabilitato per impostazione predefinita nei contesti VRF, pertanto deve essere abilitato esplicitamente nelle distribuzioni multi VRF.

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

Vantaggi dell'utilizzo di Auto-RP

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.

Agente di mapping Auto-RP e processo di selezione RP

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.

Selezione agente mapping

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.

• Criterio di selezione: Indirizzo IP più alto.
• Il processo:
  1. Tutti gli agenti mapping inviano i messaggi RP-Discovery al gruppo multicast 24.0.1.40.
  2. Gli switch client ricevono questi messaggi.
  3. Se uno switch riceve messaggi Discovery da due diversi agenti di mapping contenenti informazioni in conflitto, lo switch accetta le informazioni dall'agente di mapping con l'indirizzo IP di origine più alto.
  4. Comportamento di Nexus: Un agente di mapping con un indirizzo IP inferiore in genere entra in uno stato "passivo" o "soppressione" quando rileva un altro MA con un indirizzo IP superiore per impedire il traffico di controllo duplicato nella rete.

Selezione punto di rendering (RP)

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

• Esempio:
  • Il candidato A annuncia 224.0.0.0/4 (the intero intervallo multicast).
  • Il candidato B annuncia 224.10.20.0/24.
  • Risultato: Per il gruppo 24.10.20.5, vince il candidato B perché il suo intervallo è più specifico.

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.

• Criterio Il candidato con l'indirizzo IP più alto ha vinto.
• Esempio:
  • Candidato 1: 10.2.0.1 per l'intervallo 24.10.20.0/24.
  • Candidato 2: 10.2.0.4 per l'intervallo 224.10.20.0/24.
  • Risultato: L'agente di mapping seleziona 10.2.0.4 come RP ufficiale per l'intervallo e questo viene pubblicizzato nei suoi messaggi Discovery.

Considerazioni sul layer 2: MAC multicast e snooping

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.

Configurazione Auto-RP

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.

Flusso del traffico multicast

Router First Hop

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.

Agente di mapping e candidato RP

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.

Configurazione del routing per la raggiungibilità IPv4

• In questa topologia, tutti gli switch Nexus partecipano a un singolo processo OSPF denominato UNDERLAY, che opera nell'area 0 (0.0.0.0) per fornire una completa raggiungibilità di routing in tutta la rete.
• Sull'LHR, il protocollo OSPF è abilitato sulla VLAN 2, che funge da gateway per il ricevitore multicast, e sulle interfacce uplink Ethernet1/49 e Ethernet1/50, entrambe configurate come point-to-point. Ciò assicura una formazione efficiente dell'adiacenza verso gli switch N9K upstream senza le selezioni DR/BDR.
• Il livello FHR (FHR-1 e FHR-2) condivide una configurazione identica. Il protocollo OSPF è abilitato sulla VLAN 1, che funge da gateway per l'origine multicast, e sugli uplink instradati (Ethernet1/1 ed Ethernet1/3) verso il livello di aggregazione. Questi collegamenti sono configurati anche come point-to-point, ottimizzando la convergenza e il comportamento adiacente.
• Analogamente, N9K-1 e N9K-2 hanno configurazioni OSPF identiche, con l'aggiunta della pubblicità Loopback0 e Loopback1 in OSPF.
  • Questi loopback sono fondamentali, in quanto vengono utilizzati successivamente per i ruoli Candidato RP PIM e Agente mapping.

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

Verifica dello stato operativo e risoluzione dei problemi di Auto-RP

Passaggio 1: Verifica raggiungibilità IP di base (convalida underlay unicast)

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)

Approccio di convalida

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

Considerazioni importanti

• 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

Passaggio 2: Individuazione ruoli multicast e topologia end-to-end

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)

Riconoscimento della topologia e del piano di controllo

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

Cosa Deve Essere Compreso Chiaramente

• 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

  • Mapping degli indirizzi di loopback degli agenti

Passaggio 3: Convalida configurazione Auto-RP in base al ruolo del dispositivo

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

Passaggio 4: Convalida il funzionamento di tutti i candidati RP e di tutti gli agenti di mapping

Passaggio 4.1 Verifica delle adiacenze adiacenti del PIM

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

• Verificare che tutti i router adiacenti previsti vengano visualizzati su ogni interfaccia di routing.
• Verificare che il tempo di attività del router adiacente sia stabile e in continuo aumento.
• Verificare che il timer Scadenza venga aggiornato periodicamente.
• Verificare che non si verifichino flap adiacenti imprevisti.
• Verificare la selezione corretta del router designato (DR).
• Verificare che le interfacce multicast formino correttamente le adiacenze PIM.

In questa topologia:

• N9K-1 stabilisce tre vicini PIM.
• N9K-2 stabilisce anche tre vicini PIM.
• Tutte le adiacenze rimangono stabili per più di 23 ore, il che indica un funzionamento stabile del control plane multicast.

---

Passaggio 4.2 Verifica delle interfacce abilitate per PIM

Il passaggio successivo consiste nel verificare che tutte le interfacce che partecipano ad Auto-RP siano abilitate per PIM.

Questa convalida è particolarmente importante per:

• Loopback candidati RP
• Loopback dell'agente mapping

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:

• Verificare che nell'output vengano visualizzate tutte le interfacce multicast indirizzate.
• Verificare che i loopback RP-Candidate siano abilitati per PIM.
• Verificare che i loopback dell'agente mapping siano abilitati per PIM.
• Verificare che i conteggi dei router adiacenti siano corretti sulle interfacce di transito.
• Verificare che nelle interfacce di loopback venga visualizzato correttamente il valore Count router adiacenti = 0.

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:

• PIM è in grado di generare correttamente i messaggi di controllo Auto-RP.
• Gli annunci RP possono essere creati correttamente.
• La funzionalità Agente mapping può funzionare correttamente.

---

Passaggio 4.3 Analizzare show ip pim rp

Questo comando convalida:

• Individuazione RP
• Annunci Auto-RP
• Operazione agente mapping
• Mapping da gruppo a RP

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:

• Il router bootstrap (BSR) non è utilizzato.
• Il dominio multicast si basa esclusivamente su Auto-RP.

Questo comportamento è previsto in questa topologia.

Auto-RP RPA: 10.2.1.5*

Auto-RP RPA: 10.2.1.5*

• 10.2.1.5 corrisponde a loopback1 su N9K-1.
• Il simbolo * indica che lo switch locale è l'agente di mapping attivo.

Ciò significa che:

• N9K-1 genera messaggi RP-Discovery.
• N9K-1 raccoglie gli annunci RP dai candidati RP.
• N9K-1 distribuisce le informazioni di mapping RP al dominio multicast.

Messaggio individuazione successiva in

next Discovery message in: 00:00:39

• Verificare che il timer si aggiorni continuamente.
• Verificare che i messaggi di individuazione vengano inviati periodicamente.

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

• Non vengono applicati criteri di filtro.
• Tutti gli annunci RP e Discovery sono accettati.

Prima voce RP

RP: 10.2.0.1*, (0),

• Indirizzo RP = 10.2.0.1
• Il simbolo * indica che questo RP è locale rispetto a N9K-1.
• 10.2.0.1 corrisponde a loopback0 su N9K-1.

Ciò conferma che N9K-1 è configurato come RP-Candidato.

Tempi di attività e priorità

uptime: 22:18:44   priority: 255,

• Il tempo di attività stabile indica un'operazione di annuncio RP stabile.
• La priorità 255 è la priorità più alta predefinita.

Origine RP

RP-source: 10.2.0.1 (A),

• L'annuncio pubblicitario del RP è stato pubblicato direttamente dal RP stesso.
• (A) indica le informazioni apprese da Auto-RP.

Intervallo gruppo

224.10.20.0/24

• Verificare che venga annunciato l'intervallo multicast corretto.
• Verificare che l'intervallo di gruppi corrisponda alla configurazione.

Seconda voce RP

RP: 10.2.0.4, (0),

• Esiste un altro RP nella topologia.
• 10.2.0.4 corrisponde a loopback0 su N9K-2.
• No * viene visualizzato perché questo RP è remoto da N9K-1.

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

• No * viene visualizzato perché N9K-2 non è l'agente di mapping.
• N9K-2 apprende le informazioni dell'agente di mapping in remoto da N9K-1.

Differenza RP importante

RP-source: 10.2.1.5 (A),

• N9K-2 apprende le informazioni RP dall'agente di mapping.
• L'agente mapping è 10.2.1.5.

Ciò conferma che:

• I messaggi di individuazione Auto-RP funzionano correttamente.
• Gli annunci dell'agente mapping vengono propagati correttamente tramite il dominio multicast.

Passo 4.4 Convalida processo di selezione Auto-RP e selezione RP

Auto-RP utilizza due diverse funzioni del piano di controllo multicast:

• Candidato RP
• Agente mapping

L'interazione di queste funzioni è fondamentale per la convalida del funzionamento multicast in un ambiente PIM Sparse Mode.

In questa topologia:

• N9K-1 e N9K-2 funzionano come RP-Candidati.
• N9K-1 funziona come agente di mapping attivo.

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:

• 24.0.1.39 — Gruppo di annuncio Auto-RP
  
  

Questi annunci contengono:

• Indirizzo RP
• Intervallo gruppo
• Priority
• Holdtime

In questa topologia:

• 10.2.0.1 su N9K-1 si annuncia come RP.
• 10.2.0.4 su N9K-2 si annuncia come RP.

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:

• 224.10.20.0/24

Entrambi i candidati RP utilizzano inoltre:

• Priorità 25

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:

1. La priorità RP più alta è vincente.
2. Se le priorità sono uguali, prevale l'indirizzo IP RP più alto.

In questa topologia:

• N9K-1 Indirizzo RP = 10.2.0.1
• N9K-2 Indirizzo RP = 10.2.0.4
• Entrambi i candidati RP utilizzano la priorità 255

Poiché entrambi i candidati RP hanno la stessa priorità:

• L'indirizzo IP RP più alto diventa l'RP selezionato.

Pertanto:

• 10.2.0.4 diventa il RP attivo per 224.10.20.0/24.

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é:

• N9K-1 funziona come agente di mapping.
• L'agente mapping mantiene la visibilità di tutti i candidati RP.
• L'output visualizza tutti gli annunci RP appresi prima della distribuzione della selezione finale RP.

Passaggio 5: Verifica della raggiungibilità dei candidati RP e degli agenti di mapping

Tutti i router multicast che fanno parte del dominio PIM in modalità sparse devono mantenere una raggiungibilità IP stabile per:

• Tutti i candidati RP
• Tutti gli agenti mapping

Questa convalida è critica perché la modalità sparse PIM si basa sul routing unicast per:

• Raggiungere il punto di rendering (RP)
• Compilare la struttura multicast condivisa (RPT)
• Consegna dei messaggi del registro PIM dal router del primo hop (FHR)
• Ricevi annunci di individuazione Auto-RP
• Esegui convalida inoltro percorso inverso (RPF)

Se la raggiungibilità verso l'RP o l'agente di mapping non riesce:

• È possibile che la registrazione delle origini multicast non riesca.
• I ricevitori possono non riuscire a unirsi ai gruppi multicast.
• Impossibile propagare correttamente gli annunci Auto-RP.
• Potrebbero verificarsi errori RPF.
• L'inoltro del traffico multicast può diventare instabile o intermittente.

---

Verifica voci di routing stabili

La tabella di routing deve contenere route unicast stabili verso:

• Tutti i loopback RP
• Tutti i loopback degli agenti di mapping
• Tutte le interfacce di transito multicast

Le route devono rimanere continuamente installate senza interruzioni delle route o eventi di riconversione eccessivi.

Verifica:

• Correggere la selezione dell'hop successivo
• Correggi interfaccia in uscita
• Tempo di attività del ciclo di lavorazione stabile
• Origine prevista del protocollo di routing
• Raggiungibilità unicast coerente nel dominio multicast

---

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

---

Verifica della raggiungibilità del ping dalle interfacce PIM

Dopo aver convalidato la tabella di routing, verificare la raggiungibilità IP end-to-end per:

• Tutti i candidati RP
• Tutti gli agenti mapping

Il ping deve avere origine da:

• Interfacce abilitate per PIM
• Interfacce di loopback che partecipano al routing multicast

Questa convalida è importante perché i router multicast utilizzano questi indirizzi di origine durante:

• stabilimento adiacente PIM
• Calcoli RPF
• PIM Register encapsulation
• Comunicazione Auto-RP

Riepilogo convalida ping

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

Verifica dello stato operativo e dell'inoltro del traffico multicast su FHR e LHR

Il passaggio successivo della convalida consiste nel verificare che:

• L'FHR e l'LHR hanno appreso correttamente l'RP previsto.
• La tabella di routing multicast contiene gli stati multicast previsti.
• Il control-plane multicast funziona correttamente prima dell'inizio della trasmissione del traffico multicast.
• La modalità di sparsità PIM crea lo stato dell'albero condiviso previsto.

---

Fase 1 Verifica dell'apprendimento RP su FHR e LHR

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é:

• L'FHR deve sapere dove inviare i messaggi del registro PIM.
• L'LHR deve sapere quale RP utilizzare per la creazione dell'albero condiviso.
• Il dominio multicast deve mantenere un mapping RP coerente.

In questa topologia:

• Il prezzo consigliato selezionato è 10.2.0.4.
• L'agente mapping è 10.2.1.5.
• L'intervallo del gruppo multicast è 224.10.20.0/24.

---

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:

• Tutti i router multicast hanno imparato lo stesso RP in modo coerente.
• Il prezzo consigliato selezionato è 10.2.0.4.
• La mappatura RP è stata appresa tramite Auto-RP.
• L'agente di mapping che distribuisce le informazioni RP è 10.2.1.5.
• La mappatura RP rimane stabile per più di un giorno.
• I timer di scadenza individuazione vengono aggiornati correttamente.

Questo comportamento è previsto perché:

• 10.2.0.4 è stato selezionato come RP attivo durante il processo di selezione di Auto-RP.
• 10.2.1.5 funziona come agente di mapping.
• Tutti i router multicast ricevono correttamente gli annunci di individuazione Auto-RP.

In questa fase, il control-plane multicast funziona correttamente e tutti i router hanno una mappatura RP coerente per 224.10.20.0/24

---

2. Verificare lo stato del routing multicast prima del traffico multicast attivo

Il passaggio successivo consiste nel convalidare la tabella di routing multicast prima di avviare la trasmissione del traffico multicast.

In questo scenario:

• Il ricevitore multicast è già stato aggiunto al gruppo multicast.
• Non è ancora presente alcun flusso di traffico di origine multicast attivo.

Questo stato è importante perché convalida:

• Operazione di appartenenza IGMP
• creazione di strutture condivise PIM
• Stato multicast iniziale (*,G)
• Propagazione interessi destinatario

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:

• (* ,G) stato per 24.10.20.10
• (S,G) per l'origine multicast

Questo comportamento è previsto perché:

• Nessun traffico di origine multicast ancora attivo.
• Nessun messaggio di registro PIM generato.
• Inoltro multicast non avviato da FHR.

L'unica voce multicast presente è:

• 232.0.0.0/8

Corrisponde all'intervallo SSM predefinito e viene installato automaticamente dal sistema.

Sono previsti i seguenti valori:

• Interfaccia in ingresso: Null
• RPF adiacente: 0.0.0.0
• Conteggio interfacce in uscita: 0

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:

• 224.10.20.10

Questo comportamento è previsto perché:

• Il ricevitore multicast è già stato aggiunto al gruppo.
• Informazioni sull'appartenenza IGMP apprese sulla Vlan2.
• L'LHR ha avviato il join dell'albero condiviso verso l'RP.

La tabella di routing multicast conferma:

• L'interfaccia in ingresso (IIF) è Ethernet1/50.
• Il router adiacente è la versione 10.4.0.26.
• L'elenco delle interfacce in uscita (OIL) contiene la Vlan2.

Ciò indica che:

• L'LHR ha creato correttamente l'albero condiviso verso l'RP.
• L'interesse del ricevitore multicast è stato propagato a monte.
• I messaggi di aggiunta PIM sono stati trasmessi correttamente.

A questo punto:

• Nessun traffico di origine multicast ancora attivo.
• Non esiste ancora uno stato (S,G).
• Esiste solo lo stato dell'albero condiviso.

---

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:

• 224.10.20.0/24

Pertanto, l'RP contiene lo stato shared-tree (*,G) per 224.10.20.10

Sono previsti i seguenti valori:

• Interfaccia in ingresso = loopback0
• RPF adiacente = 10.2.0.4
• Interfaccia in uscita = Ethernet1/49

Ciò indica che:

• RP: installazione dello stato dell'albero condiviso completata.
• L'RP ha ricevuto messaggi di join PIM dai router downstream.
• L'albero multicast condiviso verso i ricevitori è stato creato correttamente.

A questo punto:

• L'RP contiene solo lo stato dell'albero condiviso.
• Nessun traffico di origine multicast ancora attivo.
• Non sono ancora presenti voci (S,G).

---

3. Verificare lo stato del routing multicast con il traffico multicast attivo

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:

• La fonte multicast è 10.150.1.37.
• Il gruppo multicast è 24.10.20.10.
• L'RP attivo è 10.2.0.4 su N9K-2.
• La sorgente multicast si connette tramite il canale porta vPC 78.

---

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:

• L'hashing del traffico può inoltrare pacchetti multicast verso uno dei due switch Nexus.
• Entrambi gli FHR richiedono una configurazione multicast identica.
• Entrambi gli FHR richiedono informazioni di routing unicast coerenti.
• Entrambi gli FHR devono mantenere mapping RP identici.
• Entrambi gli FHR devono mantenere adiacenze PIM stabili.

In questo scenario specifico:

• Il flusso multicast si hash verso FHR-2.
• FHR-2 diventa l'FHR di inoltro attivo per l'origine multicast.

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:

• Origine = 10.150.1.37
• Gruppo = 24.10.20.10

La voce di routing multicast conferma:

• L'origine è stata appresa sulla Vlan1.
• Il router adiacente RPF è l'origine multicast direttamente connessa.
• Non esistono interfacce in uscita nell'OIL.

Questo comportamento è previsto perché il flusso multicast non ha eseguito l'hash verso FHR-1 per l'inoltro in uscita.

Di conseguenza:

• FHR-1 installa solo lo stato di origine locale.
• FHR-1 non inoltra il traffico multicast a monte tramite PIM.

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:

• Elenco di interfacce in uscita attivo
• Un percorso di inoltro PIM attivo

Ciò indica che:

• FHR-2 è diventato l'FHR di inoltro operativo per il flusso multicast.
• I pacchetti multicast sono stati sottoposti a hash verso FHR-2 tramite il canale porta membro vPC.
• FHR-2 ha incapsulato il traffico multicast nei messaggi del registro PIM.
• FHR-2 ha inoltrato il traffico multicast a monte verso l'RP.

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:

• da 10.4.0.13 a Ethernet1/3
• da 10.4.0.18 a Ethernet1/4

Ciò conferma che:

• Il routing ECMP è attivo nella topologia del trasporto multicast.
• Esistono più percorsi di inoltro unicast validi verso la rete di ricezione.
• PIM può utilizzare il percorso RPF selezionato da MRIB per le decisioni di inoltro multicast.
• La duplicazione dei pacchetti su percorsi ECMP paralleli non viene eseguita.

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:

• Ethernet1/3 verso 10.4.0.13

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

---

Comportamento principale e secondario operativo vPC

I ruoli operativi vPC influenzano in modo diverso il comportamento dell'inoltro multicast per:

• traffico PIM
• elaborazione IGMP

In questa topologia:

• FHR-1 è il principale vPC operativo.
• FHR-2 è il vPC secondario operativo.

Entrambi gli switch Nexus possono:

• Elaborazione del traffico del control plane PIM
• Crea stato routing multicast
• Inoltra il traffico multicast tramite PIM

Tuttavia:

• Solo il sistema operativo principale vPC elabora il traffico dei ricevitori IGMP verso il livello di accesso.

Questa distinzione è importante perché:

• L'inoltro PIM verso la rete instradata rimane attivo su entrambi i peer.
• L'inoltro IGMP verso i segmenti del ricevitore di layer 2 rimane centralizzato sul sistema operativo primario.

Pertanto:

• Il traffico multicast dall'origine verso il dominio multicast indirizzato può uscire tramite uno dei peer vPC.
• Il traffico multicast verso i ricevitori IGMP si basa sul comportamento operativo primario.

---

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)

Analisi stato multicast LHR

L'LHR ora contiene entrambi:

• (* ,G) stato albero condiviso
• (S,G) stato albero origine

Ciò conferma:

• Aggiunta del ricevitore multicast completata.
• L'origine multicast è diventata attiva.
• L'LHR è passato dall'inoltro ad albero condiviso all'inoltro ad albero di origine.

La voce (S,G) conferma:

• Il percorso di origine multicast è stato appreso.
• Il router adiacente è la versione 10.4.0.22.
• Il traffico multicast arriva tramite Ethernet1/49.
• Il traffico multicast viene inoltrato verso i ricevitori Vlan2.

Questo comportamento conferma l'esito positivo:

• inoltro PIM
• Convalida RPF
• Costruzione dell'albero origine
• Recapito del traffico multicast

---

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:

• Il traffico multicast arriva da Ethernet1/4.
• Il traffico multicast viene inoltrato verso Ethernet1/49.
• Il percorso di inoltro multicast verso l'LHR è operativo.

Conferma riuscita:

• Operazione PIM adiacente
• Convalida RPF
• Inoltro multicast attraverso la rete di transito

---

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)

Analisi stato multicast RP

N9K-2 funziona come RP attivo per il gruppo multicast.

L'RP contiene sia:

• (* ,G) stato albero condiviso
• (S,G) stato albero origine

È prevista l'assenza di interfacce in uscita nella voce (S,G) per i seguenti motivi:

• L'RP ha già indirizzato i ricevitori verso l'albero del percorso più breve.
• Il percorso di inoltro ad albero condiviso non è più necessario per l'inoltro multicast attivo.

Informazioni multicast minime richieste per RCA e Health Diagnostics

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.

Comandi minimi per la raccolta dati multicast

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

Creazione di un archivio TAR per l'esportazione

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:

• Caricamenti richiesta TAC
• workflow RCA
• Analisi dei registri centralizzata
• Correlazione inoltro multicast
• Conservazione dei guasti storici

Cronologia delle revisioni

Revisione	Data di pubblicazione	Commenti
1.0	13-May-2026	Versione iniziale