Network Troubleshooting

"The network is broken" is not a diagnosis — it's a symptom that could come from any of five different layers. The slow way to fix it is to guess: restart the interface, flush DNS, reboot, reach for tcpdump, and hope one of them lands. The fast way is to test each layer in order and stop at the first one that fails. Everything above a broken layer is broken too, so once you find the bottom failure you've found the cause.

Think of your connection as a water supply running from the city main to your kitchen tap. If no water comes out, you don't tear open the faucet first. You walk the path backwards: is the main on? Is the valve into the house open? Is the pipe to the kitchen clear? You test each junction in order until you hit the dry one. Networking is the same — you just walk it from the bottom up.

The five junctions, bottom to top:

• LINK — is the network cable/interface physically up? (ip link)
• IP / ROUTE — do I have an address and a way out? (ip addr, ip route)
• REACHABILITY — can packets actually get there and back? (ping)
• NAME RESOLUTION — can I turn names into addresses? (dig)
• SERVICE / APP — is the thing I want actually listening? (ss, curl)

Start at the bottom: the interface — the kernel's handle on your network card. If it's DOWN, no address, route, or DNS query can possibly work, so there's no point looking higher. ip link shows every interface and its state.

An up interface with no IP address can't send anything. And even with an address, you can only reach machines on your own subnet unless you have a default route — the gateway that off-subnet traffic (i.e. the whole rest of the internet) gets handed to. These are two separate checks. In the water analogy: an address is having a pipe connected; the default route is the valve to the street main.

Now test whether packets actually make a round trip. Ping outward in stages, nearest-first, so a failure tells you where the path breaks:

1. Ping your gateway (192.0.2.1) — proves the link to your first hop works.

2. Ping a known external IP (here 192.0.2.1 stands in for any reliable off-net address) — proves routing past the gateway works.

Using a raw IP address here, never a name, is deliberate: it keeps DNS out of the picture so you're testing pure connectivity. (We test names separately in the next step — that separation is the heart of this lesson.)

Here's the most common real-world "the internet is down" call that isn't a connectivity problem at all. The tell:

• ping -c1 192.0.2.1 (by IP) → works
• ping -c1 example.com (by name) → fails with "Name or service not known"

If packets reach an IP fine but anything by name fails, connectivity is healthy — what's broken is the translation from names to addresses, i.e. DNS. Connectivity and naming are different layers, and this exact split is how you tell them apart in one move.

You've reached the top. The network delivers packets and names resolve, but "I can't connect to the web app" can still mean the service itself isn't there. Two checks finish the climb: is something listening on the expected port locally (ss), and does an actual request get a response (curl)?

Only now — when the lower layers check out but something still doesn't add up (a silent drop, a one-way connection, a handshake that never completes) — do you reach for `tcpdump` and watch the actual packets on the wire. It's the most powerful tool here, which is exactly why it's last: it shows you everything, so you want to use it once you've narrowed where to look, not as a shot in the dark.

You have a real shell. Run these in order — this is the exact bottom-up sweep you'd do on a live "the network's broken" call. Each command checks one layer; the first one that fails is your culprit. All of these are read-only and safe to run.