A civic VM moves from DC-East to DC-West over an EVPN-VXLAN DCI that stretches the tenant L2 VNI. Which EVPN behavior should operations expect?
Select an answer to reveal the explanation.
Short Explanation
When a VM packs up and moves across town, EVPN mobility is the change-of-address form that updates both fabrics. The MAC’s new location gets advertised so traffic stops chasing the empty rack. That is a big reason people stretch L2 with EVPN DCI carefully.
Full Explanation
When a civic VM moves from DC-East to DC-West over an EVPN-VXLAN DCI that stretches the tenant L2 VNI, operations should expect EVPN MAC mobility to update remote fabrics so the host’s MAC follows the move between interconnected DCs. EVPN signals the new Ethernet Segment/VTEP location with sequence-aware mobility so remote leaves/borders converge without permanent pinning to the old site. The old site does not permanently own the MAC such that remote sites must never update after the move; that behavior would blackhole the evacuated workload. MAC mobility is not disabled by definition across any DCI; multi-site L2 stretch designs explicitly rely on EVPN mobility updates across interconnected overlays. Operators should not have to clear all EVPN databases citywide before traffic resumes after every move—that is an emergency blunt instrument, not the expected steady-state behavior. Exam caveat: stretched L2 DCI implies MAC mobility signaling—plan for it rather than assuming sticky forever MACs or mandatory mass clears. Operational check: migrate a test VM across municipal DCs, watch Type-2 updates and sequence numbers on both borders, confirm the MAC’s next-hop VTEP switches to DC-West, and verify east-west flows resume without manual EVPN database wipes; note mobility timers in the runbook.