Premium apps Part of Signalhouse
Signalhouse MTU, Fragmentation & TCP Throughput Calculator
Tunnel overhead, inner MTU and MSS, IPv4/IPv6 fragments and a TCP throughput model.
Try an example: Textbook: a 4000-byte IPv4 datagram over a 1500-byte MTU · WireGuard over a PPPoE DSL line · VXLAN over an IPv6 underlay with 1500-byte links · IPsec ESP with NAT traversal (AES-CBC, approximate) and IPv6 inside · Long fat network: 1 Gbit/s over 150 ms without window scaling · TCP with 0.1 % loss on a 100 Mbit/s, 80 ms path
How it works
Stack encapsulations on a link — PPPoE, MPLS, GRE, IP-in-IP, 6in4, DS-Lite, VXLAN, Geneve, WireGuard and IPsec ESP (approximate) — and get the inner MTU, the TCP MSS for IPv4 and IPv6 and the wire efficiency. Send a packet through it to see the exact IPv4 fragments (offsets, lengths, MF flag), what happens with “Don’t Fragment” and why IPv6 routers answer “Packet Too Big”. A TCP model adds the bandwidth-delay product, the window scale you need and the Mathis loss limit. It is the MTU panel of the Signalhouse Network lab.
- Each encapsulation subtracts its header bytes from the MTU of the layer below it, from the wire inwards: PPPoE 8, MPLS 4 per label, GRE over IPv4 24 (28 with a key), IPIP and 6in4 20, IP-in-IPv6 40, VXLAN and Geneve 50 over IPv4 or 70 over IPv6 (they carry an inner Ethernet header), WireGuard 60 over IPv4 or 80 over IPv6.
- IPsec ESP in tunnel mode is computed from the cipher: outer IPv4 20, ESP header 8, IV, padding of the encrypted part to the cipher block (16 bytes for AES-CBC, 4 for AES-GCM) including the 2-byte trailer, and the ICV (12 for HMAC-SHA1-96, 16 for GCM); NAT-T adds a UDP header. Real overhead varies with options, so the figure is labelled approximate.
- IPv4 fragments carry data in multiples of 8 bytes (the offset field counts 8-byte units); every fragment but the last has MF set (RFC 791). IPv6 packets are only fragmented by the source, each fragment repeats the unfragmentable headers and adds an 8-byte Fragment header (RFC 8200); routers drop oversize packets with “Packet Too Big”.
- TCP MSS = MTU − 40 (IPv4) or − 60 (IPv6), without TCP options. The TCP estimate is the minimum of the bandwidth, window ÷ RTT and the Mathis et al. model MSS ÷ RTT × √(3/2) ÷ √loss. It models steady-state Reno-style congestion avoidance; CUBIC, BBR, slow start and queueing behave differently.
Sources
- RFC 791: Internet Protocol (fragmentation) (IETF)
- RFC 8200: Internet Protocol, Version 6 (IPv6) Specification (IETF)
- RFC 4303: IP Encapsulating Security Payload (ESP) (IETF)
- RFC 7348: Virtual eXtensible Local Area Network (VXLAN) (IETF)
- WireGuard: Next Generation Kernel Network Tunnel (protocol and message format) (J. A. Donenfeld)
- RFC 7323: TCP Extensions for High Performance (window scaling) (IETF)
- The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm (Mathis, Semke, Mahdavi, Ott, 1997) (ACM SIGCOMM CCR)
Part of Signalhouse
-
Signalhouse Website & internet infrastructure inspector
Inspect DNS, TLS, mail, CDN and routing of all your domains — and see what changed.
Related tools
- Signalhouse Route Lookup & Packet Path Simulator (longest prefix match) – Which route wins? Longest prefix match, distances, ECMP — or a hop-by-hop packet walk.
- Signalhouse Subnet Planner (VLSM, CIDR aggregation, IPv4/IPv6) – Subnet calculator, VLSM planner, CIDR aggregation and exclusion for IPv4 and IPv6.
- Network Speed Tester – Measure latency, jitter, download and upload speed between your browser and our server.
How to use the Signalhouse MTU, Fragmentation & TCP Throughput Calculator
Work out the inner MTU and TCP MSS behind PPPoE, VPNs and overlays, see exact IPv4 and IPv6 fragments, and estimate TCP throughput from RTT and loss.
What it is for
Many "some websites hang" problems are MTU problems: every tunnel or access protocol adds headers, so a full-size 1500-byte packet no longer fits and large transfers stall. This calculator stacks encapsulations on a link, shows how much room is left, what happens to a packet of a given size and how fast one TCP connection can go.
It covers PPPoE, MPLS, GRE, IP-in-IP, 6in4, DS-Lite, VXLAN, Geneve, WireGuard and IPsec ESP. Use it to pick a VPN interface MTU, set MSS clamping or explain a slow long-distance transfer. IPsec figures are approximate, and the TCP part is a model, not a measurement.
Worked example
A home office runs WireGuard over a PPPoE DSL line. Set the link MTU to 1500 and add two encapsulations, from the wire inwards: "PPPoE (DSL)" and "WireGuard over IPv4". Then send a 1500-byte packet with "Don't Fragment" set. For the TCP model, enter 250 Mbit/s, 40 ms round-trip time and 0.05 % loss.
The calculator answers: "Inner MTU 1432 bytes (68 bytes overhead on a 1500-byte link), TCP MSS 1392 bytes for IPv4; a 1500-byte packet is dropped; TCP reaches about 15.249 Mbit/s (limited by the packet loss)."
The layer table shows the details: PPPoE takes 8 bytes (1500 → 1492), WireGuard 60 bytes (1492 → 1432). The 1500-byte packet with DF is dropped with "fragmentation needed" and a next-hop MTU of 1432, so the tunnel should use MTU 1432 and an MSS of 1392.
For the TCP model, the bandwidth-delay product is 1,250,000 bytes (window scale 5 or more). A 0.05 % loss rate limits one Reno-style connection to about 15 Mbit/s, far below the 250 Mbit/s line rate.
The textbook case also works: a 4000-byte IPv4 datagram over a 1500-byte MTU becomes three fragments with offsets 0, 185 and 370 and total lengths 1500, 1500 and 1040.
How to read the result
- Inner MTU is the largest IP packet that fits inside all the layers. Overhead is what the layers cost.
- TCP MSS is the inner MTU minus 40 bytes (IPv4) or 60 bytes (IPv6), without TCP options.
- Ethernet efficiency is the TCP payload share of the bytes on the wire, counting Ethernet framing.
- The packet box says whether the packet fits, is fragmented (IPv4 without DF) or is dropped. The fragment table lists offsets in 8-byte units, data bytes, total lengths and the more-fragments flag.
- TCP throughput model shows the estimate, what limits it (bandwidth, receive window or loss), the bandwidth-delay product, the window scale you need and the Mathis loss limit.
Tips and common mistakes
- Add layers from the wire inwards; order matters for IPsec padding.
- VXLAN and Geneve carry an inner Ethernet frame. Either raise the underlay MTU to 1550 or more, or lower the overlay MTU.
- IPv6 links must carry at least 1280 bytes; the tool warns below that.
- IPv6 routers never fragment. An oversize packet comes back as "Packet Too Big", which firewalls must let through.
- Without window scaling the window stops at 65,535 bytes. That is only about 3.5 Mbit/s at 150 ms RTT.
FAQ
Why is the IPsec value marked approximate?
ESP overhead depends on the cipher, its IV and ICV sizes, padding to the block size, NAT traversal and options such as TFC padding. The calculator computes it exactly for the listed suites without TFC padding; your peers may differ by a few bytes.
Which TCP formula is used?
Throughput ≤ MSS / RTT × √(3/2) / √loss, from Mathis et al. (1997), capped by the line rate and window ÷ RTT. It describes steady-state Reno-style congestion avoidance; CUBIC and BBR can do better or worse.
Does the receive window field need a value?
No. Leave it empty and the model assumes the window grows as large as the path needs (with scaling) or stays at 65,535 bytes (without).
Is there an interactive version?
Yes. The Network lab in Signalhouse has the same panel and saves it with your project; packets there also cross links with their own MTU.
Guide last updated:
For scripts and AI agents
- JSON API:
POST https://signalhousemtucalculator.usefulweb.site/api/v1/calculate(same calculation as this page) - Interface description: OpenAPI 3.1 · AI guide: llms.txt
- MCP server (Streamable HTTP):
https://signalhousemtucalculator.usefulweb.site/mcp· tool namesignalhouse_mtu_calculator
Example request
curl -s -X POST https://signalhousemtucalculator.usefulweb.site/api/v1/calculate \
-H 'content-type: application/json' \
-d '{"linkMtu":1500,"packetSize":4000,"df":false}'