Reading a traceroute
Traceroute is the most misread tool in networking. Most “look at hop 7” reports are describing something that is not a problem at all.
The three things people get wrong
- A middle hop with high latency or loss is usually fine. Routers generate ICMP replies at low priority on a management processor. A hop showing 200 ms while the hops after it show 20 ms is not congested; it is busy doing its actual job.
- Loss only matters if it continues to the end. 40% loss at hop 6 and 0% at hop 12 means hop 6 was rate-limiting its replies. If loss starts at hop 6 and persists to the destination, now you have something.
- The return path is invisible. Traceroute shows the way out. The way back can be completely different, and the problem is frequently there. This is why one-sided traces so often lead nowhere.
Use MTR instead
mtr -rwzbc 100 destination
A hundred packets per hop, resolved names and AS numbers, as a report. That gives you a loss and latency distribution rather than three samples, and the AS numbers tell you whose network each hop belongs to — which is the information that actually determines who can fix it.
Run it from both ends
This is the single most useful thing you can do. A trace from your server to the user, and one from the user back to your server. Asymmetric routing is normal on the internet, and without both halves nobody can tell which direction is at fault.
If the user cannot run one, a looking glass on their network or their provider's serves the same purpose.
What a real problem looks like
- Loss that begins at a hop and continues to the destination, consistently, over many packets
- Latency that steps up at one hop and stays up, especially at a predictable time of day — that is congestion on a link
- A path that goes somewhere geographically absurd for the destination
- Routes that change repeatedly during a single test
What to send us
Open a ticket with:
- MTR from your server to the destination, 100 packets
- MTR from the destination back to your server, same
- The addresses at both ends and the time it was taken, with timezone
- Whether it is constant or at particular hours
With that, we can look at it properly. The network is ours, so if a path is bad we can often change it — see routing problems. With a single screenshot of a trace and no return path, we can mostly only ask you for the rest.
And check it is the network at all
A slow site with a clean path is a server problem, not a routing one. Confirm with speed testing and diagnosing a slow server before concluding it is the route.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base