TTL as a diagnostic instrument

Time to live exists to stop packets circulating forever. Each router decrements it, and at zero the packet is discarded. That is its job. Its side effect is that the value you receive tells you how far away the sender is, and that turns out to be diagnostically useful.

Counting hops from a single packet

Operating systems use predictable initial values: Linux and most modern systems 64, Windows 128, many network devices 255. Receive a packet with TTL 60 and you can reasonably infer a Linux sender four hops away.

ping -c1 host | grep ttl
tcpdump -ni eth0 -v host 10.1.1.5 | grep -o 'ttl [0-9]*'

What you can spot with it

If replies from one address arrive with two different TTLs, two different devices are answering. That is either load balancing or a duplicate address, and both are worth knowing.

If the TTL changes after a network change, the path length changed. A failover that should have been transparent but added three hops will show here even when everything still “works”.

If a device that should be one hop away replies with TTL 64 when you expected 255, it may not be the device you think it is.

How traceroute uses it

Traceroute is TTL used deliberately: send with TTL 1 and the first router replies with time-exceeded, revealing itself. TTL 2 reveals the second. Understanding that explains traceroute’s limitations — it maps the forward path only, each probe may take a different route, and a device that does not generate ICMP simply shows as a row of asterisks without being broken.

Why bother

It costs nothing. You are already looking at the packet. Reading the TTL turns one observation into two, and on a network where you cannot get access to every device, inference from what arrives is sometimes all you have.