MTU Explained: VLAN, GRE, VXLAN and IPsec Overhead

MTU problems are often caused by one simple fact: an encapsulated packet needs more bytes than the original packet. This guide explains the overhead, the resulting effective MTU and a practical troubleshooting workflow.

What Is MTU?

MTU — Maximum Transmission Unit — is the largest Layer 3 packet a network interface or path can transmit without requiring fragmentation at that layer.

1500 bytes is a common Ethernet IP MTU, but it is not universal. Jumbo Ethernet, tunnels, provider networks and overlay designs may use different values.

The important question is not only "What is the interface MTU?" but also "What is the smallest MTU available across the path after encapsulation?"

Quick Reference

Encapsulation	Typical overhead*	1500-byte outer MTU leaves
802.1Q VLAN	4 bytes at Ethernet frame level	1500-byte IP MTU remains
GRE over IPv4	24 bytes	1476-byte inner IP MTU
VXLAN over IPv4	36 bytes above inner IP	1464-byte inner IP MTU
IPsec	Implementation-dependent	Must be calculated for the actual tunnel

*Typical values. Exact overhead depends on headers, options, transport, mode and implementation. For VXLAN, the 36-byte figure is IPv4 + UDP + VXLAN above the inner IP packet; measuring a complete Ethernet frame produces a different number.

Why Does MTU Matter?

If an original packet fits inside the configured MTU but does not fit after encapsulation, something has to give. Depending on the protocol and configuration, the packet may be fragmented, dropped, or trigger Path MTU Discovery behavior.

MTU problems are especially frustrating because small packets often work. A TCP connection may establish successfully while larger transfers stall, certain applications fail, or HTTPS behaves differently from a simple ping.

MTU vs Packet Size

MTU and packet size are related but not identical concepts. MTU is the maximum size permitted by an interface or path. The packet may be smaller.

For example, with a 1500-byte IP MTU, an IPv4 TCP packet carrying 1460 bytes of TCP payload can fit because the 20-byte IPv4 header and 20-byte TCP header bring the IP packet to 1500 bytes.

VLAN Overhead

An 802.1Q VLAN tag adds 4 bytes to the Ethernet frame. Importantly, a normal VLAN tag does not usually reduce the configured Layer 3 IP MTU from 1500 to 1496. Ethernet equipment is designed to accommodate the tagged frame.

The distinction between Layer 2 frame size and Layer 3 IP MTU matters when comparing vendor documentation or diagnosing a path.

GRE Overhead

A basic GRE tunnel over IPv4 commonly adds:

20 bytes for the outer IPv4 header
4 bytes for the basic GRE header

Total: 24 bytes.

If the outer path supports only a 1500-byte IP MTU, the inner IP packet may need to be limited to approximately:

1500 - 24 = 1476 bytes

GRE options or additional encapsulation can change the exact number.

VXLAN Overhead

VXLAN commonly uses UDP over IP. A typical VXLAN packet over IPv4 adds:

20 bytes outer IPv4 header
8 bytes UDP header
8 bytes VXLAN header

That is 36 bytes above the inner IP packet:

1500 - 36 = 1464 bytes

When calculating the full outer Ethernet frame, the outer Ethernet header and optional VLAN tagging also matter. Always state which layer your overhead calculation refers to.

VXLAN Example

Underlay MTU: 1500

Suppose a host generates an inner IP packet of 1500 bytes. Adding the typical 36-byte VXLAN/IPv4/UDP overhead creates an outer IP packet of approximately 1536 bytes.

If the underlay cannot carry that size, the packet cannot traverse the path unchanged. A common design response is to raise the underlay MTU so the encapsulated packet fits.

IPsec and MTU

IPsec is more complicated because the overhead depends on the tunnel mode, encryption/authentication algorithms, padding, address family and implementation.

Do not assume one universal "IPsec overhead" number. Calculate the actual tunnel encapsulation used by the platform, then leave enough headroom for the outer packet.

This is one reason IPsec deployments often use reduced tunnel/interface MTUs or TCP MSS adjustment rather than relying on every endpoint to discover the correct value automatically.

Path MTU Discovery

Path MTU Discovery (PMTUD) attempts to discover the largest packet that can traverse a path without fragmentation. For IPv4, a router can signal that a packet is too large using ICMP Destination Unreachable with the "Fragmentation Needed" indication.

If those ICMP messages are filtered, PMTUD can fail. The sender may continue transmitting packets that are too large, resulting in a black-hole MTU condition.

Why MTU Problems Are So Difficult to Diagnose

MTU issues can be asymmetric and protocol-dependent. Common symptoms include:

Ping works, but larger pings fail.
TCP sessions establish, but transfers hang.
Some websites work while others do not.
Traffic works without a VPN or tunnel but fails through it.
IPv4 works while IPv6 behaves differently.
Only specific paths or remote sites are affected.

The fact that a small packet succeeds proves very little about the maximum packet size of the path.

MTU and TCP MSS

TCP MSS limits the TCP payload size advertised by endpoints. For a typical 1500-byte IPv4 interface MTU:

1500 - 20 IPv4 - 20 TCP = 1460 byte MSS

If the effective path MTU is 1400 bytes:

1400 - 20 IPv4 - 20 TCP = 1360 byte MSS

MSS clamping can prevent TCP endpoints from generating segments that are too large for a tunnel or constrained path. It does not, however, fix every MTU problem — non-TCP traffic and broken PMTUD still need consideration.

A Practical MTU Troubleshooting Workflow

Identify the path. Determine where encapsulation begins and ends.
List every encapsulation layer. VLAN, GRE, VXLAN, IPsec, PPPoE and provider-specific headers can all matter.
Check interface MTUs. Verify both tunnel and physical interfaces where relevant.
Calculate the expected effective MTU. Subtract the actual overhead from the outer path MTU.
Test packet sizes. Use DF-aware tests where appropriate and increase/decrease payload size systematically.
Check ICMP handling. Verify that PMTUD-related ICMP messages are not being filtered.
Inspect TCP MSS. Compare advertised MSS with the actual path MTU.
Capture traffic if needed. Packet captures often reveal the exact outer packet size and whether packets are fragmented or dropped.

MTU Design Example

Imagine an overlay network using VXLAN over an IPv4 underlay. The design target is to support a full 1500-byte inner IP packet.

With typical 36-byte VXLAN/IPv4/UDP overhead, the underlay needs to support at least:

1500 + 36 = 1536 byte outer IP packet

In a real Ethernet design, the required frame size also includes the relevant Ethernet headers and any tags. The exact configured MTU should therefore be based on the platform's definition of MTU and the complete encapsulation stack.

The Golden Rule of MTU

Calculate from the outside in.

Start with the maximum packet size the physical path can carry. Subtract every header added by encapsulation. The result is the maximum inner packet size that can safely traverse that path without fragmentation.

Use the NetOpsBench MTU Calculator

Calculate effective MTU and encapsulation overhead without doing the header math manually.

Open NetOpsBench →

FAQ

Is Ethernet MTU always 1500?

No. 1500 bytes is common, but jumbo frames and other technologies use different values.

Does a VLAN tag reduce IP MTU by 4 bytes?

Not normally. The 4-byte 802.1Q tag increases the Ethernet frame size; a standard 1500-byte IP MTU can still be carried inside the tagged frame.

Why does VXLAN often require a larger underlay MTU?

Because the original packet is wrapped in additional outer headers. If you want a full-size inner packet, the underlay must accommodate the encapsulated packet.

Can MSS clamping solve MTU problems?

It can prevent many TCP sessions from sending segments that exceed the effective path MTU, but it does not solve non-TCP traffic or every PMTUD failure.

References: RFC 2784 (GRE), RFC 7348 (VXLAN), RFC 1191 (IPv4 Path MTU Discovery), RFC 4301 (IPsec).