A stormwater bureau sees multicast video arrive at a router but get discarded before replication. Operators notice the source’s unicast best path is a different interface than the one that received the packet. What control-plane check most likely caused the drop?

When stormwater video arrives at a router but is discarded before replication, and the source’s unicast best path is a different interface than the arrival interface, the controlling check is Reverse Path Forwarding (RPF). PIM compares the incoming interface against the unicast RIB (or multicast RPF table) toward the source (or RP, depending on tree type). Mismatch fails RPF and the packet is dropped to prevent loops—classic silent multicast loss on civic WANs with asymmetric routing.

TTL expiration on the PIM Hello hold timer only affects neighbor adjacency freshness, not the data-plane decision to accept a video packet on the wrong interface. Hello-timer expiry is the wrong conceptual failure mode here.

IGMPv2 leave latency exceeding the last-member query interval can briefly keep forwarding toward a departing receiver; it does not discard packets already arriving on a non-RPF interface at a router.

DF bit enforcement on a GRE tunnel is a fragmentation/PMTUD concern. It is not the RPF interface check implied by mismatched unicast best path versus arrival interface.

Exam caveat: shared-tree traffic may RPF toward the RP while SPT traffic RPF toward S; always identify tree type before blaming the wrong route. Static mroutes or multicast RPF overrides may be required when unicast asymmetry is intentional.

Operational check: on the dropping router, compare the arrival interface of the stream with show ip rpf / mroute RPF interface for S (or RP). Fix unicast metrics, tunneling, or multicast RPF policy so civic camera replication resumes, and capture the before/after RPF interface in the incident notes.