MTU Calculator

MTU (Maximum Transmission Unit) is the largest IP datagram that can travel one link without fragmenting; it includes the IP header. MSS (Maximum Segment Size) is the largest chunk of TCP payload that fits inside that datagram, so it excludes both headers: MSS = MTU - 20 (IPv4 header) - 20 (TCP header), which is MTU - 40 for IPv4 TCP. On standard Ethernet that gives 1500 - 40 = 1460 bytes of MSS. IPv6 swaps the 20-byte IP header for a 40-byte one, so MSS on IPv6 is MTU - 60. The two ends of a TCP connection advertise their MSS in the SYN handshake and pick the smaller value.

PPPoE (RFC 2516) wraps every IP packet in a PPPoE session header (6 bytes) plus a PPP protocol field (2 bytes), totalling 8 bytes that sit between the Ethernet frame and the IP datagram. Standard Ethernet still caps the payload at 1500 bytes, so once those 8 bytes are spent the IP layer only has 1492 bytes left. Almost every DSL ISP runs PPPoE, which is why home routers default the WAN MTU to 1492 even though the LAN side is happily Ethernet 1500. If your router does not match, you will see weird symptoms like HTTPS sites timing out at the TLS handshake while pings work.

UDP adds an 8-byte header to each packet; TCP adds a 20-byte header plus its own state machinery. OpenVPN over UDP leaves more room inside the 1500-byte Ethernet frame for the encrypted tunnel payload, which is why the recommended path MTU lands around 1462 bytes for UDP versus 1438 for TCP. UDP is also the right transport for VPNs in general: tunnelling TCP over TCP doubles the retransmit timers and tanks throughput under loss (the well-known 'TCP meltdown' problem). Use UDP unless a restrictive firewall forces TCP/443.

Send a Do-Not-Fragment ping with a payload that fills the link, then shrink it until it stops being dropped. On Linux: `ping -M do -s <N> <host>`. On macOS or BSD: `ping -D -s <N> <host>`. The right N is your suspected MTU minus 28 (20 bytes for the IPv4 header, 8 for the ICMP echo header), so for a 1500-byte Ethernet path you ping with -s 1472. If that succeeds, the link supports your MTU; if you get 'Message too long' or 'frag needed' back, drop the size by 10 bytes and try again. The first size that gets through plus 28 is the path MTU.

Jumbo frames pay off on storage and backup networks (NFS, iSCSI, SMB to a NAS), inside data-centre fabrics, and on dedicated cluster links, where the per-packet overhead reduction (about 5x fewer packets for the same bytes) shows up as measurable CPU and latency wins. They are a bad idea on a general LAN or anywhere a packet might cross the internet, because every device on the path must support the same jumbo size end to end. One switch in the middle stuck at 1500 will fragment or drop the oversized frames, and there is no way to negotiate jumbo support over the public internet, which still assumes a 1500-byte ceiling.