A method, not a guess
Find out why a Linux machine can't reach something, layer by layer: interfaces and addresses, routes and ip route get, ARP and the neighbour table, ping and traceroute, DNS, and listening sockets — with real output from a three-host lab.
By the end you will be able to:
- Troubleshoot connectivity bottom-up instead of guessing
- Read interface state and addresses with ip link and ip addr
- Predict and verify the route a packet takes with ip route get
- Interpret the neighbour table and ARP failures
- Use ping, tracepath and traceroute, and read their results correctly
- Diagnose DNS with dig and getent, and services with ss and nc
- Explain where traceroute's hop names come from, how registries delegate reverse DNS, and when to trust a name
When "the network is down", resist the urge to jump straight to the firewall or the application. Work from the bottom up: each layer depends on the one below, and the first layer that fails is your problem. Most of the time it's found within a minute.
| # | Question | Command | Covered in |
|---|---|---|---|
| 1 | Is the interface up, with a link? | ip -br link | Interfaces |
| 2 | Does it have the right address and prefix? | ip -br addr | Interfaces |
| 3 | Is there a route to the destination? | ip route get <dst> | Routes |
| 4 | Can I reach the next hop on the LAN? | ip neigh, ping <gateway> | Neighbours |
| 5 | Can I reach the destination, and by which path? | ping, tracepath, traceroute | Ping and traceroute |
| 6 | Does the name resolve to the right address? | dig, getent hosts | DNS |
| 7 | Is the service listening and reachable? | ss -tlnp, nc -vz | Ports and sockets |
Everything in this lesson was run on a real lab of three Debian 12 containers: a client on an office LAN, a router between two subnets, and a server in a DMZ. All output is copied from those machines. The last section shows how to build the lab yourself.
Step through what happens when the client pings the server. Notice how many separate things must go right, in both directions.
- 1. The client looks up a route. 198.51.100.20 isn't on the client's own 192.0.2.0/24, so the most specific match is the default route: send it to the gateway 192.0.2.1 out of eth0.
- 2. ARP for the gateway. To put the packet in an Ethernet frame the client needs the gateway's MAC address. It broadcasts "who has 192.0.2.1?" and the router answers. The result is cached in the neighbour table.
- 3. Frame to the router, packet to the server. The Ethernet destination is the router's MAC, but the IP destination stays 198.51.100.20. The gateway never appears in the IP header.
- 4. The router forwards. With ip_forward enabled, the router looks up 198.51.100.20, finds it directly connected on eth1, ARPs for the server, decrements the TTL (64 → 63) and sends it on.
- 5. The reply needs its own route. The server replies to 192.0.2.10. That's not on its subnet, so it needs a route back: its default via 198.51.100.1. Without it, the request arrives but the reply is never sent.
- 6. Round trip complete. The router forwards the reply back to the client. Every hop did its own route lookup and its own ARP, in both directions.
Check your understanding
A user can't load a web page by name. Following the bottom-up method, what do you check first on their machine?
- Whether the web server is running
- That the interface is up and has the right address
- Whether DNS resolves the name
- The firewall rules