VXLAN Tenant Blackhole After a Leaf Replacement
A leaf (leaf-08) is RMA-replaced after a hardware fault. The replacement is racked, cabled identically, and brought up with a base EOS image. The engineer copies the old leaf's startup config from a backup and reloads. Most tenants come back, but one tenant (VNI 5010, VLAN 210) has intermittent connectivity: some hosts on leaf-08 can reach remote hosts, others cannot, and pings to the tenant's anycast gateway sometimes succeed and sometimes fail depending on source. The spines show the leaf's BGP EVPN session up and receiving routes for other VNIs. show vxlan vni on leaf-08 lists 5010, but show bgp evpn route-type mac-ip shows no local MACs for VLAN 210, while other VLANs populate normally. The old leaf had a documented manual MAC on a specific port.
1. Walk through the most likely reasons leaf-08 fails to advertise local MACs for VNI 5010 while other VNIs work, and how you would confirm each.
Read the worked answer
The failure is scoped to VLAN 210/VNI 5010, so it is a mapping or local-learning problem, not BGP itself (other VNIs advertise fine). Likely causes and confirmations:
- VLAN↔VNI mapping missing or wrong on the replacement:
show vxlan vlan-to-vni/show vxlan config- confirm 210↔5010 exists and matches the fabric's intended mapping. A missing mapping means no local MACs get into EVPN for that VNI. - VLAN not active / no member ports up for 210:
show vlan 210,show interfaces status. If the access ports for that tenant are down or assigned to the wrong VLAN, no MACs are learned, so nothing is advertised. - The documented manual MAC is missing. The old leaf had a static MAC on a specific port; a copied config may have failed to apply it (e.g., port name changed on the replacement, or the static entry was tied to an interface that no longer matches).
show mac address-table vlan 210- look for the expected static entry; if absent, that host's MAC never enters EVPN, explaining source-dependent reachability. - Anycast gateway inconsistency:
show ip interface vlan 210- confirm the anycast gateway IP/MAC matches the rest of the fabric. A mismatched virtual MAC would cause intermittent ping behavior depending on which leaf answers.
Intermittent, source-dependent symptoms point at (3) plus possibly (4): some hosts' MACs are learned and advertised, others (the static one) are not.
2. Describe the remediation and the verification steps that prove the tenant is fully restored, not just "mostly working."
Read the worked answer
Remediation:
- Correct the VLAN 210↔VNI 5010 mapping to match the fabric standard.
- Re-apply the static MAC on the correct interface (verify interface naming on the replacement matches the old config; fix the
mac address-table static ... vlan 210 interface ...entry). - Confirm the anycast gateway IP and virtual MAC on VLAN 210 match every other leaf.
- Ensure the tenant access ports are in VLAN 210 and up.
Verification (must be end-to-end, both directions):
show mac address-table vlan 210- expected local and static MACs present.show bgp evpn route-type mac-ipon leaf-08 - local MACs for VLAN 210 now advertised; and on a remote leaf, confirm those routes are received.- From a host on leaf-08, ping/throughput to a remote tenant host and from remote to local (both directions, multiple sources including the host behind the static MAC).
show vxlan address-table/show vxlan vni 5010- confirm remote VTEPs and MACs populated.- Compare leaf-08's tenant config against a known-good leaf (diff VLAN/VNI mapping, anycast gateway, static entries) to catch any other silent drift from the copied config.
Only when both directions work from every source, including the previously-static host, is the tenant restored. "Mostly working" with one unadvertised MAC is still a partial outage waiting to recur.