MTU / MSS / Encapsulation Calculator
Build an encapsulation stack layer by layer and see exactly how many bytes each header consumes of the MTU budget. Every header size is stated with its source and can be adjusted for the options your deployment actually uses, so the TCP MSS you derive is one you can configure.
Encapsulation stack
Layers are ordered outermost first. The MTU applies to the outermost IP packet, and each layer inward consumes part of that budget.
1500 for standard Ethernet, 9000 for jumbo frames, 1492 after PPPoE.
Common configurations
L1IPv4
RFC 791 · 20 bytes
20 B minimum header. The IHL field allows up to 15 × 4 = 60 B, so options can add as much as 40 B.
L2TCP
RFC 9293 · 20 bytes
20 B base header. The data offset field allows up to 60 B, so options can add up to 40 B.
TCP MSS calculator
MSS is the largest TCP payload that fits in one segment without IP fragmentation: MSS = MTU − IP header − TCP header.
12 B is typical with timestamps and SACK permitted.
Ignored for IPv6.
TCP MSS
1460 bytes
20 B IP header + 20 B TCP header = 40 B of headers per segment.
- MSS = MTU 1500 − IP header 20 − TCP header 20 = 1460 bytes.
- 1460 is the classic Ethernet TCP MSS for a 1500-byte MTU.
The MTU budget is a subtraction
The outer MTU is a fixed envelope. Every protocol layer inside it consumes part of that envelope, and what remains is the payload. There is no cleverness in the arithmetic — the difficulty is knowing the real header size of each layer, which is what makes tunnel MTU problems so hard to diagnose in practice.
Payload = MTU − Σ(header sizes of every layer)
TCP MSS = MTU − IP header − TCP header
= Payload when the innermost layer is TCP
Worked: GRE tunnel carrying IPv4 and TCP over a 1500-byte link
Outer IPv4 header 20 B
GRE header 4 B
Inner IPv4 header 20 B
TCP header 20 B
────────────────────────────
Total overhead 64 B
Payload / MSS 1436 BCommon encapsulation overheads
These are the figures to memorise. Each one is the total overhead in bytes and the resulting MSS when the innermost protocol is TCP with a 20-byte header.
| Encapsulation | Overhead breakdown | Total | MSS |
|---|---|---|---|
| Plain IPv4 | IPv4 20 + TCP 20 | 40 B | 1460 |
| Plain IPv6 | IPv6 40 + TCP 20 | 60 B | 1440 |
| PPPoE | PPPoE 8 + IPv4 20 + TCP 20 | 48 B | 1452 |
| 802.1Q VLAN | VLAN 4 + IPv4 20 + TCP 20 | 44 B | 1456 |
| GRE | IPv4 20 + GRE 4 + IPv4 20 + TCP 20 | 64 B | 1436 |
| GRE with key | IPv4 20 + GRE 8 + IPv4 20 + TCP 20 | 68 B | 1432 |
| VXLAN | IPv4 20 + UDP 8 + VXLAN 8 + Eth 14 + IPv4 20 + TCP 20 | 90 B | 1410 |
| GTP-U | IPv4 20 + UDP 8 + GTP-U 8 + IPv4 20 + TCP 20 | 76 B | 1424 |
| MPLS L3VPN (2 labels) | MPLS 8 + IPv4 20 + TCP 20 | 48 B | 1452 |
| IPsec ESP (AES-CBC, SHA-256) | IPv4 20 + ESP ~62 + IPv4 20 + TCP 20 | ~122 B | ~1378 |
IPsec is shown as approximate because its overhead genuinely varies: cipher block size, IV length, padding to the block boundary and the chosen integrity check length all change the total. This calculator lets you pick each of those parameters rather than presenting one number as if it were universal.
Example: diagnosing a tunnel that works for ping but not for downloads
A GRE tunnel is configured with the default 1500 MTU at both ends. Small pings succeed because they produce tiny packets. Large transfers stall, and HTTP requests to some sites hang.
The arithmetic explains it exactly:
Ping of 100 bytes → 100 + 20 (outer IP) + 4 (GRE) + 20 (inner IP) + 8 (ICMP) = 152 bytes, well under 1500. Works.
TCP segment of 1460 bytes → 1460 + 64 = 1524 bytes, over 1500. Dropped because DF is set and fragmentation is not permitted.
The fix is two configuration changes: set the tunnel interface MTU to 1476 (1500 − 24) and add MSS clamping so TCP never advertises more than 1436. Without the clamping, hosts will still try to send 1460-byte segments.
Why ICMP matters more than people expect
Path MTU discovery depends on routers being able to tell the sender that a packet was too big. When a firewall blocks ICMP type 3 code 4 (IPv4) or ICMPv6 type 2 (Packet Too Big), the sender never learns and keeps retransmitting the same oversized packet forever.
This is why “the website does not load over the VPN but works outside it” is such a common complaint, and why MSS clamping is often preferred over relying on PMTUD in networks where ICMP policy is not under your control. Clamping works unconditionally because it prevents the oversized packet from ever being created.
Choosing between the fixes
- Lower the tunnel MTU and clamp MSS. The most reliable option and the one that works regardless of ICMP policy. This is the default recommendation for GRE, VXLAN and GTP-U paths.
- Raise the physical MTU. Common in data centres, where the underlay is set to 1550 or 1600 so overlays can carry a full 1500-byte inner packet. Requires that every device on the Layer 2 path agree.
- Rely on PMTUD alone. Fine on well-behaved networks where ICMP reaches both endpoints. Fragile anywhere ICMP is filtered, which is most of the public internet.
- Enable jumbo frames end to end. Worth it in a controlled data centre, not worth it anywhere the path is not fully under your control.
Protocol header references
Every header size in this calculator comes from the defining standard. The full list, for verification against your own documentation:
| Protocol | Base size | Options | Standard |
|---|---|---|---|
| Ethernet II | 14 B | VLAN +4 B per tag | IEEE 802.3 |
| IPv4 | 20 B | up to 40 B via IHL | RFC 791 |
| IPv6 | 40 B fixed | extension headers, 8 B+ each | RFC 8200 |
| TCP | 20 B | up to 40 B via data offset | RFC 9293 |
| UDP | 8 B fixed | none | RFC 768 |
| GRE | 4 B | +4 checksum, +4 key, +4 sequence, +8 routing | RFC 2784 / RFC 2890 |
| VXLAN | 8 B fixed | none | RFC 7348 |
| GTP-U | 8 B | +4 S flag, +4 PN flag, +4 E flag | 3GPP TS 29.281 |
| PPPoE | 8 B (session) | none | RFC 2516 |
| MPLS | 4 B per label | stack depth varies | RFC 3032 |
| IPsec ESP | 8 B base | IV + padding + ICV vary by SA | RFC 4303 |
| WireGuard | 32 B + 16 B tag | none | WireGuard protocol |
For a longer discussion of PMTUD, MSS clamping and tunnel MTU design, see the MTU and MSS guide. To see how tunnel overhead reduces achievable throughput, combine this with the TCP throughput calculator.
Frequently asked questions
What is the difference between MTU and MSS?
MTU is the largest packet a link can carry, measured in bytes and including all headers. MSS is the largest TCP payload, measured in bytes and excluding the IP and TCP headers. On standard Ethernet with IPv4 and TCP, MTU is 1500, headers take 40 bytes, and MSS is 1460. MTU is a link property; MSS is an endpoint property that should be derived from the path MTU.
Why does a GRE tunnel break large packets?
GRE adds 24 bytes of overhead (a 20-byte outer IPv4 header plus a 4-byte GRE header). Packets that were exactly 1500 bytes before tunnelling become 1524 bytes, which exceeds the physical link MTU. The router must fragment, and if the DF bit is set — which it usually is, because PMTUD relies on it — the packet is dropped instead. The fix is to lower the tunnel interface MTU to 1476 and, critically, to clamp TCP MSS to 1436 so senders never produce oversized segments.
What is TCP MSS clamping?
MSS clamping rewrites the MSS value in the TCP SYN and SYN-ACK packets as they pass through a router, so both endpoints advertise a value that fits the tunnel path. It is the pragmatic fix for tunnel MTU problems, because it works even when ICMP is blocked somewhere on the path and path MTU discovery cannot complete. On Cisco devices it is configured with ip tcp adjust-mss.
How much overhead does a GTP-U tunnel add?
The base GTP-U header is 8 bytes. Add a 20-byte outer IPv4 header, an 8-byte UDP header and, if the inner packet is IPv4 with TCP, another 40 bytes of inner headers. A typical LTE or 5G user-plane packet therefore carries 76 bytes of overhead before any payload. If the S, PN or E flags are set, the GTP-U header grows to 12 bytes.
Why is the MSS 1440 with IPv6?
The IPv6 header is a fixed 40 bytes versus 20 bytes for IPv4 without options. On a 1500-byte MTU with a standard 20-byte TCP header, MSS = 1500 − 40 − 20 = 1440. IPv6 routers also never fragment on the path, so the sender must respect the discovered path MTU or the packet is dropped with an ICMPv6 Packet Too Big message.
How much overhead does VXLAN add?
VXLAN adds an outer IPv4 header (20 bytes), a UDP header (8 bytes), an 8-byte VXLAN header, and an inner Ethernet header (14 bytes) because VXLAN carries a complete Layer 2 frame. That is 50 bytes before the inner IP packet. A typical VXLAN host therefore uses a 1550 MTU on the physical interface to keep the inner MTU at 1500, or reduces the overlay MTU to 1450.
What is path MTU discovery?
PMTUD is the mechanism a sender uses to find the smallest MTU along a path. It sends packets with the DF (don't fragment) bit set and relies on routers returning an ICMP 'fragmentation needed' message when a packet is too large. ICMPv6 handles the equivalent for IPv6 with Packet Too Big. When a firewall blocks those ICMP messages, PMTUD silently fails and connections hang on large transfers while small ones work — the classic 'ping works but the website does not' symptom.
Should I use jumbo frames?
Only if every device on the Layer 2 path supports them. A 9000-byte MTU reduces header overhead from about 2.9% to 0.5% and cuts interrupt load substantially, but a single device stuck at 1500 causes drops that are hard to diagnose. Jumbo frames are common inside data centres and rare on WAN links or over the internet.