skip to content

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%

answer

  1. IANA's well-known port
  2. configurable for early implementations
  3. source port from an inner hash
  4. zero checksum allowed, then accepted
  5. IPv6 changes the checksum story

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.

solid answer

~50 s

RFC 7348 section 5 sets the **outer UDP header** this way. The **destination port** is `4789`, assigned by IANA, and SHOULD be used by default - but SHOULD also be configurable, because early implementations used other ports. The **source port** is provided by the VTEP; the RFC recommends a **hash of fields from the inner frame**, and when it is computed that way it is RECOMMENDED to fall in the dynamic range `49152-65535`, which gives the underlay per-flow entropy. The **checksum** SHOULD be transmitted as zero, and a receiver MUST accept a zero checksum; a non-zero one must be correct over the whole packet, and a receiver that verifies it MUST drop a failure. Over IPv6, RFC 8200 makes the UDP checksum mandatory by default and allows a tunnel's zero only in RFC 6936's zero-checksum mode. Riding in UDP lets existing hardware hash and filter VXLAN as an ordinary 5-tuple flow.

go deeper

for a junior

Remember that VXLAN rides in UDP and that its destination port is 4789, assigned by IANA.

for a middle

Explain all three fields: the configurable 4789, a source port hashed from the inner frame in the dynamic range, and a checksum that SHOULD be zero and MUST be accepted as zero.

for a senior

Be ready to debug a port mismatch with an early implementation and to explain why IPv6's mandatory UDP checksum needs RFC 6936's zero-checksum mode before a zero can be sent.

for a principal

Explain why riding UDP was the pragmatic choice for VXLAN: existing hardware hashes and filters 5-tuples, at the cost of a UDP header per packet and checksum rules that differ between IPv4 and IPv6.

## The outer UDP header **VXLAN** (RFC 7348) puts its 8-byte header and the tenant's Ethernet frame inside a **UDP** datagram. The UDP header is the 8-byte one RFC 768 defines - four 2-byte fields - and RFC 7348 section 5 says how a **VTEP** (VXLAN Tunnel End Point) fills each: | Field | Bytes | Value under RFC 7348 | |---|---|---| | Source port | 2 | chosen by the sending VTEP; recommended to be a hash of inner-frame fields | | Destination port | 2 | `4789`, IANA's assignment, used by default and configurable | | Length | 2 | 8 (UDP) + 8 (VXLAN) + the inner frame's length | | Checksum | 2 | SHOULD be zero; if non-zero, it must be correct | ## Destination port: 4789 IANA assigned **4789** to VXLAN, and RFC 7348 says it **SHOULD be used by default**. The same paragraph adds that the destination port **SHOULD be configurable**, because some early implementations used other values. The port is how a receiver recognises a datagram as VXLAN and hands it to decapsulation; if the two ends disagree, the receiver sees UDP to a port it does not treat as VXLAN, and the tenant frame is never delivered. Geneve (RFC 8926) uses its own port, 6081. ## Source port: entropy from the inner frame The source port is the one field a VTEP is free to vary. RFC 7348 recommends computing it as a **hash of fields from the inner packet** - for example the inner Ethernet frame's headers - and, when it is computed that way, keeping it in the **dynamic/private range 49152-65535** that RFC 6335 sets aside. The stated purpose is entropy: 1. Packets of one inner flow hash to the **same** source port, so they look like one outer flow. 2. Different inner flows tend to get **different** source ports, so they look like different outer flows. 3. Underlay devices that already balance on the UDP 5-tuple therefore spread the overlay's traffic without parsing VXLAN. How the underlay should use that entropy is a fabric-design question; the encapsulation's part is only to put it in the source port. ## Length UDP's length field counts the UDP header and everything after it: 8 + 8 + the inner frame without its FCS. For an inner frame of 1,514 bytes (a 1,500-byte payload plus a 14-byte header) the UDP length is 1,530. ## Checksum: IPv4 and IPv6 RFC 7348's rules are: - The checksum **SHOULD be transmitted as zero**. - A receiver **MUST accept** a packet with a zero checksum for decapsulation. - A sender that does include a non-zero checksum **MUST compute it correctly** across the entire packet, including the IP header, UDP header, VXLAN header and encapsulated frame. - A receiver **MAY verify** a non-zero checksum; if it verifies and the check fails, it **MUST drop** the packet; otherwise it **MUST accept** it. Over **IPv4**, an all-zero UDP checksum means the sender computed none (RFC 768). Over **IPv6** it does not: RFC 8200 says an IPv6 node must compute a UDP checksum and a receiver must discard a zero one, with one exception - a protocol using UDP as a tunnel encapsulation may enable **zero-checksum mode** for specific ports, under the requirements of RFC 6936. A VXLAN deployment over IPv6 sends zero checksums only where both ends have that mode enabled for the VXLAN port; otherwise it computes the checksum. ## Why UDP at all RFC 7348 does not run VXLAN directly over IP with its own protocol number. Inside UDP it gets a 5-tuple that existing switches and routers already hash and filter - its security section points to 5-tuple ACLs - and a source port to carry entropy. NVGRE (RFC 7637), which uses GRE, has no ports and carries an 8-bit FlowID in the GRE key for the same purpose. ## Common mistakes - Saying the **source** port is also 4789 - only the destination port is fixed. - Calling a zero checksum **invalid** - over IPv4 it is the RFC 7348 default. - Assuming RFC 7348's zero checksum carries over to **IPv6** unconditionally. - Thinking the port number **identifies the segment** - that is the VNI's job.

  • What happens when VXLAN packets arrive on a UDP port the receiving VTEP does not treat as VXLAN?
    The receiver does not decapsulate them: they are ordinary UDP datagrams to a port with no VXLAN listener, so the tenant frames are dropped, and a host stack may answer with an ICMP port-unreachable message. RFC 7348 keeps the destination port configurable because early implementations used ports other than 4789, so both ends must agree.
  • Can a VTEP send VXLAN over IPv6 with a zero UDP checksum?
    Only in zero-checksum mode. RFC 8200 requires IPv6 UDP checksums by default and has receivers discard a zero checksum, but lets protocols that use UDP as a tunnel encapsulation enable zero-checksum mode for specific ports under RFC 6936's requirements. Where that mode is not enabled at both ends, the VTEP must compute the checksum.

saying these in an interview costs you the question

  • VXLAN uses TCP port 4789
  • The outer source port is fixed at 4789 as well
  • A zero UDP checksum is invalid, so VXLAN receivers drop it
  • RFC 7348's zero checksum is automatically fine over IPv6 too
  • The UDP destination port tells the receiver which VNI the frame is in