City architects ask how VTEPs can learn remote MAC and IP mappings for municipal workloads without relying on endless unknown-unicast flooding. Which control-plane approach best answers that design goal?
Select an answer to reveal the explanation.
Short Explanation
Picture each leaf as a city branch that used to shout every unknown address into the street until someone answered. EVPN is the shared directory: VTEPs advertise MAC/IP mappings over BGP so you stop living on endless flood-and-learn. Flood-only designs still work in a pinch, but they do not scale like a real municipal fabric directory.
Full Explanation
City architects who want VTEPs to learn remote MAC and IP mappings for municipal workloads without endless unknown-unicast flooding should use EVPN—typically Multiprotocol BGP with the EVPN address family—so VTEPs advertise MAC/IP bindings as control-plane routes. That replaces perpetual flood-and-learn discovery with scalable distribution of host reachability across the civic VXLAN fabric while the underlay continues to provide only VTEP IP reachability.
Keeping flood-and-learn only and enlarging every underlay broadcast domain until every MAC appears scales poorly and reintroduces large L2 failure domains the Clos was meant to escape. Replacing every VNI with a unique OSPF area so the underlay IGP carries tenant MAC tables confuses underlay routing with overlay MAC distribution—OSPF does not advertise tenant MACs as EVPN does. Disabling VXLAN UDP ports and bridging department VLANs straight across the leaf-spine underlay abandons the overlay model and stretches L2 across the fabric core.
Exam caveat: for JNCIP-DC scalable remote learning, prefer EVPN-based MAC/IP distribution over classic flood-and-learn as the control-plane answer.
Operational check: enable EVPN AFI/SAFI on lab leaves, advertise a test MAC/IP, confirm remote leaves install Type-2 routes without relying on unknown-unicast flooding, and compare BUM rates before versus after EVPN learning.