IP MTU, MSS & Protocol Encapsulation Overhead Calculator
Calculate maximum usable TCP Segment Size (MSS), wire framing taxes, and encapsulation overhead across Layers 2 through 4. Model overlay tunnels (VXLAN, Geneve, GRE, IPsec ESP, WireGuard, PPPoE) and generate vendor router MSS clamping syntax to permanently eliminate PMTUD blackholes.
Engineering Theory & Encapsulation Mechanics
1. The Structural Distinction: MTU vs. MSS vs. Wire Footprint
In production IP networks, performance bottlenecks, mysterious packet loss, and application stalls frequently stem from conflating three distinct architectural quantities: the Maximum Transmission Unit (MTU), the Maximum Segment Size (MSS), and the total Physical Wire Footprint.
The Maximum Transmission Unit (MTU) represents the largest single Layer 3 protocol data unit (PDU) that a network interface can transmit across a physical medium without requiring fragmentation. As codified in RFC 894, the standard Ethernet MTU is fixed at 1,500 octets. This 1,500-byte boundary encompasses the entire Layer 3 packet—including IP headers, transport headers, and user payload—but explicitly excludes the underlying Layer 2 Ethernet MAC framing (14 bytes) and Frame Check Sequence (FCS, 4 bytes).
The Maximum Segment Size (MSS), defined in RFC 793 and clarified in RFC 879, is strictly a Layer 4 metric. MSS specifies the largest block of unfragmented application user data that a TCP receiver can accept in a single IP datagram:
MSS = MTU - (IP_Header_Length + TCP_Header_Length + TCP_Options)
For standard IPv4 over native Ethernet, the base IP header consumes 20 bytes and the base TCP header consumes 20 bytes, establishing the universal default IPv4 MSS of 1,460 Bytes (1500 - 20 - 20 = 1460). Under IPv6, RFC 2460 mandates a fixed 40-byte base header, reducing the native IPv6 TCP MSS to 1,440 Bytes (1500 - 40 - 20 = 1440). When RFC 7323 High-Performance TCP Timestamps are negotiated, an additional 12 bytes of TCP options are appended to every segment, depressing usable MSS further to 1,448 bytes (IPv4) or 1,428 bytes (IPv6).
Conversely, the Physical Wire Footprint accounts for every bit clocked across the physical transmission medium. On standard copper or optical Gigabit/10G/100G Ethernet, transmitting a 1,500-byte MTU frame consumes:
- Layer 1 Physical Overhead: 7-byte Preamble + 1-byte Start Frame Delimiter (SFD) + 12-byte Interpacket Gap (IPG) = 20 Bytes
- Layer 2 Framing: 6-byte Destination MAC + 6-byte Source MAC + 2-byte EtherType + 4-byte CRC/FCS = 18 Bytes
- Layer 3 Payload MTU: 1,500 Bytes
- Total Wire Consumption: 20 + 18 + 1500 = 1,538 Bytes
Consequently, the maximum theoretical wire efficiency of native IPv4/TCP on standard Ethernet is 1460 / 1538 = 94.93%. The remaining 5.07% constitutes unavoidable protocol tax.
2. Path MTU Discovery (PMTUD) and the Blackhole Phenomenon
To prevent intermediary routers from expending CPU cycles fragmenting IP datagrams, modern operating systems enable Path MTU Discovery (PMTUD) by default (RFC 1191 for IPv4, RFC 8201 for IPv6). Under PMTUD, transmitting hosts mark every outgoing packet with the Don't Fragment (DF) bit set in the IPv4 header flags.
When a DF-marked packet encounters a transit link whose MTU is smaller than the datagram size (e.g., an encrypted IPsec tunnel or a PPPoE subscriber interface with an MTU of 1,492 bytes), the router cannot forward the packet. Because the DF bit prohibits fragmentation, the router discards the packet and generates an ICMP Type 3, Code 4 control message (Destination Unreachable: Fragmentation Needed and DF Set) addressed back to the source host. Crucially, the router includes the exact Next-Hop MTU in the ICMP header. Upon receipt, the originating TCP stack caches this MTU ceiling and shrinks its outgoing packet size to match the bottleneck.
The PMTUD Blackhole: This elegant control plane mechanism collapses when security administrators configure transit firewalls or perimeter ACLs with blanket rules dropping all ICMP traffic. If ICMP Type 3 Code 4 datagrams are blocked, the originating host never receives notification that its packets are being discarded:
- TCP Handshakes Succeed: The initial TCP SYN, SYN-ACK, and ACK packets are diminutive (typically 40 to 60 bytes) and pass unhindered through the bottleneck link.
- Small Payloads Succeed: Interactive SSH keystrokes or brief HTTP requests fit comfortably below the restricted MTU and receive acknowledgments.
- Bulk Data Freezes: As soon as the application attempts to transfer a large payload (e.g., a file download, TLS certificate exchange, or database dump), TCP transmits a full-sized segment (1500 Bytes). The bottleneck router drops the packet and transmits an ICMP Type 3 Code 4 message, which the firewall discards.
- Silent Stalls: The sender retransmits the dropped segment repeatedly until the TCP connection times out, resulting in the notorious "PMTUD Blackhole."
3. Overlay Encapsulation Taxes: VXLAN, Geneve, GRE, and IPsec
Modern cloud fabrics and carrier backbones achieve multi-tenancy and network virtualization by superimposing overlay tunnels on physical leaf-spine underlays. Each tunneling protocol imposes a non-negotiable byte penalty on every packet:
-
VXLAN (RFC 7348): The standard overlay protocol for data center EVPN fabrics encapsulates an entire tenant Layer 2 Ethernet frame inside a Layer 4 UDP packet on port 4789. This introduces a 50-Byte overhead tax:
Outer Ethernet (14B) + Outer IPv4 (20B) + Outer UDP (8B) + VXLAN Header (8B) = 50 Bytes.
If the underlying physical network MTU remains at 1,500 bytes, the usable tenant MTU drops to 1,450 bytes, yielding a maximum TCP MSS of just 1,410 Bytes. - Geneve (RFC 8926): Deployed by VMware NSX-T and Open Virtual Network (OVN), Geneve adds variable-length metadata options. With base 16-byte metadata, the encapsulation overhead reaches 58 Bytes (14B Eth + 20B IP + 8B UDP + 16B Geneve), compressing tenant MSS to 1,402 Bytes.
- Generic Routing Encapsulation (GRE, RFC 2784): Site-to-site GRE over IPv4 adds 24 bytes (20B outer IPv4 + 4B GRE header). If GRE is carried over IPv6, the overhead escalates to 44 Bytes (40B outer IPv6 + 4B GRE header).
- IPsec ESP Tunnel Mode: Encapsulates the entire inner packet inside an Encapsulating Security Payload (ESP). Overhead depends on the cipher suite. Standard AES-256-GCM requires: Outer IPv4 (20B) + SPI (4B) + Sequence Number (4B) + Initialization Vector (8B) + ESP Trailer (pad + next header: ~4B) + ICV Auth Tag (16B) ≈ 56 Bytes. When traversing NAT (UDP port 4500 encapsulation), an additional 8-byte UDP header brings total overhead to 64 Bytes.
- WireGuard: Employs state-of-the-art ChaCha20-Poly1305 authenticated encryption over UDP, adding 60 Bytes of overhead (20B IPv4 + 8B UDP + 32B WireGuard header). On 1,500-byte connections, WireGuard clients typically configure an interface MTU of 1,420 bytes to guarantee headroom.
- PPPoE (RFC 2516): Widely utilized in DSL and FTTH residential uplinks, PPPoE inserts a 6-byte PPPoE header and a 2-byte PPP protocol identifier directly before the IP datagram. This reduces maximum WAN MTU from 1,500 to 1,492 Bytes, capping standard IPv4 MSS at 1,452 Bytes.
4. TCP MSS Clamping: Eliminating PMTUD Failures at the Edge
Because network architects cannot control perimeter firewall policies across third-party networks, relying on end-to-end ICMP Path MTU Discovery is inherently fragile. The carrier-grade countermeasure is TCP MSS Clamping (also known as MSS Rewriting or MSS Adjustment).
Edge routers and firewalls inspect all passing TCP synchronization packets (SYN and SYN-ACK) during the initial three-way handshake. When a client proposes an MSS option greater than the egress link can support without fragmentation, the router dynamically rewrites the MSS option field inside the TCP header:
Clamped_MSS = Path_MTU - (IP_Header + TCP_Header + Tunnel_Overheads)
Crucially, because this rewriting occurs before application payload begins streaming, both the client and server negotiate their session to the clamped ceiling. Neither host ever transmits a packet exceeding the link MTU, completely eliminating DF-bit drops, fragmentation CPU penalties, and ICMP blackholes.
5. Carrier MTU Architecture: Baby Jumbos & Leaf-Spine Fabrics
In greenfield enterprise and service provider networks, the preferred solution is not shrinking the tenant MTU, but rather elevating the physical underlay MTU.
In carrier access networks, operators implement Baby Jumbo Frames (RFC 4638). By raising the subscriber Ethernet interface MTU from 1,500 to 1,508 Bytes, the 8-byte PPPoE encapsulation overhead is absorbed entirely by the physical framing. This allows subscriber operating systems to maintain a full 1,500-byte IP MTU and a native 1,460-byte TCP MSS, delivering seamless end-user performance without fragmentation or clamping.
In modern EVPN-VXLAN data centers, switch silicon (such as Broadcom Tomahawk or Cisco Cloud Scale) natively supports Jumbo Frames up to 9,216 Bytes. System architects configure the entire leaf-spine physical underlay for a minimum MTU of 1,600 to 9,000 Bytes. This provides abundant headroom for 50-byte VXLAN headers, 8-byte VLAN tags, and 12-byte Segment Routing MPLS stacks, while guaranteeing that tenant virtual machines, Kubernetes pods, and database nodes operate at a flawless unfragmented 1,500 or 9,000-byte MTU.
Carrier Protocol Encapsulation & MSS Reference Lookup Table
Reference values assume standard 1,500-byte underlying physical link MTU unless specified otherwise. Selected configuration above highlights the corresponding protocol tier below.
| Encapsulation Protocol | Header Overhead | Effective IP MTU | Usable IPv4 MSS | Usable IPv6 MSS | Primary Deployment Domain |
|---|---|---|---|---|---|
| Native Ethernet (Untagged) | 0 Bytes (L3 Base) | 1500 Bytes | 1460 Bytes | 1440 Bytes | Standard LAN / Enterprise Campus Switching |
| 802.1Q Single VLAN Tag | +4 Bytes (L2) | 1500 B (1504 B Wire) | 1460 Bytes | 1440 Bytes | Enterprise VLAN Segmentation |
| 802.1ad QinQ Provider Bridge | +8 Bytes (L2) | 1500 B (1508 B Wire) | 1460 Bytes | 1440 Bytes | Metro Ethernet Service Provider Access |
| PPPoE Broadband Uplink (RFC 2516) | 8 Bytes | 1492 Bytes | 1452 Bytes | 1432 Bytes | FTTH & DSL Subscriber WAN Terminations |
| GRE Tunnel over IPv4 (RFC 2784) | 24 Bytes | 1476 Bytes | 1436 Bytes | 1416 Bytes | Site-to-Site Enterprise WAN Multiprotocol Overlay |
| GRE Tunnel over IPv6 | 44 Bytes | 1456 Bytes | 1416 Bytes | 1396 Bytes | IPv6 WAN Backbone Tunneling |
| VXLAN EVPN (over IPv4) | 50 Bytes | 1450 Bytes | 1410 Bytes | 1390 Bytes | Data Center Leaf-Spine Virtualization Fabrics |
| Geneve Overlay (16B Options) | 58 Bytes | 1442 Bytes | 1402 Bytes | 1382 Bytes | VMware NSX-T & Open Virtual Network (OVN) |
| WireGuard VPN | 60 Bytes | 1420 B (1440 B Typ) | 1380 Bytes | 1360 Bytes | High-Performance Modern Cryptographic VPNs |
| IPsec ESP Tunnel Mode (AES-GCM) | ~56 Bytes | 1444 Bytes | 1404 Bytes | 1384 Bytes | Secure Enterprise Site-to-Site Encrypted Tunnels |
| IPsec ESP over NAT-T (UDP 4500) | ~64 Bytes | 1436 Bytes | 1396 Bytes | 1376 Bytes | Remote Worker VPN through Consumer Firewalls |
| AWS VPC Peering / Direct Connect | 0 Bytes (9001 B Jumbo) | 9001 Bytes | 8961 Bytes | 8941 Bytes | Hyperscale Cloud Inter-VPC & Hybrid Cloud Spans |