Understanding Packet Loss in MTR
Packet loss shown at intermediate hops doesn't always indicate a problem. Many routers deprioritize ICMP traffic (used by MTR) to focus on forwarding actual data. This is called ICMP rate limiting.
The key indicator: If packet loss appears at one hop but not at subsequent hops, the router is likely just deprioritizing ICMP responses—actual traffic flows fine.
Loss that persists through later hops and the destination deserves investigation. Repeat with more probes and consider return paths and ICMP filtering before attributing a fault to one router.
Interpreting Latency Patterns
Consistent latency jumps: An increase that persists through later hops can be consistent with a long-distance link. Differences between independent RTTs do not measure the delay of an individual link.
High jitter (StDev): Large standard deviation suggests network congestion or an overloaded link. Latency should be relatively stable on healthy paths.
Latency spikes on one hop: If one hop shows high latency but subsequent hops return to normal, the router may be slow to respond to ICMP but forwards traffic efficiently.
Progressive latency increase: A persistent increase through the destination can warrant investigation. Geography, queueing and different return paths can all affect RTT.
Common MTR Patterns and Causes
Stars (* * *) at one hop: The router doesn't respond to ICMP. Common for firewalls and security appliances. Not necessarily a problem if subsequent hops work.
Stars at final destination: The target may filter probes, or may be unreachable. A TCP measurement from your own machine (mtr --tcp) can provide additional evidence.
Asymmetric routing: Forward and return paths may differ, making single-direction MTR show only part of the picture. Problems on the return path can appear as issues on the forward path.
Load balancing: Per-packet load balancing can cause MTR to show multiple IPs at the same hop, or inconsistent latency readings as packets take different paths.
Network Troubleshooting with MTR
ISP vs destination issues: This report begins at the service’s probe, so its first hops belong to that network. Run MTR from your own device too when investigating your ISP.
Comparing paths: Run MTR to multiple destinations. If all destinations show loss at hop 3, your ISP's equipment at that point is the issue. If only one destination has problems, it's that network or the path to it.
Time-based testing: Run MTR during both peak and off-peak hours. Congestion-related issues often appear only during busy periods, while hardware problems persist 24/7.
Documentation: Save MTR reports when filing support tickets. They provide objective evidence that helps network engineers quickly locate problems.