MTU and MSS are not the same number
MTU is the largest IP packet a link will carry, headers included. MSS is the largest TCP payload one segment may hold, headers excluded. The gap between them is exactly the IP header plus the TCP header, which is 40 bytes on plain IPv4 and 60 on IPv6 — so the familiar pair 1500 and 1460 is one number stated in two conventions.
Encapsulation is what makes the arithmetic worth doing. Wrap traffic in GRE, IPsec, PPPoE or VXLAN and the outer headers come out of the same 1500 bytes, leaving less for the inner packet. If the endpoints never learn about that, they keep negotiating a 1460-byte MSS from their own local interfaces, the tunnel receives packets it cannot forward whole, and the connection fails in a very specific way: the handshake succeeds, small requests work, and anything that fills a segment hangs. That is the classic MTU black hole.
The reason it hangs rather than failing cleanly is path MTU discovery. A router that cannot forward an oversized packet with the don't-fragment bit set is supposed to return ICMP Fragmentation Needed, carrying the MTU it can accept. Filter that message — which a great many firewalls still do — and the sender never learns, so it retransmits the same too-large segment forever. Clamping MSS at the tunnel edge sidesteps the whole mechanism by making the endpoints agree on a small enough segment during the handshake.
Where every byte goes
MSS = MTU − encapsulation − IP header − TCP header. The IP header is 20 bytes for IPv4 without options and 40 bytes for IPv6, whose header is longer but fixed. The TCP header is 20 bytes before options; timestamps and selective acknowledgement consume a further 12 to 20 bytes from the segment at run time, which is why a capture often shows segments slightly smaller than the negotiated MSS. That is expected behaviour, not a fault.
The encapsulation figures in this calculator are header sizes rather than estimates:
- PPPoE, 8 bytes — a 6-byte PPPoE header plus a 2-byte PPP protocol field (RFC 2516). This is why DSL lines have carried a 1492-byte MTU for decades.
- GRE over IPv4, 24 bytes — a 20-byte outer IPv4 header plus the 4-byte GRE header with no optional fields (RFC 2784). Enabling the key or sequence-number options adds 4 bytes each.
- IP-in-IP, 20 bytes — just the outer IPv4 header (RFC 2003).
- VXLAN, 50 bytes — outer Ethernet 14 + outer IPv4 20 + UDP 8 + VXLAN 8, which is why VXLAN fabrics are built with an underlay MTU of at least 1550.
- WireGuard, 60 bytes — outer IPv4 20 + UDP 8 + a 32-byte transport header comprising the message type, receiver index, counter and authentication tag.
IPsec is the one where the total depends on the crypto suite, so it is worth building up rather than memorising. For ESP in tunnel mode with AES-CBC and HMAC-SHA-1-96: outer IPv4 header 20 + ESP header 8 + AES initialisation vector 16 + padding up to 15 to reach the 16-byte block boundary + pad-length and next-header fields 2 + integrity check value 12 = 73 bytes worst case. Transport mode omits the outer IP header, so 73 − 20 = 53. AES-GCM carries an 8-byte IV, pads to a 4-byte boundary (up to 3 bytes) and appends a 16-byte tag, giving 20 + 8 + 8 + 3 + 2 + 16 = 57. Because the padding is variable, these are ceilings, and a given packet may use a few bytes less.
Fragmentation counts in units of 8 bytes. The IPv4 fragment offset field measures the position of a fragment in 8-byte units, so every fragment except the last carries a payload that is a multiple of 8. With a 1500-byte MTU the room after the 20-byte header is 1480, which is already a multiple of 8, so a 4,000-byte datagram becomes three fragments of 1480, 1480 and 1040. On IPv6 the source adds an 8-byte fragment header, so the same link carries 1432 bytes per fragment.
Worked example: a GRE-over-IPsec branch tunnel
A branch office connects over a GRE tunnel protected by IPsec ESP in tunnel mode with AES-CBC and SHA-1. The carrier delivers a standard 1500-byte MTU. Users report that web pages start loading and stall, while ping and DNS work perfectly. Work out the numbers.
- Add the encapsulation. GRE contributes 24 bytes, ESP tunnel mode with AES-CBC and SHA-1 contributes 73. Total overhead = 24 + 73 = 97 bytes.
- Find the effective MTU. 1500 − 97 = 1403 bytes available to the inner IP packet.
- Find the MSS. 1403 − 20 (inner IPv4) − 20 (TCP) = 1363 bytes.
- Compare with what the hosts negotiate. A PC on a 1500-byte LAN offers an MSS of 1460. Every segment it sends at that size becomes 1460 + 20 + 20 = 1500 bytes of inner packet, which needs 1500 + 97 = 1597 bytes on the outer link. That is 97 bytes too large, so it is dropped or fragmented.
- Confirm the symptom. The three-way handshake, a DNS query and an ICMP echo are all far below 1363 bytes, so they pass. The first full-size data segment does not, which is precisely “connects but hangs on real content”.
- Apply the clamp. Set
ip tcp adjust-mss 1363on the tunnel interface. The router now rewrites the MSS option in passing SYN packets, so both endpoints agree to 1363 and no segment ever exceeds the tunnel. - Check the efficiency cost. Each segment now carries 1363 payload bytes in 1363 + 20 + 20 + 97 + 14 Ethernet + 4 FCS + 20 preamble and interframe gap = 1538 bytes of wire time, so wire efficiency is 1363 ÷ 1538 = 88.62%, against 94.93% on the untunnelled link. The tunnel costs about six points of throughput before any encryption cost.
The last step is worth keeping in mind when someone compares a VPN's measured speed against the circuit it runs on: some of the shortfall is arithmetic, not a fault.
How to act on the result
Clamp rather than rely on discovery. Path MTU discovery is the correct mechanism and it works when ICMP is delivered, but a single filtering firewall anywhere on the path breaks it invisibly. MSS clamping on the tunnel interface — ip tcp adjust-mss on IOS, set tcp-mss on Junos, TCPMSS --clamp-mss-to-pmtu in iptables — solves the TCP case deterministically. It does nothing for UDP, which is why large DNS responses and some VPN-inside-VPN designs still need working ICMP.
Test the real path MTU rather than assuming it. Send a ping with the don't-fragment bit set and a payload size you step down until it succeeds; on IPv4, add 28 to the largest working payload to get the MTU, because the ICMP echo carries an 8-byte header inside a 20-byte IP header. A path that works at 1472 bytes of payload has a 1500-byte MTU; one that works only at 1464 has 1492 and is almost certainly PPPoE.
Read the fragment count as a risk, not a cost. Fragmentation still works, but losing any one fragment discards the entire datagram, so a path with 1% packet loss loses about 3% of three-fragment datagrams. Many firewalls and load balancers also drop non-initial fragments because they carry no port numbers to match on. If the count is above one, prefer to reduce the message size at the application.
Wire efficiency explains the missing megabits. A 1500-byte Ethernet frame carrying a full segment occupies 1538 bytes of wire time once the preamble, start delimiter, frame check sequence and 12-byte interframe gap are counted, so 1460 ÷ 1538 = 94.93% of a nominal 1 Gbps link is available as TCP payload — about 949 Mbps. Jumbo frames raise that to roughly 99%, which is why storage fabrics use them. The data transfer time calculator uses figures of this kind to turn a file size into a wall-clock estimate.
Header sizes and where they come from
| Layer or protocol | Bytes | Reference | Notes |
|---|---|---|---|
| Ethernet header + FCS | 18 | IEEE 802.3 | 14-byte header plus 4-byte frame check sequence |
| Preamble, SFD and interframe gap | 20 | IEEE 802.3 | Wire time only; not part of the frame |
| 802.1Q VLAN tag | 4 | IEEE 802.1Q | Two tags for QinQ |
| IPv4 header | 20 | RFC 791 | Up to 60 with options |
| IPv6 header | 40 | RFC 8200 | Fixed; extension headers add more |
| TCP header | 20 | RFC 9293 | Options add up to 40 more |
| UDP header | 8 | RFC 768 | |
| PPPoE + PPP | 8 | RFC 2516 | Gives the familiar 1492 DSL MTU |
| GRE over IPv4 | 24 | RFC 2784 | 20 outer IP + 4 GRE, no options |
| IP-in-IP | 20 | RFC 2003 | Outer IPv4 header only |
| VXLAN over IPv4/UDP | 50 | RFC 7348 | 14 + 20 + 8 + 8 |
| IPsec ESP transport, AES-CBC + SHA-1 | up to 53 | RFC 4303 | 8 ESP + 16 IV + 15 pad + 2 + 12 ICV |
| IPsec ESP tunnel, AES-CBC + SHA-1 | up to 73 | RFC 4303 | Transport total plus a 20-byte outer IP header |
| IPsec ESP tunnel, AES-GCM | up to 57 | RFC 4106 | 20 + 8 + 8 IV + 3 pad + 2 + 16 tag |
IPsec padding varies with the payload length, so those rows are ceilings. Size your MTU to the ceiling; individual packets will sometimes be smaller.
Mistakes that keep MTU faults alive
- Setting the tunnel interface MTU but not clamping MSS. The interface MTU governs what the router itself will send; it does not change what two endpoints negotiate. Both settings are usually needed.
- Blocking all ICMP at the firewall. Filtering ICMP type 3 code 4 on IPv4, or Packet Too Big on IPv6, disables path MTU discovery entirely. IPv6 makes this fatal rather than merely slow, because routers are not permitted to fragment.
- Testing with a default-size ping. A 56-byte ping proves nothing about MTU. Use the don't-fragment bit and a payload near the limit.
- Forgetting that TCP options shrink the segment. Timestamps and SACK take 12 to 20 bytes out of every segment. A capture showing 1448-byte segments against a 1460 MSS is healthy.
- Assuming both directions match. MSS is advertised independently by each end, and asymmetric routing can give the two directions different path MTUs. Clamp on both tunnel endpoints.
- Counting VLAN tags against the IP MTU. On a switch that supports 1522-byte frames a tag costs wire bytes, not IP MTU. It matters for efficiency and for carriers that police total frame size, not for the MSS calculation.
- Enabling jumbo frames on some devices only. A path is as small as its narrowest hop, and one 1500-byte device in a 9000-byte fabric produces exactly the black-hole symptom this page exists to explain.
Related sizing questions
MTU work sits next to throughput work. Once packets are the right size, the next limit on a long path is usually the TCP window: the bandwidth-delay product calculator works out how many bytes must be in flight before a single stream can fill a circuit, and header overhead reduces the payload share of whatever that stream achieves. For voice, the arithmetic runs the other way — payloads are tiny and headers dominate — which is why the VoIP bandwidth calculator treats the 40 bytes of IP, UDP and RTP as the main cost rather than a rounding error.
Jumbo frames are the standard lever where you control the whole path. Raising the MTU from 1500 to 9000 cuts the per-packet header cost by six times and lifts wire efficiency from roughly 95% to about 99%, while also reducing packet rate and interrupt load. The catch is that every device on the path, including switches and any tunnel endpoints, has to agree, and a mismatch produces silent drops rather than an error.
On IPv6 the rules are stricter and, once understood, simpler. RFC 8200 sets a minimum link MTU of 1280 bytes, forbids routers from fragmenting in transit, and makes Packet Too Big the only signal a sender gets. That is why an IPv6 tunnel design starts from the underlay MTU rather than discovering the problem later, and why this calculator raises an error when a stack leaves less than 1280 bytes.
Finally, remember that MSS is a ceiling negotiated at connection setup and never renegotiated. A path that shrinks mid-connection — a failover onto a tunnel with more overhead, for instance — leaves existing connections with an MSS that no longer fits, which is why some outages clear only when clients reconnect.