How it works
Two ordinary tools carry most early diagnosis: one reports the settings a device is currently using, and one tests whether a destination replies.
Check the settings first, then test reachability outward in steps. Confirming the near end before the far end saves you from chasing a fault that was never there.
Common error
A failed reply does not always mean unreachable. Some destinations decline to answer by policy, so a single failure is evidence rather than proof.
Worked example
Interpret a progression of tests rather than treating every failed reply as the same fault.
Evidence
Local address: valid
Gateway reachability: succeeds
Approved service by address: succeeds
Name lookup for that service: failsThe evidence narrows the leading hypothesis to name resolution or the service record. Inspect resolver settings and compare the lookup on a working client. Successful address-based service access makes a total local-link failure less likely, but does not prove every external route works.
Exercises
2.5.1
A host ignores ping but its HTTPS service loads. Is it necessarily unreachable? Explain.
Show solution
No. It may decline ICMP echo while accepting the application traffic. Test the required service and inspect policy rather than equating one missing echo reply with total unreachability.
2.5.2
Order these checks for one disconnected client: remote application, local link, IP settings, local gateway.
Show solution
Check the local link, inspect IP settings, test the local gateway, then test the required remote application. Use each result to narrow the next hypothesis.