EVPN & VXLAN Cheat Sheet

How to Use This Sheet

EVPN and VXLAN separate tenant forwarding from the physical topology.

VXLAN provides the data-plane encapsulation.

EVPN provides the BGP control plane that distributes MAC, IP, route, and multihoming state.

Use this as a field reference for fabric design, implementation review, migration planning, troubleshooting, and operational validation.

Design rule: EVPN/VXLAN is not one feature. It is underlay routing, overlay signaling, encapsulation, gateway behavior, endpoint learning, and operations working together.

The Simple Picture

Think of the fabric as two networks working at the same time:

• Underlay: the real IP network between leaf and spine switches.
• Overlay: the tenant networks carried inside VXLAN tunnels.
• EVPN: the BGP control plane that tells VTEPs where MACs, IPs, VNIs, and tenant routes live.

For dummies:

• Underlay is the road.
• VXLAN is the delivery truck.
• VNI is the tenant label on the package.
• EVPN is the address book that says which VTEP owns which endpoint.

---

Core Terms

---

Standards Map

Use RFC names to align multi-vendor discussions. Use vendor documentation for exact CLI behavior.

---

VXLAN Data Plane

VXLAN wraps an inner Ethernet frame inside an outer IP/UDP packet.

Outer Ethernet
Outer IP
UDP destination port 4789
VXLAN header with VNI
Inner Ethernet frame
Inner IP or payload

Operational implication:

• underlay devices forward only outer IP packets
• tenant segmentation is carried in VNI
• ECMP depends on outer headers and UDP source-port entropy
• MTU must account for encapsulation overhead

For dummies:

The original tenant packet is not changed first. The VTEP puts it inside a new outer packet so the fabric can move it across the IP underlay.

---

EVPN Control Plane

EVPN uses MP-BGP to advertise reachability.

Instead of flooding every unknown event, VTEPs exchange endpoint and service information in control-plane routes.

Checklist:

1. BGP EVPN adjacency is established.
2. Local MAC/IP routes are originated.
3. Remote EVPN routes are imported by route target.
4. VNI maps to correct bridge domain or VRF.
5. Encapsulation next hop resolves to reachable VTEP loopback.
6. Data plane can carry the encapsulated packet.

For dummies:

Without EVPN, a switch may need to flood to find unknown endpoints. With EVPN, BGP tells the fabric where the endpoint is before traffic is sent.

---

EVPN Route Types

Each EVPN route type answers a different question.

Troubleshooting shortcut:

---

L2VNI, L3VNI, VLAN, and VRF Mapping

Common mapping:

Design recommendation:

• use deterministic VNI numbering
• separate L2VNI and L3VNI ranges
• document VLAN-to-VNI-to-VRF mappings
• avoid reusing a VNI across different tenants
• standardize RT generation

For dummies:

VLAN is local to the leaf. VNI is what the overlay carries across the fabric. VRF is where routed tenant traffic lives.

---

Underlay Requirements

The overlay only works when the underlay is clean.

Underlay routing options:

Underlay checks:

ping <remote-vtep-loopback>
traceroute <remote-vtep-loopback>
show ip route <remote-vtep-loopback>
show bgp ipv4 unicast summary
show interfaces counters errors

If VTEP loopbacks are unstable, EVPN routes may exist but data traffic still fails.

For dummies:

If the leaves cannot reach each other's VTEP loopbacks, the VXLAN tunnel has nowhere reliable to go.

---

Overlay BGP EVPN Sessions

EVPN routes are carried in BGP address-family l2vpn evpn.

Common models:

Control-plane checks:

show bgp l2vpn evpn summary
show bgp l2vpn evpn route-type 2
show bgp l2vpn evpn route-type 3
show bgp l2vpn evpn route-type 5
show bgp l2vpn evpn neighbors

What to verify:

• EVPN address family is negotiated
• route reflectors preserve next-hop behavior as intended
• route targets import and export correctly
• VTEP loopback is used as update source or next hop
• remote VTEP next hop is reachable in the underlay

---

Anycast Gateway

Anycast gateway lets every leaf act as the default gateway for locally attached hosts.

Benefits:

• avoids traffic hairpinning to a central gateway
• supports active-active default gateway
• improves east-west traffic efficiency
• reduces first-hop dependency

Failure checks:

show interface vlan <id>
show mac address-table address <host-mac>
show arp vrf <tenant> <host-ip>
show bgp l2vpn evpn route-type 2 | include <host-mac-or-ip>

If gateway IP is correct but virtual MAC differs between leaves, host movement and ARP behavior can fail unpredictably.

---

IRB Models

IRB connects L2 bridge domains to tenant routing.

Symmetric IRB is common in scalable data center fabrics.

Symmetric IRB flow:

What must exist:

• source L2VNI
• destination L2VNI
• tenant VRF
• L3VNI
• anycast gateway
• route targets for L2 and L3
• host MAC/IP type 2 routes or prefix type 5 routes

For dummies:

Same subnet traffic uses the L2VNI. Different subnet traffic enters the VRF and usually crosses the fabric through the L3VNI.

---

Route Type 2: MAC and MAC/IP

Route type 2 advertises endpoint location.

Troubleshooting:

show bgp l2vpn evpn route-type 2
show mac address-table address <mac>
show arp vrf <vrf> <ip>
show vxlan address-table

Common failure:

• local switch learns MAC but does not advertise EVPN route
• remote switch receives route but does not import RT
• next-hop VTEP is unreachable
• duplicate MAC dampening suppresses movement
• stale ARP/ND binding points to old VTEP

---

Route Type 3: BUM Handling

BUM traffic still needs controlled distribution.

Route type 3 advertises VTEP membership for a VNI.

Use ingress replication for simplicity.

Use multicast only when the operational model supports it.

Checks:

show bgp l2vpn evpn route-type 3
show vxlan flood vtep
show nve peers
show multicast route

If unicast works but ARP, DHCP, or unknown unicast fails, check type 3 and flood-list behavior.

---

Route Type 5: IP Prefix Routes

Route type 5 advertises IP prefixes through EVPN.

Use cases:

• advertise tenant prefixes between VTEPs
• advertise external routes into EVPN fabric
• reduce host-route scale where prefixes are enough
• connect EVPN tenant VRFs to firewalls, WAN, or services

Type 5 route needs:

Checks:

show bgp l2vpn evpn route-type 5
show ip route vrf <vrf> <prefix>
show bgp vrf <vrf> ipv4 unicast
show forwarding vrf <vrf> <prefix>

---

Multihoming and ESI

EVPN multihoming allows a device or segment to attach to more than one PE/VTEP.

Control-plane routes:

Checks:

show bgp l2vpn evpn route-type 1
show bgp l2vpn evpn route-type 4
show evpn ethernet-segment
show lacp neighbor
show interface port-channel

Multihoming failures usually come from inconsistent ESI, LACP, VLAN/VNI membership, or DF election state.

---

ARP and ND Suppression

EVPN can reduce flooding by answering ARP or Neighbor Discovery from learned MAC/IP bindings.

Symptoms:

Checks:

show arp vrf <vrf>
show ipv6 neighbors vrf <vrf>
show bgp l2vpn evpn route-type 2 | include <ip>
show mac address-table dynamic

---

MTU and Encapsulation Overhead

VXLAN adds outer headers. The fabric MTU must carry the larger packet.

Common overhead estimate:

Operational baseline:

• set fabric MTU high enough for tenant MTU plus VXLAN overhead
• validate every link in the underlay path
• check host-facing MTU separately
• account for extra tags, IPv6, or additional encapsulation

Checks:

ping <remote-vtep-loopback> size <fabric-test-size> df-bit
show interface mtu
show interface counters errors
tracepath <remote-vtep-loopback>

If small packets work but storage, TLS, or backup traffic hangs, suspect MTU.

---

VNI and Route Target Plan

Keep numbering boring and deterministic.

Planning table:

Avoid:

• hand-assigned random VNIs
• overlapping L3VNI between tenants
• undocumented route-target imports
• local VLAN IDs treated as global truth

---

Common Design Models

Architecture rule:

Stretch L2 only where there is a real dependency. Prefer routed boundaries for failure isolation.

---

Border Leaf and External Connectivity

Border leaves connect tenants to outside networks.

Common patterns:

Checks:

show ip route vrf <tenant>
show bgp vrf <tenant> ipv4 unicast
show bgp l2vpn evpn route-type 5
show route-map
show access-list

Do not leak routes between tenants casually. Every import must have an owner and reason.

---

Operations Validation Chain

Use this for a new VLAN/VNI turn-up.

1. VLAN exists on access leaf
2. VLAN maps to bridge domain
3. bridge domain maps to L2VNI
4. SVI exists if routed
5. SVI maps to correct VRF
6. VRF maps to L3VNI
7. local host MAC learned
8. type 2 route originated
9. remote VTEP imports route
10. underlay reaches remote VTEP
11. packet capture shows VXLAN encapsulation
12. counters increment without drops

Minimal checks:

show vlan id <vlan>
show vxlan vni <vni>
show mac address-table vlan <vlan>
show bgp l2vpn evpn route-type 2
show nve peers
show ip route <remote-vtep-loopback>

---

Troubleshooting: Host Cannot Reach Same Subnet

Same subnet over EVPN/VXLAN depends on L2VNI and type 2 reachability.

Check sequence:

local interface/VLAN up
local MAC learned
local VNI active
remote VTEP peer up
remote type 2 MAC route present
type 3 flood membership present
underlay VTEP reachable
MTU clean

Likely causes:

---

Troubleshooting: Inter-Subnet Routing Fails

Inter-subnet traffic requires IRB.

Check sequence:

source SVI up
anycast gateway MAC/IP correct
source VRF correct
L3VNI active
destination L2VNI present
remote type 2 or type 5 route present
recursive next hop resolves to VTEP
underlay path clean

Commands:

show ip route vrf <vrf> <destination>
show bgp l2vpn evpn route-type 2
show bgp l2vpn evpn route-type 5
show forwarding vrf <vrf> <destination>
show arp vrf <vrf>

Common misses:

• SVI not in tenant VRF
• L3VNI missing
• RT import missing for L3 routes
• anycast gateway mismatch
• border route leaked into wrong VRF

---

Troubleshooting: Remote VTEP or NVE Peer Down

NVE peer state usually depends on underlay reachability and EVPN control-plane state.

Check:

show nve peers
show bgp l2vpn evpn summary
show ip route <remote-vtep-loopback>
ping <remote-vtep-loopback>
traceroute <remote-vtep-loopback>
show interface counters errors

Likely causes:

---

Troubleshooting: Host Mobility

EVPN handles host moves through MAC mobility sequence numbers.

Symptoms:

• traffic follows old leaf
• duplicate MAC detected
• route suppressed or dampened
• ARP points to old VTEP
• endpoint works after cache timeout only

Checks:

show bgp l2vpn evpn route-type 2 | include <mac>
show mac address-table address <mac>
show arp vrf <vrf> <ip>
show evpn mac mobility
clear arp <ip>

Root causes:

• real duplicate endpoint
• stretched VM moves faster than control-plane convergence
• loop creates MAC movement
• stale endpoint on access switch
• inconsistent ESI or port-channel behavior

---

Troubleshooting: Multihoming

EVPN multihoming failures can create blackholes or loops.

Check sequence:

LACP state
port-channel state
same ESI on both PEs
same VLAN/VNI membership
type 1 routes present
type 4 routes present
DF election result
split-horizon behavior

Commands:

show lacp neighbor
show interface port-channel
show evpn ethernet-segment
show bgp l2vpn evpn route-type 1
show bgp l2vpn evpn route-type 4

Common causes:

• mismatched ESI
• VLAN allowed on one side only
• inconsistent VNI mapping
• LACP fallback behavior
• DF election mismatch
• server NIC team mode mismatch

---

Packet Capture and Data Plane Checks

Capture on VTEP-facing interfaces when possible.

tcpdump -ni <underlay-interface> udp port 4789
tcpdump -ni <underlay-interface> host <remote-vtep-ip>
tcpdump -ni <access-interface> ether host <host-mac>

What to verify:

Capture filters vary by platform. On appliances, use vendor packet tools when raw shell is unavailable.

---

Scale and Limits

EVPN/VXLAN scale depends on control-plane, forwarding table, and operational limits.

Track:

Scale controls:

• summarize with type 5 where appropriate
• avoid unnecessary L2 stretch
• use ARP/ND suppression carefully
• prune VNIs from leaves that do not need them
• monitor route churn and MAC mobility
• standardize route-target import policy

---

Change Window Checklist

Before change:

fabric topology
VNI and VLAN mapping
VRF and route-target mapping
underlay reachability
BGP EVPN neighbor state
current MAC/IP routes
rollback commands
packet capture point

After change:

local VLAN and VNI active
NVE peer up
type 2 route originated
remote route imported
host ARP/ND correct
same-subnet test passes
inter-subnet test passes
external route test passes
no new errors or drops

Rollback trigger examples:

• VTEP peer loss
• unexpected route-target import
• MAC mobility storm
• endpoint blackhole
• MTU-related service failure
• BGP EVPN route churn

---

Common Anti-Patterns

---

Quick Command Map

Command names vary by vendor, but the operational questions are consistent.

---

References

Use primary standards for terminology and vendor documentation for exact syntax:

• RFC 7348: Virtual eXtensible Local Area Network
• RFC 7432: BGP MPLS-Based Ethernet VPN
• RFC 8365: A Network Virtualization Overlay Solution Using EVPN
• RFC 9135: Integrated Routing and Bridging in EVPN
• RFC 9136: IP Prefix Advertisement in EVPN

The goal is not to memorize every EVPN route.

The goal is to know which route, table, VNI, gateway, and tunnel state proves the fabric is behaving correctly.