MTU MSS Calculator

Path MTU:

Use 1500 for a normal Ethernet path, 1492 for PPPoE, or the measured path MTU if known.

bytes

Common MTU slider {{ pathMtuRangeLabel }}

Encapsulation preset:

Choose a starting stack for PPPoE, GRE, VXLAN, WireGuard, IPsec, or combined VPN handoffs.

Payload IP version:

Pick the IP family carried by the flow whose TCP MSS should be clamped.

Overhead stack:

Use rows such as GRE over IPv4,24 and PPPoE,8.

Safety reserve:

Use 0 for exact math, or 8-32 bytes when the tunnel path has unknown vendor padding.

bytes

Reserve slider {{ safetyBytesRangeLabel }}

Check MTU assumptions

{{ error }}

TCP option reserve:

Leave 0 for the normal MSS clamp. Use 12 for a conservative timestamp/SACK payload estimate.

bytes

Option reserve slider {{ tcpOptionBytesRangeLabel }}

Curve step:

Use smaller steps for smoother exports and larger steps for compact CSV output.

bytes

Curve interval slider {{ curveStepBytesRangeLabel }}

Metric	Value	Detail	Copy
{{ row.label }}	{{ row.value }}	{{ row.detail }}

Component	Bytes	Remaining MTU	Note	Copy
{{ row.component }}	{{ row.bytesLabel }}	{{ row.remainingLabel }}	{{ row.note }}

Check	Recommendation	Detail	Copy
{{ row.check }}	{{ row.recommendation }}	{{ row.detail }}

Overhead	Effective MTU	TCP MSS	Status	Copy
{{ row.overheadLabel }}	{{ row.effectiveMtuLabel }}	{{ row.mssLabel }}	{{ row.status }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

A network path can look healthy until the first large transfer stalls. Small pings, DNS answers, and login prompts may pass because they fit inside the available packet budget, while file copies, HTTPS sessions, backups, or VPN traffic start dropping once encapsulation leaves too little room. That failure pattern often belongs to packet sizing, not reachability.

Maximum transmission unit, or MTU, is the largest packet budget available at a chosen scope of the path. TCP maximum segment size, or MSS, is the part of that budget left for TCP data after the IP and TCP headers are removed. A 1500-byte outside path normally suggests a 1460-byte IPv4 TCP payload, but the assumption breaks when PPPoE, GRE, VXLAN, WireGuard, IPsec, VLAN tags, or provider handoffs spend bytes before the inner packet is carried.

The most important discipline is deciding which MTU is being discussed. Some devices report a Layer 3 IP MTU, some talk in Ethernet frame terms, and some tunnel interfaces already subtract part of the overhead. Double-counting access bytes can make a clamp unnecessarily small; missing ESP padding, NAT traversal, or an optional tunnel field can leave packets too large.

MTU and MSS planning terms
Term	Plain meaning	Common mistake
Path MTU	The smallest usable packet budget at the planning point.	Assuming `1500 B` when the access link or tunnel interface has already reduced the budget.
Encapsulation overhead	Bytes consumed by wrappers around the carried packet.	Mixing Layer 2 and Layer 3 byte counts without checking the device documentation.
Effective IP MTU	The inner IP packet budget after overhead and reserve are removed.	Treating a planned budget as proof that the live route will forward that size.
TCP MSS	The TCP data payload limit advertised or clamped for TCP flows.	Expecting it to resize UDP, QUIC, ICMP, or non-TCP application packets.

Diagram showing path MTU reduced by overhead and reserve, then IP and TCP headers subtracted to produce a TCP MSS value.

PPPoE commonly reduces a 1500-byte Ethernet IP budget before any tunnel overhead is considered.
IPv6 uses a larger base IP header than IPv4, so the same effective MTU leaves less room for TCP data.
IPsec ESP overhead varies with transform, tag length, nonce or IV size, padding, and NAT traversal.
Path MTU Discovery still matters because MSS clamping changes TCP behavior only.

TCP MSS clamping helps TCP endpoints choose a smaller segment before large packets disappear in the tunnel. It is a workaround for a specific class of TCP trouble, not a general packet-size cure. UDP, QUIC, ICMP, and tunnel handshake traffic still need packet-too-big feedback, application-level sizing, or a smaller configured tunnel MTU.

A planned MSS is best treated as a first configuration value for a router, firewall, VPN concentrator, or host policy. Filtered ICMP messages, asymmetric paths, carrier changes, and vendor-specific overhead can all make a field test disagree with a clean byte budget, so the final value still needs confirmation with real traffic.

How to Use This Tool:

Use the form as a byte budget before copying a clamp into a device configuration. Start with the outside packet limit, then account for only the overhead bytes that are not already included in that limit.

Set Path MTU to the real outside path value. Use 1500 for a normal Ethernet IP path, 1492 when PPPoE has already reduced the usable IP MTU, or a measured value from your environment.
Choose an Encapsulation preset as a starting point. If the path uses a vendor-specific stack, switch to Custom stack or edit Overhead stack with one CSV row per component, such as GRE over IPv4,24,base GRE header.
Select Payload IP version for the traffic being clamped. IPv4 uses a 20 B base IP header in the MSS calculation, while IPv6 uses 40 B.
Set Safety reserve only for uncertainty you mean to hold back. Use 0 for exact documented math, or a small reserve such as 8 to 32 B when padding or platform behavior is not fully known.
Open Advanced when you need a separate TCP option reserve estimate or a different Curve step for the overhead sensitivity data. The normal TCP MSS clamp remains visible even when an option-aware payload is also shown.
Read MTU Ledger first, then compare Overhead Stack against the device documentation. If Check MTU assumptions appears, fix non-numeric or negative overhead rows and review any normalized Path MTU value before using the result.
Use Clamp Guidance for the first configuration value and MSS Overhead Curve when comparing tunnel designs or explaining how quickly MSS drops as overhead grows.

The most important setup check is double-counting. If an ISP, router, or VPN platform already reports the reduced inner MTU, remove those same access bytes from Overhead stack before reading the clamp.

Interpreting Results:

TCP MSS clamp is the value most likely to be copied into a firewall, router, tunnel, or host policy for TCP flows. Effective IP MTU explains how that value was reached: it is the path MTU minus the listed overhead bytes and the safety reserve.

Option-aware payload is a second estimate after the optional TCP option reserve is removed from the normal MSS. Use it for analysis, not as a replacement for the displayed clamp unless your configuration target explicitly expects a payload size after options.

MTU MSS status labels and interpretation
Status cue	Trigger	Meaning	Action
`Clamp ready`	No input errors, MSS is at least `1200 B`, and total reduction is `160 B` or less	The modeled stack leaves a usable TCP clamp.	Confirm the byte assumptions and test the path.
`Heavy encapsulation`	Total overhead plus reserve is greater than `160 B`	The path spends a large part of MTU on wrappers.	Check nested tunnels, access overhead, ESP details, and reserve bytes.
`Tight MSS`	TCP MSS is below `1200 B`	TCP still has payload room, but efficiency and application behavior need attention.	Reduce overhead, raise the path MTU, or test representative transfers.
`IPv4 floor missed` or `IPv6 floor missed`	Effective MTU is below the selected planning floor	The modeled inner MTU is below the floor checked for that payload family.	Raise path MTU, remove overhead, or choose a different design.
`No TCP room`	Effective MTU cannot cover the selected IP header and base TCP header	No usable TCP payload remains under the current assumptions.	Fix the path MTU or overhead stack before using the result.

DF ping payload is the ICMP echo payload budget at the calculated effective MTU. Translate that number into the packet test syntax for the operating system you are using, because ping tools count payload bytes differently from full IP packet bytes.

A green status does not prove the route is clear. It means the entered byte budget is internally usable. Verify the Overhead Stack, permit packet-too-big feedback where policy allows, and test a real flow after applying the clamp.

Technical Details:

MTU and MSS planning is a subtraction problem with a standards boundary. IP MTU is counted at the IP packet level, while many encapsulations are documented at different scopes. GRE over IPv4 can be modeled as an outer IPv4 header plus a basic GRE header, PPPoE reduces the payload available inside Ethernet, VXLAN carries an inner Ethernet frame through UDP, and ESP overhead changes with the selected IPsec transform.

The TCP MSS option is based on the effective MTU after fixed IP and TCP headers are removed. TCP options and IPv6 extension headers can reduce actual data carried in an individual packet, but the advertised MSS itself is normally derived from the effective MTU minus fixed headers. That is why the optional TCP option reserve is shown as a separate payload estimate instead of silently lowering the normal clamp.

Formula Core:

The governing budget is direct arithmetic. Each overhead row contributes bytes to the stack total, the safety reserve is subtracted separately, and the selected payload IP version controls the IP header size.

\begin{matrix} O_{stack} & = & \sum O_{component} \\ O_{total} & = & O_{stack} + R_{safety} \\ M_{effective} & = & \max (0, M_{path} - O_{total}) \\ MSS & = & \max (0, M_{effective} - H_{IP} - 20) \\ P_{options} & = & \max (0, MSS - O_{TCP options}) \\ P_{DF ping} & = & \max (0, M_{effective} - H_{IP} - 8) \end{matrix}

Formula symbols for MTU and MSS calculation
Symbol	Meaning	Where it comes from
`Mpath`	Outside path MTU in bytes	Path MTU
`Ostack`	Sum of all overhead component bytes	Overhead stack rows after preset or custom edits
`Rsafety`	Extra reserve bytes deliberately held back	Safety reserve
`HIP`	Payload IP header bytes	`20 B` for IPv4, `40 B` for IPv6
`O TCP options`	Optional post-clamp payload reserve	TCP option reserve

With the default combined GRE, IPsec NAT-T, and PPPoE stack, Mpath is 1500 B, Ostack is 108 B, and the default safety reserve is 8 B. The total reduction is therefore 116 B, the effective IPv4 MTU is 1384 B, the TCP MSS clamp is 1344 B, and the IPv4 DF ping payload is 1356 B.

Header, floor, and validation values used by the MTU MSS calculator
Item	IPv4 payload	IPv6 payload	How it affects the result
Base IP header	`20 B`	`40 B`	Subtracted before the TCP MSS clamp and DF ping payload are reported.
Base TCP header	`20 B`	`20 B`	Subtracted after the IP header to produce the normal TCP MSS clamp.
ICMP echo header	`8 B`	`8 B`	Subtracted for the displayed DF ping payload budget.
Planning floor checked	`576 B`	`1280 B`	Used for the warning that appears when effective MTU falls below the selected payload family’s floor.

Built-In Overhead Presets:

Built-in encapsulation byte presets
Preset	Modeled bytes	Byte stack	Planning note
Plain Ethernet / no tunnel	`0 B`	No overhead rows	Effective MTU equals path MTU unless a safety reserve is added.
PPPoE plus one VLAN tag	`12 B`	PPPoE `8 B` plus 802.1Q VLAN `4 B`	Use only when those access bytes are not already reflected in the entered path MTU.
GRE over IPv4	`24 B`	Outer IPv4 `20 B` plus basic GRE `4 B`	Does not include optional GRE key, checksum, or sequence fields.
VXLAN over IPv4	`50 B`	Outer Ethernet `14 B`, outer IPv4 `20 B`, UDP `8 B`, VXLAN `8 B`	Check whether the platform reports a frame-oriented or IP-oriented MTU before keeping the Ethernet bytes.
WireGuard over IPv4 UDP	`60 B`	Outer IPv4 `20 B`, UDP `8 B`, WireGuard data header and tag `32 B`	Models data packets over IPv4 transport, not handshake packet size.
IPsec ESP NAT-T over IPv4 estimate	`76 B`	Outer IPv4 `20 B`, UDP/4500 `8 B`, ESP estimate `48 B`	ESP bytes vary by transform, tag length, nonce or IV size, and padding.
GRE over IPsec NAT-T on PPPoE	`108 B`	PPPoE `8 B`, outer IPv4 plus GRE `24 B`, IPsec NAT-T estimate `76 B`	A conservative combined handoff starting point for nested tunnel planning.

The overhead curve uses the same formulas over a range of candidate overhead totals. It marks the current stack and labels each row as usable, tight, below the selected IP-family floor, or without TCP room. Curve rows are capped by the point where the path MTU can no longer cover the selected IP header and base TCP header.

Accuracy Notes:

The calculation is a local byte-budget estimate from the values you enter. It does not send probes, capture packets, query a router, or prove the live path MTU. Use it to choose a first clamp, then test the actual path.

Confirm whether each device reports MTU at Layer 2, Layer 3, or tunnel-interface scope before subtracting access and encapsulation bytes.
Keep ICMP Fragmentation Needed and IPv6 Packet Too Big feedback working where policy allows; MSS clamping protects TCP only.
Treat ESP and nested tunnel presets as planning values until the actual transform, padding, and platform behavior are known.

Worked Examples:

A simple GRE tunnel on a normal 1500 B IPv4 path uses the GRE over IPv4 preset and a 0 B safety reserve. Encapsulation overhead is 24 B, Effective IP MTU is 1476 B, TCP MSS clamp is 1436 B, and DF ping payload is 1448 B. The Clamp ready cue is reasonable after the GRE byte count is confirmed.

A VXLAN handoff with a 1500 B path and an 8 B Safety reserve subtracts 50 B of preset overhead plus the reserve. The MTU Ledger shows 1442 B effective MTU, 1402 B TCP MSS, and 1414 B DF ping payload for IPv4. If the device already reports an IP MTU after outer Ethernet handling, remove the outer Ethernet row before trusting the clamp.

A nested custom stack that totals 272 B plus an 8 B reserve on a 1500 B IPv4 path leaves 1220 B as Effective IP MTU. The TCP MSS clamp becomes 1180 B, so the status changes to Tight MSS. That does not mean TCP is impossible, but it is a warning to reduce overhead, raise the path MTU, or test the exact application traffic.

For the default GRE, IPsec NAT-T, and PPPoE preset, Payload IP version changes the clamp without changing the tunnel stack. With the default 1384 B effective MTU, IPv4 produces a 1344 B TCP MSS clamp; IPv6 produces 1324 B because its base IP header is 40 B.

FAQ:

Is MSS the same as MTU?

No. MTU is a packet-size budget for an IP packet or path. MSS is only the TCP data portion left after IP and TCP headers are removed from the effective MTU.

Should PPPoE use 1500 or 1492 as Path MTU?

Use the value your planning point actually exposes. If the path MTU is already 1492 B, PPPoE has usually already been accounted for and should not be subtracted again in Overhead stack.

Why does IPv6 produce a smaller TCP MSS than IPv4?

The IPv6 base header is 40 B, while the IPv4 base header used here is 20 B. With the same effective MTU, IPv6 leaves 20 B less room for TCP payload.

Why does Check MTU assumptions appear?

That warning appears when an overhead row has a missing, non-numeric, or negative byte value, or when Path MTU has been normalized into the supported 68 to 65535 B range.

Does MSS clamping fix UDP or QUIC packet size problems?

No. MSS clamping changes TCP behavior only. UDP, QUIC, ICMP, and similar traffic still need Path MTU Discovery, application packet sizing, or a smaller configured MTU.

Why can the IPsec preset be only an estimate?

ESP overhead changes with transform, nonce or IV size, tag length, padding, NAT traversal, and platform behavior. Check the actual VPN configuration before treating the preset as final.

Does the calculator measure the live network path?

No. It calculates from the entered Path MTU, Overhead stack, reserve values, and selected IP version. Use the DF ping payload and real traffic tests to verify the path after planning.

Glossary:

MTU: Maximum transmission unit, the largest packet size a link, interface, or path can carry at the modeled scope without fragmentation.
Path MTU: The smallest usable MTU across the route or tunnel handoff being planned.
Effective IP MTU: The inner IP packet budget after the modeled encapsulation overhead and safety reserve are subtracted.
TCP MSS: Maximum segment size, the TCP data payload limit after IP and TCP headers are accounted for.
Encapsulation overhead: Extra bytes added by a wrapper such as PPPoE, GRE, VXLAN, WireGuard, or IPsec.
PMTUD: Path MTU Discovery, the process that learns a path’s largest usable packet size through packet-too-big feedback.
DF ping payload: An ICMP echo payload size that corresponds to the modeled effective MTU after IP and ICMP headers are removed.

References:

RFC 9293: Transmission Control Protocol, RFC Editor, September 2022.
RFC 1191: Path MTU Discovery, RFC Editor, November 1990.
RFC 8200: Internet Protocol, Version 6 Specification, RFC Editor, July 2017.
RFC 2784: Generic Routing Encapsulation, RFC Editor, March 2000.
RFC 7348: VXLAN Framework, RFC Editor, August 2014.
RFC 2516: Transmitting PPP Over Ethernet, RFC Editor, February 1999.
RFC 4303: IP Encapsulating Security Payload, RFC Editor, December 2005.
WireGuard Protocol and Cryptography, WireGuard project.
How to change MTU with ip link, Simplified Guide.

MTU MSS Calculator

Introduction:

How to Use This Tool:

Interpreting Results:

Technical Details:

Formula Core:

Built-In Overhead Presets:

Accuracy Notes:

Worked Examples:

FAQ:

Glossary:

References: