How do ping's and tracert's echo requests differ at the protocol level?
They send the same ICMP Echo Request, but tracert deliberately uses a low TTL to provoke errors from routers along the way. ping always uses the OS-default TTL.
* Same Echo Request, opposite intent — tracert's low TTL vs ping's high TTL. *
ping echo request:
ICMP Type 8 (Echo Request)
TTL = 64 (Linux) or 128 (Windows) — the default
Goal: reach the destination, get an Echo Reply back
tracert echo request:
ICMP Type 8 (Echo Request)
TTL = 1, then 2, then 3, ... — incrementing per probe
Goal: NOT reach the destination — provoke "Time Exceeded" errors from each hop
The same payload, opposite intent:
| Aspect | ping | tracert |
|---|---|---|
| ICMP type | 8 (Echo Request) | 8 (Echo Request) |
| TTL | High (default) | Low, incrementing |
| Wanted reply | Type 0 (Echo Reply) | Type 11 (Time Exceeded) |
| What it tests | Reachability | Path |
Why this is elegant:
Tracert didn't need a new protocol — it just creatively misuses the existing TTL+ICMP combo. The "errors" routers send back become the diagnostic data.
Tip: This is a classic example of "the network was designed for one purpose, but exposes useful diagnostic side effects." Many security techniques (port scanning, OS fingerprinting) similarly repurpose normal protocol behaviors.
Go deeper:
Time to live (Wikipedia) — the IP TTL hop-counter that tracert deliberately sets low to provoke errors.- Traceroute (Wikipedia) — the incrementing-TTL technique and the Time Exceeded replies it harvests.