A retailer configured a static rendezvous point. Unicast routing reaches that address from the leaves, and receivers still cannot join the shared tree. PIM sparse mode is enabled on the transit links and is missing on the loopback that owns the rendezvous-point address. What must be enabled on that loopback?
Select an answer to reveal the explanation.
Short Explanation
The street address is real, and your office never opened. NX-OS requires PIM sparse mode on the loopback that owns the rendezvous-point address, because unicast reachability alone does not put that interface in PIM.
Full Explanation
PIM sparse mode builds the shared tree toward the rendezvous point. The interface whose address is the rendezvous point has to run PIM sparse mode, or the router is not actually a PIM rendezvous point on that address and joins do not complete. A second static rendezvous point for the same group splits the shared tree. It does not fix a loopback that is not in PIM. Dense mode floods and prunes. Turning it on only for the receiver VLAN does not create the sparse-mode shared tree this group is using. HSRP elects a gateway. It is not part of rendezvous-point configuration, and preemption will not process joins. Caveat: every router that must use this rendezvous point still needs the same RP address for the group. Fixing the loopback does not help a leaf that points at a different RP. Operational check: confirm PIM sparse mode is on the RP loopback, then look for the shared-tree join from a receiver VLAN. Use the same rendezvous-point address on every router that forwards this group. A leaf that still points at a different address will build its shared tree in the wrong place even after this loopback runs PIM.