VTEP Troubleshooting Guide

VTEP Troubleshooting Guide for L2VPN VXLAN

VTEP Troubleshooting Guide

For L2VPN VXLAN on IOS-XE with BGP EVPN & OSPF Underlay

What is a VTEP?

A VTEP (VXLAN Tunnel Endpoint) is a crucial component in a VXLAN (Virtual Extensible LAN) network. It's the device that originates and terminates VXLAN tunnels. Think of it as the on-ramp and off-ramp for traffic entering and leaving the VXLAN overlay network.

VTEP 1 192.168.1.1 VTEP 2 192.168.1.2 VXLAN Tunnel Host A Host B

Key Responsibilities of a VTEP:

  • Encapsulation: When a frame from a local host needs to cross the network to a remote host, the VTEP takes the original Ethernet frame (Layer 2), wraps it in a VXLAN header, and then further wraps it in a standard UDP/IP packet (Layer 3/4).
  • Decapsulation: When an incoming packet arrives from the VXLAN tunnel, the VTEP strips off the outer IP/UDP and VXLAN headers to reveal the original Ethernet frame, which it then forwards to the destination host on its local segment.

Each VTEP has at least one IP address on the underlay (transport) network. This IP is used as the source and destination for the UDP packets that form the VXLAN tunnel.

Troubleshooting VTEP Communication

When hosts on different VTEPs can't communicate, the problem usually lies in one of three areas: the Underlay, the BGP EVPN Control Plane, or the VXLAN Overlay configuration itself. We'll follow a bottom-up approach, starting with the underlay network.

Step 1: Verify the Underlay Network (OSPF)

The underlay's only job is to provide IP reachability between VTEPs. If the VTEPs can't reach each other's tunnel source IP addresses, nothing else will work.

First, check if your OSPF neighbor relationships are up.

VTEP-1# show ip ospf neighbor 
Neighbor ID     Pri   State           Dead Time   Address         Interface
192.168.1.2       0   FULL/  -        00:00:35    10.0.0.2        GigabitEthernet1

The key is to see the FULL state. If it's stuck in another state (like INIT or 2-WAY), you have a basic OSPF configuration issue (mismatched MTU, area ID, authentication, etc.) that must be fixed first.

Next, and most importantly, verify that the VTEPs can ping each other using their loopback interfaces, which are typically the source for the NVE tunnel.

# Ping from VTEP-1 (Loopback0: 192.168.1.1) to VTEP-2 (Loopback0: 192.168.1.2)
VTEP-1# ping 192.168.1.2 source Loopback0 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms

If this ping fails, you have a routing problem in your underlay. Use show ip route 192.168.1.2 to ensure a valid OSPF route exists.

Step 2: Verify the BGP EVPN Control Plane

BGP EVPN is responsible for advertising MAC addresses (and optionally IP addresses) of the end hosts between VTEPs. If BGP isn't working, VTEPs won't know which remote VTEP to send traffic to.

Check the BGP L2VPN EVPN neighbor summary.

VTEP-1# show bgp l2vpn evpn summary 
BGP router identifier 192.168.1.1, local AS number 65000
...
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.1.2     4        65000      10      12        5    0    0 00:05:12        5

The most important column is the last one. If it shows a number (like 5 in this case), the session is established and you are receiving prefixes. If it says "Idle" or "Active", you have a BGP peering problem (TCP port 179 blocked, wrong AS number, etc.).

Now, verify that specific host MAC addresses are being learned via BGP.

# Check for a specific MAC address learned from a host on the remote VTEP
VTEP-1# show bgp l2vpn evpn mac 0050.568b.1a2b 
BGP routing table entry for [2][0050.568b.1a2b][0][32]/216, version 5
Paths: (1 available, best #1, table evi_100)
  Advertised to update-groups:
     1
  Refresh Epoch 1
  65000
    192.168.1.2 (metric 2) from 192.168.1.2 (192.168.1.2)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      EVPN ESI: 00000000000000000000, Route Distinguisher: 192.168.1.2:100
      Next Hop: 192.168.1.2

This confirms that VTEP-1 has learned about the remote MAC address and knows the Next Hop VTEP is 192.168.1.2. If this command returns nothing, the remote VTEP is not advertising the MAC.

Step 3: Verify the VXLAN Overlay (NVE Interface)

Finally, check the VXLAN configuration itself. The NVE (Network Virtualization Endpoint) interface is the logical entity that manages the VXLAN tunnels.

Check the NVE interface detail.

VTEP-1# show nve interface nve1 detail 
Interface: nve1, State: Up, encapsulation: VXLAN
...
 Source Interface: Loopback0 (primary: 192.168.1.1)
...

Ensure the interface state is Up and the source interface is correct.

Next, verify that the remote VTEPs are discovered and listed as peers.

VTEP-1# show nve peers 
Interface  VNI      Peer-IP          State  Up-Time   VLAN/BD
nve1       10100    192.168.1.2      Up     00:15:20  100

This shows that for VNI 10100, our VTEP has a peer relationship with 192.168.1.2, and the state is Up. If the peer is missing or down, it points back to a BGP control plane issue.

Lastly, check the data plane forwarding information. This table is built from the BGP EVPN information.

VTEP-1# show l2fib bridge-domain 100 address unicast 0050.568b.1a2b 
Bridge Domain : 100
  MAC Address    Next Hop Addr    Encapsulation  Label
  0050.568b.1a2b 192.168.1.2      vxlan          10100

This is the final confirmation. It shows that for a packet destined to MAC `0050.568b.1a2b` in bridge-domain 100, the switch knows it must encapsulate it in a VXLAN packet (for VNI 10100) and send it to the remote VTEP at 192.168.1.2. If you've reached this point and everything looks correct, your VTEP communication should be working.