Beyond a Single Traceroute: MTR, Asymmetric Routing, and Diagnosing Intermittent Network Issues

A single traceroute is a snapshot — and intermittent network problems, by definition, won't necessarily show up in a snapshot taken at one moment

The previous traceroute article on this site covered how to read a single traceroute's output. This article addresses a different, common follow-up situation: "I ran a traceroute and everything looked fine, but the problem is intermittent / only happens sometimes / only affects certain traffic" — and covers continuous monitoring tools (MTR being the most prominent), asymmetric routing, and why "the path looks fine in one direction" doesn't mean the path is fine.

MTR: traceroute that keeps running

MTR (My Traceroute, or various similarly-named tools) combines traceroute's hop-by-hop path discovery with ping's continuous, repeated measurement — instead of a single traceroute "snapshot" (one packet per TTL value, showing the path at that moment), MTR continuously sends packets to each hop along the path, displaying running statistics (loss percentage, average/best/worst/standard-deviation latency) per hop, updated in real-time.

Why this matters for intermittent issues: a single traceroute might show "all hops responded, latencies looked normal" — simply because, at the moment that traceroute ran, nothing unusual was happening. If a specific hop experiences intermittent packet loss (say, 5% of packets dropped, randomly) — a single traceroute (one packet per hop) has a 95% chance of not showing any loss for that hop, for any individual run — but running MTR for several minutes, sending many packets to each hop, would reveal that 5% loss rate at the affected hop as a statistic, even though any individual packet has a high chance of succeeding.

Reading MTR output: the key columns to focus on for diagnosing issues:

• Loss% per hop — a hop showing consistent loss (especially if subsequent hops show less or no loss) can indicate that hop specifically is dropping/deprioritizing the diagnostic traffic (ICMP) without this necessarily affecting forwarding (the hop might still be correctly forwarding packets toward later hops, while not always responding to the ICMP messages traceroute/MTR use to measure that specific hop) — vs. loss that's consistent from a hop onward through all subsequent hops, which more likely indicates a genuine problem at or before that hop affecting the actual path
• Latency consistency (StDev/Standard Deviation) — a hop with high latency variability (not just high average latency, but a wide spread between best and worst observed) can indicate congestion or queuing issues at that hop, even if the average latency doesn't look alarming

Why a hop showing loss doesn't always mean that hop is "the problem"

ICMP rate-limiting at individual hops: many routers apply rate-limiting specifically to ICMP Time Exceeded messages (the messages that make traceroute/MTR work, as covered in the previous article) — a router might be perfectly capable of forwarding actual traffic (TCP/UDP packets passing through it toward later hops) without any issue, while simultaneously dropping some percentage of the ICMP messages it would otherwise send back in response to traceroute/MTR probes about itself, simply due to this rate-limiting.

The diagnostic implication: a hop showing, say, 30% loss in MTR — while all subsequent hops show 0% loss — is a classic signature of ICMP rate-limiting at that specific hop, not a sign that 30% of actual traffic through that hop is being lost. If actual traffic were being lost at that hop, you'd expect subsequent hops to also show elevated loss (since traffic that doesn't make it past hop N can't be measured at hop N+1 either) — a hop showing loss in isolation, with normal-looking subsequent hops, is more consistent with that hop selectively deprioritizing ICMP about itself specifically, while still forwarding general traffic normally.

Genuinely problematic loss patterns: loss that appears at a certain hop and persists (at similar or increasing levels) through all subsequent hops to the destination — this pattern is more consistent with actual packet loss occurring at or around that hop, affecting the path (not just ICMP-about-that-hop specifically).

Asymmetric routing: why the forward and return paths can differ entirely

Traceroute (and MTR) show the path from the device running the tool toward the destination. The path that return traffic takes — from the destination back to you — is not necessarily the same path, and routing between the same two endpoints is frequently asymmetric (different paths in each direction) due to how internet routing (BGP, covered in the previous article) makes independent decisions for each direction based on each network's own routing policies, which don't have to be "mirror images" of each other.

Why this matters for diagnosing problems: if you run traceroute from your network toward a remote server, and it looks fine — this tells you about the outbound path. If the actual problem (e.g., poor video call quality, where received video/audio from the remote party is what's degraded) is occurring on the return path (remote server back to you) — your traceroute, showing only the outbound path, wouldn't reveal it.

Diagnosing the return path: this generally requires running traceroute/MTR from the other end — i.e., from the remote server/service back toward you — which isn't something you can do directly unless you have some access to that remote endpoint (your own server, or a cooperating party at the other end who can run diagnostics from their side). For diagnosing issues with third-party services (a video call platform, a cloud provider) where you don't have this access, this asymmetry is part of why "my outbound traceroute looks fine, but I'm still having issues" doesn't fully rule out a path-related cause — it rules out outbound path issues specifically, while return-path issues remain a possibility that's harder to directly investigate from your side alone.

Continuous monitoring vs point-in-time checks for ongoing issues

For issues described as "intermittent" or "happens at certain times of day": running MTR (or similar continuous tools) during a period when the issue is occurring — rather than after the fact, when things may have returned to normal — is important. Some tools/approaches support logging MTR output over extended periods (hours), allowing correlation between logged network statistics and the times when the issue was reported/observed — useful for identifying whether network-path issues correlate with the reported problem timing, vs. the problem having a different (non-network-path) cause that happens to occur on a similar schedule coincidentally (e.g., both might correlate with "everyone in the household is home and using the network in the evening," but that correlation alone doesn't establish causation specifically via path issues vs. simply local network congestion from increased simultaneous usage, which is a different category of issue than a problem at some specific hop along the wider internet path).

Distinguishing "my network" from "the wider path" from "the destination"

A useful diagnostic structure for "is this issue on my end, in the middle, or at the destination":

1. Local network segment (the first few hops, typically your own router and your ISP's nearby infrastructure) — issues here affect everything you do on the internet, not just the specific service you're having trouble with
2. Middle of the path (intermediate networks/hops between your ISP and the destination's network) — issues here might affect multiple destinations that happen to route through the same intermediate networks, but not necessarily all internet destinations (different destinations can take different paths through different intermediate networks)
3. Near the destination (the last few hops, the destination's own network) — issues here would specifically affect that destination (and perhaps others hosted in the same network/datacenter), while other destinations (with different hosting) would be unaffected

If a specific service is having issues, but traceroute to other, unrelated destinations looks completely normal — this is more consistent with an issue specific to that destination's network (#3) or possibly something specific to the path to that destination's network (#2, if that intermediate network is specific to routes toward that destination) — rather than a general local network issue (#1), which would be expected to affect traceroutes to multiple destinations similarly.

How to use the Traceroute tool on sadiqbd.com

1. For one-off path investigation: a single traceroute (the tool's core function) remains useful for understanding the general path and identifying any hops with notably high latency or obvious failures
2. For intermittent issues: recognize that a single "looks fine" traceroute doesn't rule out intermittent problems — running multiple traceroutes over time (during the period when issues are reported) provides more information than a single run
3. Compare traceroutes to multiple destinations: running traceroute to the problematic destination and to a different, unrelated destination, and comparing — helps localize whether an issue is general (affecting the shared early portion of both paths) or specific to the problematic destination's path

Frequently Asked Questions

If MTR shows 0% loss at every hop including the final destination, can I rule out network path issues entirely? This rules out loss on the outbound path, as measured by ICMP, at the time of the test. It doesn't rule out: return-path issues (asymmetric routing, as discussed), latency issues that don't manifest as loss (high but consistent latency might not show as "loss" but could still affect latency-sensitive applications), or issues that are intermittent and didn't occur during the specific test window. "0% loss in this MTR run" is meaningful information, but addresses a specific type of issue (outbound packet loss, at the time of testing) rather than all possible network-related causes.

Why do different traceroutes to the same destination, run minutes apart, sometimes show completely different paths? This can occur due to routing changes (a network along the path adjusting its routing — which happens for various operational reasons on the internet, sometimes frequently for some paths) or due to load balancing — some networks distribute traffic across multiple paths/links for the same destination, and different traceroute runs (or even different packets within the same run, depending on how load balancing is implemented relative to traceroute's TTL-incrementing packets) might be routed via different paths through such load-balanced segments, showing up as "different hops" for what's actually consistent load-balancing behavior rather than a "changing" path in a problem sense.

Is the Traceroute tool free? Yes — completely free, no sign-up required.

Try the Traceroute tool free at sadiqbd.com — map the network path to any host and identify latency at each hop.