Understanding MTU, MSS, and Packet Fragmentation

MTU problems cause some of the strangest network symptoms: ping works, SSH starts, but web pages never finish loading; small API calls pass, large uploads hang; everything looks healthy until you enable a VPN. In many outages, routing is not broken and DNS is not broken. Packet size is broken.

That is why MTU and MSS matter. They control how much real application data fits in each packet once protocol overhead is added. If packet size is wrong for one hop in the path, traffic fragments or drops. Either outcome costs performance. In the worst case, sessions black-hole and users see random timeouts that are hard to reproduce.

For network engineers, cloud operators, and CCNA/CCNP students, MTU literacy is practical day-one skill. You need it for tunnels, overlays, WAN links, edge firewalls, SD-WAN, and hybrid cloud.

What is MTU?

MTU (Maximum Transmission Unit) is the largest Layer 3 packet payload a link can carry without fragmentation. On Ethernet, standard MTU is 1500 bytes. That 1500 excludes Ethernet header and FCS; it is the payload portion of Ethernet frame.

Common values you will see:

• Standard Ethernet: 1500
• Jumbo Ethernet: often 9000
• PPPoE access: 1492
• WireGuard deployments: often around 1420

MTU is link-local property, not global internet constant. Each hop can have different MTU. End-to-end path MTU is always minimum MTU found anywhere on path. Smallest segment wins.

That minimum is your operational limit. If source sends packets larger than path MTU, something must happen:

• packet fragments (IPv4 only, when allowed), or
• packet drops and sender must reduce size.

What is MSS?

MSS (Maximum Segment Size) is TCP payload limit. It is not whole packet size. It is only application bytes carried inside TCP segment.

Classic formula:

MSS = MTU - IP header - TCP header

For standard IPv4 + TCP headers (20 + 20) on MTU 1500:

1500 - 20 - 20 = 1460

So each TCP segment carries at most 1460 bytes of user data in this baseline case.

Important details:

• MSS applies to TCP only.
• UDP has no MSS negotiation; apps must choose safe datagram size.
• MSS is announced in SYN and SYN-ACK during TCP handshake.
• TCP options (for example timestamps) increase header size and effectively lower payload.

When someone says “set MSS to 1360,” they are controlling TCP payload, usually to avoid fragmentation inside tunnel path.

Packet anatomy: where bytes go

Think of packet as nested wrappers:

1. Application data
2. TCP or UDP header
3. IP header
4. Link-layer frame header/trailer on wire

With plain IPv4/TCP over Ethernet, on-wire frame roughly looks like:

• Ethernet header: 14 bytes
• IP header: 20 bytes
• TCP header: 20 bytes
• Payload: up to MSS
• Ethernet FCS: 4 bytes

Inside a 1500 MTU context, IP+TCP consume 40 bytes, leaving 1460 payload.

Once you add more layers, payload shrinks. Example with tunnel:

• Outer IP/UDP/tunnel headers added
• Inner packet still has its own IP/TCP headers
• Effective data fraction goes down

This is why overlay-heavy networks often need careful MTU design and MSS clamping.

Fragmentation

IPv4 fragmentation

IPv4 allows routers to fragment packets if packet exceeds outgoing link MTU and DF bit is not set. Router splits packet into pieces, each with its own IP header. Destination host reassembles fragments.

This works, but performance cost is real:

• extra headers reduce efficiency,
• reassembly adds CPU and memory pressure,
• packet loss sensitivity increases (lose one fragment, whole original packet fails),
• middleboxes may drop fragments inconsistently.

Fragmentation is compatibility mechanism, not optimization strategy.

IPv6 behavior

IPv6 routers never fragment transit packets. If packet is too big, router drops it and returns ICMPv6 Packet Too Big. Only sender can decide smaller size (or perform source fragmentation with extension headers, uncommon in typical operations).

Operational takeaway: blocking ICMPv6 breaks PMTUD faster than many teams expect.

DF bit in IPv4

IPv4 DF (Don’t Fragment) bit tells network: “Do not fragment this packet.”

If DF packet is too large for link:

• router drops packet,
• router sends ICMP “Fragmentation Needed” with next-hop MTU.

This signal powers PMTUD.

Path MTU Discovery (PMTUD)

PMTUD tries to find largest packet size that survives path unfragmented.

Typical flow:

1. Sender transmits at local MTU with DF semantics.
2. Oversize packet hits smaller link.
3. Network returns ICMP “Fragmentation Needed” (IPv4) or “Packet Too Big” (IPv6).
4. Sender reduces packet size.
5. Process converges on safe path MTU.

When it works, you get efficient packets and no fragmentation.

When it fails, you get black-hole connections.

Why PMTUD fails in real networks

Most common reason: ICMP blocked by firewall policy. Teams often block ICMP broadly for “security” and accidentally remove control-plane feedback PMTUD needs.

Result:

• handshake may succeed,
• larger data packets disappear,
• app retries, stalls, or times out.

Symptoms look random because only certain packet sizes fail.

MSS clamping

MSS clamping rewrites MSS value in TCP SYN packets to conservative number. That forces endpoints to use smaller segments from start, reducing chance of PMTUD failure impact.

Common implementations:

• Cisco: ip tcp adjust-mss
• Linux: iptables -j TCPMSS --clamp-mss-to-pmtu

Clamping does not fix UDP sizing problems, but it is highly effective for TCP-heavy flows crossing constrained MTU domains.

Tunnel and VPN overhead

Encapsulation is where MTU math becomes operationally critical. Tunnels add outer headers around inner packet. Those bytes come from same MTU budget.

Typical overhead ranges:

• GRE: about 24B in practical model (outer IPv4 + GRE base)
• VXLAN: about 50B (outer Ethernet + outer IP + UDP + VXLAN)
• WireGuard: often around 60B effective overhead (implementation/path-dependent)
• IPsec ESP (AES-GCM): often 50-73B depending on mode and padding

Because numbers vary by mode, platform, and options, treat these as engineering baselines, then verify in captures.

Rule of thumb

If underlay MTU is fixed:

• lower inner MTU by expected overhead, and/or
• clamp TCP MSS at tunnel edge.

Example:

• underlay MTU 1500
• overhead 60
• inner safe MTU near 1440
• IPv4/TCP MSS near 1400

Double encapsulation compounds quickly. VXLAN inside IPsec can consume 100+ bytes. If you ignore this, random fragmentation and throughput collapse follow.

Troubleshooting MTU issues

MTU failures often masquerade as application bugs. Build repeatable workflow.

Common symptoms

• large downloads stall, small requests succeed
• SSH interactive shell works, SCP/SFTP hangs
• VPN connected but certain sites fail
• gRPC or TLS handshakes intermittently timeout

Practical diagnostics

1) Controlled ping sizing

Linux:

Windows:

Lower SIZE until packets pass. Add headers back to estimate path MTU.

2) tracepath on Linux

tracepath can reveal PMTU changes along route and often identifies where size drops.

3) Packet capture in Wireshark

Look for:

• IPv4 ICMP Type 3 Code 4 (Fragmentation Needed)
• ICMPv6 Type 2 (Packet Too Big)
• retransmissions that correlate with larger segment sizes

4) Validate tunnel/interface settings

Check both sides of tunnel and intermediate device policies. Mismatched MTU across peers is common failure mode.

Fast mitigation path

When outage is active and root cause not fully mapped yet:

1. clamp MSS on affected edge,
2. reduce tunnel/interface MTU conservatively,
3. restore service,
4. then refine with captures and PMTU tests.

This approach reduces blast radius quickly while preserving path to permanent fix.

Common MTU values reference

Environment / Link	Typical MTU	Notes
Ethernet (standard)	1500	Most enterprise/user LANs
PPPoE	1492	8-byte PPPoE overhead from 1500
GRE (effective inner target)	1476	Common baseline with outer IPv4 + GRE
VXLAN overlay	1450	Assumes ~50-byte overhead
WireGuard	1420	Frequent default in many deployments
IPsec tunnel	~1400	Depends on transform and mode
Jumbo Ethernet	9000	Datacenter east-west patterns
Loopback (Linux typical)	65536	Local software interface
IPv6 minimum link MTU	1280	Required by IPv6 standards

Use these as starting points, not final truth. Actual safe value depends on full path and active encapsulation stack.

Design guidance for engineers

Keep MTU domain intentional

In large networks, define MTU standards per domain:

• campus LAN,
• datacenter fabric,
• WAN/Internet edges,
• overlay underlay.

Document where transitions occur. Hidden transitions create hidden failures.

Prefer consistent underlay where possible

Uniform underlay MTU reduces surprises for overlays. If fabric supports larger MTU, tunnels get more room and fewer clamp hacks.

Don’t block required ICMP blindly

Security policy should permit ICMP types needed for PMTUD, especially on controlled boundaries. “Block all ICMP” is recurring anti-pattern.

Validate after changes

After enabling new tunnel, IPSec policy, or firewall rewrite, verify:

• effective MSS seen in SYN,
• PMTUD signals pass,
• large-payload flows complete reliably.

Watch telemetry

Fragment counters, retransmission rates, and tunnel drops can reveal MTU drift early before users complain.

MTU and performance economics

Packet size affects throughput efficiency directly. More payload per packet means fewer packets for same data volume, lower per-packet overhead, and often better CPU utilization on hosts and network devices.

Too-small MSS means:

• more packets for same transfer,
• more ACK/control traffic,
• higher interrupt/processing load,
• lower goodput on high-latency paths.

That said, chasing largest possible MTU blindly is also mistake. Stability first. Correct end-to-end size beats theoretical max with intermittent black-holes.

Putting it all together

When evaluating path, ask three questions:

1. What is smallest MTU on path?
2. What encapsulation overhead applies in this direction?
3. What MSS should TCP advertise to stay below fragmentation boundary?

If you can answer these fast, you can solve most MTU incidents quickly.

Use Packetry MTU/MSS Calculator to model combinations interactively: base MTU, IPv4 vs IPv6 headers, TCP options, PPPoE, and common tunnels/security wrappers. Visual packet breakdown makes overhead visible, which is useful both for design reviews and incident response.

Conclusion

MTU and MSS are not obscure theory. They are core controls for reliable transport behavior across modern networks full of overlays, VPNs, and security wrappers. Fragmentation, PMTUD, and MSS clamping are tightly linked; ignoring any one of them creates brittle paths.

Strong MTU practice is simple:

• measure real path,
• account for encapsulation,
• set sane MSS,
• allow PMTUD feedback,
• verify with captures.

If traffic behaves strangely under load, packet size math is one of first places to look. And once you build habit of checking MTU/MSS early, many “mystery” issues stop being mysteries.