The NOC wants multicast optimization inside an EVPN-VXLAN civic fabric rather than pure unoptimized flooding. What high-level control-plane expectation is fair?
Select an answer to reveal the explanation.
Short Explanation
EVPN is not stuck in “flood the whole city” mode—it can signal smarter BUM/multicast membership so you are not photocopying every blast to every leaf blindly. Killing VNIs or disabling IGMP for “optimization” is the opposite of a plan. Ask for EVPN multicast-related control features, not nostalgia protocols.
Full Explanation
When the NOC wants multicast optimization inside an EVPN-VXLAN civic fabric rather than pure unoptimized flooding, a fair high-level expectation is that EVPN provides control-plane mechanisms related to multicast and BUM optimization—such as selective replication membership and EVPN multicast route signaling—beyond naive flood-everything behavior. Exact Junos feature names vary by release, but the exam-level idea is that EVPN can improve on pure flood-and-learn or unoptimized fan-out when applications need it.
EVPN is not limited to flooding every BUM frame to all VTEPs forever with no multicast-related mechanisms. Multicast optimization does not require deleting all VNIs and switching the pod to hub-and-spoke Frame Relay. Disabling IGMP everywhere so receivers cannot join groups is not an optimization—it removes receiver signaling.
Exam caveat: EVPN includes multicast/BUM optimization concepts beyond blind flood; know the architectural idea even when knob names differ.
Operational check: align BUM mode, IGMP/MLD snooping where applicable, and EVPN multicast capabilities with the application; compare BUM fan-out volume before and after enabling selective membership for a civic multicast group.