What is a VXLAN Tunnel Endpoint (VTEP), and what does it do to an Ethernet frame entering and leaving the tunnel?
answer
- originates and terminates tunnels
- wrap at one edge, unwrap at the other
- outer addresses belong to the VTEPs
- the host never sees the VNI
basics
~20 sA VTEP originates and terminates VXLAN tunnels: it wraps a host's Ethernet frame in a VXLAN header carrying the segment's VNI, plus UDP and an outer IP header addressed VTEP to VTEP, and the far VTEP strips them and delivers the original frame.
solid answer
~50 sRFC 7348 defines a VTEP as an entity that originates and/or terminates VXLAN tunnels. On the sending side it takes an ordinary Ethernet frame from a virtual machine or server, works out which VXLAN segment (VNI) the frame belongs to and which remote VTEP serves the destination MAC address, and prepends a VXLAN header, a UDP header with destination port `4789`, an outer IP header from its own address to the remote VTEP's, and a new outer Ethernet header. The IP network between them, the underlay, routes on those outer addresses only. The receiving VTEP checks that the VNI is valid and that a local host on that VNI owns the inner destination MAC, strips the outer headers and hands over the original frame. The hosts never see the VNI or the tunnel: to them the remote host is simply on the same LAN.
go deeper
Recall that a VTEP wraps a host's Ethernet frame in VXLAN, UDP and an outer IP header between two VTEP addresses, and the far VTEP unwraps it so the host never notices.
Explain both directions in order: VNI and remote-VTEP lookup, the four added headers, the receiver's VNI and destination-MAC checks, then stripping and delivery.
Show the operational consequence: the underlay routes only VTEP addresses, so tenant subnets stay out of its tables, and most overlay faults sit either between VTEP addresses or inside one VTEP.
Frame the VTEP as the boundary between two address spaces, and weigh where to put that boundary, in hypervisors or in switches, against who operates each side.
## Where the VTEP sits **VXLAN** (Virtual eXtensible Local Area Network) carries Ethernet frames across an IP network, so that machines in different racks, or even different rooms, can share one **Layer 2 segment** while the network between them is routed at **Layer 3**. It is documented in **RFC 7348**, an Informational RFC published in 2014; it describes a deployed protocol rather than an Internet Standard. The component that does the work is the **VXLAN Tunnel End Point (VTEP)**. RFC 7348 defines it in one line: an entity that originates and/or terminates VXLAN tunnels. Its examples put the VTEP inside the **hypervisor** of the server that hosts the virtual machines, and the RFC adds that a VTEP can also be a physical switch or a physical server, implemented in software or in hardware. Two vocabulary terms recur: - the **overlay** is the stretched Layer 2 segment the hosts believe they are on, identified by a 24-bit **VXLAN Network Identifier (VNI)**; - the **underlay** is the ordinary IP network that carries VTEP-to-VTEP packets and knows nothing about the segments. The IETF's general architecture for overlays, RFC 8014, calls the same role a **Network Virtualization Edge (NVE)**; RFC 8365 states that an NVE and a VTEP are equivalent. RFC 7348 explains why anyone wants this. A routed fabric between racks avoids spanning tree's blocked links and uses every path, but virtual machines that must share a Layer 2 segment cannot then sit on different racks. Putting a VTEP at the edge reconciles the two: the hosts keep their segment, and the network in the middle stays routed. ## Encapsulation: the sending side When a host sends a frame to another host on its segment, the local VTEP: 1. **Identifies the segment.** It knows which VNI the sending host's port or virtual interface belongs to. 2. **Finds the far end.** It looks up the destination MAC address within that VNI to find the IP address of the remote VTEP behind it. How that mapping gets into the table, by learning from traffic or from a control protocol, is a separate subject. 3. **Wraps the frame.** It drops the frame's original FCS and prepends, from the inside out, an **8-byte VXLAN header** carrying the VNI, a **UDP header** whose destination port is `4789` by default, an **outer IP header** whose source is its own VTEP address and whose destination is the remote VTEP's, and an **outer Ethernet header** for the first hop, followed by a new FCS. 4. **Hands it to the underlay.** From here the packet is an ordinary UDP/IP packet routed toward the remote VTEP's address. ## Decapsulation: the receiving side When a VXLAN packet addressed to it arrives, the remote VTEP: 1. **Checks the VNI.** RFC 7348 has it verify that the VNI is valid and that a local host on that VNI uses the inner destination MAC address. 2. **Strips the outer headers.** Outer Ethernet, outer IP, UDP and the VXLAN header are removed. 3. **Delivers the original frame** to the destination host, which, in RFC 7348's words, never knows about the VNI or that the frame was carried with a VXLAN encapsulation. ## What a VTEP is not - **Not a session.** RFC 7348 calls the tunnels **stateless**: each frame is encapsulated independently according to a set of rules. VXLAN itself defines no handshake or keepalive between VTEPs. - **Not a router of tenant traffic.** For traffic within one segment the VTEPs bridge: they do not rewrite the inner MAC addresses or touch the inner IP header. - **Not visible to the hosts.** No configuration on the virtual machine mentions a VNI or a VTEP address. ## Two address spaces The clearest way to see what a VTEP achieves is to separate the addresses it juggles. | Address | Belongs to | Who forwards on it | |---|---|---| | Inner MAC and IP addresses | the tenant hosts | the VTEPs, by MAC within a VNI | | VNI | the overlay segment | the VTEPs only | | Outer IP source and destination | the two VTEPs | every underlay router | | Outer MAC addresses | the current underlay hop | each underlay link | Because underlay routers forward only on the outer addresses, they need routes to the VTEP addresses and nothing else. The tenant hosts' subnets never have to appear in the underlay's routing tables, which is what lets a Layer 2 segment span a routed fabric.
- Does a VXLAN VTEP set up a session with the remote VTEP before sending frames, the way many VPN tunnels do?No. RFC 7348 describes VXLAN tunnels as stateless: every frame is encapsulated independently, using the VTEP's mapping from destination MAC to remote VTEP address, and VXLAN defines no handshake or keepalive. The tunnel between two VTEPs is just the stream of packets one addresses to the other; whether the far VTEP is reachable is decided by the underlay's routing.
- What does a receiving VXLAN VTEP check before it delivers a decapsulated frame?RFC 7348 has it verify that the VNI is valid, which requires the I flag in the VXLAN header to be set, and that a local host on that VNI uses the inner destination MAC address; only then does it strip the headers and pass the frame on. A decapsulated frame carrying an inner VLAN tag SHOULD be discarded unless the VTEP is configured to accept it.
An office mailroom that slips an internal memo into an envelope addressed to the other building's mailroom: couriers read only the envelope, the receiving mailroom opens it and walks the memo to the right desk, and the person who wrote the memo never sees the envelope.
saying these in an interview costs you the question
- Underlay routers decrement the inner packet's TTL at every hop between two VTEPs.
- Each virtual machine must be configured with its VNI and the remote VTEP's address.
- A VXLAN tunnel is a session that VTEPs negotiate before any frame can be sent.
- Underlay routers need routes to the tenant subnets to deliver VXLAN traffic.
- A VTEP can only ever be software inside a hypervisor.