{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }}{{ badge.value }}

Use 1500 for a common Ethernet IP path, 1492 when PPPoE is already reflected, or a measured path value.
bytes
IPv4 uses a 20-byte fixed IP header; IPv6 uses a 40-byte fixed header.
Presets are planning starting points for no tunnel, PPPoE/VLAN, GRE, VXLAN, WireGuard, and IPsec paths.
Example: Outer IPv4 plus GRE,24,basic GRE over IPv4. Editing the stack selects Custom stack.
Use 0 for exact documented arithmetic or a small reserve when the platform byte count is uncertain.
bytes
Zero is neutral. TCP and IP options reduce data carried in an individual segment, not the fixed-header MSS basis.
bytes
The default changes only chart and table density; it does not change the current MSS result.
bytes
MetricValueMeaningCopy
{{ row.metric }}{{ row.value }}{{ row.note }}

Recommended starting point

{{ formatInteger(model.tcp_mss_bytes) }} B TCP MSS for flows crossing the declared stack. Confirm the byte assumptions and test the live path before production use.

Effective inner MTU
{{ formatInteger(model.effective_mtu_bytes) }} B
DF ping payload
{{ formatInteger(model.probe_payload_bytes) }} B
Option-aware data
{{ formatInteger(model.option_aware_payload_bytes) }} B

Calculation record

{{ formulaText }}
  • Keep ICMP Fragmentation Needed and IPv6 Packet Too Big feedback working where policy allows.
  • MSS clamping changes TCP only; UDP, QUIC, ICMP, and other traffic still need suitable packet sizing or PMTUD.
  • Treat the ESP bytes as an estimate until the actual transform, IV, tag, and padding are known.
  • Do not subtract access or tunnel bytes twice when the entered path MTU already reflects them.
Total overheadEffective MTUTCP MSSStatusCopy
{{ formatInteger(row.overheadBytes) }} B{{ formatInteger(row.effectiveMtuBytes) }} B{{ formatInteger(row.tcpMssBytes) }} B{{ row.status }}
VPN Tunnel Capacity Calculator Estimate practical VPN concurrent-user capacity from tunnel rate and packet overhead with gateway limits, busy-hour demand, and MTU risk checks.
IPsec Overhead Calculator Calculate a safe IPsec inner MTU and TCP MSS from the ESP profile and path budget, including NAT-T, padding and optional reserve bytes.
Ethernet Frame Efficiency Calculator Calculate Ethernet payload efficiency and goodput from frame size plus VLAN and wire-time overhead, then check whether a target rate fits.
Jumbo Frame Savings Calculator Estimate how jumbo frames reduce packet rate and repeated Ethernet overhead for eligible traffic, with path-risk and optional CPU relief checks.

Packet-size trouble often hides behind an otherwise healthy route. DNS lookups, short requests, and small pings may succeed while file transfers or tunneled TCP sessions stall because the larger packets no longer fit through the narrowest point on the path.

Maximum transmission unit (MTU) is a packet-size limit expressed in bytes. Path MTU is the smallest usable limit from one endpoint to another. Maximum segment size (MSS) is narrower: it is the TCP data that remains after the IP and TCP headers are removed. On a plain 1500-byte IPv4 path, the usual base-header arithmetic leaves 1460 bytes for TCP data. Encapsulation, access-link overhead, or a deliberately held safety reserve reduces that figure.

Outside path MTU
The packet budget available before the carried packet's tunnel or access overhead is subtracted.
Effective MTU
The inner IP packet budget left after overhead and safety reserve.
TCP MSS
The inner TCP data limit after the base IP and TCP headers.
MSS clamp
A network policy that lowers the MSS advertised during TCP setup so endpoints send smaller segments.

The counting point matters as much as the arithmetic. An interface MTU may already describe the reduced inner packet, while a carrier or tunnel document may quote bytes added outside it. Subtracting the same PPPoE, VLAN, GRE, or VPN bytes twice produces an unnecessarily small MSS. Leaving out variable IPsec padding, authentication data, or platform-specific fields can produce packets that still exceed the live path.

IPv4 and IPv6 also spend different base-header amounts. The model uses 20 bytes for IPv4, 40 bytes for IPv6, and 20 bytes for the base TCP header. It compares the effective MTU with planning floors of 576 bytes for IPv4 and 1280 bytes for IPv6. Those checks expose obviously tight designs, but they do not prove that every device, option, or packet type will behave correctly.

  • MSS clamping affects TCP. UDP, QUIC, ICMP, and other traffic still need a suitable MTU or working packet-too-big feedback.
  • TCP options occupy space within a segment after the base MSS calculation, so option-heavy traffic can carry less application data.
  • Asymmetric routing can give each direction a different path MTU.
  • Filtered ICMP messages can break Path MTU Discovery and make a mathematically sound value fail in practice.

Treat an MSS calculation as a configuration starting point. Confirm the chosen value from the affected endpoint and destination, preferably with non-fragmenting probes and a representative TCP transfer after the change.

How to Use This Tool:

Build the byte budget from the outside inward. Use a measured path value when available and subtract only overhead that is not already reflected in it.

  1. Enter the Path MTU and choose the carried Payload IP version. A value such as 1500 or 1492 is meaningful only when you know where that limit is measured.
  2. Choose an Encapsulation preset, then compare its Overhead stack with the actual tunnel and access-link documentation. Editing the rows switches the calculation to a custom stack.
  3. Set Safety reserve to zero for exact documented arithmetic or hold back a small number of bytes when padding or platform behavior is uncertain. Add a TCP option reserve only when you want a separate estimate of application payload after TCP options.
  4. Read the TCP MSS with the effective MTU and floor headroom. Stop if the status reports No TCP room or an IPv4 or IPv6 floor miss.
  5. Compare the clamp guidance with a no-fragment probe payload and test real TCP traffic across the same route before applying the value broadly.

Interpreting Results:

The TCP MSS is the main clamp candidate, while the option-aware payload shows how much data remains after the separate TCP option reserve. Do not substitute the option-aware value for the MSS unless a device or policy explicitly calls for that convention.

The status follows an ordered check. Missing TCP room and an IP-version floor miss are failures. A positive MSS below 1200 bytes is marked Tight MSS; a total reduction above 160 bytes is marked Heavy overhead. Clamp ready only means that none of those modeled warnings fired.

Verify the result against the live route. A passing floor and a sensible MSS cannot detect an omitted tunnel field, a different reverse path, or blocked Path MTU Discovery messages.

Technical Details:

MTU and MSS planning is a subtraction budget. Encapsulation rows and the safety reserve reduce the outside path MTU first. The carried IP and base TCP headers are then removed from the effective MTU.

Formula Core

The governing equations keep every quantity in bytes and clamp negative packet-space results to zero.

Meffective = max(0, Mpath −Ostack −R) MSS=max(0, Meffective −HIP −20) Pprobe =max(0, Meffective −HIP −8)
SymbolMeaningUnit or rule
MpathEntered outside path MTU68 to 65,535 B
OstackSum of custom or preset overhead rowsB
RSafety reserve0 to 4,096 B
HIPBase carried-IP header20 B IPv4; 40 B IPv6
20Base TCP headerB
8ICMP header used for the probe-payload estimateB

The option-aware payload is MSS minus the entered TCP option reserve, again bounded at zero. The reduction percentage is total overhead plus reserve divided by path MTU. Floor headroom is effective MTU minus 576 bytes for IPv4 or 1280 bytes for IPv6.

Rule Core

First matching conditionStatusMeaning
TCP MSS ≤ 0 BNo TCP roomThe effective MTU cannot hold the base IP and TCP headers.
Effective MTU < planning floorIPv4 or IPv6 floor missedThe carried IP packet falls below the model's version-specific floor.
0 B < TCP MSS < 1200 BTight MSSThe TCP payload is positive but unusually constrained.
Total reduction > 160 BHeavy overheadEncapsulation and reserve consume a large byte budget.
OtherwiseClamp readyNo modeled status warning applies.

All calculations use whole-byte inputs. The sensitivity step changes only the spacing of comparison points; it does not change the current MSS result.

Accuracy Notes:

Preset overheads are planning assumptions. Actual ESP padding, authentication tags, tunnel options, nested encapsulation, and vendor counting conventions can differ. Measure the affected direction and keep the overhead stack aligned with the exact point where the path MTU was observed.

  • The IPv4 and IPv6 floor checks are guidance boundaries, not proof of application success.
  • A DF ping payload estimate assumes the base IP header and an 8-byte ICMP header.
  • MSS clamping cannot repair non-TCP packet sizing or filtered packet-too-big feedback.

Worked Examples:

Nested IPv4 tunnel

A 1500-byte IPv4 path with 108 bytes of PPPoE, GRE, and IPsec planning overhead plus an 8-byte reserve leaves a 1384-byte effective MTU. Removing the 20-byte IPv4 and 20-byte TCP headers gives a 1344-byte TCP MSS. The corresponding IPv4 ICMP probe payload is 1356 bytes.

IPv6 floor boundary

A 1304-byte outside path carrying IPv6 through a 24-byte GRE-over-IPv4 wrapper leaves exactly 1280 bytes. The floor headroom is zero, so the floor still passes, and the base-header TCP MSS is 1220 bytes.

References: