City engineers see EVPN Type-2 routes for a server MAC and IP on the municipal leaf fabric. What is the primary purpose of those Type-2 advertisements?
Select an answer to reveal the explanation.
Short Explanation
Think of Type-2 as the fabric's host phone book: which leaf owns this MAC—and often which IP rides with it. City servers show up there so remote VTEPs can unicast without guessing. It is not the underlay map and not the BUM roll call.
Full Explanation
EVPN Type-2 MAC/IP Advertisement routes are the municipal fabric's control-plane record of where an end-host MAC lives, and they may also carry the host IP so integrated routing and bridging and ARP/ND suppression can work without flooding every request. On a city leaf-spine EVPN-VXLAN design, remote VTEPs install those Type-2s and unicast overlay frames toward the owning leaf instead of guessing. That is why advertising MAC, and optionally IP, host reachability for Layer 2 and Layer 3 overlay forwarding is the primary purpose of Type-2. Underlay IGP or BGP prefixes that build Clos ECMP among loopbacks are a separate IP-fabric concern; spines do not learn server MACs from Type-2 in order to replace the underlay. Ethernet Segment identifiers and Designated Forwarder context are carried by Ethernet Auto-Discovery and Ethernet Segment routes (Type-1/Type-4 families), not by Type-2 alone. Inclusive multicast / IMET membership that tells VTEPs who participates in a VNI for BUM is Type-3, not Type-2. Exam caveat: Type-2 may be MAC-only or MAC+IP depending on what was learned and whether IRB/suppression features need the IP binding—do not assume every Type-2 must include an IP, and do not confuse optional IP binding with Type-5 prefix routing. Operational check: on a leaf that owns a municipal server, confirm the host MAC (and IP if expected) appears as an EVPN Type-2 advertisement, that remote leaves import it under the correct route targets, and that traffic to that MAC is VXLAN-unicast to the advertising VTEP rather than flooded fabric-wide.