Testing the Path: ping and traceroute/tracert — What They Actually Prove

Both tools in this chapter have already made cameo appearances — Chapter 1's timed-out ping, Chapter 3's gateway ping. This chapter goes deeper on what they're actually doing under the hood, because a surprising amount of wasted diagnostic time comes from treating a ping reply as proof of more than it actually proves, or reading a broken-looking traceroute as more conclusive than it really is.

What Ping Actually Tests

ping sends an ICMP echo request and waits for an ICMP echo reply. That's the entire test — it says nothing directly about whether any actual service on that machine is working. A web server can be completely healthy and serving every request correctly while its host doesn't answer ping at all (ICMP disabled by policy, same as Chapter 3's gateway example); equally, a host can answer ping instantly while the one service you actually care about has crashed. Ping tests reachability at the network layer, not health at the application layer — conflating the two is one of the most common false conclusions in network troubleshooting.

Reading Ping Output In Depth

• Packet loss % — the single most important summary line; any sustained loss above 0% on a healthy path is worth investigating further, even if most packets get through
• Round-trip time (min/avg/max) — high or wildly varying latency (a large gap between min and max, called jitter) can point toward congestion somewhere on the path, even when every packet technically arrives
• TTL in the reply — a rough hint at how many hops away the destination is; a TTL value much lower than expected for a "local" destination can be a sign traffic is taking an unexpectedly long path

Traceroute: Watching the Path Hop by Hop

Where ping only reports the final result, traceroute (Linux/macOS) and tracert (Windows) reveal every router along the way. The mechanism is a genuinely clever trick with a packet's TTL field: the first probe is sent with TTL set to 1, so the very first router along the path decrements it to 0 and sends back an ICMP "time exceeded" message — revealing itself — instead of forwarding the packet further. The next probe uses TTL 2, revealing the second router, and so on, one hop further with each round, until a probe finally reaches the actual destination.

Reading Traceroute Output

Each numbered line is one hop, with up to three round-trip times from three separate probes sent to it. Hop 3 shows three asterisks — no response at all from that specific router — yet hop 4 responds normally and the trace reaches the actual destination at hop 5. That's a genuinely common, non-broken pattern: many routers are configured to rate-limit or simply not generate the ICMP "time exceeded" messages traceroute depends on, even while forwarding the actual traffic through them perfectly normally.

What Neither Tool Proves

Two honest limits worth carrying into every later chapter. First, neither tool says anything about the application layer — a perfect ping and a clean traceroute both stop exactly at "the network path works," which is Chapter 6 and 7's job to build on, not this chapter's. Second, the path a traceroute reveals is only the outbound path — return traffic can genuinely take a different route back (asymmetric routing is common on real networks), so a trace that looks broken partway through doesn't necessarily mean the return path is broken in the same place, or at all.

Working Example: Continuing the Ticket

Chapter 4 confirmed the correct IP is 203.0.113.42 once the user's DNS cache issue was accounted for. A ping directly to that IP now returns clean, consistent replies with 0% loss — network reachability confirmed. A traceroute shows one silent hop partway through, but reaches the destination normally, consistent with this chapter's own "silent hop, normal arrival" pattern rather than a real problem. The ladder moves to Chapter 6: with the network path confirmed healthy, is the actual application port open and accepting connections?

Hands-On Exercises