Protocol Independent Multicast is the tree-building protocol of practical multicast, and 'protocol independent' is literal: PIM invents no topology discovery, it simply uses the unicast routing table for its RPF decisions. Its dense-mode variant — flood everywhere, prune back — survives only in labs and legacy corners. Sparse mode inverted the assumption: nobody gets traffic until they explicitly join, which is the only model that scales, and the model that raises sparse mode's central puzzle. Receivers join a tree toward the source — but how does anyone know who the sources are? The rendezvous point is the answer: a router designated as the meeting place where sources are announced and the shared tree is rooted.
The three-act mechanism
- Receiver side: a host joins group G via IGMP; its last-hop router creates (*,G) state and sends a PIM Join hop-by-hop toward the RP. Each router on the way adds the interface to its outgoing list — the shared tree (RPT) grows branch by branch, entirely receiver-driven.
- Source side: a source just starts sending — sources never signal. Its first-hop router unicast-encapsulates the initial packets to the RP in PIM Register messages. The RP decapsulates, forwards down the shared tree, and joins (S,G) back toward the source so native traffic flows; a Register-Stop then ends the encapsulation.
- The optimisation: traffic now reaches receivers via the RP, which is rarely the shortest path. So the last-hop router, on seeing the first packets, sends an (S,G) join directly toward the source — switching to the shortest-path tree — and prunes the source from the shared tree. Cisco's default SPT threshold of zero means this happens immediately; the RP ends up handling introductions, not traffic.
Deploying the RP
Every router must agree on the RP-to-group mapping. Static configuration is fine for small domains; Auto-RP (legacy Cisco) and the standard Bootstrap Router (BSR) mechanism distribute mappings dynamically with candidate-RP election. Production designs use Anycast RP: two or more routers share one RP address on loopbacks, receivers and sources rendezvous at the nearest instance, and MSDP (or PIM anycast-RP, RFC 4610) synchronises source knowledge between the instances — RP failover becomes an IGP reconvergence, invisible to the multicast layer.
R(config)# ip multicast-routingR(config)# interface gi0/0R(config-if)# ip pim sparse-modeR(config)# ip pim rp-address 10.255.255.1R1# show ip mroute 239.1.1.10 | include Flags|RP (*, 239.1.1.10), 00:04:12/00:03:17, RP 10.255.255.1, flags: SJC
Reading and troubleshooting the trees
show ip mroute tells the whole story in flags: S sparse, J switched-to-SPT, C connected receiver, F registering source, T forwarding on SPT. The troubleshooting ladder rarely changes: RP mapping consistent everywhere (show ip pim rp mapping)? PIM neighbours up on every hop of both trees (show ip pim neighbor)? RPF check passing toward RP and source (show ip rpf x.x.x.x)? Registers arriving and being answered (debug ip pim on the RP)? Nine faults in ten are an RPF interface that unicast routing moved, or one router in the path with a different idea of who the RP is.
Where receivers' applications can name their sources (IGMPv3), Source-Specific Multicast deletes the whole middle of this chapter: no RP, no registers, no shared tree — last-hop routers join (S,G) directly in 232.0.0.0/8. New designs that can use SSM, should.