ICMP, Ping & Traceroute
IP moves packets but says almost nothing when things go wrong. That feedback -
"host unreachable", "time exceeded", "here is my echo reply" - comes from a
companion protocol, ICMP, which also powers the two tools every network
engineer reaches for first: ping and traceroute.
ICMP: the network layer's messenger
The Internet Control Message Protocol (ICMP) carries error and diagnostic messages for IP. ICMP messages ride inside IP packets but are considered part of the network layer, because they report on IP's own behaviour. Each message has a type and code, for example:
| Type | Meaning | Used by |
|---|---|---|
| Echo Request / Echo Reply | Is this host alive and reachable? | ping |
| Time Exceeded | A packet's TTL hit 0 and was dropped | traceroute |
| Destination Unreachable | No route / port closed / host down | error reporting |
Ping: echo request and reply
ping tests basic reachability and latency. It sends an ICMP Echo Request to a
host; if the host is up and reachable, it returns an ICMP Echo Reply. The
round-trip time between them is the measured latency, and lost replies indicate
packet loss along the path.
Traceroute: exploiting TTL
Every IP packet carries a Time To Live (TTL) field. Each router that forwards the packet decrements the TTL by one; if the TTL reaches 0, the router drops the packet and sends an ICMP Time Exceeded message back to the source.
traceroute turns this failure mode into a mapping tool. It sends probes with
deliberately small, increasing TTLs:
- TTL = 1 - the first router decrements it to 0, drops the probe, and returns Time Exceeded. Its address is now known: that is hop 1.
- TTL = 2 - the probe survives the first router and expires at the second, which returns Time Exceeded. That is hop 2.
- ...and so on. Each larger TTL reveals one more router, one hop farther along.
- Eventually a probe reaches the destination, which does not return Time Exceeded but an Echo Reply (or a port-unreachable), signalling the end of the path.
The round-trip time of each reply is reported as the latency to that hop. Step through it below: each probe travels TTL hops, an ICMP reply comes back, and a new row is added to the traceroute output.
| # | Router | RTT | ICMP reply |
|---|---|---|---|
| 1 | gateway.local | 2 ms | Time Exceeded |
The RTTs generally grow with each hop because the probe travels farther. A sudden
jump can mean a long-distance link; a hop that never replies (shown as * * * in
real output) is usually a router configured not to send Time Exceeded, not
necessarily a broken path.
Worked example: reading real traceroute output
A traceroute from a home network in Boston to a server in Frankfurt sends three probes per hop (so transient jitter doesn't look like a trend) and reports the RTT of each:
| Hop | Router | Probe 1 | Probe 2 | Probe 3 |
|---|---|---|---|---|
| 1 | 192.168.1.1 (home router) | 1 ms | 1 ms | 1 ms |
| 2 | 96.120.10.1 (ISP edge) | 9 ms | 8 ms | 11 ms |
| 3 | 68.86.103.5 (ISP backbone) | 12 ms | 13 ms | 12 ms |
| 4 | * (no reply) | * | * | * |
| 5 | 80.239.132.29 (transatlantic link) | 78 ms | 79 ms | 81 ms |
| 6 | 203.0.113.9 (Frankfurt destination) | 80 ms | 80 ms | 82 ms |
The jump from ~12 ms at hop 3 to ~79 ms at hop 5 is the transatlantic hop
becoming visible - roughly 66 ms added by physical distance, consistent with a
one-way fiber path across the Atlantic. Hop 4 shows * * *: some router along the
way is configured to silently drop or deprioritize ICMP Time Exceeded rather than
send it, but the path is clearly still working, since hop 5 replies with a
sensible RTT that keeps climbing consistently from hop 3.
Many routers and firewalls apply rate limiting to ICMP messages (a common
DoS-mitigation default) - for example, allowing only a handful of Time Exceeded or
Echo Reply messages per second. Under that limit, a hop that is perfectly healthy
can show up as * * * for some probes and a normal RTT for others, because the
router is silently discarding the ICMP replies it doesn't have "budget" for, not
because packets are actually being lost. This is compounded by asymmetric
routing: the forward path your probes take and the reverse path an ICMP reply
takes can differ (common with multiple ISPs or ECMP load balancing), so a "slow"
or "lossy" hop in a traceroute may reflect congestion on the return path, not the
forward path your actual application traffic uses. Network engineers who
over-trust traceroute output as ground truth for "which link is failing" during an
incident can end up debugging the wrong router entirely - corroborating with
other tools (MTR's loss percentages over time, or direct interface counters on the
suspect router) avoids that trap.