New VLAN Works Locally but Fails Across the EVPN Fabric
Two S5232F-ON spines and four S5248F-ON leaves run an EVPN-VXLAN fabric. The underlay is OSPF area 0; the overlay is iBGP AS 65000 with the spines as route reflectors. Each leaf has a loopback 10.0.0.1-10.0.0.4/32. VLAN 140 is 10.140.0.0/24 with anycast gateway 10.140.0.1 and VNI 10140; the same virtual-router MAC is configured on all leaves. Host A (10.140.0.10) is on leaf-1 and host B (10.140.0.20) is on leaf-2. Both hosts can ping their local gateway. Host A cannot ping host B. The EVPN BGP sessions are Established on both leaves. On leaf-2, show vxlan vni does not list 10140, although VLAN 140 exists and has the correct IP. No ACL or firewall sits between the hosts. The team expects a single configuration omission rather than a hardware fault.
1. What does the local gateway success prove and not prove? List the first four checks you would run, in order, and why.
Read the worked answer
Local gateway success proves the VLAN, SVI/anycast address, local switching, and local host ARP are working on each leaf. It does not prove the VLAN is mapped to a VNI, that the VXLAN tunnel endpoints are reachable, or that EVPN MAC/IP routes are exchanged. First checks: (1) VLAN-to-VNI mapping on both leaves (show running-config interface vlan 140, show vxlan vni); (2) EVPN BGP address-family and route-type 2/3 presence for VNI 10140 (show bgp l2vpn evpn summary, show bgp l2vpn evpn route-type 2, route-type 3); (3) loopback reachability and VXLAN UDP 4789 path between leaf-1 and leaf-2; (4) MAC/ARP and VXLAN address tables on both leaves (show mac address-table, show vxlan address-table). The missing VNI on leaf-2 makes the mapping check the leading hypothesis.
2. Assuming leaf-2 is missing the VNI mapping, what is the fix and what exact control-plane and data-plane evidence should appear after the fix?
Read the worked answer
Under interface vlan 140 on leaf-2, add the VXLAN mapping (vxlan-vni 10140 in OS10), ensure feature vxlan is enabled, and confirm the EVPN address family advertises the VNI (advertise-all-vni or the per-VNI equivalent). With the mapping absent, leaf-2 has no local VNI for VLAN 140, so it does not originate the local MAC/IP (type 2) route for host B and cannot encapsulate traffic for that VNI. After the fix, leaf-2 should advertise a type-2 route for 10.140.0.20/32 with VNI 10140 and a type-3 IMET route for the VNI; leaf-1 should install a remote MAC/VXLAN entry pointing to leaf-2's loopback. Verify show bgp l2vpn evpn route-type 2, show vxlan address-table, and a ping from A to B. If routes appear but ping fails, check underlay MTU: VXLAN adds about 50 bytes, so the underlay should carry jumbo frames and the VTEP interfaces must not fragment.
3. How would you distinguish an EVPN control-plane problem from a VXLAN data-plane/MTU problem using only the leaf CLI?
Read the worked answer
Control plane is healthy if leaf-1 has the type-2 route for host B and a remote VXLAN/MAC entry for B via leaf-2's VTEP; data plane is then suspect. If the route and remote entry exist but large pings fail while small pings succeed, test with a large DF-bit ping across the fabric and check interface MTU on the underlay links and loopbacks. VXLAN encapsulation adds outer IP, UDP, and VXLAN headers, so a 1500-byte underlay will drop full-size frames. If the route is missing, work the control plane: BGP EVPN session, VNI mapping, route-target import/export, and whether the VNI is advertised. show vxlan vni, show bgp l2vpn evpn, show vxlan address-table, and show interface MTU are enough to separate the two.