EVPN ESI Mismatch on a Dual-Homed Server
A data center uses EVPN-VXLAN with two spines and four leafs. Each leaf has a loopback in 10.0.0.0/24 carried by the underlay IGP. A dual-attached database server connects to leaf1 and leaf2 with a two-member LAG in all-active mode. The intended ESI is 00:11:22:33:44:55:66:77:88:99 and is configured on leaf1. On leaf2 the ESI was typed as 00:11:22:33:44:55:66:77:88:98, but the LAG itself is up and passing traffic locally. The server MAC 00:aa:bb:cc:dd:ee is advertised from both leafs. Leaf3 logs a MAC move every few seconds, and some flows to the server drop for a few seconds at a time. show evpn ethernet-segment on leaf2 shows the wrong ESI and a designated-forwarding role. BUM traffic from leaf3 is also received twice at the server.
1. Explain why leaf3 sees MAC moves and why BUM traffic is duplicated, and describe the correct configuration and verification.
Read the worked answer
The ESI is the identity of the Ethernet segment. Because leaf1 and leaf2 advertise different ESIs, EVPN does not recognize the server as dual-homed to one segment; it sees the same MAC arriving from two independent single-homed segments behind two different VTEPs. Each advertisement looks like a MAC move, so the sequence number increments, the older path is withdrawn, and traffic alternates between leaf1 and leaf2. The brief drops are the withdrawal and re-advertisement intervals.
BUM duplication has the same root cause. Designated forwarder election runs per Ethernet segment per VLAN. With two different ESIs, each leaf is the only member of its own segment and therefore the DF for it. Both forward broadcast, unknown unicast, and multicast toward the server, so the server receives duplicates.
Fix: configure the same ESI, 00:11:22:33:44:55:66:77:88:99, on leaf2's LAG, with all-active mode on both leafs. The ES-Import route target derived from the ESI then matches automatically, and the remote leaf installs one MAC path with aliasing toward both VTEPs. The DF election picks one leaf per VLAN for BUM forwarding.
Verify with show evpn ethernet-segment on both leafs (same ESI, DF status complementary), show evpn mac-table on leaf3 (one MAC, remote, with the expected ESI), and confirm MAC move messages stop.
2. After the ESI fix, unicast to the server works but the server still receives duplicate multicast from a source behind leaf3. What would you check next?
Read the worked answer
The ESI fix corrects the segment identity, but duplicate BUM delivery can still occur if the DF election or the VNI mapping is inconsistent. First check show evpn ethernet-segment on leaf1 and leaf2 for the same ESI and for complementary DF roles for the VLAN carrying the multicast group. If both show designated forwarding, the segment is not being treated as one and the ESI, LAG ID, or VLAN-to-VNI mapping still differs.
Second, check that the VNI and route targets match on both leafs for that VLAN. If leaf1 and leaf2 map the VLAN to different VNIs, the remote leaf may replicate into two different VXLAN tunnels that both reach the server.
Third, confirm the server's LAG hashing and whether it is dual-attached in a way that both links can receive the same frame. Some servers or switches with misconfigured LACP may flood received multicast back out the other member link; check interface counters on both leafs for the same frame arriving twice.
Finally, check for an unintended PIM or IGMP snooping configuration that is replicating the group at Layer 3 in addition to EVPN BUM forwarding. The verification point is that exactly one DF should forward the BUM frame into the segment for each VLAN.