Signal9Signal9 — home
online
back to labs

Black Hole: Diagnose the MTU Mismatch Behind Stalled Transfers

HardNetworking20-30 min
The brief

Users on a remote network report the same thing: ssh works and small requests return fine, but anything large — an scp, a package download, a dump — stalls at the start and never finishes, with no error. That is the signature of a Path-MTU black hole: an interface is sending frames larger than something on the path will carry, the oversize packets are dropped with the Don't-Fragment bit set, and the ICMP that would tell the sender to shrink is filtered upstream, so it never self-corrects.

You are handed the captured diagnostics under /root/case/: ip_link.txt (each interface's configured MTU), ip_route.txt (which interface carries the route to the affected network), and mtu_probe.txt (a Don't-Fragment ping sweep to a host on that network, reporting pass/fail per payload size).

Work it out and record three findings: the interface whose configured MTU is too large for its path (/root/case/iface.txt), that interface's current (wrong) configured MTU (/root/case/confmtu.txt), and the actual path MTU the sweep proves the path can carry (/root/case/pmtu.txt). The probe reports the ICMP payload size, not the whole packet — account for the IPv4 and ICMP header overhead when you state the path MTU. See /root/case/brief.txt. This lab grades the diagnosis.

What you'll do
  • Recognize 'small works, large stalls' as a Path-MTU black hole
  • Correlate configured interface MTUs with the route that carries the failing path
  • Read a DF ping sweep to find the largest packet the path passes
  • Convert the largest successful payload into the true path MTU using header overhead

Hands-on lab: you work on a real Linux box in your browser, graded on the machine's actual state.