Path MTU Discovery

Path MTU Discovery, commonly abbreviated PMTUD, allows a sender to adapt packet sizes to the capabilities of an end-to-end network path. An interface MTU describes the largest IP packet that an interface can carry without fragmentation; the path MTU is the smallest applicable MTU along the route. Ethernet frame size and IP MTU are related but are not interchangeable: Ethernet headers and other link-layer overhead are outside the IP MTU.

Classic IPv4 PMTUD sends packets with the Don't Fragment flag set. A router that cannot forward a packet because it exceeds the next-hop MTU drops it and returns an ICMP Destination Unreachable message with type 3, code 4, meaning fragmentation is needed. The sender uses that feedback to reduce its packet size. IPv6 routers do not fragment forwarded packets; they return ICMPv6 Packet Too Big messages, type 2, so the source can adjust its transmissions.

Filtering these messages can create a PMTUD black hole. DNS queries, TCP handshakes, and small interactive requests may succeed, while large responses, file transfers, or TLS exchanges stall. This pattern often indicates a packet-size problem rather than a routing failure. Permit the required ICMP feedback through relevant security groups, network ACLs, host firewalls, and on-premises firewalls. Allowing only ICMP echo requests and replies is not sufficient.

For example, an instance with a 9001-byte interface MTU might communicate successfully with another instance over a jumbo-capable path but encounter a smaller limit when reaching an on-premises system through a tunnel. Setting both endpoint interfaces to 9001 does not make the intermediate path jumbo-capable. IPsec and other encapsulations consume packet space, reducing the usable inner-packet MTU. Paths in opposite directions can also have different limits, and routing changes can invalidate a previously discovered value.

Validate connectivity with size-controlled probes as well as application traffic. On Linux, ping -4 -M do -s 1472 destination tests a 1500-byte IPv4 packet when there are no IP options: 1472 bytes of payload plus an 8-byte ICMP header and a 20-byte IPv4 header. Increase or decrease the payload to locate the working boundary. This test requires ICMP echo support and does not prove that TCP or UDP follows an identical path. Use tracepath where supported, capture ICMP errors and retransmissions, and test representative transfers in both directions. Account for segmentation and receive offloads when interpreting packet captures on endpoints.

Jumbo packets can reduce per-packet processing and header overhead during bulk transfers, but they do not increase the physical link speed. Configure them only where every relevant segment supports the intended MTU. In AWS, supported EC2 interfaces can use an MTU of 9001. AWS Direct Connect supports jumbo MTUs of 9001 on private virtual interfaces and 8500 on transit virtual interfaces, subject to connection support and configuration; public virtual interfaces use 1500. Transit Gateway has an 8500-byte MTU for supported attachment paths, while VPN paths have lower limits.

Not every managed connectivity service supports classic PMTUD. AWS Site-to-Site VPN does not support it, so select an appropriate tunnel MTU and TCP maximum segment size rather than assuming ICMP feedback will resolve oversized packets. Its maximum supported MTU is 1446 bytes, and encryption settings can require a smaller value. TCP MSS clamping can mitigate TCP sizing problems, but it does not fix UDP or increase the path MTU. Packetization-layer discovery can probe usable sizes without depending solely on ICMP, where the transport or application implements it. A practical design combines compatible MTUs, permitted feedback where supported, and explicit validation of primary and failover paths.