EVPN VXLAN MAC Mobility Blackhole in a Dual-Homed Server Migration
An enterprise runs two data centers, DC-A and DC-B, each with 8 leaf switches, 2 spines, and 2 border leaves. The fabric uses VXLAN with BGP EVPN; the underlay is OSPF area 0. There are 620 VTEPs and roughly 14,000 MAC entries. A server team dual-homes a VMware cluster to leaf-03 and leaf-04 with a static port-channel; no ESI-LAG was configured. During a migration, 40 VMs are moved from leaf-03 to a new leaf-09. Within minutes, some flows between DC-A and DC-B stall for 20–40 seconds, then recover. Logs show EVPN MAC mobility sequence numbers for the affected VM MACs increasing rapidly, and duplicate-MAC alarms on leaf-04. ARP suppression is enabled on all leafs. The operations team wants to know whether to disable ARP suppression, add static MACs, or change the EVPN design.
1. What is the most likely root cause of the intermittent cross-site drops, and why are ARP suppression changes or static MAC entries the wrong first move?
Read the worked answer
The symptom pattern points to the server being dual-homed to leaf-03 and leaf-04 without an ESI-LAG, while the same VM MACs also appear on leaf-09 after migration. Each leaf is an independent VTEP and advertises the MAC with an EVPN MAC mobility sequence number. When the VM or its ARP entry moves, multiple VTEPs keep advertising the same MAC and keep increasing the sequence; EVPN may freeze the route or select the latest advertiser while stale ARP suppression entries remain. Traffic then follows a VTEP that no longer has the MAC, causing a 20–40 second blackhole until the route stabilizes. The duplicate-MAC alarms on leaf-04 support this. Disabling ARP suppression only removes the proxy ARP cache; it does not fix duplicate MAC ownership. Static MACs are worse because they hide mobility and can conflict with EVPN advertisements. Root fix: put leaf-03/04 in one ESI-LAG with a common ESI and DF election for the dual-homed server, ensure the migrated VMs are removed cleanly from leaf-03, and enable duplicate-MAC detection plus MAC mobility dampening. Verify with display evpn mac-route, display mac-address, and display evpn esi.
2. Propose a remediation and staged verification plan for the 40-VM migration, naming the EVPN controls you would enable and the evidence you would collect before and after each step.
Read the worked answer
Pre-check: record the MAC mobility sequence for all 40 VM MACs, confirm ESI-LAG state on leaf-03/04, verify VLAN-to-VNI mapping on leaf-09, and confirm no static MAC or ARP suppression conflict. Configure the ESI first and let EVPN converge before moving any VM. Enable duplicate-MAC detection and a conservative mobility threshold/dampening so a flapping MAC is frozen rather than permanently blackholed. Move 5 VMs as a canary; after each move, clear only the old dynamic MAC if needed, then check that display evpn mac-route shows one active advertiser with a stable sequence and that tracert between sites follows the expected leaf. Monitor duplicate-MAC alarms and BUM counters for 30 minutes. Only then move the remaining 35 VMs in batches of 10. Rollback is to move the batch back and remove the leaf-09 VNI/MAC ownership, not to disable ARP suppression fabric-wide. Keep a per-VM table of expected VTEP, ESI, and sequence so the evidence is auditable.