A national retailer uses PIM sparse mode for one group. The source and the receivers are up, unicast between them works, and the two leaves list different static rendezvous points for that group. Why does the shared tree fail to form?
Select an answer to reveal the explanation.
Short Explanation
PIM sparse mode is a meeting that only happens if everyone walks to the same rendezvous point. You sent the leaves to two different static rendezvous points for one group, so the joins and the register never meet. Unicast between the hosts can still work, because this failure is the shared tree, not the unicast route.
Full Explanation
PIM sparse mode builds a shared tree rooted at the rendezvous point. The last-hop router sends joins toward the rendezvous point it has configured for the group, and the router nearest the source registers the source to the rendezvous point it has configured. When two leaves list different static rendezvous points, those joins and registers go to different places and one shared tree never forms, even though ordinary unicast between the hosts still works. That split is the retailer's failure. HSRP elects a gateway for a VLAN. It does not drop a multicast group because preempt is off, and preempt is an HSRP behavior, not a PIM tree builder. The vPC peer-keepalive tells a vPC pair whether the peer is alive. It does not elect a rendezvous point, and many of these leaves are not decided by one keepalive. A stub OSPF area changes which link-state advertisements are exchanged. The stem already says unicast works, so the underlay is not blocking the source from reaching the receivers. Caveat: source-specific multicast does not use a rendezvous point, so this diagnosis applies to the shared-tree group in the question, not to a source-specific group. Operational check: set the same static rendezvous point for the group on every participating router, then confirm joins and the source register converge on that one address.