skip to content

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%

answer

  1. two 32-bit words
  2. one flag bit matters
  3. zero on send, ignored on receipt
  4. 24 reserved bits before the VNI
  5. a trailing reserved byte

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.

solid answer

~50 s

RFC 7348 section 5 lays the **VXLAN header** out as two 32-bit words. The first word is an **8-bit flags field** followed by **24 reserved bits**; of the eight flags only the **I bit** is defined - it MUST be 1 for a valid VNI - and the other seven are reserved. The second word is the **24-bit VNI** followed by **8 reserved bits**. Every reserved bit MUST be zero on transmission and **ignored on receipt**, so a receiver must not reject a packet because one is set. Because the I bit is the fifth bit of the first byte, a conforming header starts with `0x08`; VNI 5000 (`0x001388`) gives `08 00 00 00 00 13 88 00`. There is no length, protocol-type or checksum field: the payload is always an Ethernet frame, and a 24-bit VNI allows 16,777,216 values.

code

pseudocode · 15 lines
pseudocode
function encode_vxlan_header(vni):
    require 0 <= vni <= 0xFFFFFF          // 24 bits
    h[0] = 0x08                           // I flag set, seven R bits zero
    h[1] = 0x00; h[2] = 0x00; h[3] = 0x00 // 24 reserved bits
    h[4] = (vni >> 16) AND 0xFF
    h[5] = (vni >> 8) AND 0xFF
    h[6] = vni AND 0xFF
    h[7] = 0x00                           // 8 reserved bits
    return h                              // vni 5000 -> 08 00 00 00 00 13 88 00

function decode_vxlan_header(h):
    if (h[0] AND 0x08) == 0:
        return NO_VALID_VNI               // I flag clear
    // reserved bits are ignored, whatever their value
    return (h[4] << 16) OR (h[5] << 8) OR h[6]

go deeper

for a junior

Remember that the VXLAN header is 8 bytes and that its main job is to carry the 24-bit VNI naming the overlay segment.

for a middle

Draw the two 32-bit words from memory - flags, 24 reserved bits, the VNI, 8 reserved bits - and state the I-bit and reserved-bit rules for sender and receiver.

for a senior

Read a header from a hex dump, explain why ignoring reserved bits matters for interoperability, and say what the format's lack of a protocol type and options rules out.

for a principal

Weigh a fixed 8-byte header that hardware parses trivially against an extensible one, such as Geneve's options, that carries metadata at the cost of variable length and parsing work.

## Where the header sits **VXLAN** (RFC 7348) wraps a tenant's Ethernet frame in UDP and IP. Between the outer UDP header and the inner frame sits the **VXLAN header**: exactly **8 bytes**, the same for every packet. It carries one thing the underlay does not - the **VNI** (VXLAN Network Identifier), which tells the receiving **VTEP** (VXLAN Tunnel End Point) which overlay segment the inner frame belongs to. ## The layout RFC 7348 draws it as two 32-bit words, most significant bit first: ``` 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 |R|R|R|R|I|R|R|R| Reserved | | VXLAN Network Identifier (VNI) | Reserved | ``` | Bytes (from 0) | Bits | Field | Rule in RFC 7348 | |---|---|---|---| | 0 | 8 | Flags: `R R R R I R R R` | **I** MUST be 1 for a valid VNI; the seven R bits MUST be zero on transmission and ignored on receipt | | 1-3 | 24 | Reserved | MUST be zero on transmission, ignored on receipt | | 4-6 | 24 | **VNI** | identifies the overlay segment | | 7 | 8 | Reserved | MUST be zero on transmission, ignored on receipt | ## Sender and receiver rules - **The I bit** is the only defined flag. RFC 7348 ties the validity of the VNI to it: with I set, bytes 4-6 are a VNI; with I clear, the packet carries no valid VNI. The RFC does not write a separate receive rule for a clear I bit. - **Reserved bits** follow the classic be-strict-in-what-you-send rule: zero when sending, ignored when receiving. Ignoring them on receipt means a bit given a meaning later does not make older receivers drop the traffic. - **The VNI** is compared against the segments the receiving VTEP serves; RFC 7348 section 4.1 has the remote VTEP verify the validity of the VNI before delivering the inner frame. ## Worked example: encoding VNI 5000 1. Convert to 24-bit hex: 5000 = `0x001388` (4,096 + 3 x 256 + 8 x 16 + 8). 2. Byte 0 = `0x08`: only the I bit, the fifth from the most significant end, is set. 3. Bytes 1-3 = `00 00 00`. 4. Bytes 4-6 = `00 13 88`. 5. Byte 7 = `00`. Result: `08 00 00 00 00 13 88 00`. A decoder reverses it: test `byte0 AND 0x08`, then read bytes 4-6 as one big-endian 24-bit number. ## What the header does not have | Missing field | Consequence | |---|---| | Protocol type | The payload is always an Ethernet frame; the UDP destination port is what says "VXLAN" | | Length | Not needed: the UDP length covers everything after the UDP header | | Options | The header is fixed at 8 bytes, which keeps parsing simple in hardware but leaves no room for metadata | | Checksum | Each link's FCS protects a hop; end-to-end cover comes only from the outer UDP checksum, which RFC 7348 lets the sender set to zero | Two overlays make the contrast. **Geneve** (RFC 8926) also has an 8-byte fixed header but includes a version, an option length, a protocol type and variable-length options. **NVGRE** (RFC 7637) puts a 24-bit Virtual Subnet ID and an 8-bit FlowID in the GRE key. ## Common mistakes - Placing the VNI **straight after the flags** - it comes after 24 reserved bits, in bytes 4-6. - Reading the I bit as the **most significant** bit (`0x80`) - it is the fifth bit, `0x08`. - **Rejecting** packets with non-zero reserved bits - the RFC says ignore them. - Confusing the **8-byte header** with the **50-byte overhead** of the full encapsulation over IPv4. - Treating the VNI like a **12-bit VLAN ID** - it is 24 bits, 16,777,216 values; how a fabric spends them is a tenancy design question.

  • Why does RFC 7348 have receivers ignore the VXLAN reserved bits rather than check that they are zero?
    So the bits can be given a meaning later without breaking receivers built earlier. A receiver that dropped packets with a non-zero reserved bit would stop interoperating with any sender that used one; sending zero and ignoring on receipt keeps old and new implementations working together.
  • With no protocol-type field in the VXLAN header, how does a receiver know what the payload is?
    Under RFC 7348 the payload is always an Ethernet frame, so nothing needs to say so: UDP destination port 4789 identifies VXLAN, and VXLAN means Ethernet. Geneve, RFC 8926, adds a Protocol Type field to its header so one encapsulation can carry other payloads.

saying these in an interview costs you the question

  • The VNI is 12 bits wide, just like a VLAN ID
  • The VXLAN header itself is 50 bytes long
  • A protocol-type field in the VXLAN header identifies the payload
  • Receivers must drop any VXLAN packet with a reserved bit set
  • The VNI sits in the 24 bits directly after the flags byte