PIM-SM attraverso una VPN: verificare BSR, mappatura RP e percorsi RPF

Il tunnel è attivo, i ping unicast lo attraversano e il ricevitore mostra ancora uno schermo nero. In una distribuzione PIM-SM quel sintomo significa quasi sempre che uno dei quattro percorsi di controllo è rotto e che il percorso dati non è mai stato il problema. Seguite l’elenco qui sotto in ordine e fermatevi al primo passo che fallisce, perché ogni passo successivo dipende da quello precedente. Tengo queste cinque verifiche in un file di appunti e le incollo in un terminale quando arriva una segnalazione multicast, il che impedisce alla diagnosi di trasformarsi in congetture.

Cominciate dal ricevitore, non dal tunnel

Un ricevitore che non ha mai chiesto il gruppo non crea alcuno stato su alcun router, quindi confermate che l’iscrizione esista sul segmento rivolto al ricevitore prima di ispezionare qualsiasi altra cosa. Sulle piattaforme in stile Cisco, show ip igmp groups sul router dell’ultimo salto stampa i gruppi iscritti accanto all’interfaccia che li ha uditi. Quando il gruppo manca in quell’output, il tunnel è una distrazione: la richiesta è morta sullo switch di accesso, sulla socket dell’host o in una VLAN priva di querier.

Due cause banali spiegano la maggior parte delle iscrizioni mancanti che ho visto: una discrepanza di versione IGMP tra host e router, e un’elezione del querier che è finita su uno switch che non instrada. Una terza è più sottile: il gruppo è iscritto ma sulla VLAN sbagliata, perché l’host ha due schede di rete e l’applicazione si è legata a quella errata. I ricevitori IPv6 hanno il problema equivalente con MLD, dove show ipv6 mld groups risponde alla stessa domanda. Nessuna di queste si risolve toccando il tunnel, ed è esattamente per questo che l’ordine conta.

Una volta che l’iscrizione è visibile, confermate che PIM sia abilitato sia sull’interfaccia rivolta al ricevitore sia sull’interfaccia che porta verso il punto di incontro. Un router con appartenenza IGMP ma senza PIM sulla sua interfaccia a monte terrà il gruppo in una tabella locale e non invierà nulla da nessuna parte.

L’insieme BSR raggiunge l’altro lato?

I messaggi Bootstrap Router avanzano salto per salto all’interno di un singolo dominio PIM, ed è quella la direzione che si rompe attraverso un tunnel. Gli RP candidati inviano i propri annunci al BSR eletto via unicast, quindi il tratto RP-BSR di solito sopravvive intatto a un tunnel funzionante. L’inondazione di messaggi Bootstrap nell’altra direzione dipende dal fatto che ogni interfaccia intermedia abbia PIM abilitato e che nulla fermi i messaggi a un confine. RFC 5059 definisce quella distribuzione e i confini di ambito amministrativo che possono accorciarla.

Un’istruzione ip pim bsr-border, un ACL che filtra il protocollo 103 o un tunnel IPsec basato su criteri che non può trasportare multicast taglieranno ciascuno l’inondazione lasciando intatto l’unicast. È proprio quella combinazione a far sembrare il guasto un problema di RP quando in realtà è un problema di raggiungibilità, ed è per questo che leggo lo stato BSR prima della configurazione RP.

Sul router del lato remoto, show ip pim bsr-router indica il BSR eletto e l’insieme di RP appreso; se l’output è vuoto, il lato remoto sta nel proprio dominio e nessuna quantità di configurazione RP riconcilierà i due. Confrontate gli intervalli di gruppo e gli indirizzi RP in show ip pim rp mapping sui due lati del tunnel. Una mappatura che esiste solo localmente produce un albero condiviso che termina nel posto sbagliato, e il ricevitore attende per sempre.

Allineate la mappatura RP sui due lati del tunnel

RP statico, BSR e anycast-RP sono tre modi di rispondere alla stessa domanda, e mescolarli attraverso un tunnel è un modo affidabile di costruire un dominio che non converge mai. Se l’estremità principale usa BSR e la filiale usa un ip pim rp-address statico che punta a un indirizzo diverso, la filiale costruisce il proprio albero condiviso verso un RP che non sa che il ricevitore esista. La mappatura deve concordare sia sull’intervallo di gruppo sia sull’indirizzo, poiché un intervallo più specifico vince su uno più ampio.

Anycast-RP esiste proprio perché due sedi possano condividere un indirizzo RP, e vale la pena nominarlo qui perché cambia cosa significa «lo stesso RP». Due RP che annunciano un solo indirizzo sono coerenti per progettazione; due RP che annunciano indirizzi diversi per lo stesso intervallo non lo sono, per quanto sano sembri ciascun sito preso da solo.

Per il multicast specifico per sorgente all’interno di 232.0.0.0/8, l’RP non viene mai consultato, quindi una mappatura RP vuota non è automaticamente un guasto. Decidete quale modello di servizio usa l’applicazione prima di inseguire un RP che non è mai stato necessario.

Leggete la ricerca RPF verso la sorgente

PIM costruisce un albero invertendo il percorso unicast, quindi il controllo che conta è la rotta di ritorno verso la sorgente, o verso l’RP per un albero condiviso. Un’iscrizione che arriva su un’interfaccia che il router non considera a monte viene scartata, e il motivo viene registrato come guasto RPF e non come guasto del tunnel. Su un router di filiale con una rotta predefinita sul tunnel e una rotta più specifica sulla WAN, l’interfaccia RPF può facilmente essere la WAN anche se la sorgente è raggiungibile solo attraverso il tunnel. È la ragione singola più comune per cui un’iscrizione viene scartata in silenzio.

show ip rpf 192.0.2.10 stampa l’interfaccia scelta, il salto successivo e la rotta che ha prodotto la decisione, il che di solito basta per vedere la discrepanza. Una rotta multicast statica come ip mroute 192.0.2.0 255.255.255.0 tunnel0 scavalca la ricerca unicast per quel prefisso, ed è una correzione legittima quando la topologia multicast differisce davvero da quella unicast. Trattatela come configurazione da documentare, non come una pezza applicata durante un incidente e poi dimenticata.

Confermate l’iscrizione con i comandi, non con un ping

Il ping dimostra che l’unicast funziona, cosa che già sapevate. La conferma end-to-end è una sequenza che mostra l’iscrizione, la mappatura, il vicino e l’albero in quest’ordine, e ogni comando risponde a una domanda diversa.

show ip igmp groups 239.1.1.1
show ip pim rp mapping
show ip pim neighbor
show ip rpf 192.0.2.10
show ip mroute 239.1.1.1

Una voce (S,G) popolata con un’interfaccia in ingresso reale e una lista in uscita non vuota significa che il piano di controllo ha finito il suo lavoro. Una voce la cui interfaccia in ingresso risulta Null, o un contatore etichettato RPF failed che continua a salire, riporta alla sezione precedente e non al tunnel.

Se tutti e cinque i comandi sembrano corretti e il ricevitore non vede ancora nulla, il sospetto rimasto è la policy del tunnel stesso: un ACL di crittografia o una regola del firewall che consente il protocollo di routing unicast ma non PIM, IGMP o il traffico di gruppo stesso. Su un tunnel IPsec basato su criteri il multicast non viene affatto trasportato, quindi la risposta è un progetto GRE o VTI e non un’altra eccezione nei filtri. Annotate quale delle cinque verifiche ha fallito prima di cambiare qualcosa, poi cambiate solo quello strato.