After enabling multihoming on a municipal server ESI, ops confuses EVPN Type-1 with Type-2. What role do Type-1 Ethernet Auto-Discovery routes primarily play?
Select an answer to reveal the explanation.
Short Explanation
Type-1 is the multihoming paperwork for an Ethernet Segment—aliasing and fast mass withdraw when a link fails—not the host MAC flyer. Type-2 still advertises the servers. Mixing them up is like confusing the lease document with the tenant's name on the mailbox.
Full Explanation
EVPN Type-1 Ethernet Auto-Discovery routes support multihoming behaviors on an Ethernet Segment: mass withdraw when a multihomed interface fails, aliasing so remote VTEPs can load-balance or fail over across segment members, and related Ethernet Auto-Discovery signaling alongside the ESI context. After a municipal server is dual-homed, confusing Type-1 with Type-2 mixes host MAC reachability with segment-level multihoming control. Type-1 does not replace Type-2; hosts still need MAC(/IP) advertisements for unicast overlay forwarding. Type-1 is not an IGMP-join transport that forces underlay PIM; multicast interest and BUM membership use Type-3/SMET-style mechanisms and local snooping, independent of making PIM mandatory. Type-1 also does not advertise a tenant VRF default route—the way prefixes and defaults move in L3 EVPN is Type-5 (and routing-policy design), not Auto-Discovery. Exam caveat: per-ES and per-EVI Auto-Discovery variants exist in the EVPN toolbox; JNCIP-DC emphasis is on the multihoming roles (withdraw, aliasing, ES readiness) rather than memorizing every subtype code in isolation from Type-2 host routes. Operational check: on a dual-homed municipal ESI, confirm Type-1 A-D routes are present for the segment, fail one access link, and verify remote leaves mass-withdraw or re-resolve toward the surviving PE without waiting for every Type-2 to time out individually; also confirm Type-2 host routes still advertise from the remaining leaf.