How do I trace a Linux server’s network path and investigate MTU problems?
tracepath sends diagnostic probes and reports responding hops and path-MTU information when the network provides it. It can help explain why small requests work while larger transfers stall. Intermediate routers may filter or rate-limit diagnostic responses, so a missing hop is not proof that the router is dropping ordinary application traffic.
Before you start
- An authorised destination IP.
- A known failing transfer or connection to compare with the diagnostic result.
Instructions
1. Inspect the outgoing interface MTU
Use the actual interface name found with ip link. This is the local configured MTU, which may be larger than the usable end-to-end path.
ip link show dev ens3Displays interface details including the local MTU; replace ens3 with the real interface.
2. Trace the path numerically
Replace the reserved example address with the affected destination. Numerical output avoids extra reverse-DNS delays. Stop the diagnostic with Ctrl+C if enough evidence has been collected.
tracepath -n 198.51.100.20Reports responding hops and any discovered path-MTU reduction.
3. Compare with the real symptom
Record the destination, address family, observed MTU and whether small and large transfers behave differently. VPNs, tunnels and provider overlays can reduce available packet size; the return path may also differ from the displayed outward path.
Check the result
- A route reaches the intended destination, or collected evidence identifies the boundary where further network investigation is needed.
Troubleshooting
- The trace shows no reply at one hop
- Compare later hops and the actual application. Do not change interface MTU based on a single nonresponding router.
- Large transfers still stall
- Check both directions and ICMP path-MTU signalling with the network administrator before applying a persistent MTU change.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.