A regional bank streams market data via PIM sparse-mode to trading floors in three sites. During failover testing, a core router receives the same source packet on two interfaces and designers worry about a routing loop amplifying traffic. Which RPF check behavior should the designer validate to ensure loop-free multicast forwarding?
Select an answer to reveal the explanation.
Short Explanation
You've got this — multicast has no TTL safety net like unicast loops do. Your guardrail is the RPF check, like accepting a delivery only from your usual courier's door.
Full Explanation
Reverse path forwarding prevents multicast loops by tying forwarding to the unicast routing table, so a router accepts a multicast packet only if it arrives on the interface it would use to reach the source, which guarantees a loop-free tree back toward the origin and causes duplicates arriving on non-RPF interfaces to be discarded. Forwarding based only on group membership fails by concept because outgoing interface list membership controls where copies go, not whether the received copy was looped. Flooding to all PIM neighbors except the arrival interface fails by concept because that is a spanning approach without a source-oriented check and would still replicate loops. Relying on an assert election fails by concept because asserts elect a single forwarder on a multi-access LAN to stop duplicates, but they do not validate the upstream path toward the source. For the exam, remember RPF uses the unicast table, static mroutes, or MBGP, not the multicast table itself, and a practical check is to verify show ip rpf aligns with the expected incoming interface before enabling dense traffic sources.