Why the MTU Calculator I Wished Existed: Stackable Tunnel Overhead, Per-Vendor MSS Clamp Commands, and Shareable Links

What’s new: The MTU / MSS Calculator on TravTeks now does three things the others don’t: one-click scenario presets for the most common tunnel stacks (IPsec, GRE-over-IPsec, VXLAN, VXLAN-over-MPLS, GENEVE, WireGuard, PPPoE), per-vendor adjust-mss commands ready to copy-paste (Cisco IOS-XE, IOS-XR, NX-OS, JunOS, Linux iptables, Linux nftables, pfSense/OPNsense), and shareable URLs that encode the full calculation so you can paste a link in chat and the recipient sees exactly what you saw.

The problem with every other MTU calculator

If you’ve ever searched “MTU calculator” you’ve seen the same five results, and they all stop at the same place: type in a path MTU, pick one encapsulation, get an answer.

That’s not how real networks work. Real networks stack encapsulations on top of each other constantly:

• A site-to-site GRE tunnel inside an IPsec tunnel (the RFC 4023 pattern, because IPsec can’t carry multicast or routing-protocol traffic natively)
• A VXLAN overlay over an MPLS L3VPN transport in a service-provider data center
• A GENEVE encapsulation in an NSX-T fabric, sometimes itself riding over IPsec to a remote site
• A WireGuard mesh that customers tunnel additional protocols through

When the stack gets two layers deep, every calculator I could find went hand-wavy: “add the overheads together.” That’s true but it doesn’t help when you’re staring at a tunnel that’s silently dropping large packets and you need to know exactly what MSS to clamp to.

I also kept hitting another wall — I’d compute the right MSS value, but then I still had to look up the syntax for adjust-mss for whichever device I was configuring. Cisco IOS, NX-OS, JunOS, IOS-XR, and Linux iptables all have different syntax. The five-minute calculation became a ten-minute calculation plus a vendor doc dive.

So this week I went back and rebuilt the TravTeks MTU calculator to solve those two problems.

What’s actually new

1. Scenario presets at the top

Seven one-click buttons that load the most common tunnel stacks instantly:

• IPsec site-to-site — ESP tunnel mode, AES (56 bytes overhead)
• GRE over IPsec — the classic for routing-protocol or multicast over IPsec (80 bytes total: 56 + 24)
• VXLAN overlay — flat VXLAN in a DC fabric (50 bytes)
• VXLAN over MPLS — VXLAN inside a 2-label MPLS L3VPN (58 bytes: 50 + 4 + 4)
• GENEVE overlay — for NSX-T, OVN, modern SDN (50 bytes base, more with options)
• WireGuard — site-to-site WireGuard over IPv4 (60 bytes)
• PPPoE — consumer broadband DSL/fiber CPE (8 bytes)

Plus a Clear button. You can still add and remove encapsulations manually for cases the presets don’t cover.

2. Per-vendor MSS clamp commands

This is the one I personally needed. Once the calculator has your MSS value, it shows the actual adjust-mss command for whichever platform you’re configuring, tabbed across:

• Cisco IOS / IOS-XE — interface Tunnel0 / ip tcp adjust-mss <value>
• Cisco NX-OS — same syntax, applied on the SVI or routed interface
• Cisco IOS-XR — needs tcp mss-adjust enable globally first, then per-interface
• Juniper JunOS — set system internet-options tcp-mss <value> system-wide, or filter-based per-tunnel
• Linux iptables — -j TCPMSS --set-mss <value> in the mangle table
• Linux nftables — tcp option maxseg size set <value> in the modern syntax
• pfSense / OPNsense — System → Advanced → Networking → MSS

Each tab has a Copy button. One click, paste into your terminal. No more typing the wrong syntax three times.

3. Shareable URLs

The full state of the calculator — path MTU, IP version, transport, every encapsulation in the stack with custom byte values — encodes into the URL hash. So this:

/tools/mtu-calculator#m=1500&v=4&t=20&s=ipsec-tun-aes,gre&b=56,24

…is a complete configuration. Open it, and the calculator loads with IPsec tunnel + GRE inside, on a 1500-byte path, IPv4, TCP — exactly what someone shared. There’s a Copy Link button on every result.

This is the feature I use the most when troubleshooting with another engineer. Two people looking at the same problem can now point at literally the same numbers without screen-sharing.

A quick MTU vs MSS primer (in case it’s needed)

MTU (Maximum Transmission Unit) is the largest frame size — including all headers — that an interface will forward without fragmentation. Ethernet is 1500 by default. PPPoE drops it to 1492. Jumbo frames bump it to 9000.

MSS (Maximum Segment Size) is a TCP-specific value: the largest TCP payload a host will send in one segment. It’s negotiated in the SYN handshake, and it equals MTU − IP_header − TCP_header. For a standard 1500-byte IPv4 path with TCP, that’s 1500 − 20 − 20 = 1460 bytes.

When you stack tunnels, every encapsulation you add eats into the same 1500-byte budget. Add a 56-byte IPsec ESP tunnel-mode overhead, and your inner MTU is now 1444, your effective TCP MSS is 1404. Add a 24-byte GRE header inside the IPsec, and you’re down to inner MTU 1420, effective MSS 1380.

If you don’t tell the endpoints about this — through TCP MSS clamping at the tunnel device — they’ll happily send 1460-byte segments that arrive at the tunnel ingress, get an IPsec wrapper slapped on, and become 1516-byte packets that don’t fit through the 1500-byte path. The router either fragments them (rare these days; many networks block fragments) or drops them with ICMP Fragmentation Needed. If Path MTU Discovery is being blocked too (and it often is, by overzealous firewalls), the session just hangs. PMTUD black holes are a top-3 cause of “the VPN works but websites won’t load” complaints in every network team I’ve worked with.

MSS clamping fixes this preemptively. The tunnel device intercepts SYN/SYN-ACK packets and rewrites the MSS option to a safe value that fits even after encapsulation. The endpoints then send appropriately-sized segments from the start, no PMTUD required.

What the calculator actually does, step by step

1. You set the path MTU — typically 1500 unless you know your transport has something smaller (jumbo, PPPoE, IPv6 minimum).
2. You set the inner IP version — IPv4 has a 20-byte header, IPv6 has 40. This affects the final MSS math.
3. You set the inner transport — TCP (20-byte header), UDP (8 bytes), or none (raw IP).
4. You build the encapsulation stack, outermost first. Either click a scenario preset or pick from the dropdown.
5. The calculator instantly shows:
   • The inner MTU after subtracting all encap overhead from the path MTU
   • The effective payload after subtracting the inner IP header
   • The effective TCP MSS after subtracting the transport header
   • A per-encap breakdown with byte counts
   • A warning if the overhead exceeds the path MTU (fragmentation expected)
   • The paste-ready MSS clamp command for whatever platform you pick

If anything ends up negative — overhead exceeds MTU — you get a clear red warning. That happens more often than people think when someone enables Jumbo on one side of a transport but not the other.

Use it

The polished version is live now: /tools/mtu-calculator

Run through the scenarios. Try the share-link feature. Most importantly, paste the vendor commands into a lab and confirm the math matches what your tunnel actually negotiates — I’ve tested against Cisco IOS-XE, NX-OS, and Linux iptables; the JunOS and pfSense flows are based on docs but I’d love confirmation from anyone who has those in production.

If you spot an encapsulation that should be in the preset list, an overhead value that’s off, or a vendor syntax that’s broken on your platform, open an issue on GitHub or just message me. Tools are only useful if they’re right.

Why I write tools like this

The TravTeks tools (now 28 of them, all in /tools) are built around a simple test: when I’m troubleshooting something in the middle of an outage, would I rather use this tool or one of the alternatives? The alternatives are usually slow, ad-laden, tracking-heavy, or vendor-locked to whatever company is hosting them.

Every TravTeks tool is fully client-side where possible (this MTU calculator runs entirely in your browser — your tunnel topology never leaves your laptop), free, ad-free, account-free, and built specifically for the daily work of a network engineer. That’s the whole brief.

More tools are in the pipeline. If there’s one you wish existed, ask — most are an afternoon’s work to build.