Jumbo Frame MTU Mismatch: Ping DF Bit Troubleshooting - 夜莺博客

Jumbo Frame MTU Mismatch: Ping DF Bit Troubleshooting

Jumbo frames fail in the most deceptive way possible: small requests work, big transfers hang, and nothing in the logs says why. The classic symptom — connections establish but data stalls — is a Path MTU Discovery black hole, usually caused by an MTU mismatch somewhere along the path plus a firewall that drops the ICMP "fragmentation needed" messages. This guide shows how to isolate the mismatch with ping and the Don't Fragment bit, then fix it consistently across switches, SVIs and hosts.

Why MTU Mismatch Becomes a Black Hole

When a packet exceeds the next link's MTU, an IPv4 router can fragment it — unless the Don't Fragment (DF) bit is set. TCP sets DF to enable Path MTU Discovery: the router then drops the packet and sends back an ICMP type 3 code 4 message telling the sender to use smaller packets. If a firewall blocks that ICMP, the sender never learns, retransmits forever and the connection "works but transfers nothing". Tunnel overhead makes this worse — GRE subtracts 24 bytes, GRE over IPsec around 52, WireGuard 80, and PPPoE drops you to 1492.

Finding the Path MTU with Ping and DF

Measure the real end-to-end MTU with DF set and the ICMP payload sized correctly (add 28 bytes for IP+ICMP headers):

# Linux: 1472 + 28 = 1500 (standard MTU)
ping -c 3 -M do -s 1472 8.8.8.8
# 8972 + 28 = 9000 (jumbo)
ping -c 3 -M do -s 8972 STORAGE_SERVER_IP
# Windows: ping -f -l 8972 <target>

If 8972 fails but 1472 succeeds, the path is not consistently jumbo-capable. Bisect between the two sizes to find the exact ceiling — for example 1450 succeeding and 1500 failing pinpoints the MTU. Crucially, always test with DF: without it the router fragments happily and the ping succeeds even when the real path MTU is smaller.

Where the Mismatch Usually Lives

  • Switch port MTU — the port is still at 1500 while the host is at 9000.
  • SVI MTU — Layer 3 VLAN interfaces need their own ip mtu; the L2 port MTU alone is not enough for routed traffic.
  • System MTU — on Cisco Catalyst the global system mtu change only applies after a reload.
  • Tunnel/VPN interfaces — encapsulation overhead was never subtracted from the MTU.
  • VLAN subinterfaces on Linux — a VLAN interface inheriting the parent MTU while the parent was changed.

On Cisco IOS-XE, check the hardware side with show controllers ethernet-controller Gi1/0/1 | include ValidOverSize — rising oversize counters prove frames bigger than the port MTU are arriving. Cisco Catalyst 9300-specific MTU troubleshooting is covered in depth by the network-switch.com engineering article.

Fixing It: The All-or-Nothing Rule

Jumbo frames require every device in the path to support them, so either standardize 9000 (or 9216) end-to-end across hosts, switches and SVIs, or keep 1500 and fix the tunnel endpoints instead:

! Cisco IOS - consistent jumbo deployment
Switch(config)# system mtu 9000
Switch(config)# interface Vlan10
Switch(config-if)# ip mtu 9000
Switch(config)# interface GigabitEthernet1/0/1
Switch(config-if)# mtu 9000
! Linux host
sudo ip link set ens3 mtu 9000
! TCP MSS clamp for tunneled/broken paths
R1(config-if)# ip tcp adjust-mss 1360

After the change, re-run the DF ping in both directions — asymmetric success (A to B works, B to A fails) is the signature of a one-sided mismatch. For storage networks that depend on jumbo frames, also verify the NIC and switchport of every hop; our ethtool diagnostics guide covers the host side and the SFP checklist covers the physical layer beneath it.

原文链接:https://packetmentor.com/topics/mtu-fragmentation