MTU and IP Fragmentation
See whether a packet fits the MTU, how many IP fragments result, and the per-frame payload (MTU − header). Presets 1500, 1492, and 1400 for LAN, PPPoE, and VPN.
Results
Enter data and click Calculate.
What MTU means
MTU (Maximum Transmission Unit) is the largest packet/frame size (in bytes) a link or path can carry without splitting. On typical Ethernet, IPv4 MTU is usually 1500 B — the limit for an IP datagram (IP header + payload) that fits an Ethernet frame without fragmentation on that hop.
If you send a packet larger than the path MTU, a router must fragment it (when allowed) or drop it (when the DF — Don't Fragment — bit is set). This calculator estimates how many fragments result for a given packet size and MTU, and the usable per-fragment payload (MTU − IP header).
What IP fragmentation is
- A large datagram is split into smaller fragments, each with its own IP header.
- The receiver reassembles them; losing one fragment loses the whole datagram.
- Fragmentation adds header overhead, CPU cost, and fragility (middleboxes that mishandle fragments).
- In IPv6, intermediate routers do not fragment — the source does; path MTU discovery matters even more.
Common MTU values
- 1500 — classic Ethernet / most LAN and many WAN links.
- 1492 — common for PPPoE (Ethernet 1500 minus ~8 B PPPoE overhead).
- ~1400–1420 — typical VPN tunnels (IPsec, OpenVPN, WireGuard depending on overhead); exact value varies.
- 9000 — jumbo frames in some datacenter LANs (must be consistent end-to-end).
- 1280 — minimum required for IPv6.
Form presets (1500 / 1492 / 1400) cover the most common LAN, PPPoE, and “safe” VPN starting points.
Example calculations
Assume IPv4 header = 20 B (no options). Per-fragment payload ≈ MTU − 20.
- 2000 B packet, MTU 1500: first fragment carries up to ~1480 B payload + 20 B IP; the rest follows. Expect 2 fragments (calculator simplification — real splits also honor fragment offset alignment).
- 1500 B packet, MTU 1500: fits in one piece — 1 (no fragmentation at that limit).
- 1500 B packet, MTU 1492 (PPPoE): no longer fits — fragmentation or lower MSS/MTU at the source.
- 1400 B packet, MTU 1400 (VPN): tunnel edge case; larger TCP flows often need MSS clamping.
Enter your own numbers — the result shows fragment count and per-frame payload.
Quick table: MTU vs packet size
A simplified view — use the form for exact fragment counts (IP header + offset alignment).
| MTU | Packet | Fits? | Note |
|---|---|---|---|
| 1500 | 1400 | Yes (1) | Typical Ethernet — headroom |
| 1500 | 1500 | Yes (1) | Ethernet MTU boundary |
| 1500 | 1600 | No → fragments | Expect ≥2 fragments |
| 1492 | 1500 | No → fragments | Common PPPoE case |
| 1400 | 1500 | No → fragments | Common VPN starting point |
Educational arithmetic, not full Path MTU Discovery. With DF and black-hole symptoms, diagnose separately (ping/tracepath/VPN MSS).
Why fragmentation matters
- Performance — more packets mean more interrupts and headers.
- Reliability — one lost fragment kills the datagram; TCP retransmits more.
- Security / middleboxes — some firewalls mishandle or drop fragments.
- Symptoms — partial page loads, VPN stalls on large transfers, SSH works but HTTPS does not (classic MTU black hole).
Honest note: this is simplified, not full PMTUD
The calculator does arithmetic splitting by MTU and IP header size. It does not simulate Path MTU Discovery, DF bits, ICMP “Packet Too Big”, TCP MSS clamping, or real-world IPv4/IPv6 operator quirks. Treat the output as a quick educational/planning estimate — for production diagnostics use ping -f -l / tracepath / VPN tests per your link docs.
MTU vs TCP MSS (practical link)
For typical IPv4 + TCP without options: MSS ≈ MTU − 40 (20 B IP + 20 B TCP). At MTU 1500, MSS ≈ 1460; at 1492 ≈ 1452; at 1400 ≈ 1360. When a VPN lowers the effective MTU, clamping MSS on the firewall/router often fixes “page never finishes loading”, because SYN/ACK negotiates a smaller segment and avoids fragmentation.
- Pick the target MTU first (e.g. 1400 on VPN).
- Set MSS clamp ≈ MTU − 40 (IPv4) or MTU − 60 (IPv6 + TCP).
- Confirm with the calculator that a typical app packet (e.g. 1500) would fragment at the new MTU — that is your signal that clamp/PMTUD is required.
FAQ — MTU, PPPoE, VPN, and fragmentation
Short answers on common MTU values and what this calculator does not simulate.
- What does MTU 1500 mean?
- On Ethernet it is the usual maximum IP datagram size in a frame — about 1500 B of IP (header + data) without fragmenting on that hop.
- Why is PPPoE often 1492?
- PPPoE adds a few bytes of overhead; with Ethernet 1500 the effective IP MTU usually drops to 1492.
- How many fragments for a 2000 B packet at MTU 1500?
- With a 20 B header — typically 2 fragments. Check the calculator for the exact count (offset alignment can affect details).
- Does VPN always need MTU 1400?
- Not always — it depends on protocol and options. 1400 is a safe starting point; WireGuard/IPsec may need another value. Test.
- What is an MTU black hole?
- Large DF packets are dropped and ICMP “too big” never returns — the session stalls on bigger transfers.
- Does this replace PMTUD?
- No. This is simplified arithmetic. PMTUD/PLPMTUD discovers the path MTU live on the network.
- Which IP header size should I enter?
- Plain IPv4 without options: 20. IPv6 base: 40. Tunnels add their own overhead — you usually lower MTU rather than invent a huge header size.
- When is jumbo 9000 appropriate?
- Only when every device on the LAN path supports a consistent jumbo MTU. Do not assume jumbo on the public Internet.