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