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.

Link MTU, Transport & Encapsulation Engine
RFC 879 / RFC 7348 Standards
Bytes
Common Interface Presets
Usable Maximum Segment Size (MSS)
1460 Bytes
94.93% Usable Payload Capacity
Total Protocol Overhead Tax
78 Bytes
L1=20B | L2=18B | L3=20B | L4=20B
Total Wire Footprint per Packet
1538 Bytes
Max Wire Efficiency = 94.93%
Full Physical Frame Anatomy Breakdown Total: 1538 Bytes on Wire
L1 (20B)
L2 (18B)
L3 (20B)
L4 (20B)
MSS Payload (1460B)
L1 Framing: 20B (Preamble, SFD, IPG)
L2 Ethernet: 18B (14B MAC + 4B FCS)
Inner IP: 20B (IPv4 Header)
Transport: 20B (TCP Base)
Usable Payload: 1460B (TCP MSS)
Configure Overlay Tunnels, Multi-Tags & Carrier Encapsulation [+] Expand Options
Optimal Transmission: No Fragmentation Risk
The current MTU and encapsulation stack fit cleanly. Standard TCP handshakes will negotiate MSS cleanly without requiring synthetic fragmentation or triggering PMTUD drops.
interface GigabitEthernet0/0/1 ip tcp adjust-mss 1460
Real-Time Mathematical Derivation Chain
Physical MTU = 1500 Bytes | Encapsulation Stack: Standard L2 Ethernet (18B MAC+FCS) + IPv4 (20B) + TCP (20B) | Total L3/L4 Overhead = 40 Bytes | Usable TCP MSS = 1500 - 40 = 1460 Bytes | Wire Footprint = 20B (L1) + 18B (L2) + 1500B (MTU) = 1538 Bytes | Wire Efficiency = 1460 / 1538 = 94.93%

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