Calculate the tunnel MTU or TCP MSS that avoids fragmentation, find the underlay MTU a VPN needs, and convert
payload size to Ethernet frame and on-wire size. Build PPPoE, VLAN, GRE, VXLAN, WireGuard, IPsec, MPLS, MACsec,
and jumbo-frame stacks byte by byte.
All inputs stay in your browser. Use the result as a planning estimate, then validate production paths with device MTU, tunnel, and packet-capture tests.
Inputs
The IP MTU available before tunnel overhead is applied.
Outer headers plus any inner Ethernet header consumed before the inner IP packet.
VLAN tags add wire bytes; they do not usually reduce the configured IP MTU.
Used to check whether a payload or TCP MSS fits without fragmentation.
Used for packet count and total wire-byte estimate.
Used by “payload from frame size”; excludes preamble and inter-frame gap.
Protocol stack builder
Add the bytes consumed before the inner IP packet. Click an added layer to remove it.
Start with the underlay MTU: use the IP MTU supported by the real path, such as 1500, 1492, 9000, or 9216 bytes.
Add tunnel overhead: choose PPPoE, GRE, VXLAN, WireGuard, IPsec, or enter a custom byte value from your platform documentation.
Pick inner protocol headers: choose IPv4 or IPv6, then TCP, UDP, ICMP, or a custom transport header.
Set wire accounting: count VLAN tags, Ethernet FCS, and preamble/IFG when estimating line-rate efficiency.
Review the fit: compare target payload or TCP MSS with the calculated maximum and check the required MTU for a no-fragmentation design.
Formula and assumptions
Effective inner MTU:underlay link MTU - encapsulation overhead
Application payload per packet:effective inner MTU - inner IP header - transport header
TCP MSS:effective inner MTU - inner IP header - 20 for TCP without options.
Wire bytes per full packet:Ethernet header + VLAN tags + packet bytes + optional FCS + optional preamble/SFD/IFG
Wire efficiency:application payload / wire bytes per full packet
Required underlay MTU:target payload + inner IP header + transport header + encapsulation overhead
Header presets are planning values. IPsec ESP, TCP options, QUIC, MPLS, provider tags, MACsec, and device-specific tunnel implementations can change the exact byte count.
Common MTU, MSS, frame, and tunnel values
Scenario
Typical overhead before inner IP
Effective inner MTU on 1500 underlay
IPv4 TCP MSS estimate
Plain Ethernet
0 B
1500 B
1460 B
PPPoE on Ethernet
8 B
1492 B
1452 B
IPv6 minimum link MTU
0 B
1280 B
1220 B
GRE over IPv4
24 B
1476 B
1436 B
VXLAN over IPv4
50 B
1450 B
1410 B
WireGuard over IPv4 / IPv6
60 / 80 B
1440 / 1420 B
1400 / 1380 B
VLAN / QinQ frame carrying 1500 IP MTU
4 / 8 wire B
1500 B
1460 B; frame is 1522 / 1526 B through FCS
9000 byte jumbo, no tunnel
0 B
9000 B
8960 B
9216 byte jumbo, no tunnel
0 B
9216 B
9176 B
Worked MTU and VPN examples
1500 MTU to 1460 MSS
1500 - IPv4 20 - TCP 20 = 1460. Clamp no higher than 1460 on a plain IPv4 path.
PPPoE MSS 1452
1500 - PPPoE 8 - IPv4 20 - TCP 20 = 1452. Use a 1492 inner MTU or clamp MSS to 1452.
VXLAN underlay sizing
1500 inner IP + 50 VXLAN/UDP/IPv4/inner-Ethernet = 1550. Raise the underlay to about 1550 or lower the inner MTU to 1450.
WireGuard IPv4 and IPv6
Typical data overhead is 60 B over IPv4 and 80 B over IPv6: inner MTUs are 1440 and 1420 on a 1500 path. Confirm with the platform.
Jumbo-frame efficiency
With standard wire accounting, a 1460-byte payload uses 1538 wire bytes (94.9%); an 8960-byte payload uses 9038 wire bytes (99.1%). Every hop must support the jumbo MTU.
MTU, MSS, Ethernet frames, and wire rate
MTU is the largest Layer 3 packet a link can carry without fragmentation. TCP MSS is smaller because it is
only the TCP payload portion of that IP packet. For a common 1500 byte IPv4 path with no tunnel, TCP MSS is
1460 bytes after subtracting a 20 byte IPv4 header and a 20 byte TCP header.
Ethernet wire usage is larger than the IP MTU. A normal Ethernet frame has a 14 byte MAC header and commonly
a 4 byte FCS. Each VLAN tag adds 4 bytes. Physical line-rate accounting also includes 8 bytes of preamble/SFD
and 12 bytes of inter-frame gap, which is why useful payload efficiency is lower than the MTU alone suggests.
Jumbo frames can help large transfers by reducing per-packet overhead, but every device in the path must
support the configured MTU. Mixed MTU paths, hidden provider tags, tunnels, and firewalls that drop fragmented
traffic are common causes of black-hole behavior.
Reference notes
Ethernet examples use the RFC 894 1500-byte data-field assumption and IEEE frame accounting.
WireGuard’s protocol is documented in its official protocol description. The 32-byte data message header is combined here with outer UDP and IP headers.
Methodology
The calculator subtracts selected tunnel overhead from the entered underlay MTU, then subtracts the selected
inner IP and transport headers to find the maximum application payload. It separately estimates Ethernet wire
bytes by adding the outer Ethernet header, selected VLAN tags, optional FCS, optional preamble/SFD/IFG, and the
transmitted packet bytes. Bulk estimates use full-size packets plus one final partial packet when needed.
Last reviewed: June 2026. Calculations are deterministic byte arithmetic and run locally in your browser.
MTU troubleshooting FAQs
What is the difference between MTU and TCP MSS?
MTU limits the whole IP packet. MSS limits only TCP data, so common IPv4 TCP MSS is MTU minus 40 bytes; TCP or IP options can reduce actual data per packet.
What is the difference between MTU and Ethernet frame size?
IP MTU excludes the Ethernet header and FCS. A 1500-byte IP packet normally occupies a 1518-byte untagged frame through FCS, or 1522 bytes with one VLAN tag.
Why does a ping with DF set work or fail?
DF prevents IPv4 fragmentation. Account for the 20-byte IPv4 and 8-byte ICMP headers: a 1472-byte ping payload tests a 1500-byte IP packet. Some systems report sizes differently.
What is a PMTUD black hole?
It occurs when oversized packets are dropped but the ICMP message needed by Path MTU Discovery is filtered. Small packets work while large transfers stall; correct filtering, MTU, or MSS clamping can resolve it.
Should I set MTU or clamp TCP MSS?
MTU fixes the packet size at the interface or tunnel. TCP MSS clamping only affects TCP payload negotiation. Non-TCP traffic such as UDP may still need correct MTU and path-MTU behavior.
How do VLAN and QinQ change frame size?
Each tag adds 4 bytes to the frame. One VLAN makes a 1518-byte frame 1522 bytes; QinQ makes it 1526 bytes, while a capable path can keep the IP MTU at 1500.
Do UDP and QUIC need the correct MTU?
Yes. MSS clamping does not cover UDP. QUIC runs over UDP and relies on correct packet sizing and path-MTU behavior to avoid loss or IP fragmentation.
Why must every device on a jumbo-frame path match?
The smallest MTU on the path is the constraint. A switch, router, firewall, virtual switch, or NIC that cannot pass the selected frame size can drop or fragment traffic.
Can this predict exact IPsec overhead?
No. IPsec ESP overhead varies with tunnel mode, NAT-T, IV size, padding, integrity check value, and cipher suite. Use the IPsec presets as estimates unless you have exact vendor byte counts.
Is this calculator private?
Yes. Inputs are processed locally and are not submitted to a backend.
Disclaimer
MTU and overhead estimates are infrastructure planning aids. Validate production designs with device
documentation, packet captures, path MTU discovery tests, tunnel configuration, and change-management review.
Starlight Tools