PIM-SM Across a VPN: Check BSR, RP Mapping and RPF Paths

The tunnel is up, unicast pings cross it, and the receiver still shows a black screen. In a PIM-SM deployment that symptom almost always means one of four control paths is broken, and the data path itself was never the problem. Work the list below in order and stop at the first step that fails, because every later step depends on the one before it. I keep these five probes in a scratch file and paste them into a terminal when a multicast complaint lands, which keeps the diagnosis from turning into guesswork.

Start with the receiver, not the tunnel

A receiver that never asked for the group produces no state on any router, so confirm the join exists on the receiver-facing segment before you inspect anything else. On Cisco-style platforms, show ip igmp groups on the last-hop router prints the joined groups next to the interface that heard them. When the group is missing from that output, the tunnel is a distraction: the request died at the access switch, at the host socket, or in a VLAN that has no querier.

Two mundane causes account for most missing joins I have seen: an IGMP version mismatch between host and router, and a querier election that landed on a switch which does not route. A third is subtler, in that the group is joined but on the wrong VLAN because the host has two NICs and the application bound to the wrong one. IPv6 receivers have the equivalent problem with MLD, where show ipv6 mld groups answers the same question. None of these are fixed by touching the tunnel, which is exactly why the order matters.

Once the join is visible, confirm that PIM is enabled on both the receiver-facing interface and the interface that leads toward the rendezvous point. A router with IGMP membership but no PIM on its upstream interface will hold the group in a local table and send nothing anywhere.

Does the BSR set reach the far side?

Bootstrap Router messages move hop by hop inside a single PIM domain, and that is the direction that breaks across a tunnel. Candidate RPs send their advertisements to the elected BSR by unicast, so the RP-to-BSR leg usually survives a working tunnel unchanged. The flood of Bootstrap messages in the other direction depends on every intermediate interface having PIM enabled, and on nothing stopping the messages at a boundary. RFC 5059 defines that distribution and the administrative scope boundaries that are allowed to cut it short.

An ip pim bsr-border statement, an ACL that filters protocol 103, or a policy-based IPsec tunnel that cannot carry multicast will each cut the flood while leaving unicast intact. That combination is what makes the failure look like an RP problem when it is really a reachability problem, and it is why I read the BSR state before I read the RP configuration.

On the far-side router, show ip pim bsr-router names the elected BSR and the RP set it learned; if the output is empty, the far side sits in its own domain and no amount of RP configuration will reconcile the two. Compare the group ranges and the RP addresses in show ip pim rp mapping on both sides of the tunnel. A mapping that exists only locally produces a shared tree that terminates in the wrong place, and the receiver waits forever.

Match the RP mapping on both sides of the tunnel

Static RP, BSR and anycast-RP are three ways to answer the same question, and mixing them across a tunnel is a reliable way to build a domain that never converges. If the head end uses BSR and the branch uses a static ip pim rp-address pointing at a different address, the branch builds its shared tree toward an RP that has no idea the receiver exists. The mapping has to agree on the group range as well as on the address, since a more specific range wins over a broader one.

Anycast-RP exists precisely so that two sites can share one RP address, and it is worth naming here because it changes what "the same RP" means. Two RPs advertising one address are consistent by design; two RPs advertising different addresses for the same range are not, no matter how healthy each site looks on its own.

For source-specific multicast inside 232.0.0.0/8, the RP is never consulted, so an empty RP mapping is not automatically a fault. Decide which service model the application uses before chasing an RP that was never needed.

Read the RPF lookup toward the source

PIM builds a tree by reversing the unicast path, so the check that matters is the route back to the source, or back to the RP for a shared tree. A join that arrives on an interface the router does not consider upstream is dropped, and the reason is logged as an RPF failure rather than as a tunnel failure. On a branch router with a default route over the tunnel and a more specific route over the WAN, the RPF interface can easily be the WAN even though the source is only reachable through the tunnel. That is the single most common reason a join gets silently discarded.

show ip rpf 192.0.2.10 prints the chosen interface, the next hop and the route that produced the decision, which is usually enough to see the mismatch. A static multicast route such as ip mroute 192.0.2.0 255.255.255.0 tunnel0 overrides the unicast lookup for that prefix, and it is a legitimate fix when the multicast topology genuinely differs from the unicast topology. Treat it as configuration to be documented, not as a patch applied during an incident and then forgotten.

Confirm the join with commands, not with a ping

Ping proves that unicast works, which you already knew. The end-to-end confirmation is a sequence that shows the join, the mapping, the neighbor and the tree in that order, and each command answers a different question.

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

A populated (S,G) entry with a real incoming interface and a non-empty outgoing list means the control plane finished its job. An entry whose incoming interface reads Null, or a counter labelled RPF failed that keeps climbing, points back at the previous section rather than at the tunnel.

If all five commands look right and the receiver still sees nothing, the remaining suspect is the tunnel's own policy: a crypto ACL or firewall rule that permits the unicast routing protocol but not PIM, IGMP, or the group traffic itself. On a policy-based IPsec tunnel, multicast is not carried at all, so the answer is a GRE or VTI design rather than another filter exception. Write down which of the five probes failed before you change anything, then change only that layer.