EVPN Deep Dive: Route Types, MAC Mobility, Multi-Homing, and ARP Suppression

March 13, 2026·10 min read

Overview

EVPN is what turns VXLAN from a dumb tunnel into a proper control plane. Without EVPN, VTEPs use flood-and-learn — every unknown MAC causes a broadcast storm across all tunnels. With EVPN, each VTEP announces its local MACs and IPs into BGP before any traffic flows, eliminating floods and enabling features that flood-and-learn simply cannot provide: ARP suppression, MAC mobility, and multi-homing.

EVPN Route Type Reference

Type	Name	NLRI Contents	Purpose in the Fabric
1	Ethernet Auto-Discovery	ESI + Ethernet Tag + MPLS label	Multi-homing: per-ESI and per-EVI routes for split-horizon and aliasing
2	MAC/IP Advertisement	MAC address + optional IP + VNI	The workhorse — distributes host MAC and ARP bindings across fabric
3	Inclusive Multicast (IMET)	VTEP IP + VNI	Announces VTEP participation in a VNI; builds BUM replication list
4	Ethernet Segment	ESI + originating router IP	Designated Forwarder (DF) election for multi-homed segments
5	IP Prefix Route	IP prefix + gateway MAC + L3 VNI	Inter-subnet routing in symmetric IRB; carries external prefixes into fabric

Type-2 Route: MAC/IP Advertisement in Detail

Part 1 — MAC Mobility (VM Live Migration)

When a VM migrates from Leaf-1 to Leaf-3, Leaf-3 sees the MAC appear on a local port and sends a new Type-2 route with a higher sequence number. All other VTEPs update their tables.

cisco

! MAC mobility sequence number is incremented each migration! Verify MAC mobility on NX-OS:Leaf-3# show bgp l2vpn evpn route-type 2 0 AA:BB:CC:DD:EE:FF 0! Output shows:! Route Distinguisher: 10.1.1.3:32867! MAC: AA:BB:CC:DD:EE:FF! Seq No: 2  <- incremented from 1 when VM migrated! VTEP: 10.1.1.3  <- now at Leaf-3! If you see rapid MAC mobility (seq incrementing every few seconds):Leaf-1# show bgp l2vpn evpn route-type 2 0 AA:BB:CC:DD:EE:FF 0! Competing Type-2 routes from two VTEPs = two ports think the MAC is local! Cause: network loop, or VM migration storm, or incorrect port assignment

Leaf-1 (NX-OS) — show bgp l2vpn evpn
Leaf-1# show bgp l2vpn evpn
BGP routing table — VRF default, address family L2VPN EVPN
BGP table version: 47   Local Router-ID: 10.1.1.1 (Leaf-1 loopback)
Status: *=valid >=best  Origin: i=IGP | =multipath
Route Distinguisher: 10.1.1.1:32867 (L2VNI 10100, VLAN 10)
     Network                                         Next-Hop        LocPrf Weight Path
*>l[2]:[0]:[48]:[AA:BB:CC:11:22:33]:[32]:[10.100.0.10]/272
     10.1.1.1 (local)           100  32768 i  <-- Type-2: MAC+IP local to this VTEP
*> [2]:[0]:[48]:[DD:EE:FF:44:55:66]:[32]:[10.100.0.20]/272
     10.1.1.2                   100  0 i     <-- Type-2: MAC+IP on VTEP 10.1.1.2 (Leaf-2)
Route Distinguisher: 10.1.1.1:3 (L3VNI 50001, VRF TENANT-A)
*>l[5]:[0]:[24]:[10.100.0.0]/224
     0.0.0.0 (local)           100  32768 i  <-- Type-5: IP prefix, L3VNI=50001 L2VNI=10100
*> [5]:[0]:[24]:[10.200.0.0]/224
     10.1.1.2                   100  0 i     <-- Type-5: prefix from Leaf-2, L3VNI=50001 L2VNI=10200
Route Distinguisher: 10.1.1.1:32867 (IMET, VNI 10100)
*>l[3]:[0]:[32]:[10.1.1.1]/88
     10.1.1.1 (local)           100  32768 i  <-- Type-3 IMET: announces VTEP joins VNI 10100 for BUM
[2] Type-2: MAC/IP
Carries host MAC + IP. Enables ARP suppression — local VTEP answers ARP from this cache instead of flooding.
[3] Type-3: IMET
VTEP announces participation in a VNI. Builds BUM (broadcast/unknown/multicast) replication list between VTEPs.
[5] Type-5: IP Prefix
Symmetric IRB inter-subnet routing. label1=L3VNI (50001) label2=L2VNI (10100). No MAC needed — pure IP routing.

Part 2 — ARP Suppression

ARP suppression makes each VTEP answer ARP requests locally using the MAC/IP bindings learned from EVPN Type-2 routes — instead of flooding an ARP broadcast across all tunnels to all VTEPs.

cisco

! Enable ARP suppression on NVE VNIinterface nve1 member vni 10100  suppress-arp  ! Each VTEP now responds to ARP for any IP it learned via EVPN Type-2! Verify suppression cacheLeaf-1# show ip arp suppression-cache detail! Shows: IP, MAC, VLAN, VTEP — entries learned from EVPN! If an IP is missing here, the VTEP will flood the ARP — check Type-2 routes

Part 3 — Multi-Homing with ESI (Ethernet Segment Identifier)

Multi-homing connects a server to two leaf switches with a LAG (port-channel). Without ESI, the same MAC would be advertised from two VTEPs causing confusion. ESI coordinates this.

cisco

! Both Leaf-1 and Leaf-2 share the same ESI for the dual-homed segmentinterface port-channel10 evpn ethernet-segment  identifier 0010.0000.0000.0000.0001  ! All 10 bytes — must match on both leaves! Type-1 routes are generated per ESI — Leaf-1 and Leaf-2 advertise:! "I am part of ESI 0010.0000.0000.0000.0001"! Type-4 routes elect a Designated Forwarder (DF):! Only one leaf forwards BUM (broadcast/unknown unicast/multicast) per ESI! The other leaf is Non-DF — drops BUM to prevent loopsLeaf-1# show evpn ethernet-segment esi 0010.0000.0000.0000.0001 detail! Shows: DF election result — which leaf is DF for which VLANs

Part 4 — Type-5 Routes for External Prefix Advertisement

Type-5 is used when you need to advertise prefixes that don't correspond to a locally attached MAC. The primary use case is advertising an IP prefix from outside the VXLAN fabric into the fabric for symmetric IRB routing.

cisco

! Configure a VRF with EVPN Type-5 import/exportvrf context TENANT-A vni 50001 rd auto address-family ipv4 unicast  route-target both auto evpn  advertise l2vpn evpn  ! "advertise l2vpn evpn" enables Type-5 advertisement  ! Redistributes VRF prefixes as EVPN Type-5 routes! Redistribute external routes into the VRF for Type-5 advertisementrouter bgp 65001 vrf TENANT-A  address-family ipv4 unicast   redistribute ospf 100 route-map RM-OSPF-TO-BGP   ! External OSPF routes appear as Type-5 in EVPN fabric! Verify Type-5 routesLeaf-1# show bgp l2vpn evpn route-type 5! Shows all IP prefix routes in the EVPN table! Each entry: prefix, originating VTEP, gateway MAC, L3 VNI

Real-World Scenario

The situation: After deploying EVPN/VXLAN across a 4-leaf 2-spine fabric, a VM on Leaf-1 can reach a VM on Leaf-2 in the same VNI, but inter-VNI routing (same tenant, different subnets) fails. VMs can ping their own subnet gateway but not reach the other subnet.

Symptoms observed:

show ip route vrf TENANT-A on all leaves shows only locally-connected subnets
show bgp l2vpn evpn shows Type-2 and Type-3 routes but zero Type-5 routes
show nve vni shows the L3 VNI (50001) as Up state

Root cause: advertise l2vpn evpn missing under address-family ipv4 unicast in the VRF config. Without it, the VRF's connected subnets are never converted to Type-5 EVPN routes and never distributed to other leaves.

Fix:

cisco

vrf context TENANT-A address-family ipv4 unicast  advertise l2vpn evpn! Verify immediately after:Leaf-1# show bgp l2vpn evpn route-type 5! Should now show 10.100.0.0/24 and 10.200.0.0/24 as Type-5 routes! Other leaves: show ip route vrf TENANT-A! Should show both subnets via nve1 (VTEP addresses as next-hop)

Troubleshooting

Type-2 routes present but ARP suppression not working (floods still seen)

Symptom: show ip arp suppression-cache detail is empty despite Type-2 routes in BGP.

Cause: suppress-arp not enabled under the VNI in the NVE interface.

Fix:

cisco

interface nve1 member vni 10100  suppress-arp  ! Verify: show nve vni — "ARP suppression: Enabled"

MAC mobility loop — MAC bouncing between two VTEPs

Symptom: show bgp l2vpn evpn route-type 2 0 <MAC> shows sequence number incrementing rapidly (>5 per minute).

Cause: Two leaf switches both see the MAC on a local port — usually a spanning tree loop, dual-homed server without proper ESI/LACP, or a mispatched cable.

Fix:

cisco

! Identify both VTEPs advertising the MACLeaf-1# show bgp l2vpn evpn route-type 2 | include <last 4 of MAC>! Note the originating VTEPs! On each advertising leaf — check what port the MAC is learned onLeaf-1# show mac address-table address AA:BB:CC:DD:EE:FF! If port = nve1: learned remotely (correct)! If port = Eth1/5: learned locally — check if this port should have this MAC

Inter-VNI routing fails despite symmetric IRB config

Symptom: Hosts in different VNIs (same VRF) can't communicate. show ip route vrf TENANT-A missing remote subnets.

Cause: Missing advertise l2vpn evpn in the VRF address-family, OR L3 VNI SVI not in Up state.

Fix:

cisco

! Check L3 VNI SVILeaf-1# show interface vlan 3001! Must be: Vlan3001 is up, line protocol is up! Must have: ip forward (not an IP address)! Check advertise configLeaf-1# show running-config vrf TENANT-A | include advertise! Must show: advertise l2vpn evpn

EVPN Hardening Checklist

send-community extended on all EVPN BGP peers — route targets are extended communities; missing this strips them
route-target both auto evpn used consistently — manual RT mismatches between leaves break import/export
suppress-arp enabled on all L2 VNIs — without it, every ARP is flooded to all VTEPs
advertise l2vpn evpn under each VRF address-family — required for Type-5 (inter-subnet) routes
L3 VNI SVI configured with ip forward only — no IP address, just a carrier for the L3 VNI
Anycast gateway MAC identical on ALL VTEPs — even one mismatch causes ARP failures on that leaf
Type-3 IMET routes verified for every VNI on every VTEP — missing Type-3 = VTEP not participating in BUM
MAC mobility threshold configured: mac-move limit 10 time 30 action syslog — detect loops before they cascade
Spine route reflectors: route-reflector-client for all leaf EVPN peers — no direct leaf-to-leaf BGP sessions needed