Have you ever run an MTR, seen 40% packet loss on a router halfway to
your destination, and assumed you had found the culprit?
Often, you haven't. One of the most common mistakes in network
troubleshooting is treating the first unusual number as the root cause.
This guide explains how traceroute and MTR work, how to interpret their
output, and how to avoid blaming the wrong hop.
1. What Does Traceroute Actually Tell You?
Traceroute identifies the intermediate network hops between your device
and a destination.
traceroute example.com
On Windows:
tracert example.com
A typical result looks like this:
1 192.168.1.1 1.2 ms
2 10.20.0.1 8.4 ms
3 203.0.113.10 18.7 ms
4 * * *
5 198.51.100.20 42.1 ms
Each numbered line represents a hop. The time shows how long it took to
receive a response to a probe from that hop. * * * means no response
arrived before the timeout; it does not automatically mean that the
hop is dropping forwarded traffic.
Traceroute has two important limitations:
- A single run is only a snapshot. Congestion, routing changes, and wireless interference can produce different results from one run to the next.
- It does not reveal the full return path. The route taken by replies from a hop back to your device may differ from the outbound path. A slow response from an intermediate hop does not necessarily mean that ordinary traffic is being forwarded slowly.
2. Why MTR Is More Useful for Troubleshooting
MTR combines traceroute-style path discovery with repeated measurements.
Instead of collecting only one response per hop, it repeatedly probes
the route and accumulates statistics.
Common metrics include:
- Loss%: The percentage of probes to that hop that did not receive a response.
- Last: The most recent response time.
- Avg: The average response time.
- Best / Wrst: The lowest and highest response times.
- StDev: A measure of how much response times vary.
These numbers help you ask better questions. Is latency consistently
high or only occasionally high? Does response-time variability appear at
a particular hop? Does apparent loss continue all the way to the
destination?
For a shareable text report from a desktop, try:
mtr -rw -c 100 example.com
Here, -r prints a report, -w uses wide output, and -c 100 runs 100
probe cycles. Options for displaying IP addresses or ASN information
vary by MTR version; consult the installed version's manual if you want
to include them.
3. How to Interpret MTR Results Correctly
Consider this simplified example:
Host Loss% Avg
Gateway 0% 1.5 ms
Router A 0% 8.2 ms
Router B 35% 12.4 ms
Router C 0% 18.6 ms
Destination 0% 25.1 ms
Router B shows 35% probe loss, but the later hops and destination show
none. This pattern is more consistent with ICMP response rate limiting
or deprioritization than with end-to-end packet loss. Many routers
prioritize forwarding traffic over responding to diagnostic probes, so
they may ignore or delay some replies while continuing to forward
ordinary traffic.
However, this is a diagnostic clue, not definitive proof. Probe
behavior, return paths, and load balancing can complicate the results.
Scenario A: Loss appears at one intermediate hop only
Loss appears at one intermediate hop, while later hops and the
destination are clean. ICMP response rate limiting or deprioritization
is one likely explanation. Do not conclude that the router is faulty
based on that hop alone.
Scenario B: Loss continues to the destination
Compare the previous result with this example:
Host Loss% Avg
Gateway 0% 1.5 ms
Router A 0% 8.2 ms
Router B 22% 12.4 ms
Router C 21% 18.6 ms
Destination 23% 25.1 ms
Here, loss begins at Router B and remains visible through subsequent
hops and at the destination. That pattern deserves closer investigation.
Repeat the test at different times and check whether real application
traffic is affected.
Even this pattern does not, by itself, prove that Router B is the cause.
It identifies a point from which further investigation is warranted.
Scenario C: Latency rises and stays high
Response times are low for the first few hops, then increase and remain
elevated. This may point to a longer-distance segment, congestion, or a
routing change. It is a useful lead, not proof of a fault at the first
hop where the increase appears. Remember that response times from
intermediate hops can be affected by their return paths and by how they
prioritize diagnostic traffic.
The key principle: diagnose patterns across the path, not isolated
numbers.
4. A Practical Workflow
Step 1: Establish a baseline. Run a trace to a known destination and
record the route and typical latency.
Step 2: Repeat the measurement. Multiple rounds help distinguish
persistent behavior from short-lived variation.
Step 3: Check the first few hops. If latency or loss appears near
your gateway, investigate Wi-Fi, cabling, and your router. If the local
path looks stable, continue upstream.
Step 4: Compare the suspicious hop with the hops after it. A hop
that fails to answer probes is not necessarily dropping forwarded
traffic.
Step 5: Try a different probe type. Some networks treat ICMP
differently from TCP or UDP. If you suspect ICMP is being limited, try a
TCP-based test toward the port your application actually uses:
mtr -T -P 443 -rw -c 100 example.com
This example uses TCP probes toward port 443. If TCP-based MTR shows no
loss while ICMP-based MTR shows loss, that supports the ICMP
rate-limiting hypothesis, but does not prove it. Different probe types
may follow different ECMP paths or be treated differently by firewalls
and network devices. TCP mode and supported options can also vary by MTR
version.
Step 6: Match the results to the symptom. If SSH sessions drop or an
app slows down, check whether the timing lines up with the trace.
Application logs and other targeted tests can provide additional
evidence.
Step 7: Save the results. Recorded reports make it easier to spot
recurring patterns and explain the problem to an ISP or colleague.
This workflow applies to home networks, cloud servers, remote
administration, and homelabs.
5. Running MTR from an iPhone or iPad
Desktop tools are excellent for deep diagnostics, but problems do not
always happen next to a laptop. You might be at a customer site, using
guest Wi-Fi, or away from your desk and need a quick answer: is the
problem local, or is it farther upstream?
That is why I built Visual MTR: Traceroute, a native iOS and iPadOS
app for route tracing and path analysis.
Free
- IPv4 and IPv6 route tracing
- Per-hop IP addresses and response times
- Adjustable hop limit and probe timeout
- Offline IPv4 and IPv6 ASN lookup, so you can see which network each hop belongs to
- Up to three configurable DNS servers
Pro Lifetime --- one-time purchase, no subscription
- Multi-round MTR with independent statistics for each round
- Minimum, average, and maximum RTT, plus RTT variation
- RTT trends and hop-by-round heatmaps
- Visual ASN route topology
- Unlimited saved diagnostic history
- PDF, JSON, and text report export
These Pro features map directly to the workflow above. Multiple rounds
and heatmaps help distinguish a one-off spike from a persistent pattern
(Steps 2 and 4), while report export makes it easier to save evidence
and share it (Step 7).
Diagnostic history stays on your device, and ASN lookup works offline
without a cloud account. One important caveat: ASN country labels
reflect registration data, not necessarily the physical location of a
router.
6. Try Visual MTR
A route trace tells you where your probes travel. Repeated measurements
help you understand how the path behaves. The difference between those
two is the difference between guessing and troubleshooting.
A route trace tells you where your probes travel. Repeated measurements help you understand how that path behaves. The difference between those two is the difference between guessing and troubleshooting.
Try Visual MTR: Traceroute for iPhone and iPad.
https://apps.apple.com/us/app/visual-mtr-traceroute/id6821332849
Top comments (0)