Using Traceroute to Find Where a Connection Slows Down

Step-by-step

1. 1

   Run a trace to the destination

   Enter the host you are trying to reach in the Traceroute Tool, using either a hostname or an IP. A hostname is usually more useful because the reverse DNS on each hop hints at which network you are crossing. Let the full trace finish before you interpret anything; the last few hops are what matter, and they only appear at the end. Run it two or three times, because routing and load change minute to minute and a single trace can be misleading.

2. 2

   Understand how TTL probing builds the path

   Traceroute does not have a magic list of routers. It sends packets with a Time To Live of 1, which the first router decrements to 0 and drops, replying with an ICMP Time Exceeded that reveals its address. Then it sends TTL 2 to reach the second router, TTL 3 for the third, and so on. Each row you see is one router confessing its identity because a probe expired on it. That is also why traceroute is fragile: it depends on routers being willing to send those expiry messages back to you.

3. 3

   Read the three timings per hop

   Most tools send three probes per hop, so you see three round-trip times. Look at the pattern, not a single number. Three tight values like 24, 25, 24 ms mean a stable link. Wildly scattered values like 12, 480, 14 ms usually mean one probe hit a busy router control plane, not that the link is bad. Read the times as a trend down the list: they should climb roughly as you move outward, and the number you care about is the one at your actual destination.

4. 4

   Ignore the scary middle hop that recovers

   This is the single most misread thing in traceroute. You will often see hop 6 sitting at 300 ms while hop 5 and hop 7 are both at 30 ms. That is almost never a problem. Routers treat ICMP Time Exceeded generation as the lowest-priority work they do; a busy core router answers your probe slowly while forwarding real traffic at full speed. If the latency spikes at one hop and then drops back down at the next, the high number was an artifact of that router's control plane, not congestion on the path.

5. 5

   Treat asterisks as filtered, not down

   A row full of asterisks means no reply came back within the timeout. It almost never means that router is offline. Plenty of networks rate-limit or drop ICMP Time Exceeded for security or policy reasons, so the hop stays silent while still forwarding your traffic perfectly. The proof is simple: if hops after the stars answer again, packets clearly passed through the silent router. Only treat missing replies as a real failure when the trace goes dark at one hop and never recovers all the way to the destination.

6. 6

   Find the latency jump that persists

   The real signal is a step up in latency that stays elevated for every hop afterward, all the way to the destination. If hops 1 to 8 sit near 20 ms and hop 9 jumps to 160 ms and hops 10, 11, 12 all stay near 160 ms, hop 9 is where your traffic crossed something expensive, often a congested peering link or a long-haul submarine leg. That sustained jump is the bottleneck. The isolated spikes that recover are noise; the plateau that holds is where you focus.

7. 7

   Account for asymmetric routing

   Every round-trip time includes the return path, and the return path can be completely different from the outbound one. So a hop can look slow purely because the reply took a scenic route home, even though your packets reached it quickly. This is why a traceroute from you to a server and the reverse trace from the server to you often disagree. When you are diagnosing a problem with a provider, capture both directions; the outbound trace alone can point the finger at the wrong network.