5.3Basic diagnostic commands and interpreting results

Against a complaint of "no connection," the first hands-on way to gather facts is the basic diagnostic commands. ping, ipconfig/ifconfig/ip, tracert/traceroute, and nslookup—available on every OS—each check a different layer and viewpoint. What matters is less being able to type the command than how you read the result. In particular, when a firewall blocks specific traffic, a command may display "failure" while the host is in fact reachable—a discrepancy. This section covers when to use each command and the correct interpretation, including such result pitfalls.

5.3.1When to use each staple command

• ping checks L3 reachability to a target using ICMP. If a reply returns, you also see the round-trip time (RTT). It is the first move to see "does it even reach?" Pinging an IP like ping 8.8.8.8 separates out the effect of name resolution.
• ipconfig (Windows) / ifconfig and ip (Linux/mac) show your own IP settings (IP address, subnet mask, default gateway, etc.). Use them first to check "do I even have a correct IP?" and "is the gateway set?"
• tracert (Windows) / traceroute (Linux/mac) trace the path (hops) one by one to a destination. Seeing which router it reaches and where it stops narrows down "where along the way it is broken." nslookup checks whether name resolution (DNS)—host name to IP—works correctly.

5.3.2Interpreting results and the effect of firewalls

• If a firewall blocks ICMP, ping times out (fails) even when the target is healthy. So "ping fails" does not necessarily mean "down." A web server replying on 443 but not to ping is a classic case.
• The symptom "reachable by IP but not by name" (ping 8.8.8.8 works but ping example.com fails) points to a name-resolution (DNS) problem, not reachability. Here nslookup isolates whether DNS resolves.
• tracert/traceroute may show just that hop as * (no reply) if a router along the way is set not to return ICMP—yet that is not necessarily a fault. The essence of interpretation is to not take a "failure" display at face value and to judge together with other means.

A user reports "I cannot reach the new internal web server." You first ping the server, but there is no reply and it times out. Concluding "ping fails, so the server is down" is a classic interpretation error, because many servers and firewalls deliberately block responses to ICMP (the protocol ping uses) for security. So next you check whether the actual service, HTTPS (TCP 443), works via a browser or another means, and the web page opens fine—meaning the server is up and ping failed only because a firewall was stopping ICMP. Consider another case. If a user says "ping 8.8.8.8 works but ping internal-server-name fails," reachability itself is alive and the suspect is the host-name-to-IP conversion—name resolution (DNS). Running nslookup internal-server-name to see whether a correct IP returns isolates whether it is a DNS problem. Further, if "it goes partway but breaks beyond a certain site," you use tracert/traceroute to see which hop it stops at. Consistently, the key is to not swallow a command's "failure" whole, but to corroborate why that result occurred with another means. Rather than jumping on the result of a single ping, combine commands of different viewpoints to build up facts—ipconfig for your own settings, nslookup for name resolution, tracert for the path—which is the diagnostic manner worth acquiring even at the introductory stage.

5.3.3Section summary

• ping = ICMP reachability, ipconfig/ifconfig/ip = local IP settings, tracert/traceroute = path, nslookup = DNS resolution—each a different viewpoint
• A firewall blocking ICMP can make ping fail while still reachable—do not take a failure display at face value
• Reachable by IP but not by name is a DNS problem—combine commands of different viewpoints to build up facts