MTU

Every network link has a MTU — the maximum number of bytes the link can carry as one unit. When a packet exceeds the MTU of a link along its path, it must be fragmented into smaller pieces and reassembled at the destination. Fragmentation wastes CPU, adds latency, and breaks when the DF (Don't Fragment) bit is set. TCP avoids fragmentation using Path MTU Discovery (PMTUD): it probes the path and sets MSS (Maximum Segment Size) accordingly. When PMTUD breaks — commonly because firewalls block ICMP — connections stall silently for large transfers while small packets continue working.

Why Ethernet MTU is 1500 bytes

The 1500-byte Ethernet MTU dates to the original 10 Mbps Ethernet specification developed at Xerox PARC in the 1970s and formalised in the DIX Ethernet standard. The value was chosen to balance two competing concerns: large frames carry more useful data per header (efficiency), but large frames also mean a transmitting station occupies the shared medium for longer, increasing collision probability and latency for other stations. At 10 Mbps, 1500 bytes represented a reasonable compromise. When Fast Ethernet (100 Mbps) and Gigabit Ethernet arrived, the MTU was kept at 1500 for backwards compatibility — changing it would have broken existing equipment and software. Today 1500 bytes is effectively a fixed constraint of the internet, even though the original tradeoff is long obsolete.

Common MTU values

Path MTU Discovery mechanics

PMTUD works by setting the DF (Don't Fragment) bit in every outgoing IP packet. If a router along the path receives a DF-flagged packet larger than its outgoing link's MTU, it drops the packet and returns an ICMP Type 3 Code 4 message ("Fragmentation Needed") back to the sender, including the MTU of the constraining link. The sender reduces its segment size and retransmits. TCP uses PMTUD to derive the MSS value for a connection — the largest TCP segment it can send without triggering fragmentation on any hop in the path.

MTU black holes and MSS clamping

When an intermediate router drops an oversized packet without sending an ICMP "Fragmentation Needed" message back (because its firewall blocks ICMP type 3), PMTUD fails silently. The symptom: pages load slowly or partially, large file downloads stall, but small requests like ping work fine. This is an MTU black hole. The standard fix is MSS clamping at the router edge — the router rewrites the MSS field in TCP SYN packets to a safe value (typically interface MTU − 40 bytes for IPv4, − 60 for IPv6), preventing oversized segments from ever being sent. On Linux this is done with iptables --clamp-mss-to-pmtu; on most home routers it is enabled by default for PPPoE and VPN interfaces.

PPPoE overhead

PPPoE (Point-to-Point Protocol over Ethernet) is used by many DSL and some fibre connections to authenticate the subscriber. It adds an 8-byte header (2-byte PPPoE header + 6-byte PPP header) to every Ethernet frame. Since the Ethernet frame payload is capped at 1500 bytes, and 8 bytes are consumed by PPPoE overhead, the effective IP MTU over PPPoE is 1492 bytes. If your router is not configured with MTU 1492 on the WAN interface, packets near the 1500-byte boundary will be fragmented or silently dropped, causing the classic symptom of web browsing working but large file downloads stalling.

VPN tunnel overhead

Every VPN protocol wraps your original packet in additional headers, reducing the available payload. WireGuard adds approximately 60 bytes (20-byte IPv4 outer header + 8-byte UDP header + 32-byte WireGuard header), so a path with MTU 1500 supports only 1420 bytes of inner payload. IPsec in tunnel mode with AES-GCM adds roughly 70–90 bytes. OpenVPN over UDP adds 28–50 bytes depending on cipher and compression settings. Misconfigured VPN MTU is a common cause of slow VPN throughput — the tunnel fragments every large packet, doubling per-packet overhead. Most VPN clients set their tunnel interface MTU automatically, but manual tuning is sometimes needed.

Jumbo frames

Jumbo frames extend the Ethernet MTU to 9000 bytes (sometimes 9216 bytes). They are used exclusively in LAN environments — data centres, NAS clusters, virtual machine storage traffic, and high-performance computing networks. Because all devices on the path must support the same jumbo MTU, jumbo frames cannot traverse the public internet (where 1500 is universal). The benefit is significant for bulk data transfers: a 9000-byte frame carries 6x the payload of a 1500-byte frame with the same per-frame header overhead, reducing CPU interrupt rates and improving throughput for NFS, iSCSI, and VMware vMotion traffic.

How to test your path MTU

Use ping with the don't-fragment flag and a payload size starting at 1472 bytes (1472 + 20-byte IP header + 8-byte ICMP header = 1500 total). On macOS and Linux: ping -D -s 1472 8.8.8.8. On Windows: ping -f -l 1472 8.8.8.8. If the ping fails, reduce by 10 until it succeeds, then narrow down to the exact byte. Add 28 to the largest successful payload to get your path MTU. For PPPoE connections you expect 1464 + 28 = 1492; for WireGuard you expect around 1392 + 28 = 1420.

IPv6 minimum MTU

IPv6 requires every link to support a minimum MTU of 1280 bytes — this is mandated by RFC 8200. Unlike IPv4, IPv6 routers do not fragment packets in transit; only the source host may fragment. If a packet is too large for a link, the router sends an ICMPv6 "Packet Too Big" message back to the source (equivalent to ICMP type 3 code 4 in IPv4). IPv6 PMTUD therefore depends entirely on ICMPv6 not being blocked. The 1280-byte floor ensures that even a host performing no PMTUD at all can always send a minimally-sized packet without fragmentation on any RFC-compliant link.

Frequently Asked Questions

What is the standard MTU size?

Standard Ethernet MTU is 1500 bytes. PPPoE connections lose 8 bytes for the PPPoE header, leaving 1492 bytes. VPN tunnels subtract further overhead (20–80 bytes), and jumbo frames extend MTU to 9000 bytes for LAN storage networks.

What is an MTU black hole?

When a router drops oversized DF-flagged packets without returning an ICMP "Fragmentation Needed" response, TCP Path MTU Discovery breaks. Large transfers stall while ping works. Fix: enable MSS clamping on your router to prevent oversized segments.

How do I find the correct MTU for my connection?

Ping with the don't-fragment flag and sizes starting at 1472. On macOS/Linux: ping -D -s 1472 8.8.8.8. Reduce by 10 until it succeeds, then narrow down. Add 28 to the largest successful payload size to get path MTU.