A regional hospital sends multicast video from a source that is registered, but receivers on another leaf get no stream. That leaf's unicast route to the source points out a different interface than the one where the multicast packets arrive. Which check is dropping the stream?
Select an answer to reveal the explanation.
Short Explanation
You can spot the issue by comparing where the multicast packet arrives with the interface your unicast route uses to reach the source. A failed RPF check drops the stream; HSRP elects a gateway but does not filter this multicast traffic.
Full Explanation
PIM forwards a multicast packet only when it arrives on the reverse-path interface toward the source, or toward the rendezvous point for the shared tree. Here, the leaf’s unicast route to the source points to a different interface from the one where the stream arrives, so the packets fail the RPF check and are dropped even though receivers exist and the source is registered. Correcting the unicast route or the interface the stream uses can make RPF pass. HSRP elects which router owns a virtual gateway IP; it does not accept or drop multicast data based on the source route. The vPC peer-gateway setting lets a peer route packets addressed to the other peer’s MAC; it does not compare the multicast ingress interface with the unicast route to the source. An OSPF stub-flag mismatch prevents an adjacency, but this leaf already has a route, so that flag is not what discards the video. Exam caveat: a stale static multicast route or an incorrect rendezvous-point address can cause RPF failure even when ordinary unicast routing looks correct, so check which address the multicast tree uses. Practical check: compare the stream’s ingress interface with the unicast next hop toward the source, then confirm that the group forwards after they match.