Octet

What are the classic symptoms of an MTU problem, and how do you prove it?

Show the answer

Say this first

Small things work and big things hang. Ping works, the TCP handshake completes and SSH logs in, but web pages stall partway, file copies freeze, or a VPN connects and then passes almost nothing. Full-size packets are being dropped somewhere, usually at a tunnel or PPPoE link, and the ICMP message that should tell the sender is filtered. I prove it with DF-bit pings of increasing size and fix it with a consistent MTU, TCP MSS clamping, and by letting ICMP fragmentation-needed through.

Go deeper

Symptoms

  • The handshake works, then the connection stalls at the first full-size segment, often the server's certificate during TLS.
  • Some websites load and others hang.
  • File copies, replication or backups stall over a VPN.
  • It works over one path and fails over another, such as a backup tunnel.

Prove it

Shell
ping -M do -s 1472 10.30.0.15     # 1500 bytes total, passes on a clean path
ping -M do -s 1372 10.30.0.15     # 1400 bytes total

Windows: ping -f -l 1472. Cisco: ping 10.30.0.15 size 1500 df-bit. Bisect to the largest size that passes. Linux tracepath reports the path MTU hop by hop when ICMP is allowed. In a capture, look for the same full-size segment retransmitted again and again, with no ICMP type 3 code 4 coming back.

Common MTU budgets

PathIP MTU
Ethernet1500
PPPoE1492
GRE (24 bytes overhead)1476
IPsec tunnel moderoughly 1400 to 1440, depending on cipher and NAT-T
GRE over IPseccommonly set to 1400

Fixes

  • Set the tunnel MTU and clamp TCP MSS: ip mtu 1400 and ip tcp adjust-mss 1360 on the tunnel.
  • Permit ICMP type 3 code 4, and ICMPv6 type 2 (packet too big), through every firewall.
  • Keep jumbo MTU consistent end to end in the data center.

MSS clamping fixes TCP only. Large UDP still needs a correct MTU or fragmentation.

Traps

  • Ruling out MTU because ping works. Default pings are tiny.
How did you do?Book 3.3 Internet (IP)Book 5.2 Reliable Byte Stream (TCP)