Network Troubleshooting & Tools
The problem
When something is broken across a network, the cause could be anywhere from a physical cable to a misconfigured DNS record to an overloaded server — troubleshooting tools let you isolate exactly which layer and which hop is failing, instead of guessing.
Why now
This is the applied capstone of the domain: ping, traceroute, curl, and dig each interrogate a different layer or protocol already covered (IP, routing, HTTP, DNS), so this topic only makes sense once those pieces already exist to be tested individually.
Mental model
Troubleshooting a network problem is the layered model in reverse: start at the layer most likely to fail (usually DNS or application), and work down (or up) until you find where behavior diverges from expectation. Each tool is a probe aimed at exactly one layer — ping tests reachability, traceroute tests the path, curl tests the application response.
Requires
- TCP & UDPNetworking
Tools like ping (ICMP, adjacent to IP) and traceroute directly probe the transport/network layers; understanding what they're testing requires already knowing what those layers guarantee.
- IP Addressing & RoutingNetworking
Traceroute's output is a sequence of routing hops; interpreting it requires already understanding what a routing hop is.
Unlocks
Used in
- On-call incident response — diagnosing 'why is this service unreachable'
- Local development debugging (why can't my app reach this API)
- Verifying deployment and DNS configuration changes actually took effect
- Performance debugging — isolating latency to a specific network hop
Projects
- Given a synthetic 'broken' scenario (DNS misconfigured, port closed, server down), use the appropriate tool to correctly diagnose which layer is at fault
- Build a personal troubleshooting checklist mapping symptoms (can't resolve, can't connect, slow response) to the tool that diagnoses each
Examples
- ping fails but traceroute shows a path — likely a firewall blocking ICMP rather than an actual routing failure
- curl -v returning a connection refused versus a timeout points to two different failure categories (nothing listening vs. network path blocked)
Resources
Mastery checklist
- I can use ping, traceroute, curl, and dig, and explain what layer each one probes
- I can diagnose whether a failure is DNS, connectivity, or application-level from tool output
- I can distinguish a connection-refused error from a timeout and explain what each implies
- I can build a systematic troubleshooting approach instead of guessing randomly