Diagnose Path MTU Problems on an IP Network

Admin

October 4, 2026

7 min read

Some connections establish but stall when larger packets or payloads are sent. One possible cause is a path MTU discovery (PMTUD) problem: a router cannot forward a packet at its size, and the required ICMP feedback does not reach the sender. The commands in this guide test IPv4; IPv6 uses ICMPv6 Packet Too Big messages and different probe options.

Use these probes against an endpoint you administer or are authorized to test. Results can be inconclusive when ICMP is filtered, and MTU symptoms can have other causes such as proxy behavior, congestion, or application-layer timeouts.

Step 1: Record the Interface and Route

Find the Egress Interface and Current MTU

Baseline

Replace the documentation-only IPv4 address below with a reachable destination you are authorized to test. Record the selected route and interface MTU before changing anything. The command extracts the egress interface from the route result instead of assuming a name such as eth0.

DESTINATION_IP="192.0.2.20" # Documentation-only placeholder; replace it.
ip route get "$DESTINATION_IP"
EGRESS_IF=$(ip -o route get "$DESTINATION_IP" | awk '{for (i=1; i<=NF; i++) if ($i == "dev") {print $(i+1); exit}}')
printf 'Egress interface: %s\n' "$EGRESS_IF"
ip link show dev "$EGRESS_IF"

Step 2: Ask tracepath to Estimate the Path MTU

Trace the Route and Report MTU Changes

Path Probe

Run tracepath to the destination. It traces the route and attempts to discover the path MTU without requiring root on typical Linux systems. Install your distribution’s IPutils package if the command is missing. Routers that do not reply may appear as gaps, so compare with other evidence rather than treating missing hops as a failure.

tracepath -n "$DESTINATION_IP"

Step 3: Test IPv4 with Don’t-Fragment Probes

Check a Known Reachable IPv4 Destination

Controlled Test

For a 1500-byte IPv4 path, an ICMP payload of 1472 bytes plus the 20-byte IPv4 and 8-byte ICMP headers totals 1500 bytes. Start with that size, then reduce it in measured increments if fragmentation is reported. This tests the path to the selected host, not every route used by your application.

ping -4 -M do -s 1472 -c 3 "$DESTINATION_IP"

Step 4: Compare with a Smaller Payload

Check Whether Smaller Packets Succeed

Interpretation

If the larger probe fails, try a smaller size and compare results. A pattern where small probes work and larger do not supports an MTU hypothesis, but an ICMP policy can create the same appearance. Preserve the destination, source interface, and packet sizes so the test can be repeated from both sides of a VPN or routed boundary.

ping -4 -M do -s 1300 -c 3 "$DESTINATION_IP"

Step 5: Correct the Constraining Link or ICMP Policy

Fix the Path Design, Then Retest Applications

Resolution

Review tunnel overhead, interface MTUs, and firewall rules at the hop where the path MTU changes. For IPv4, allow ICMP Destination Unreachable / Fragmentation Needed (Type 3, Code 4). For IPv6, allow ICMPv6 Packet Too Big (Type 2). Set interface MTUs or TCP MSS adjustments only when the network design calls for them, then verify large application transfers end to end.

Document: affected route, probe sizes, path MTU estimate, tunnel overhead
Change: approved router/VPN/firewall setting at the identified boundary
Verify: repeat probes and test the original application flow

See the tracepath manual for its path-MTU discovery behavior.