A VTEP, or VXLAN Tunnel Endpoint, is a network device or software function that creates and manages tunnels in a VXLAN overlay network. It sits at the edge of the tunnel, taking regular Ethernet frames from local devices, wrapping them in additional headers so they can travel across a standard IP network, and unwrapping them at the other end. VTEPs are the core building blocks that let organizations stretch Layer 2 networks across Layer 3 infrastructure, a capability that modern data centers rely on heavily.
Why VTEPs Exist
Traditional VLANs top out at about 4,094 unique network segments. That limit becomes a serious constraint in large data centers and multi-tenant cloud environments where thousands of customers or workloads each need isolated network space. VXLAN solves this by using a 24-bit identifier called a VNI (VXLAN Network Identifier), which supports over 16 million unique segments.
The VTEP is the component that makes this work in practice. Every VTEP has two interfaces: one facing the local network segment where devices like virtual machines or physical servers connect, and one facing the IP transport network that carries tunneled traffic between sites. This dual role lets the overlay network (the VXLAN segments) operate completely independently from the physical network topology underneath it.
How a VTEP Handles Traffic
When a device sends an Ethernet frame to a destination on a remote VXLAN segment, the local VTEP intercepts it and performs several steps. First, it identifies which VNI the destination belongs to. Then it looks up the relationship between the destination MAC address and the IP address of the remote VTEP responsible for that destination. With that information, it adds a VXLAN header tagged with the correct VNI, wraps the whole thing in a UDP packet (using destination port 4789, the standard VXLAN port), and adds an outer IP header with its own IP address as the source and the remote VTEP’s IP address as the destination. The resulting packet travels across the regular IP network like any other IP traffic.
At the receiving end, the remote VTEP strips away all the added headers, checks that the VNI is valid, confirms it has a host matching the destination MAC address, and forwards the original Ethernet frame to the intended recipient. From the perspective of the two communicating devices, it looks like they’re on the same local network, even though their traffic may have crossed multiple routers and data center boundaries.
VLAN Tag Handling
VTEPs also manage VLAN tags during this process. When a VLAN-tagged frame enters a VXLAN tunnel, the VTEP strips the VLAN tag before encapsulation unless specifically configured to keep it. On the decapsulation side, any frames that arrive with an inner VLAN tag are discarded by default. This behavior keeps the overlay network clean and prevents VLAN conflicts between different sites or tenants. One important rule defined in the VXLAN specification (RFC 7348): VTEPs must not fragment VXLAN packets, so the underlying network needs to support a large enough MTU to accommodate the extra headers.
How VTEPs Learn Where Devices Are
A VTEP needs to know which MAC addresses live behind which remote VTEPs. There are two main approaches to building this knowledge.
The original method is flood-and-learn. When a VTEP receives a frame for an unknown destination, it encapsulates the frame and sends it to a multicast group that all VTEPs in that VNI have joined. Every VTEP in the group receives the packet, decapsulates it, and forwards it into the matching local VLAN. When the destination device responds, the reply travels back as a unicast packet to the originating VTEP. Through this exchange, both VTEPs learn each other’s IP addresses and the MAC addresses behind them. It works, but it generates a lot of unnecessary traffic, especially at scale.
The more modern approach uses a protocol called BGP EVPN as a dedicated control plane. Instead of flooding traffic and waiting for replies, each VTEP learns the MAC and IP addresses of its local hosts and then advertises that information through BGP to all other VTEPs in the fabric. Remote VTEPs receive these advertisements and populate their forwarding tables without any data-plane flooding. This separation of control plane and data plane significantly reduces unnecessary traffic and can eliminate unknown unicast flooding entirely. Most current data center designs use BGP EVPN rather than flood-and-learn.
Hardware vs. Software VTEPs
VTEPs can run in software or in dedicated hardware, and the choice affects performance significantly. Software VTEPs typically run inside a hypervisor, often as part of a virtual switch like Open vSwitch (OVS). They’re flexible because they can map each individual virtual machine’s MAC address directly to a VNI, and they don’t require any special network hardware. The downside is that all the encapsulation and decapsulation work happens on the server’s CPU.
Hardware-accelerated VTEPs, built into physical switches or network interface cards, offload that processing. Research comparing the two found that hardware VTEPs deliver two to three times the throughput of software VTEPs, depending on packet size, while consuming roughly half the CPU resources per gigabit of traffic. For environments pushing large volumes of east-west traffic between servers, hardware acceleration can make a meaningful difference in both performance and the compute resources left available for actual workloads.
In practice, many data centers use both. Software VTEPs handle traffic at the hypervisor level where per-VM granularity matters, while hardware VTEPs on top-of-rack or leaf switches handle high-throughput aggregation and gateway functions between VXLAN and non-VXLAN networks.
VTEP Placement in the Network
In a typical leaf-spine data center architecture, VTEPs sit on the leaf switches. Each leaf switch has a VTEP IP address, and the spine switches simply route encapsulated VXLAN traffic between them. The underlay network connecting these switches uses standard IP routing, with point-to-point links between leaf and spine nodes typically assigned /30 or /31 address masks. Some designs use IP unnumbered links to conserve address space.
The VTEP’s IP address in the underlay is what other VTEPs use as the outer destination when sending tunneled traffic. As long as the underlay network can route between VTEP IP addresses, the overlay network functions regardless of how many hops or routing changes exist in the physical topology underneath.
Verifying VTEP Connectivity
Troubleshooting VXLAN fabrics often starts with confirming that VTEPs can reach each other across the underlay. Standard tools adapted for VXLAN include overlay-aware versions of ping and traceroute. A ping from one VTEP to another confirms basic reachability, while traceroute and pathtrace commands reveal the exact path packets take through the VXLAN overlay. These tools operate at the VXLAN layer rather than just the IP layer, so they can detect problems specific to the overlay, like misconfigured VNIs or failed encapsulation, that a regular IP ping would miss.