Ping: the simplest active measurement there is
In the previous guide you saw the split between watching traffic that already exists (passive measurement) and injecting your own probe traffic to provoke an answer (active measurement). Ping is the canonical active probe and probably the first networking command you ever ran. The idea is almost childishly simple: send a tiny packet that politely asks "are you there?", and time how long the reply takes to come back. That round-trip time is the headline number ping reports.
Under the hood, ping does not use TCP or UDP at all. It rides on ICMP, the Internet Control Message Protocol — the network layer's own little messaging system for diagnostics and errors. Ping sends an ICMP "Echo Request" and the target, if it is willing, sends back an ICMP "Echo Reply" carrying the same payload. There is no connection, no three-way handshake, no sequence-number sync — just a request and an echo. Because ICMP sits right beside IP rather than on top of a transport protocol, ping is testing reachability at a very low level.
What ping gives you is two genuinely useful measurements at once. First, round-trip time, usually quoted in milliseconds: how long the there-and-back journey took. Second, packet loss: if you send 10 pings and only 8 replies come back, that is 20% loss — a strong hint that something on the path is dropping packets. Run ping for a while and you also see jitter, the variation in those round-trip times from probe to probe, which matters enormously for voice and video. Three numbers — delay, loss, variation — from one trivial command.
Reading the round-trip time honestly
Here is the first place beginners go wrong: round-trip time is a round trip, not a one-way delay. If ping reports 40 ms, the journey out and the journey back together took 40 ms. People often assume the one-way latency is exactly half, 20 ms, but that is only an estimate — the forward and return paths through the Internet are frequently different routes with different delays, a property called path asymmetry. Ping cannot see the two halves separately; it only ever sees the sum.
Next, remember what makes up that delay. The round-trip time is the sum of several pieces you met in the foundations rung: propagation delay (the time for the signal to physically travel the distance, bounded by the speed of light), transmission delay (the time to clock the bits onto the wire), and queuing delay (time spent waiting in buffers inside busy routers). The first is fixed by geography and physics; the last is what swells and swings when the network gets busy. So a ping that jumps from 40 ms to 200 ms under load is usually screaming queuing delay, not a longer road.
Traceroute: abusing the TTL on purpose
Ping tells you the destination is reachable and how far away it feels, but it says nothing about the road in between. Traceroute fills that gap: it reveals the sequence of routers — the hops — a packet passes through on its way to the destination. The brilliant part is that traceroute was never given any special permission to do this. It pulls off the whole trick by deliberately abusing a humble field in every IP datagram: the TTL, or Time To Live.
Remember what TTL is normally for. Every IP packet carries a small TTL counter, and every router that forwards it decreases that counter by one. The instant TTL hits zero, the router discards the packet and — crucially — sends an ICMP "Time Exceeded" error back to the source. This was designed purely as a safety valve so a packet caught in a routing loop dies instead of circling forever. Traceroute realised this safety valve could be turned into a flashlight: if you set the TTL low on purpose, you can make a packet die at a chosen router and force that exact router to identify itself.
- Send a probe with TTL set to 1. The very first router on the path decrements it to 0, drops the packet, and mails back an ICMP Time Exceeded. That error's source address tells you who hop 1 is, and the time it took is your round-trip time to hop 1.
- Send another probe with TTL set to 2. Now it survives the first router (which decrements it to 1) and dies at the second, which reports back. Hop 2 revealed.
- Keep incrementing the TTL — 3, 4, 5, ... — one hop deeper each time, collecting the address and timing of each successive router along the way.
- Stop when a probe finally reaches the destination itself, which replies differently (with a Port Unreachable or an Echo Reply, depending on the variant). The full list of hops is your traced path. Most tools send three probes per TTL, which is why you see three timing numbers on each line.
Why a traceroute is more fragile than it looks
A traceroute looks authoritative — a clean numbered list of routers — but it is full of honest caveats, and reading it wrongly is one of the most common mistakes in network diagnosis. The first surprise: the per-hop times often look weird, with a middle hop showing a higher round-trip time than a later one. That does not mean the path doubled back. It happens because generating an ICMP Time Exceeded is low-priority busywork for a router; a busy core router may dawdle before answering its own TTL-expiry probe even while it forwards your real traffic at full speed. A slow-replying hop is not necessarily a slow hop.
The second caveat is path instability. Modern networks spread traffic across several equal-cost links for load balancing, so probe number two with TTL 5 may take a different route than probe number one with TTL 5. The result is a traceroute that can show different routers at the same hop, or even an apparent path that no single packet ever actually took. Add to this that the return path of every Time Exceeded message can differ from the forward path, so the times you see blend two directions that traceroute can never disentangle.
Third, silence is not the same as failure. Many routers and firewalls are configured to rate-limit or simply not send ICMP at all, so a hop may show up as three asterisks — a timeout — while traffic flows through it perfectly. Beginners panic at the asterisks and declare "the problem is at hop 7," but more often hop 7 is just a quiet router that declines to chat. The honest reading is: traceroute shows you a plausible path and rough per-hop delays, not a guaranteed, stable, bidirectional map.
Where they fit, and where they stop
Used together, ping and traceroute form a beautifully cheap first-look toolkit, and they pair naturally. A common workflow: ping the destination and notice loss or a fat round-trip time, then run a traceroute to see roughly where the path gets long or starts dropping. If the round-trip time stays small for the first six hops and then jumps at hop seven and stays high, that jump is a strong candidate for where the trouble — perhaps a congested link or a bottleneck — actually lives.
One last layer of humility. Because these tools lean entirely on ICMP, they show you what the network is willing to admit, not necessarily the truth. Routers de-prioritise ICMP, firewalls filter it, and load balancers scatter it — so treat ping and traceroute as a quick, revealing sketch, not a courtroom transcript. When the sketch raises real questions, the next rung's heavier tools — capturing actual packets with tools like Wireshark and pinning down latency-versus-throughput precisely — are where you go to get the answer. Start cheap, escalate deliberately.