Every network engineer eventually troubleshoots from a Linux shell — a cloud instance that cannot reach its database, a container with no DNS, a monitoring server that suddenly went quiet. The toolkit is compact, and the discipline is the same layered walk the OSI chapter promised: physical/link, address, route, name, socket, filter — in that order, because each layer's tools assume the previous layer works.
The iproute2 quartet
- ip link — interfaces and their state: ip link show lists them; state UP versus DOWN, and ip -s link prints error counters (a climbing RX-ERR is a physical conversation, not a software one).
- ip addr — addresses on interfaces: the modern replacement for ifconfig, plural addresses per interface included. ip addr add 10.1.1.5/24 dev eth0 configures one live (until reboot).
- ip route — the routing table: ip route show; ip route get 8.8.8.8 answers the only question that matters — 'which interface and gateway will this packet actually use?'.
- ip neigh — the ARP/ND cache; a neighbour stuck in FAILED is your gateway problem announcing itself.
$ ip -br addrlo UNKNOWN 127.0.0.1/8 ::1/128eth0 UP 10.1.20.14/24 fe80::5054:ff:fe12:3456/64$ ip route get 8.8.8.88.8.8.8 via 10.1.20.1 dev eth0 src 10.1.20.14
Path, name and socket
ping tests reachability and, with -s and -M do, MTU; traceroute (or mtr, which is traceroute with statistics and a live display) locates where a path dies. DNS gets dig: dig api.example.com asks the configured resolver (systemd-resolved distributions: resolvectl status shows which that actually is — /etc/resolv.conf is often a stub), dig @1.1.1.1 bypasses it to split 'DNS is broken' into 'my resolver is broken'. Sockets get ss: ss -tlnp lists listening TCP sockets with owning processes — the instant answer to 'is the service even listening, and on which address?' — and ss -tnp state established shows live conversations. curl -v closes the loop by exercising the full stack, narrating name resolution, TCP, TLS and HTTP in one output.
$ ss -tlnp | head -4State Local Address:Port ProcessLISTEN 0.0.0.0:22 sshdLISTEN 127.0.0.1:5432 postgres$ dig +short api.example.com203.0.113.40
Persistence and filters
Live ip commands do not survive reboot; persistent config lives with the distribution's manager — Netplan YAML under /etc/netplan on Ubuntu servers, NetworkManager (nmcli, nmtui) on RHEL-family systems. Know which owns the box before editing, because hand-edits under the wrong manager silently revert. The host firewall is the last gate: iptables -L -n or nft list ruleset shows raw rules, with firewalld (firewall-cmd --list-all) and ufw as the common frontends. 'Service works locally, fails remotely' is the firewall's signature — test from the host itself first precisely to isolate it.
The ladder, applied
- ip link — interface up, errors clean?
- ip addr — expected address and mask?
- ip route get <dst> — sane egress and gateway? ip neigh — gateway resolving?
- ping gateway, then past it — where does reachability end?
- dig — names resolving, and via the resolver you think?
- ss -tlnp — service listening on the right address?
- Firewall rules — on both this host and the far one.
Run the ladder identically every time and most host-side faults localise in under five minutes — the same layered discipline as every troubleshooting chapter in this library, with the OSI model once again earning its keep as a checklist generator.