What is MTU? Packet size and path problems explained

MTU is the largest network packet size an interface or link can carry without splitting it at that layer. A common Ethernet MTU is 1500 bytes, but tunnels and other links may allow less. A connection must work within the limits of the path it actually takes.

Interface MTU is not path MTU

The number shown for a network card describes its local link, not automatically every hop to a remote server. A VPN or another tunnel adds outer headers that consume space. If the inner packet is already as large as the outer link allows, the encapsulated packet may be too big. Path MTU is the largest IP packet that can traverse a particular path. It can differ between destinations and potentially between directions.

MTU is neither a file-size limit nor a line speed. Applications can transfer large files while the transport divides the data into suitable segments. In TCP, maximum segment size (MSS) refers to the data carried by one TCP segment and is smaller than the relevant MTU because IP and TCP headers also need space. IPv4 and IPv6 handle oversized packets differently.

How endpoints discover the limit

Path MTU Discovery uses signals that a packet is too large. In IPv4, a router can report that fragmentation is needed when the packet must not be fragmented. In IPv6, transit routers do not fragment packets and can send ICMPv6 Packet Too Big. Blocking these messages may create a puzzling failure: small requests work, while larger responses stall. Some implementations also use other probing techniques to find a working size.

RFC 1191 specifies IPv4 Path MTU Discovery; RFC 8201 covers IPv6. Header sizes and tunnel behaviour matter, so 1500 is not a universal end-to-end setting. Avoid calculating MSS from a memorised number without accounting for the real path.

Diagnose before changing settings

If failures happen only through a VPN, or a site loads partly but larger transfers hang, compare the same task with and without the tunnel. Record the interface, destination and symptoms. Ping probes with different payload sizes and a no-fragment option can help, but command syntax varies by system and ICMP may be filtered. Use network tests as supporting evidence, not a single definitive verdict.

Do not lower MTU on every device without a hypothesis. Check tunnel settings and relevant ICMP messages, change one setting at a time, and retest the application. An unnecessarily small MTU increases header overhead and can reduce efficiency. If the bottleneck is outside your control, give the provider a reproducible example.