A city public-works team must keep administratively scoped site-local multicast groups from being forwarded onto the WAN. Which mechanism directly enforces that containment?
Select an answer to reveal the explanation.
Short Explanation
Scoped groups are the “employees only” hallway—fine inside the building, not across the city WAN. A multicast boundary on the WAN edge is the door lock that drops those ranges before they leak. Without it, site-local chatter rides outbound like any other group.
Full Explanation
City public-works often uses administratively scoped site-local multicast (commonly policies within 239.0.0.0/8) that must not leak onto the WAN. A multicast boundary (or equivalent TTL/scope filter) on WAN-facing interfaces directly enforces that containment for both data and, typically, unwanted join propagation for filtered ranges. That is the precise mechanism for keeping yard-local groups on-site.
Increasing OSPF reference bandwidth only skews unicast metric calculation. It does not filter scoped multicast groups at the site edge.
Disabling IGMP snooping on access switches facing WAN routers increases Layer-2 flooding risk and does nothing to enforce administrative scope on the WAN handoff.
Forcing civic cameras into PIM Dense Mode on the core worsens flood behavior and is unrelated to scoped-range containment on WAN interfaces.
Exam caveat: boundaries must be applied consistently on every exit path (dual WAN routers, DMZ links); a single unfiltered uplink defeats the scope policy.
Operational check: configure multicast boundaries for the site-local ranges on all WAN-facing interfaces, attempt a join from a remote site, and verify the group neither forwards nor builds external tree state. Record the scoped ranges in the public-works multicast standard.