Ridondanza RP: Anycast RP e MSDP

Il problema: PIM-SM e il singolo RP

In PIM Sparse Mode ogni gruppo multicast è ancorato a un Rendezvous Point (RP): le sorgenti si registrano verso l’RP con un messaggio PIM Register, i receiver costruiscono lo shared tree (RPT) verso lo stesso RP. Un RP unico è un single point of failure e non consente load sharing: tutte le registrazioni convergono su un solo router. Serve un design che offra sia ridondanza sia distribuzione del carico, con failover rapido e trasparente.

Anycast RP: un indirizzo, più RP

Anycast RP consiste nel configurare lo stesso indirizzo IP di RP (tipicamente una Loopback /32) su due o più router, annunciandolo nell’IGP (OSPF/EIGRP). Grazie all’unicast routing, ogni sorgente e ogni receiver raggiunge l’RP più vicino con quell’indirizzo condiviso.

Vantaggi immediati:

• Load sharing: le sorgenti si registrano sull’RP topologicamente più vicino, distribuendo lo stato (S,G).
• Failover a velocità IGP: se un RP cade, l’IGP riconverge e l’indirizzo anycast viene servito dal secondo RP. Nessun cambio di configurazione, nessuna rielezione di protocollo — failover sub-secondo e trasparente per gli host.

C’è però un problema di sincronizzazione dello stato: l’RP1 conosce solo le sorgenti registrate su di sé, l’RP2 solo le proprie. Un receiver ancorato a RP2 non saprebbe nulla di una sorgente registrata su RP1. Qui entra MSDP.

MSDP: sincronizzare le Source-Active

Il Multicast Source Discovery Protocol (MSDP) — nato per il multicast inter-dominio — viene riutilizzato intra-dominio per collegare fra loro gli RP anycast. Ogni RP che riceve un Register origina un messaggio Source-Active (SA) contenente (Source, Group, RP-originator) e lo propaga ai peer MSDP. Così tutti gli RP conoscono tutte le sorgenti attive: RP2 apprende via SA le sorgenti registrate su RP1 e può costruire lo shared tree correttamente.

Peering, RPF e mesh group

• I peer MSDP non devono usare l’indirizzo anycast: serve una loopback unica per il peering (connect-source / originator-id), altrimenti il peer-RPF check sugli SA fallisce.
• Fra gli RP anycast (peer full-mesh) si configura un MSDP mesh-group: gli SA ricevuti da un membro non vengono ri-inoltrati agli altri membri e il peer-RPF viene bypassato, evitando loop e duplicazioni.

! RP1 (RP2 speculare)
interface Loopback0
 ip address 10.0.0.1 255.255.255.255   ! anycast RP (condiviso)
interface Loopback1
 ip address 10.1.1.1 255.255.255.255   ! indirizzo MSDP unico
ip pim rp-address 10.0.0.1
ip msdp peer 10.1.1.2 connect-source Loopback1
ip msdp originator-id Loopback1
ip msdp mesh-group ANYCAST 10.1.1.2

Anycast RP vs Auto-RP vs BSR

Punto chiave d’esame: Auto-RP e BSR forniscono ridondanza ma non load sharing e il failover dipende dai timer di protocollo. Anycast RP offre ridondanza + load sharing con failover a velocità IGP, ed è complementare agli altri: l’indirizzo anycast può essere distribuito proprio via static, Auto-RP o BSR.

Design guideline (ENSLD)

Scegli Anycast RP + MSDP quando i requisiti sono alta disponibilità dell’RP e distribuzione del carico in un dominio enterprise. Posiziona gli RP nel core/distribution, usa loopback dedicate e assicura che l’indirizzo anycast sia raggiungibile in modo simmetrico dall’IGP.

Trappole tipiche d’esame

• Anycast RP senza peering MSDP → gli RP non si scambiano gli SA: i receiver ancorati a un RP non ricevono le sorgenti registrate sull’altro e il failover non è trasparente (stato (S,G) non sincronizzato). Risposta: manca il peering MSDP.
• Peer MSDP configurati sull’indirizzo anycast → il peer-RPF check fallisce e gli SA vengono scartati. Risposta: usare una loopback unica con connect-source/originator-id.
• SA duplicati o loop tra RP full-mesh → manca il mesh-group. Risposta: configurare ip msdp mesh-group.
• Scenario che chiede load sharing degli RP: Auto-RP e BSR non lo forniscono (sono active/standby). Risposta corretta: Anycast RP.
• Scenario che chiede il failover più rapido possibile dell’RP: non affidarsi ai timer di Auto-RP/BSR ma all’IGP → Anycast RP.