A retail chain streams training video from headquarters to 200 stores over the overlay. The design names two data-center edges as replicators, stores act only as receivers, and PIM runs only on store LANs. Which role behavior should the engineer verify to ensure overlay multicast delivery works as designed?
Select an answer to reveal the explanation.
Short Explanation
Getting the fan-out backwards breaks video fast. You keep it working when replicators copy once and receivers simply join locally with PIM.
Full Explanation
The design calls for overlay multicast with hierarchical replication, so the two data-center edges must act as replicators that receive one copy from headquarters and then fan out copies over unicast tunnels across the overlay, while the 200 store edges remain receivers-only that signal local interest with service-side PIM on their LANs. The native-multicast-on-transport behavior fails because it assumes PIM and multicast forwarding in the underlay, which contradicts the stated overlay-only transport with PIM confined to store LANs and would require provider support that is not in scope. The behavior with PIM joins toward the transport core fails because it moves the join state and rendezvous function into the WAN, whereas the design isolates PIM to the service side at stores and uses overlay control plane for distribution. The headend direct per-store unicast behavior fails because it bypasses the two designated replicators and forces the source to sustain 200 parallel copies, losing the scalability and redundancy purpose of replicator hierarchy despite correctly using service-side joins. Exam caveat: do not equate any PIM visibility with overlay multicast working, since LAN PIM only expresses local interest and delivery still depends on overlay tunnels and replicator roles. Practical check: verify replicator tunnel counts and replication state plus store IGMP/PIM join state and RPF toward the service VPN, then confirm video flows when a store joins and stops when it prunes.