Test Path MTU across tunnels and cloud edges before applications stall

Source facts: Path MTU belongs to a route, not an interface label

IETF RFC 8899 defines Datagram Packetization Layer Path MTU Discovery, or DPLPMTUD, as a robust way for a datagram transport or application to discover whether a network path supports its current packet size. It uses probe packets and confirmation from the packetization layer, can reduce message size after detecting a packet black hole, and does not depend solely on receiving ICMP Packet Too Big signals.

Path MTU is the maximum IP packet size that can traverse the current path without requiring fragmentation beyond what the protocol and endpoints support. It can be lower than either endpoint interface MTU when IPsec, GRE, VXLAN, provider overlays, or other headers consume part of the packet budget. It can also differ by direction, destination, address family, or route and can change after failover.

Traditional IPv4 Path MTU Discovery in RFC 1191 uses the Don’t Fragment behavior and ICMP “fragmentation needed” responses. IPv6 Path MTU Discovery in RFC 8201 relies on ICMPv6 Packet Too Big because routers do not fragment IPv6 packets in transit. Blocking these diagnostic signals without an alternate probing mechanism can prevent a sender from learning the smaller path size.

A small ping, DNS query, or TCP handshake can succeed while larger packets fail. TCP may adapt through Path MTU or maximum-segment-size behavior, while a UDP application has no universal transport-level recovery unless it implements one. Therefore, the symptom can appear as selective website loading, stalled file transfer, broken large DNS response, unreliable tunnel traffic, or an application-specific timeout rather than a clear link outage.

DSE recommendation: validate packet size as part of every tunnel change

1. Draw the encapsulated path. Record endpoint interface MTUs and every VPN, SD-WAN, GRE, IPsec, cloud gateway, firewall, load balancer, and overlay that adds headers. Calculate an expected payload budget for IPv4 and IPv6, but treat it as a hypothesis to test.
2. Keep control messages intentional. Review firewall and network-security policy for the required ICMPv4 and ICMPv6 error types, rate limits, and return routing. Permit the documented signals rather than enabling or blocking all ICMP as one undifferentiated rule.
3. Probe both directions. Test representative sources and destinations across normal and failover routes, each address family, and remote-user paths. Use increasing packet sizes with the appropriate no-fragment behavior where supported, and collect packet traces at both sides when results disagree.
4. Test the transport, not only ping. Run sustained TCP transfers, large HTTPS requests and responses, UDP or QUIC workloads, DNS over UDP and TCP, storage, backup, replication, and application transactions. Include payloads near the expected boundary and observe retransmission, Packet Too Big messages, fragmentation, and latency.
5. Apply fixes at the right layer. Prefer correcting the path MTU and control-message handling. Where architecture requires it, set a supported tunnel MTU, enable application or transport probing, or apply TCP MSS adjustment at a documented boundary. A TCP-only clamp does not repair UDP.
6. Exercise route changes. Repeat tests during carrier, gateway, tunnel, firewall, and regional failover. Confirm monitoring detects a newly smaller path and that recovery does not depend on a cache learned only on the primary route.

Baseline successful maximum sizes, ICMP response rates, retransmissions, black-hole indicators, application timeouts, and path selection. Add MTU validation to acceptance for new carriers, VPN profiles, cloud connections, overlay changes, and security appliances. Document the exact tool options and whether their size includes or excludes IP and transport headers so later tests are comparable. The goal is not to force every interface to 1500 bytes; it is to ensure each important application can discover or safely operate within the real packet budget of every path it may use.

Official references

• IETF, RFC 8899: Packetization Layer Path MTU Discovery for Datagram Transports, September 2020.
• IETF, RFC 8201: Path MTU Discovery for IP version 6, July 2017; and RFC 1191: Path MTU Discovery, November 1990.