Ping and traceroute: How route tracing actually works

When something looks wrong with your server's network, ping and traceroute are the two tools you'll reach for first. Understanding how they work is what lets you tell "slow" apart from "down" — and pinpoint where the trouble lives.

ping: reachability and RTT

ping sends an ICMP Echo Request to a target; the target replies with an Echo Reply. The tool measures the time between sending and receiving — the round-trip time (RTT) — and tracks packet loss.

# Linux: sends continuously until you press Ctrl+C
ping your-server.example.com
ping -c 4 203.0.113.10        # send just 4 packets

# Windows: sends 4 packets by default
ping your-server.example.com
ping -t 203.0.113.10          # send continuously, Ctrl+C to stop

Focus on three things: whether replies come back at all (reachability), the time= value in milliseconds (latency), and the loss summary at the end. A steady RTT with zero loss usually means a healthy path.

traceroute: mapping the path hop by hop

ping only shows the end-to-end picture. traceroute reveals every hop — every router — a packet crosses on the way.

The trick is TTL (Time To Live). Every router that forwards an IP packet decrements its TTL by one; when the TTL hits zero, that router drops the packet and returns an ICMP Time Exceeded message. traceroute exploits this:

• First it sends a probe with TTL=1 → the first router replies with Time Exceeded, exposing hop 1;
• Then TTL=2 → hop 2 is revealed;
• It keeps incrementing until the probe reaches the target or hits the maximum hop count.

Linux vs Windows

# Linux: default probes are UDP (some builds use ICMP, or add -I)
traceroute your-server.example.com

# Windows: different command name, and probes with ICMP Echo by default
tracert your-server.example.com

The difference is the probe protocol: Linux traceroute defaults to UDP, while Windows tracert uses ICMP. Because intermediate devices treat protocols differently, the two can report slightly different paths and timings.

Reading the per-hop output

Each hop typically shows three latency samples (three probes by default) alongside the hop's IP. A few things to keep in mind:

• The symbol: no reply came back for that probe. The hop may be configured not to respond, a firewall may be filtering it, or the probe/reply was simply dropped. A stray doesn't mean the path is broken — as long as later hops still answer, you're fine.
• A middle hop spikes, then latency drops again: this is usually not a problem. Routers commonly apply ICMP rate limiting to control messages like Time Exceeded, prioritizing real traffic and delaying their reply to traceroute. What matters is the latency at the final hop (the destination) — and whether latency climbs from some hop onward and never recovers.
• Spotting real loss: don't judge a hop by its own ; look at whether the hops after it also drop. Loss at a middle hop but a clean final hop is almost always rate limiting. Loss that starts at one hop and persists all the way to the end is what points to a genuine fault.

mtr: ping and traceroute combined

mtr merges the two: it continuously probes every hop along the path and refreshes each hop's loss rate and latency in real time.

mtr your-server.example.com
mtr -r -c 100 your-server.example.com   # run 100 cycles, then print a report

Unlike a one-shot traceroute, mtr samples over time, which makes it far more reliable at surfacing intermittent loss and jitter. It's the go-to tool for diagnosing line quality.

Summary

ping uses ICMP to test reachability and RTT — a quick answer to "is it up, and is it fast?" traceroute/tracert uses an increasing TTL to expose the path hop by hop, with Windows probing over ICMP and Linux defaulting to UDP. When reading the output, remember that marks and high latency on middle hops often come from ICMP rate limiting and aren't cause for alarm — focus on the final hop's latency and on sustained loss. When you need to watch line quality over time, reach for mtr, which combines the strengths of both.