Path MTU Discovery (PMTU)
An aide-memoir for PMTU operation.
Usually, the path MTU is determined using MTU Path Discovery. Usually, two hosts can dynamically negotiate the path MTU (e.g. client and server ) but networks that contain firewalls or tunnels (VPN, GRE, IPSec transport mode) sometimes require tuning the MTU values manually.
Determine MTU manually by sending ICMP pings with different lengths, with the “Do Not Fragment” bit set. For example:
- ping 10.64.8.62 -M do -s 1464 (note 1464 plus 28 bytes of ICMP header = 1492) – this failed.
- ping 10.64.8.62 -M do -s 1444 (note 144 plus 28 bytes of ICMP header = 1472) – this passed.
When PMTU is not blocked the usual operation during connection establishement between the two hosts involv exchanging their TCP maximum segment size (MSS) values. The smaller of the two MSS values is used for the connection.
- The MSS for a host is the MTU at the link layer minus 40 bytes for the IP and TCP headers.
- However, support for additional TCP options, such as timestamps, has increased the typical TCP+IP header to 52 or more bytes:
When TCP segments are destined to a non-local network, the “do not fragment” bit is set in the IP header, however any router along the path may have an MTU that differs from that of the two hosts:
- If a media segment has an MTU that is too small for the IP datagram being routed, the router will attempt to fragment the datagram accordingly. It will then find that the “do not fragment” bit is set in the IP header.
- At this point, the router should inform the sending host that the datagram cannot be forwarded further without fragmentation. This is done with anICMP Destination Unreachable message.
Most routers will also specify the MTU that is allowed for the next hop by putting the value for it in the low-order 16 bits of the ICMP header field that is labeled unused in the ICMP specification. (See RFC 1191, section 4, for the format of this message):
Upon receiving this ICMP error message, TCP adjusts its MSS for the connection to the specified MTU minus the TCP and IP header size, so that any further packets sent on the connection will be no larger than the maximum size that can traverse the path without fragmentation.
- A router along the TCP path of the session (possibly originating a VPN tunnel) might not support the packet size and since it is not allowed to fragment the packet, it can request the originator to reduce the packet size. It does this with an ICMP type 3, code 4 (34) packet that carries the desired maximum size in a two octet fields labeled Next-Hop MTU. In this same packet you can also find the sequence number for the offending packet.
Disabling PMTU:
- On Linux: echo 1 >/proc/sys/net/ipv4/ip_no_pmtu_disc
- On Cisco routers:
no ip tcp mtu-path discovery
Microsoft Windows servers have registry settings to enable path MTU discovery. If this is not enabled, an MTU value of 576 bytes might be used, which can produce suboptimal network performance when a device communicates with a host outside of its local IP subnet.
You can enable PMTU Discovery using the registry settings in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
The EnablePMTUDiscovery registry value governs whether TCP will attempt to discover the Maximum Transmission Unit (MTU), or largest packet size for the entire path to a remote host.
- Setting this parameter to 0 (or off) causes an MTU of 576 bytes to be used for all connections to destinations other than the local subnet.
By discovering the Path MTU (PMTU) and limiting TCP segments to this size, TCP can eliminate packet fragmentation at routers along the path that connect networks with different MTUs. Fragmentation adversely affects TCP throughput and causes network congestion.
