## TL;DR
When a hop has a smaller MTU than the sender and path-MTU discovery is broken (usually a firewall eating the ICMP "fragmentation needed" messages), large packets die silently while small ones pass - SSH hangs on big output, TLS stalls mid-handshake. Detect it by sending non-fragmenting pings of decreasing size until they pass, then fix the hop's MTU or clamp TCP MSS at the gateway.

```text
"MTU mismatch causing silent packet drops": how to detect
```

## Steps

1. Send a large ping with the do-not-fragment bit set to the destination.
   Expected: 100 percent packet loss on the large size while normal small pings succeed - that is the signature of an MTU blackhole.

2. Bisect the ping size downward until replies come back.
   Expected: you find the largest size that passes; add the IP and ICMP header overhead to get the real path MTU.

3. Run a traceroute toward the destination to identify the suspect hop.
   Expected: the path crosses a tunnel, VPN, PPPoE link, or cloud gateway - the usual places MTU shrinks.

4. Check the MTU configured on your interface and on the suspect hop if you control it.
   Expected: one side is set higher (often 1500 or 9000) than what the path actually supports.

5. Fix it: lower the interface MTU to the discovered value, or enable TCP MSS clamping on the gateway so TCP negotiates a fitting segment size.
   Expected: large transfers, SSH sessions with big output, and TLS handshakes complete normally.

6. Re-run the sized ping test to confirm.
   Expected: the previously failing size now passes, or MSS clamping keeps TCP under the ceiling.

## Use this when
- SSH connects but hangs when output gets large
- TLS handshakes stall or VPN tunnels pass only small packets
- a new tunnel, PPPoE link, or cloud gateway just went in and big transfers broke

## Not for this skill when
- nothing connects at all - that is routing or firewall, not MTU
- DNS fails outright - name resolution never gets far enough for MTU to matter
- the symptom is latency rather than stalled large transfers

## Variant phrasings
- packet fragmentation needed but DF set
- path MTU discovery blackhole
- ping works but ssh hangs
- jumbo frames dropped silently

## Why it happens
TCP sets the do-not-fragment bit and relies on ICMP "fragmentation needed" messages to learn the path's smallest MTU. When a middlebox drops those ICMP messages, the sender never learns to shrink packets, keeps retransmitting oversized ones, and the connection stalls - silently, because small packets (like the initial handshake) got through fine.

## Edge cases
- PPPoE links top out at 1492, and VPN/tunnel headers eat another 20-80 bytes on top
- MSS clamping on the gateway fixes TCP but not UDP-based protocols - those need the real MTU fixed
- Jumbo frames (9000) inside a VPC die the moment they cross any 1500 hop without fragmentation
- Some clouds silently drop rather than fragment, so "it worked in the old datacenter" is a classic trigger

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_PB7PbbJdMHqlXYRiPe62Dg