Multicast: PIM sparse mode e rendezvous point

PIM Sparse Mode: il modello explicit-join

In una progettazione enterprise il multicast si basa quasi sempre su PIM Sparse Mode (PIM-SM), il modello explicit-join in cui il traffico raggiunge solo i segmenti dove un ricevitore ha esplicitamente richiesto il gruppo. È l’opposto di dense mode (flood-and-prune), inadatto a topologie WAN o campus estese perché spreca banda. Il cuore di PIM-SM è il Rendezvous Point (RP): un router che funge da punto d’incontro tra sorgenti e ricevitori.

Il flusso logico è:

1. Il last-hop router (DR) del ricevitore, ricevuto un IGMP Join, invia un PIM (*,G) Join verso l’RP, costruendo lo shared tree (RPT) con radice l’RP.
2. Il first-hop DR della sorgente incapsula i primi pacchetti in messaggi PIM Register unicast verso l’RP.
3. L’RP de-incapsula, inoltra sul RPT e a sua volta invia un (S,G) Join verso la sorgente per ricevere il flusso nativo; quando questo arriva, manda un Register-Stop al DR sorgente.

Dallo shared tree allo Shortest Path Tree

Il RPT è ottimale per stabilire la sessione, ma il percorso sorgente → RP → ricevitore raramente coincide con il cammino più breve. Per questo il last-hop router, ricevuto il primo pacchetto sull’RPT, esegue lo switchover al Shortest Path Tree (SPT), radicato direttamente sulla sorgente. Si passa così dallo stato (*,G) allo stato (S,G), con inoltro basato sull’RPF verso la sorgente e potatura del ramo RPT ridondante.

Su IOS/IOS-XE il default è lo switchover immediato dopo il primo pacchetto (ip pim spt-threshold 0). Per mantenere il traffico sull’RPT — utile per ridurre lo stato (S,G) su router edge o in scenari di scalabilità — si usa:

ip pim spt-threshold infinity

Attenzione: con infinity l’RP resta permanentemente nel data path, quindi la sua collocazione diventa critica.

Distribuzione dell’RP

Il design deve scegliere come i router apprendono l’indirizzo dell’RP.

Per la ridondanza la best practice è Anycast RP: più RP condividono lo stesso indirizzo (loopback), con MSDP che sincronizza lo stato delle sorgenti attive tra loro. Si ottengono failover rapido e load sharing, indipendentemente dal metodo di distribuzione scelto.

La trappola del posizionamento dell’RP

Il posizionamento dell’RP è una delle decisioni più insidiose. Un RP collocato lontano dalle sorgenti e dai ricevitori (per esempio in una sede periferica) produce due problemi:

• Path multicast allungati: finché non avviene lo switchover all’SPT, tutto il traffico attraversa l’RP, seguendo un percorso a “boomerang” invece del cammino più breve.
• Punto di concentrazione: l’RP diventa un collo di bottiglia e un single point of failure; con spt-threshold infinity il problema è permanente.

La regola progettuale è collocare l’RP in posizione centrale/core, topologicamente vicino a sorgenti e ricevitori principali, e prevedere ridondanza con Anycast RP. In campus multi-sito si valuta la distribuzione dei gruppi su RP diversi per bilanciare il carico.

Trappole tipiche d’esame

• Scenario multi-vendor che richiede distribuzione dinamica dell’RP → scegliere BSR (standard PIMv2), non Auto-RP che è Cisco-proprietario.
• Auto-RP in rete sparse-mode pura con mappe RP che non si propagano → i gruppi 224.0.1.39/224.0.1.40 non vengono inoltrati: applicare ip pim autorp listener (o sparse-dense-mode).
• Richiesta di RP ridondante con failover rapido e load sharing → Anycast RP con MSDP, non un semplice RP statico secondario.
• Necessità di mantenere il traffico sullo shared tree (ridurre stato (S,G) su router a basse risorse) → ip pim spt-threshold infinity; ma ricordare che così l’RP resta nel data path.
• RP posizionato all’edge con percorsi subottimali e traffico concentrato → ricollocare l’RP nel core vicino a sorgenti/ricevitori; lo switchover SPT mitiga ma non elimina il problema del path iniziale.