The city wants efficient multicast for IPTV receivers inside a tenant VNI on the EVPN-VXLAN fabric. Which statement best reflects EVPN multicast concepts at professional depth?
Select an answer to reveal the explanation.
Short Explanation
IPTV in a VNI should not mean "blast every leaf in the county." EVPN multicast features let the fabric signal who cares about which groups and tighten BUM delivery. Blind underlay floods and Type-5-only thinking miss that overlay signaling.
Full Explanation
At professional depth, EVPN multicast concepts mean the overlay can signal which VTEPs care about BUM or group traffic for a VNI and can optimize distribution—via inclusive IMET membership, selective interest signaling where supported, and coordination with IGMP/MLD snooping—rather than blindly flooding IPTV to every device in the underlay. Municipal IPTV receivers inside a tenant VNI should remain inside that tenant's broadcast domain and follow EVPN-VXLAN multicast design, not underlay-wide broadcast. Disabling all EVPN signaling and flooding IPTV as broadcast to every underlay router destroys tenant isolation and wastes fabric bandwidth. Using only Type-5 default routes does not convey multicast group interest; prefixes are L3 unicast reachability. Forcing every IPTV packet through a single spine CPU without VXLAN encapsulation abandons the overlay architecture and creates a chokepoint. Exam caveat: inclusive replication is simpler but can tax ingress leaves; selective multicast reduces copies but requires correct interest signaling—know which mode the city platform actually supports. Operational check: place IPTV receivers on a subset of leaves, confirm EVPN multicast/BUM membership reflects those leaves and snooped groups if selective, capture that non-member leaves do not receive the stream, and verify other tenants' VNIs stay free of the multicast.