An enterprise video team reports duplicate multicast streams looping between two distribution routers during a PIM deployment with redundant paths. Engineers need loop-free forwarding without relying on TTL. Which RPF check behavior for multicast loop prevention should they validate in the design?
Select an answer to reveal the explanation.
Short Explanation
You're stopping copies from circling forever, and direction matters. RPF accepts traffic only from the best path back to the source. It's like only trusting directions from someone facing home.
Full Explanation
Loop-free PIM forwarding depends on Reverse Path Forwarding, which consults the unicast table for the source and accepts a packet only when it arrives on the interface that would be used to reach back toward that source, discarding other arrivals to break loops between redundant routers without using TTL. Accepting RPF-checked packets on any redundant interface for resilience keeps the lookup but removes the interface constraint that makes RPF effective, so duplicates on non-RPF paths would still be forwarded and the loop would persist. Relying on TTL decrement and threshold discard is valid for unicast loop mitigation, yet it violates the explicit no-TTL requirement and is ineffective here because multicast packets can duplicate many times before expiration while wasting bandwidth. Using PIM assert election on a LAN is standard for selecting a single forwarder when multiple routers forward the same group, but it acts after forwarding to resolve duplication rather than preventing loops at the forwarding decision like RPF. An exam caveat is to distinguish RPF toward the source for shortest-path trees from RPF toward the RP for shared trees and not confuse either with TTL or assert logic. A practical check is to run show ip rpf and show ip mroute on both routers and confirm the incoming interface for the S,G entry matches the unicast next hop toward the source.