Duplicate BUM Traffic After Adding a VLAN to an EVPN Multihomed Server
A four-leaf, two-spine EVPN-VXLAN fabric uses QFX5120-32C leaves and QFX5120-48Y spines. Each leaf has an anycast VTEP address and 2x100G uplinks. Twelve dual-homed servers use ESI-LAG with all-active multihoming. The fabric carries 48 VLANs, each mapped one-to-one to an EVPN instance. During a change to add VLAN 210 for a backup network, the engineer adds VLAN 210 to both member links of ESI 00:11:22:33:44:55:66:77:88:99 on leaf1 and leaf2, but the server team reports broadcast storms and duplicate ARP replies. You have no maintenance window; the change must be corrected during a 30-minute window. The leaves run Junos 21.4R3. You cannot take down the ESI-LAG.
1. A colleague says 'both leaves see the ESI, so the DF must be fine.' What command output would you use to test that assumption, and what fields prove or disprove it?
Read the worked answer
DF election is per ESI and per VLAN; seeing the ESI on both leaves proves only that the ESI is configured, not that VLAN 210 belongs to the same EVPN instance on both. Run show evpn instance extensive and show ethernet-switching evpn designated-forwarder on both leaves, then compare the DF state for VLAN 210 and the ESI. A true DF mismatch shows one leaf as DF and the other as non-DF for the same ESI/VLAN, or both as DF because the ESI or VLAN-to-EVI mapping differs. A Layer 2 loop instead shows MAC moves, rising storm-control counters, and broadcast counters on multiple access ports; DF output may look correct. Also check show evpn instance extensive for the local and remote VTEP and the EVI's VLAN list. If leaf2 has VLAN 210 as a plain VLAN and not in the EVPN instance, it will not participate in DF election and will flood BUM locally while leaf1 also floods, producing duplicate ARP.
2. List the configuration deltas you would compare on leaf1 and leaf2, and give the minimal correction if VLAN 210 is present on only one leaf's EVPN instance.
Read the worked answer
Compare show configuration interfaces ae0 for ESI and LACP system ID, show configuration vlans VLAN210, show configuration protocols evpn, and show configuration switch-options. The usual delta is that VLAN 210 exists under vlans on both leaves but is missing from the EVPN instance on leaf2, or the ESI is applied to ae0 on leaf1 and to a different interface on leaf2. Another common delta is an LACP system-ID mismatch, which breaks the ESI-LAG but can leave LACP apparently up on one side. Minimal correction: if VLAN 210 is intended to be EVPN, add it to the same EVI on leaf2 and verify the ESI is identical; if it is not intended, remove it from leaf1's EVPN instance and from the ESI-LAG. Use commit confirmed 5 so the 30-minute window has an automatic rollback.
3. What rollback and verification sequence would you use within the 30-minute window?
Read the worked answer
Take a baseline first: show evpn instance extensive, show ethernet-switching evpn designated-forwarder, and interface BUM counters. Apply the single missing VLAN/ESI correction with commit confirmed 5, then verify DF state, MAC learning, and storm-control counters on both leaves. Generate a test ARP from a server and confirm one reply path. If counters still rise, roll back by letting the confirm expire or with rollback 1. After the window, compare configurations and add a pre-check to the change template: both ESI members must show the VLAN in the same EVI and the same DF state before the change is closed.