Online traceroute

A worked example

Here is a simplified traceroute from a server in Europe to a website in the United States:

 1  10.0.0.1              0.4 ms   (our data centre gateway)
 2  core1.fra.example.net 1.1 ms   Frankfurt
 3  ae-5.ldn.carrier.net  12.8 ms  London
 4  * * *                          (no reply)
 5  ae-2.nyc.carrier.net  79.4 ms  New York
 6  edge.target-host.com  81.0 ms  destination

• Hops 1–3 add latency gradually as the packets cross Europe.
• Hop 4 shows asterisks. That router simply does not answer traceroute probes. Because hop 5 and later still respond, nothing is wrong.
• The big jump between London and New York (about 67 ms) is the transatlantic cable – expected, not a problem.
• The final hop is the destination. Latency stays level after the jump, which means the path is healthy.

Spotting a real problem

• Latency jumps at one hop and stays high for every hop after it. That link is congested or long. If the jump is between two cities close together, it is worth reporting.
• A single hop shows high latency but later hops are normal. Ignore it – routers answer traceroute at low priority while still forwarding traffic quickly.
• Every hop after a certain point is * * * and the destination never appears. Traffic is being dropped there, or a firewall at the destination blocks probes. Check with a browser before concluding the site is down.
• The same hops repeat in a loop. A routing loop – rare, and something only the network operator can fix.

Using the network names

Router hostnames often contain city or airport codes (fra Frankfurt, ams Amsterdam, lhr or ldn London, sin Singapore, nyc New York) and the carrier’s name. Together with the network (AS) column, this tells you which provider’s network a problem is in, which is exactly what their support team will ask for. Look up an unfamiliar network with our WHOIS lookup.

Want to go deeper? Read How to read ping and traceroute results.