Configuration and routing

Use ICMP, ping, and traceroute

Use ICMP feedback without treating ping or traceroute as a complete test of application health.

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?”

-c 4 stops after four probes. Without it, ping on Linux keeps going until you press Ctrl-C.

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.

Lesson completed