Testing MTU With Ping and the DF Bit

Small pings work, SSH works, but file copies hang and some websites never load. That symptom set has one classic cause: an MTU mismatch somewhere on the path, usually introduced by a tunnel. The fastest way to find it is the tool you already have open. This article shows how to hunt path MTU with ping from both Linux and Cisco IOS XE, demonstrated against a lab link deliberately clamped to 1400 bytes. It is part of the PingLabz ping guide.

The Setup: a 1400-Byte Link in the Path

The lab path runs from a Debian host through R1 and R2 to R3's loopback (3.3.3.3). The R2-R3 link carries ip mtu 1400, exactly what you would see on a network with a GRE tunnel in the middle (GRE eats 24 bytes, and engineers commonly clamp to 1400 for margin; the full story is in the GRE guide). One detail worth internalizing from R2:

R2#show ip interface Ethernet0/2 | include MTU
  MTU is 1400 bytes

R2#show interfaces Ethernet0/2 | include MTU
  MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec,

Two different commands, two different answers, both correct. show interfaces reports the hardware MTU (still 1500), while show ip interface reports the IP MTU (clamped to 1400). Only the IP MTU governs whether an IPv4 packet gets fragmented. Knowing which command answers which question saves you from chasing ghosts.

The 28 Bytes Everyone Forgets

Ping's -s flag sets the ICMP payload size, not the packet size. The wire size is payload + 8 (ICMP header) + 20 (IPv4 header). So to test a 1400-byte MTU, the largest payload that fits is 1400 - 28 = 1372:

(Cisco's size option, by contrast, sets the full IP packet size, so size 1400 on IOS is equivalent to -s 1372 on Linux. The off-by-28 confusion between the two conventions has burned many an engineer.)

Testing From Linux: -M do

-M do sets the DF (Don't Fragment) bit, which forbids routers from fragmenting the packet. First, prove the exact fit passes:

j@lab:~$ ping -c 3 -s 1372 -M do 3.3.3.3
PING 3.3.3.3 (3.3.3.3) 1372(1400) bytes of data.
1380 bytes from 3.3.3.3: icmp_seq=1 ttl=253 time=5.43 ms
1380 bytes from 3.3.3.3: icmp_seq=2 ttl=253 time=4.81 ms
1380 bytes from 3.3.3.3: icmp_seq=3 ttl=253 time=4.86 ms

--- 3.3.3.3 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss

Now push one byte class beyond it (payload 1400 = 1428 on the wire) and watch the path answer back:

j@lab:~$ ping -c 3 -s 1400 -M do 3.3.3.3
PING 3.3.3.3 (3.3.3.3) 1400(1428) bytes of data.
From 10.0.12.2 icmp_seq=1 Frag needed and DF set (mtu = 1400)

--- 3.3.3.3 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss

ping: sendmsg: Message too long

Two things happened here, and both are diagnostic gold. First, the router at 10.0.12.2 sent an ICMP "Fragmentation Needed" error that names the limiting MTU: 1400. No binary search required; the path told you the answer. Second, the follow-up probes failed locally with Message too long: the kernel cached the discovered path MTU (that is Path MTU Discovery doing its job) and refused to send oversized packets at all.

Remove the DF bit and the same oversized packet sails through, because R2 is now allowed to fragment it:

j@lab:~$ ping -c 3 -s 1400 3.3.3.3
PING 3.3.3.3 (3.3.3.3) 1400(1428) bytes of data.
1408 bytes from 3.3.3.3: icmp_seq=1 ttl=253 time=5.35 ms

--- 3.3.3.3 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss

Working fragmentation is why MTU problems hide: most traffic without DF gets fragmented and limps along (with a performance tax), while TCP flows, which set DF because they rely on PMTUD, hang.

Testing From IOS XE: df-bit

The router-side equivalent, from R1:

R1#ping 3.3.3.3 size 1500 df-bit
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with the DF bit set
M.M.M
Success rate is 0 percent (0/5)

Every M is a "could not fragment" report. For an exhaustive scan, the interactive extended ping dialog offers a size sweep (Sweep range of sizes), which walks every packet size in a range and shows precisely where ! turns into M. One-line options and the rest of the extended toolkit are covered in Cisco extended ping.

When the Path Won't Tell You: Binary Search

The router named 1400 in its ICMP error, but on real networks the error often never reaches you (filtered upstream). Then you binary search with -M do: 1472 fails, try 1372; passes, try 1422; and so on until you bracket the ceiling in half a dozen pings. Common answers you will land on: 1472 (clean 1500 path), 1444 (GRE), 1412-1424 (IPsec variants), 1452 (PPPoE).

PMTUD Black Holes: the Silent Killer

Path MTU Discovery depends entirely on that "Frag needed" ICMP message getting back to the sender. Every hardening guide that says "block all ICMP" and every interface running no ip unreachables breaks the feedback loop: the sender keeps transmitting full-size DF packets into a hole and never learns why nothing comes back. That is a PMTUD black hole, and its signature is exactly the symptom this article opened with: small packets fine, big transfers dead.

If you operate the small-MTU link, the mitigation on Cisco gear is ip tcp adjust-mss on the tunnel or LAN interface, which rewrites the MSS in TCP handshakes so endpoints never send oversized segments in the first place. If you only operate the client side, clamping the interface MTU works as a blunt instrument. Either way, never filter ICMP type 3 code 4 at your edge; allowing "fragmentation needed" through is part of running a functional network, a point expanded in the pillar's ICMP filtering section.

Key Takeaways

• Linux -s sets payload (add 28 for the wire size); Cisco size sets the whole IP packet. 1372 payload = 1400 packet.
• ping -s N -M do on Linux and ping X size N df-bit on IOS are the same test: does an N-byte-class packet fit without fragmentation?
• A "Frag needed" error often names the limiting MTU. When it does not arrive, binary search for the ceiling.
• show ip interface (IP MTU) and show interfaces (hardware MTU) answer different questions.
• Small pings pass + large transfers hang = suspect a PMTUD black hole. Fix with ip tcp adjust-mss, and never filter ICMP frag-needed messages.

Related reading: Linux ping options in depth, the GRE tunnel guide (where these MTU numbers come from), and the full ping guide.