Duplicate MAC Mobility Across an EVPN Multihomed ESI
A 6-leaf, 2-spine EVPN-VXLAN fabric uses edge-routed bridging with a distributed anycast gateway: the same IP and MAC for VLAN 110 exist on every leaf. VLAN 110 is stretched across leaf-03 and leaf-04. A dual-homed database server uses LACP active-active with an ESI-LAG configured on both leaves. After a NIC firmware upgrade, the server begins sourcing traffic from a new MAC address for the same IP. Within minutes, leaf-03 and leaf-04 log EVPN MAC mobility limit exceeded and the host route is dampened for 15 minutes. Other hosts on VLAN 110 intermittently lose connectivity to the server. The EVPN database on leaf-05 shows the server MAC alternating between next hops 10.0.0.13 and 10.0.0.14, with sequence numbers incrementing. Underlay BGP is stable and all VTEP loopbacks are reachable. No fabric changes were made.
1. Which component should you inspect first, and what evidence distinguishes a true MAC move from a local ESI forwarding artifact?
Read the worked answer
Do not start by raising the mobility limit. The first check is whether the two leaves agree that the server is local to the same ESI. On a correct ESI-LAG, both leaves share one ESI and one LACP system ID; the server MAC is learned locally on each leaf, and EVPN multihoming treats the two next hops as members of the same ESI, not as a remote MAC move. Run show lacp interfaces ae0 on both leaves and compare the system ID; run show evpn instance VLAN110 extensive and compare the ESI and designated-forwarder state; run show evpn database and look for the ESI next to the MAC. If the ESI values differ, or if the LACP system IDs differ, each leaf sees the other as a remote VTEP and increments the mobility sequence. That produces exactly the alternating next hops and dampening. The server firmware change is a red herring; a new MAC for the same IP would be a single move, not a sustained fight between two leaves. Also verify the server bond is not using two independent MACs on the same IP, which would be a genuine mobility event, but that would not normally hit the limit within minutes unless the bond is flapping.
2. What immediate mitigation would you apply, and what permanent fix prevents recurrence?
Read the worked answer
Immediate: identify the dampened MAC, clear the EVPN MAC entry and the proxy ARP/ND entry so traffic can resume: clear evpn database mac-address <mac>, clear evpn arp-cache, and clear arp. If the fabric is production and the ESI fix cannot be made at once, temporarily raise the mobility limit only as a measured stopgap, because it hides the underlying disagreement and can cause a forwarding loop or duplicate MAC learning. Do not disable MAC mobility damping globally. Permanent fix: make the ESI and LACP system ID identical on both leaves, use a unique ESI per LAG, and confirm the server's LACP bond uses one system ID. After the change, clear the EVPN database and verify the MAC is installed with the expected ESI on both leaves and learned as a single local ESI on remote leaves. If the server genuinely changes MAC per boot, fix the server bond or enable a mobility policy with a higher threshold for that specific MAC, but only after the ESI is proven correct.
3. Why did hosts on other leaves lose connectivity to the server, and what check confirms that ARP suppression is involved?
Read the worked answer
The server's IP-to-MAC binding is cached in the leaf's EVPN ARP/ND proxy table. When the MAC route is dampened or withdrawn, the cached binding can still point to the old next hop, so the leaf answers ARP for the server with stale information and blackholes the traffic. This is why unrelated hosts on VLAN 110 fail even though their own routes are fine. Confirm with show evpn arp-cache for the server IP, show arp no-resolve on the leafs, and show ethernet-switching table for the MAC. Clear the proxy entries and test. If the problem returns while the ESI issue is open, disable ARP/ND suppression on VLAN 110 as a temporary measure; that increases BUM traffic but removes the stale proxy. Do not treat ARP suppression as the root cause; it only amplifies a bad EVPN MAC state.