Use ICMP, ping, and traceroute

ICMP carries control and error information for IP. It’s not a protocol applications use to move data; it’s how the network itself reports what happened. Echo Request and Echo Reply messages power ping. Time Exceeded messages help traceroute reveal hops.

ping 192.0.2.1
traceroute 203.0.113.10

Reading ping output

Try a real destination and let it run a few rounds:

ping -c 4 1.1.1.1

64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=9.6 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=10.2 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=9.8 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=48.1 ms

4 packets transmitted, 4 received, 0% packet loss

Three fields matter. icmp_seq numbers the probes — gaps mean lost packets. time is the round trip; steady values mean a healthy path, and a jump like that last 48.1 ms means queuing or congestion somewhere. The summary line gives you the loss percentage, the single most useful number for “is this path reliable?”

What ping does and doesn’t prove

A successful ping shows that a particular ICMP exchange worked. It does not prove that a TCP application port is open — a server can answer ping perfectly while its web server is crashed.

A failed ping does not prove the host is down either, because a firewall may filter echo messages. Plenty of production servers deliberately ignore ping. Absence of a reply is weak evidence; treat it as “ICMP is filtered or the host is down”, not as a verdict.

Reading traceroute output

traceroute -n 1.1.1.1

 1  192.168.1.1    2.0 ms   1.8 ms   1.9 ms
 2  100.64.12.1    8.9 ms   9.1 ms   8.7 ms
 3  * * *
 4  141.101.67.40  10.3 ms  10.1 ms  10.4 ms

Each line is a router that returned a Time Exceeded error, with three timing probes. The -n flag skips reverse DNS so the output is faster and cleaner.

Line 3 is the classic trap: * * * means that router didn’t answer traceroute probes, not that the path is broken there. Traffic clearly continued, because hop 4 answered. Traceroute output can contain missing hops or changing routes — paths can even differ between packets.

Treat it as path evidence, not a perfect map. Combine it with routes, port tests, and application-specific checks before drawing conclusions.