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.
Genuine network problems show loss that persists or increases at every hop after the problematic point. If hop 5 shows 20% loss and hops 6-10 also show 20%+, the issue is likely at hop 5.
Interpreting Latency Patterns
Consistent latency jumps: A 70ms increase between two hops typically indicates a long-distance link (transoceanic cable, transcontinental backhaul). This is normal physics, not a problem.
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: Latency building up at each hop after a certain point indicates genuine congestion or routing issues.
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: Target host blocks ICMP or has a strict firewall. Try TCP mode (mtr --tcp) to work around this.
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: Identify where problems start. First few hops are your network, next few are your ISP, then transit providers, finally the destination's network. This helps direct support requests to the right party.
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.