How to Read MTR Results — Column by Column

Back to Help

Reading MTR Results

How to interpret hop-by-hop MTR output — understanding packet loss, latency patterns, and what asterisks really mean.

8 min read · Last updated Feb 2026

What is MTR

MTR (My Traceroute) provides a hop-by-hop view of how packets travel across the network from the test server to your device. It combines the functionality of traceroute and ping to show latency, packet loss, and path stability at each intermediate router.

Understanding how to interpret these results helps identify where connectivity issues may be occurring.

Example MTR output showing common patterns
HopHostLoss %AvgBestJitter
1192.168.1.10.0%1 ms1 ms0.2 ms
2isp-gw-01.example.net0.0%4 ms3 ms0.5 ms
3core-rtr.transit.net8.0%12 ms11 ms1.1 ms← ICMP rate limiting
4border.transit.net0.0%14 ms13 ms0.8 ms
5* * *← No response
6peering.cdn.net0.0%45 ms42 ms2.1 ms← Latency jump (geographic)
7edge.destination.com0.0%46 ms43 ms1.9 ms

This example shows several common patterns. Each is explained in detail below.

Loss at a Single Hop (But Not Beyond)

0% lossHop 10% lossHop 28% lossHop 30% lossHop 40% lossHop 5 (you)ICMP rate limiting(not real loss)

If you see packet loss at one hop, but the following hops show little or no loss, this usually does not indicate a real problem.

Many routers intentionally limit or deprioritize ICMP responses to reduce load. This behavior is called ICMP rate limiting. The router may drop probe replies while still forwarding actual traffic normally.

Verdict: Typically harmless. Loss at one hop only — with clean hops after it — is almost always ICMP rate limiting, not a real network problem.

Persistent Loss Across All Subsequent Hops

0% lossHop 10% lossHop 25% lossHop 36% lossHop 45% lossHop 5 (you)Real problem here(loss continues onward)

If packet loss begins at a specific hop and continues for every hop after that — including the final destination — this strongly suggests a real issue at or near that point in the network path.

Possible Causes

  • Congestion at an ISP or transit network
  • Overloaded router
  • Physical link problems (damaged cable, failing hardware)
  • Routing instability

Verdict: Likely a real problem. Persistent loss from one hop onward is a strong indicator of a genuine network issue. If this hop belongs to your ISP, contact them with the MTR output.

Sudden Increase in Latency Between Hops

4msHop 1Local
8msHop 2ISP
12msHop 3ISP
14msHop 4ISP
45msHop 5CDN
46msHop 6Dest
↑ Geographic distance (cross-country link)

A noticeable jump in latency between two consecutive hops often indicates a longer geographic distance between those network segments.

SegmentTypical LatencyWhat It Means
Local network → ISP edge1–5 msShort physical distance
ISP → cross-country backbone15–40 msData crossing states/regions
Cross-continent links60–150 msUndersea cables, satellite, long fiber runs

This is normal behavior and reflects physical distance and routing paths rather than a fault.

Verdict: Expected behavior. A one-time latency jump between hops is usually geographic distance — not a problem. Only investigate if latency increases and stays elevated at every subsequent hop, which could indicate congestion.

Asterisks (* * *) in Results

0% lossHop 10% lossHop 2* * *Hop 30% lossHop 40% lossHop 5 (you)Router silent(ICMP blocked — normal)

If a hop shows asterisks (* * *), it means that router did not respond to probe packets. This is common and does not necessarily indicate packet loss.

Many routers are configured to ignore ICMP probes, block diagnostic traffic, or limit responses for security reasons.

If later hops and the final destination respond normally, this is considered expected behavior.

Verdict: Usually normal. Missing responses at intermediate hops are common. Only concerning if the final destination also shows asterisks or loss.

Testing to Your Device Using UDP and NAT Traversal

How Our Hop-by-Hop Test Works

Your Browser
WebRTC DataChannel
Test Server
1WebRTC establishes UDP connection
2STUN discovers your public IP:port
3Server runs MTR toward your IP
4Results stream back via WebSocket

When you run a hop-by-hop test to your own connection, the platform uses UDP-based probing through WebRTC and STUN. This process temporarily opens a NAT mapping (public IP and port) on your network, allowing the test server to send probe packets back toward your device.

Why This Approach is Better

🔄

Real Traffic

Uses UDP behavior similar to real application traffic

🏠

NAT Friendly

Works through NAT environments in home and office networks

📊

Unique View

Measures path from internet toward YOUR connection

What It Measures

Using this NAT-assisted UDP method, the system estimates hop-by-hop:

Latency— time to each hop
Jitter— variation at each hop
Packet Loss— drops at each hop

This provides a unique view of how traffic reaches your connection and helps identify issues that may occur within ISP networks or along the route between your location and the broader internet.

Quick Reference Table

What You SeeSeverityWhat It Means
Loss at one hop only, following hops are cleanNormalICMP rate limiting. The router drops probe replies but forwards traffic fine.
Loss starting at one hop and continuing to all hops afterIssueReal network problem at or near that hop. Likely congestion, hardware, or routing issue.
Sudden latency jump between two hops, stable afterwardNormalGeographic distance between those network segments.
Latency increases and stays elevated for all remaining hopsWatchPossible congestion. Monitor over time. May resolve during off-peak hours.
* * * at intermediate hops, final destination respondsNormalRouter configured to not respond to probes. Traffic still passes through.
* * * at final destinationIssueDestination unreachable or blocking all probe traffic. Possible outage.
High jitter at one hopWatchRouter under intermittent load. Check if it affects application performance.

Ready to trace your network path?

Run the UDP packet loss test first, then use the hop-by-hop analysis to see exactly where issues occur.