// field notes · troubleshooting
EVPN / VXLAN: what's actually happening?
Pull the control plane and data plane apart and EVPN stops being magic. Follow one MAC address from host to remote VTEP.
EVPN/VXLAN feels complicated because several ideas arrive at once: an overlay, an underlay, a BGP address family and a tunnelling encapsulation. Separate them and each piece is simple on its own.
It’s like a Defender drivetrain. Engine, gearbox, transfer case, propshafts and differentials each do one job. When something knocks, you isolate which component it’s coming from before you start unbolting.
The components
| Component | Job | Mechanical equivalent |
|---|---|---|
| Underlay (IS-IS/OSPF/eBGP) | Loopback-to-loopback reachability | Chassis |
| VTEP | Encapsulate and decapsulate | Transfer case |
| VXLAN | The tunnel (UDP/4789) | Propshaft |
| EVPN (BGP l2vpn/evpn) | Tell every VTEP where every MAC/IP lives | Wiring loom |
Follow one MAC
A host aa:bb:cc:00:00:01 in VLAN 100 (VNI 10100) plugs into leaf1.
1. Local learning. leaf1 learns the MAC on its access port like any switch.
user@leaf1> show ethernet-switching table aa:bb:cc:00:00:01
2. Advertise. leaf1 originates an EVPN Type-2 (MAC/IP) route carrying the MAC, the VNI and its own VTEP address as the next hop.
user@leaf1> show route table bgp.evpn.0 match-prefix "2:*aa:bb:cc:00:00:01*"
3. Learn remotely. leaf4 receives it, imports it via route-target, and installs the MAC pointing at a VXLAN tunnel to leaf1.
user@leaf4> show ethernet-switching vxlan-tunnel-end-point remote mac-table | match aa:bb:cc
4. Forward. A frame on leaf4 destined for that MAC is wrapped in VXLAN and sent across the underlay to leaf1’s loopback.
Where it usually goes wrong
- Underlay MTU. VXLAN adds 50 bytes. If the fabric is at 1500, large frames silently disappear. Check with a don’t-fragment ping between loopbacks at full size.
- Route-target mismatch. The Type-2 route arrives but isn’t imported. It sits in
bgp.evpn.0but never reaches the VRF/MAC-VRF table. - Type-3 missing. No Inclusive Multicast route means no BUM flooding between VTEPs, so ARP never resolves even though unicast “should” work.
- Underlay next-hop unreachable. The EVPN route is present but its VTEP next hop isn’t in
inet.0, so it’s hidden.
The method
Check the chassis before the loom. Confirm underlay reachability and MTU, then EVPN routes, then the forwarding tables, in that order. Each layer can only be as healthy as the one beneath it.