Cisco NX-OS VXLAN EVPN (Leaf/Spine)

Cisco NX-OSAdvanced

VXLAN EVPN fabric configuration for Cisco Nexus: NVE interface, BGP EVPN address-family, L2VNI and L3VNI per tenant, with eBGP underlay (OSPF or iBGP).

↓ example.txt

What is it?

VXLAN EVPN is the modern data center fabric technology. VXLAN (Virtual Extensible LAN) encapsulates Layer 2 frames inside UDP packets, allowing L2 segments to stretch across an L3 IP underlay network. EVPN (Ethernet VPN — RFC 7432) is the control plane that uses BGP to distribute MAC and IP address information between VTEPs (VXLAN Tunnel Endpoints). In a Nexus fabric, leaf switches are VTEPs that terminate VXLAN tunnels. Spine switches only carry the L3 underlay (OSPF or IS-IS) and EVPN BGP route reflector functions. This replaces legacy STP-based campus VLANs with a scalable, loop-free, multi-tenant fabric.

✓ When to use

·Building a new data center network from scratch — VXLAN EVPN is the industry standard
·When you need to stretch VLANs between data center pods, rows, or sites
·Multi-tenant environments (cloud providers, co-location) where each tenant needs isolated VRFs
·Replacing legacy STP-blocked designs with a fully active-active topology
·When you need more than 4094 VLANs across the fabric (VXLAN supports 16 million VNIs)

✗ When NOT to use

·Small campus networks — the complexity is not justified. Use traditional VLAN/STP or vPC.
·Networks without dedicated spine/leaf architecture — VXLAN EVPN requires an IP underlay between all switches
·Environments without BGP expertise — EVPN control plane requires deep BGP knowledge to troubleshoot

How it compares

vs Traditional STP fabricSTP blocks 50% of uplinks to prevent loops. VXLAN EVPN uses all links simultaneously via ECMP in the IP underlay. EVPN fabric is faster, more scalable, and supports active-active designs.

vs vPC (Virtual Port-Channel)vPC provides dual-homed redundancy at the access layer using two Nexus switches as one logical switch. VXLAN EVPN solves the same problem at fabric scale across all leaves, not just a pair.

vs MPLS L3VPNMPLS is the WAN equivalent of VXLAN EVPN — both use VRFs and route targets for multi-tenancy. VXLAN EVPN is IP-based (any switch can be an underlay), while MPLS requires a dedicated LSR infrastructure.

Prerequisites

→NX-OS 7.0(3)I4 or later for stable VXLAN EVPN support on Nexus 9000
→IP underlay must be configured first (OSPF or IS-IS between loopbacks)
→BFD recommended on all underlay links for fast failure detection
→Route targets and RDs must be planned before deployment — consistent across all leaves
→VNI-to-VLAN mapping must be consistent across all leaves that carry the same VLANs

Config Generator

Hostname *

Node Role

Loopback0 (Router-ID) *

Loopback1 (VTEP NVE) *

BGP AS Number *

Spine BGP Neighbors (eBGP underlay)

L2 VNIs (per VLAN)

L3 VNIs (per VRF / tenant)

Underlay Protocol

Verification commands

show nve peers

Show all VTEP peers and their VXLAN tunnel state

Expected: All leaf VTEPs should appear as peers with state 'UP'. If missing, BGP EVPN peering or OSPF underlay is not working.

show bgp l2vpn evpn summary

Show BGP EVPN neighbor state with all spines

Expected: All spine neighbors should show 'Established' state with a non-zero up/down time.

show bgp l2vpn evpn

Show EVPN route table — MAC/IP routes from all VTEPs

Expected: Should show Type 2 (MAC/IP), Type 3 (multicast), and Type 5 (IP prefix) routes from all leaf VTEPs.

show nve vni

Show all VNIs configured on this NVE interface and their status

Expected: Each VNI shows 'Up' state and the peer VTEP count.

Debug commands

show ip ospf neighbors

Verify OSPF underlay adjacencies are up with all connected spines

Common mistakes & fixes

⚡ NVE peers not appearing / VXLAN tunnels not forming

Cause: OSPF underlay not propagating loopback1 (VTEP source) routes, or BGP EVPN not establishing

Fix: Verify OSPF includes loopback1: 'show ip ospf database router'. Check BGP EVPN: 'show bgp l2vpn evpn summary'. VTEPs must reach each other via loopback1.

⚡ VMs in same VLAN cannot communicate across leaves

Cause: VNI-to-VLAN mapping mismatch, or Route Target mismatch between leaves

Fix: Verify VNI mapping: 'show vlan id <id>'. Confirm VLAN has 'vn-segment' configured. Check RT import/export values match across all leaves.

⚡ Inter-VLAN (L3) routing not working between tenants

Cause: L3VNI not configured, or VRF route targets not matching

Fix: Verify 'show vrf detail <vrf>' shows the VNI. Check L3VNI VLAN exists and SVI has 'ip forward'. Confirm RT import matches the remote leaf's RT export.