📡 MTU Size Calculator

📋 Preset configurations

Pick a preset to fill in the link MTU, IP version, transport, and encapsulation stack automatically. Adjust afterwards to mix and match.

🔗 Link MTU (bytes)

Standard Ethernet is 1500; PPPoE DSL is 1492; jumbo frames go to 9000 or higher. Range: 576 – 9216.

🌐 IP version

📦 Transport

MSS is only meaningful for TCP. UDP just costs 8 bytes; "None" skips L4 entirely.

🧅 Encapsulations

Toggle each layer to add its overhead. Ordering inside the breakdown matches the selection order.

🔍 Path MTU Discovery panel

Simulates a coarse-grained probe for common sizes to show how many fragments each size would require under the current configuration.

📊 Results

Inner MTU
{{ result.mtu }}
bytes available for IP + L4 + payload
TCP MSS
{{ mssDisplay }}
MTU − IP header − TCP header
Effective payload
{{ result.payload }}
bytes of application data per packet
Total overhead
{{ result.overhead }}
bytes for encap + IP + L4 headers
Enter a link MTU and configuration to see results.

🧱 Header breakdown

Layer Bytes
{{ row.layer }} {{ row.bytes }}
Total overhead {{ result.overhead }}

⚠️ Warnings

  • • {{ w }}

🔍 Path MTU Discovery probe

Probe size Fragments Status
{{ row.size }} {{ row.fragmentsRequired }} DROP FRAG OK
⚠️

ℹ️ About MTU Size Calculator

What is MTU and why MSS depends on it

The Maximum Transmission Unit (MTU) is the largest size, in bytes, of a single IP datagram that a link can carry without fragmentation. Standard Ethernet has an MTU of 1500 bytes; jumbo frames raise the ceiling to 9000 or higher. When a packet is too large for a link, the sender either fragments it (IPv4) or the network drops it and returns ICMP "fragmentation needed" (IPv6 — fragmentation is sender-side only).

The Maximum Segment Size (MSS) is the largest TCP payload per segment and is derived from the path MTU: MSS = MTU − IP header − TCP header. For plain Ethernet + TCP + IPv4, that is 1500 − 20 − 20 = 1460. Every encapsulation (PPPoE, VLAN tags, VPN tunnels) eats into the inner MTU and pushes the safe MSS down. Getting these numbers wrong produces silent connection stalls — large transfers hang while small payloads work, the classic MTU black hole.

Hard-coded header sizes (from the RFCs)

  • IPv4 header — 20 bytes fixed (RFC 791 §3.1).
  • IPv6 header — 40 bytes fixed (RFC 8200 §3).
  • TCP header — 20 bytes without options (RFC 9293 §3.1).
  • UDP header — 8 bytes (RFC 768).
  • PPPoE — 8 bytes (RFC 2516): 6-byte PPPoE session header + 2-byte PPP protocol field.
  • 802.1Q VLAN tag — 4 bytes (IEEE 802.1Q).
  • QinQ (802.1ad) — 8 bytes (two stacked VLAN tags).
  • WireGuard over UDPv4 — 60 bytes (project whitepaper §5.4); WG recommends an inner MTU of 1420.
  • IPsec ESP (AES-CBC) — variable, ≈38 bytes (RFC 4303); transport-mode estimate.
  • IPsec ESP (AES-GCM, tunnel) — ≈62 bytes (RFC 4106); tunnel-mode estimate.
  • GRE — 24 bytes with key + sequence (RFC 2784 + RFC 2890); strict base header is 4 bytes.
  • L2TPv3 — 12 bytes (RFC 3931).
  • IPIP — 20 bytes (RFC 2003); adds an outer IPv4 header.

Common results — worked out

  • Ethernet + TCP/IPv4: MTU 1500 → MSS 1460 (1500 − 20 − 20).
  • PPPoE + TCP/IPv4: inner MTU 1492 → MSS 1452 (8-byte PPPoE shim).
  • 802.1Q VLAN + TCP/IPv4: inner MTU 1496 → MSS 1456.
  • QinQ + TCP/IPv4: inner MTU 1492 → MSS 1452.
  • WireGuard over IPv4: inner MTU 1440 (recommended 1420) → MSS 1400 or lower.
  • GRE + TCP/IPv4: inner MTU 1476 → MSS 1436.
  • IPv6 + TCP: MSS drops by exactly 20 vs IPv4 (40-byte IPv6 header instead of 20).

Practical use cases

  • Tuning a VPN tunnel (WireGuard, IPsec, OpenVPN) — set the tunnel MTU and the outbound MSS clamp on both ends. Without clamping, asymmetric paths drop the full-size handshake silently.
  • PPPoE on DSL/fiber CPE — set the WAN interface MTU to 1492 and clamp MSS to 1452 on the CPE so the LAN-side hosts never emit oversize segments.
  • Carrier Ethernet with QinQ — datacenter tenants pushing 1500-byte guest VMs over a QinQ uplink must shrink the guest MTU by 8 bytes or enable jumbo on the underlay.
  • Diagnosing "the web works but file transfers hang" — classic Path MTU black hole. Verify the MSS in tcpdump SYN packets matches what this calculator says for the underlying path.
  • Designing an overlay network — adding WireGuard (60), then 802.1Q (+4) leaves an inner MTU of 1436 over Ethernet. Plan capacity accordingly.

Path MTU Discovery (PMTUD)

PMTUD is the mechanism by which TCP probes for the smallest MTU on a path. IPv4 senders mark packets DF (don't fragment) and rely on intermediate routers to return ICMP "fragmentation needed". If those ICMPs are dropped (overly aggressive firewalls), the connection black-holes: the SYN/ACK works but the first full-size segment never arrives. IPv6 has no in-network fragmentation at all — the sender must probe via ICMPv6 "packet too big" messages. The PMTUD panel here simulates a coarse-grained probe table for the currently selected configuration.

Mitigation: clamp the advertised MSS (iptables … TCPMSS --clamp-mss-to-pmtu on Linux, or ip tcp adjust-mss on Cisco). Many tunnel implementations enable this automatically.

Source references

  • RFC 791 — Internet Protocol (IPv4); §3.2 defines the 576-byte minimum any host must accept.
  • RFC 1191 — Path MTU Discovery (IPv4).
  • RFC 8201 — Path MTU Discovery for IPv6.
  • RFC 879 — TCP Maximum Segment Size; the 536 default.
  • RFC 4459 — MTU and Fragmentation Issues with In-the-Network Tunneling.
  • WireGuard whitepaper — packet structure and MTU recommendations.

Limits and practical notes

  • Header sizes are baseline. TCP and IP options, GRE tunnel-key configuration, IPsec cipher choice, and L2TP variant (v2 over UDP vs v3) all shift the real overhead.
  • The IPsec figures here are conservative estimates. Real overhead depends on the cipher, mode (transport vs tunnel), authentication algorithm, and inner padding.
  • WireGuard recommends an inner MTU of 1420 over IPv4 even though the raw header math suggests 1440 — the extra slack absorbs Path MTU Discovery quirks on the public internet. Over IPv6 the recommendation drops to 1400.
  • Calculations run in your browser. The same logic is exposed by the API endpoint below, which uses the shared Module-First TypeScript module.

API Usage Example:

POST /api/tools/networking/mtu-size-calculator
Content-Type: application/json

{
    "operation": "compute",
    "linkMtu": 1500,
    "ipVersion": "4",
    "transport": "tcp",
    "encapsulations": [
        "pppoe"
    ]
}
Ready