skip to content

Encapsulation Format

3 roadmaps5 questions

Outer Ethernet, IP and UDP to port 4789, then an 8-byte VXLAN header with the VNI, then the original frame minus its FCS. Interviewers ask you to count the 50 bytes of overhead.

on this pageshow

explore

questions

5

How many bytes does VXLAN encapsulation add to an Ethernet frame over IPv4, and how does that change with IPv6 or an outer 802.1Q tag?

level: middleimportance: must knowfreq 36%

answer

  1. four headers, add them up
  2. 14 + 20 + 8 + 8
  3. the two FCSs cancel out
  4. IPv6 header is twice IPv4's minimum

basics

~20 s

Over IPv4, VXLAN adds 50 bytes: outer Ethernet 14, outer IPv4 20, UDP 8 and the VXLAN header 8. An outer 802.1Q tag makes it 54; an outer IPv6 header, 40 bytes, makes it 70, or 74 tagged.

solid answer

~50 s

Add the four headers VXLAN puts in front of the inner frame: **outer Ethernet 14** bytes, **outer IPv4 20** (the minimum header, no options), **outer UDP 8** and the **VXLAN header 8** - **50 bytes**. The frame check sequences do not change that: RFC 7348 drops the inner frame's 4-byte FCS and appends a new 4-byte FCS to the outer frame, so a frame that was `N` bytes on the wire becomes `N + 50`. An optional **outer 802.1Q tag** adds 4, giving **54**. With an **IPv6** outer header, which is a fixed 40 bytes, the sum is 14 + 40 + 8 + 8 = **70**, or **74** tagged. The count assumes the inner VLAN tag is stripped, as RFC 7348 recommends, and no IPv4 options. What that growth demands of the underlay is a separate design question.

go deeper

for a junior

Remember the sum 14 + 20 + 8 + 8 = 50 for VXLAN over IPv4 and which header each number belongs to.

for a middle

Add up each header from memory, explain why the dropped inner FCS and the new outer FCS cancel, and give the 54 and 70 variants with their reasons.

for a senior

Recompute the overhead for whatever the underlay actually carries - a tag on some links, IPv6 on others, an inner tag a VTEP kept - and state which assumption each figure rests on.

for a principal

Treat the per-packet byte cost as one input to an overlay choice: a fixed 50 is predictable, while an extensible format such as Geneve trades a variable overhead for metadata the fabric can use.

## The headers VXLAN adds **VXLAN** (RFC 7348) carries an Ethernet frame inside UDP inside IP inside another Ethernet frame. The **overhead** is the number of bytes the encapsulated frame has over the original one. Four headers are added in front of the inner frame: | Header | Bytes | Where the size comes from | |---|---|---| | Outer Ethernet header | 14 | destination MAC 6 + source MAC 6 + EtherType 2 (the IEEE's format, drawn in RFC 7348's Figure 1) | | Outer IPv4 header | 20 | RFC 791: the header length field counts 32-bit words, and its minimum is 5 | | Outer UDP header | 8 | RFC 768: source port, destination port, length, checksum - 2 bytes each | | VXLAN header | 8 | RFC 7348 section 5: flags, reserved, VNI, reserved | ## Adding it up 1. Outer Ethernet: 14 bytes, running total 14. 2. Outer IPv4: 20 bytes, running total 34. 3. Outer UDP: 8 bytes, running total 42. 4. VXLAN header: 8 bytes, running total **50**. The inner Ethernet header is **not** overhead: it was already part of the original frame. ## Why the FCS does not change the count RFC 7348's frame-format figure notes that the original Ethernet frame's **FCS is not included**, and it ends the packet with a **new FCS** for the outer frame. Take a frame whose payload is `P` bytes: - **Original frame:** 14-byte header + `P` + 4-byte FCS = `P + 18`. - **Encapsulated frame:** 14 + 20 + 8 + 8 + (14 + `P`) + 4 = `P + 68`. - **Growth:** `P + 68` - (`P + 18`) = **50**. For a full-size frame with a 1,500-byte payload, 1,518 bytes become 1,568. The 4 bytes dropped and the 4 bytes added cancel, so the answer is the same whether you count both frames with their FCS or both without it. Adding the inner FCS on top - and quoting 54 for that reason - is a counting mistake. ## Variations | Outer IP | Outer 802.1Q tag | Overhead (bytes) | |---|---|---| | IPv4 | no | 14 + 20 + 8 + 8 = **50** | | IPv4 | yes | 18 + 20 + 8 + 8 = **54** | | IPv6 | no | 14 + 40 + 8 + 8 = **70** | | IPv6 | yes | 18 + 40 + 8 + 8 = **74** | The IPv6 base header is a fixed 40 bytes (RFC 8200), twice IPv4's 20-byte minimum, which is the whole of the 20-byte difference. RFC 7348 calls the outer VLAN tag **optional**: it exists only on an underlay link that carries one, so the same packet can be 54 bytes larger than the original on a tagged link and 50 on the next, untagged one. ## What the count leaves out - **IPv4 options** in the outer header would add to the 20 bytes; VTEPs normally send none, so 20 is the number used. - **An inner VLAN tag** is not encapsulation overhead, but if a VTEP is configured to keep it (RFC 7348 section 6.1 says it SHOULD strip it by default), the inner frame - and so the whole packet - is 4 bytes longer. - **Preamble and inter-frame gap** are physical-layer costs of every frame, not VXLAN's, and are never part of the 50. - **Other overlays differ.** Geneve (RFC 8926) has the same 8-byte fixed header but variable options after it, so its overhead is not a single number; NVGRE (RFC 7637) uses an 8-byte GRE header with a key instead of UDP plus VXLAN. ## Where the number is used The 50 (or 54, or 70) is the input to sizing decisions on the underlay - how much larger a link's MTU must be than the tenant's, and what happens to a packet that does not fit. Those decisions are a design topic of their own; the arithmetic here is what they start from.

  • Why do some sources quote 50 bytes of VXLAN overhead over IPv4 and others 54?
    Fifty counts an untagged outer Ethernet header; 54 adds a 4-byte outer 802.1Q tag. RFC 7348 marks the outer VLAN tag optional, so both are right for their link: the same packet can carry a tag on one underlay link and none on the next routed hop.
  • Does the inner frame's FCS add 4 more bytes to the VXLAN overhead?
    No. RFC 7348's frame format omits the inner FCS and appends a new FCS for the outer frame, so the two 4-byte fields cancel. A frame of `N` bytes on the wire becomes `N + 50` over untagged IPv4, whether you count both frames with their FCS or both without.
  • If a VTEP keeps the tenant's 802.1Q tag inside the tunnel, how does the byte count change?
    The header overhead stays 50 over IPv4, but the inner frame is 4 bytes longer, so the packet on the underlay is 4 bytes bigger than for the same frame untagged. RFC 7348 section 6.1 says a VTEP SHOULD strip the inner tag before encapsulating unless configured otherwise.

saying these in an interview costs you the question

  • VXLAN adds 8 bytes, because that is the size of the VXLAN header
  • Over IPv6 the VXLAN overhead is still 50 bytes
  • The inner FCS travels too, so the real overhead is 54 bytes
  • The inner Ethernet header counts as part of the encapsulation overhead
  • The outer UDP header is 20 bytes, the same as a TCP header
open as a page

In VXLAN, which headers wrap the original Ethernet frame, from the outside in, and what job does each one do?

level: juniorimportance: should knowfreq 28%

basics

~20 s

VXLAN wraps the original Ethernet frame, minus its FCS, in an 8-byte VXLAN header carrying the 24-bit VNI, then UDP to port 4789, an outer IP header between the two VTEPs, and an outer Ethernet header with a new FCS.

open as a page

How does a VXLAN VTEP set the outer UDP header's destination port, source port and checksum under RFC 7348?

level: middleimportance: should knowfreq 16%

basics

~20 s

Destination port 4789, IANA's assignment, is the default but should be configurable; the source port is the VTEP's choice, recommended as a hash of inner-frame fields in 49152-65535; the checksum SHOULD be zero, and receivers MUST accept zero.

open as a page

What does each field of the 8-byte VXLAN header carry, and what must a VTEP do with its flag and reserved bits?

level: middleimportance: should knowfreq 18%

basics

~20 s

The VXLAN header is 8 bytes: 8 flag bits whose I bit must be 1 for a valid VNI, 24 reserved bits, the 24-bit VNI, then 8 more reserved bits. Reserved bits are sent as zero and ignored on receipt.

open as a page

A capture shows VXLAN packets reaching the remote VTEP, yet the tenant hosts never see the frames; which encapsulation-format mismatches would you check?

level: seniorimportance: should knowfreq 12%

basics

~20 s

Walk the packet against RFC 7348: a destination port the receiver does not decapsulate, a clear I bit or unknown VNI, an inner VLAN tag the receiver discards by default, or a UDP checksum it rejects.

open as a page