Instruction 05-network-troubleshooting-tools-and-methodology: Reading

Effective network troubleshooting is a process of reducing uncertainty, not a process of trying random fixes. Begin by recording the exact symptom, the source host, the intended destination, the protocol, the port, the time, and what success should look like. A statement such as “the network is down” is too broad. A statement such as “an HTTP request from this host to 127.0.0.1 port 18081 is refused immediately” is testable.

Work through the path in layers. First confirm local interface state and addressing with ip address. Next ask the kernel how it would reach the destination with ip route get DESTINATION; this is usually more useful than merely reading the entire route table because it reveals the selected interface and source address. If a hostname is involved, test resolution separately with getent ahosts NAME. This follows the host's configured name-service path and helps distinguish name lookup from packet delivery. A name resolving successfully does not prove that an application is available, and a successful ping does not prove that a TCP port is open.

At the transport layer, identify whether a service is actually listening with ss -lntp. Address scope matters: a process bound only to 127.0.0.1 can be reached locally but not through a different host interface. A process may also be healthy on one port while the client is configured for another. An immediate “connection refused” is evidence that the destination stack was reached and rejected the connection or had no matching listener. A timeout is less specific; possible causes include packet loss, an incorrect route, an unavailable destination, or silent policy filtering. Preserve that distinction instead of treating every failure as the same condition.

Finally, test the application protocol. curl -v exposes address selection, connection attempts, request headers, response headers, and application status. A completed TCP connection followed by an HTTP 404 is not a basic connectivity failure: the network path and web service worked, but the requested resource was absent. Likewise, an HTTP 500 indicates that the request reached the application even though the application failed internally. Use bounded tests such as --connect-timeout and --max-time so a diagnostic command cannot wait indefinitely.

A disciplined cycle is: observe, scope, hypothesize, test one variable, compare the result with the prediction, and record the conclusion. Prefer read-only inspection before changing anything. Do not restart unrelated services or alter host networking merely because a client failed. Changes can erase evidence and create a second problem. In this lab, the deliberately wrong port produces a transport failure, while the correct port produces an HTTP success. The contrast demonstrates how listener inspection and client output can locate a fault without changing system-wide network configuration.