Municipal security wants multicast for one tenant contained so it does not leak into other tenants' broadcast domains. What EVPN-VXLAN principle applies?
Select an answer to reveal the explanation.
Short Explanation
Each tenant VNI is its own multicast neighborhood—keep the noise inside that broadcast domain. Do not build one megaphone for every VRF or flatten everyone into VLAN 1. Type-4 is about Ethernet Segments, not merging tenant multicast universes.
Full Explanation
In EVPN-VXLAN, multicast and BUM are scoped by VNI and tenant broadcast-domain boundaries. Municipal security containment means IPTV or other multicast for one tenant stays inside that tenant's VNI/MAC-VRF, not in a fabric-wide flood domain shared with every VRF. All VNIs must not share one multicast tree that reaches every VRF—that would be a containment failure. Disabling VNIs and bridging all tenants into VLAN 1 collapses isolation. Type-4 ES routes do not merge tenant multicast domains by design; they support multihoming for a segment within the intended overlay context. Exam caveat: route-target leaks or shared L2 VNIs across tenants can accidentally merge domains even when multicast features look correct—containment is as much RT/VNI design as IGMP. Operational check: source multicast in tenant A, confirm tenant B VNIs show no receivers and no forwarded frames, verify RT import/export does not leak A into B, and repeat the test after any DCI or VRF-stitching change that might broaden membership. Treat RT and VNI hygiene as part of the security boundary for municipal multicast tenants, equal in importance to IGMP features. Treat RT and VNI hygiene as part of the security boundary for municipal multicast tenants, equal in importance to IGMP features.