About the Linux Networking cheat sheet
Linux networking troubleshooting is mostly a matter of asking questions in the right order: does the name resolve, is there a route, does the connection establish, and is anything listening on the other side. Working out of order is why so much time is spent on the wrong layer.
The tooling has shifted. The ip command replaced ifconfig and route years ago and exposes things its predecessors cannot show, including policy routing and multiple routing tables. ss replaced netstat and is considerably faster on a host with many connections. Both changes are worth making permanently — the old commands are missing information you will eventually need.
The concept that explains the most confusing behaviour is conntrack. Anything doing NAT, including every container host, tracks connections in a kernel table with a finite size. When that table fills, new connections fail while existing ones continue, which presents as intermittent failures with no obvious pattern.
Frequently asked questions
How do I find which process is listening on a port?
Use ss with the listening, process, numeric, TCP and UDP flags, which shows sockets with owning processes without resolving names. Run it with sufficient privilege or the process column stays empty for sockets you do not own — a common reason people conclude nothing is listening when something is.
Why can I ping a host but not connect to it?
They test different layers. ICMP reaching the host proves routing works; a refused or timed-out TCP connection means something above that is blocking. Refused means nothing is listening on that port. A timeout usually means a firewall dropping silently, either on the host or somewhere in between.
What is conntrack and why does the table fill?
It is the kernel's connection tracking table, needed for NAT and stateful firewalling. Every tracked connection occupies an entry, and entries persist after close for a timeout period. A host making many short-lived outbound connections can exhaust the table, at which point new connections are dropped while established ones survive — an intermittent failure that looks like anything but a full table.
How do I test connectivity without telnet or netcat installed?
Bash can open a TCP connection through its dev/tcp pseudo-device, so redirecting to that path tests whether a port accepts a connection using nothing but the shell. It is invaluable in minimal containers. For anything richer, kubectl debug or a temporary container with proper tooling is the better route.
Why does DNS work for some names and not others?
Look at the search domains and the ndots setting in the resolver configuration. A short name may be tried against every search domain before the correct one, and a fully qualified name only resolves correctly if the trailing behaviour is right. In containers this is amplified, because Kubernetes sets ndots to 5 and turns one external lookup into several failures first.
Need this managed for you, not just automated?
We're also a hands-on DevOps consultancy — Kubernetes, CI/CD, and cloud infrastructure.