Linux Networking Commands: A Troubleshooting Reference
Organized by the question you actually have at 2am, not by man page. Modern tooling as the default, with the deprecated equivalent noted for the muscle memory that predates it.
By William Bradshaw | August 3, 2026 | 10 min read
Most Linux networking references are organized the way the tools are organized: one section per command, every flag listed, alphabetical. That is useful exactly once, when you are learning the tool. It is useless at the moment you actually need it, because at that moment you do not have a command, you have a symptom.
This reference is ordered by the question instead. Each section is a thing that is actually wrong, the command that answers it, and what in the output tells you whether to stop or keep going. The ordering matters as much as the commands: checking DNS before you have confirmed the interface has an address wastes the first ten minutes of an outage on the wrong layer.
The commands assume a current distribution using the iproute2 suite and, where relevant, systemd. If you are coming from ifconfig and netstat, there is a translation table near the end. If you are running these servers in production rather than troubleshooting someone else's, our reference on Linux server administration for SMBs covers the operational patterns around them, and Ansible automation for SMB infrastructure covers making a fix stick across more than one host.
Work Outward, In This Order
Nearly every network problem resolves faster if you refuse to skip ahead. Each layer below assumes the one above it is confirmed working. When someone reports "the network is down," start at one and do not jump to five because five is more interesting.
1. Does the interface exist, is it up, and does it have an address?
Layer 1 and 2. Nothing above this can work if the answer is no, and the answer is no more often than people expect.
2. Is there a route, and can it reach the next hop?
A correct address with no default route is a very common and very confusing state.
3. Does name resolution work, and which resolver is answering?
Only ask this once you can reach an IP address. Half of all "DNS problems" are routing problems.
4. Is the service listening, on the address you think?
A daemon bound to 127.0.0.1 is invisible from the network and perfectly healthy locally.
5. Is something in between dropping it?
Firewall, interface errors, MTU. This is where you finally reach for packet capture.
1. Is the Interface Up and Addressed?
The brief output flag is the one worth building muscle memory for. It prints one line per interface instead of a paragraph, which is the difference between scanning and reading.
ip -br addr # one line per interface: name, state, addresses
ip -br link # same, but MAC and link state without the addressing
ip addr show eth0 # the full detail for one interface when you need it
Read the state column first. UP means the kernel has the interface administratively up and carrier is present. DOWN means it is administratively down, which is a configuration problem. LOWER_UP missing from the flags in the full output means no carrier: the cable, the transceiver, or the switch port. That distinction saves you from debugging software when the problem is a cable.
If the address is in the 169.254.0.0/16 range, DHCP failed and the host self-assigned. If there is no address at all on an interface that should have one, the question moves up to your configuration layer, which is Netplan on Ubuntu, NetworkManager on the RHEL family, and possibly ifupdown on older Debian systems.
ip -s link show eth0 # per-interface counters: RX/TX errors, dropped, overruns
ethtool eth0 # negotiated speed, duplex, and whether link is detectedNon-zero and climbing error or dropped counters point at physical or driver problems. A 1000baseT link that negotiated at 100 Mb/s half duplex is a bad cable or a switch-port mismatch, and it presents to users as "the network is slow" rather than as an outage, which is why it survives for weeks.
2. Is There a Route, and Does the Next Hop Answer?
ip route # the routing table, default route first
ip route get 8.8.8.8 # which route the kernel would actually choose
ip neigh # the ARP/neighbour table and its states
ip route get is the underused one. Rather than making you reason about longest-prefix matching across a table with several entries, it tells you the decision the kernel makes for one destination, including the source address it will use. On a multi-homed host that answer is frequently not the one you assumed.
In the neighbour table, REACHABLE is healthy and STALE is normal for an idle entry. FAILED against your default gateway means ARP is not resolving, which is a layer 2 problem: wrong VLAN, wrong subnet mask, or a gateway that is genuinely absent.
ping -c 4 <gateway-ip> # next hop, before anything further out
ping -c 4 1.1.1.1 # a known-good public IP, bypassing DNS entirely
mtr -rwc 100 1.1.1.1 # report mode, 100 cycles, per-hop loss and latencyPing an IP address, never a hostname, at this stage. The entire point is to test routing with name resolution taken out of the picture. If a hostname ping fails and an IP ping succeeds, you have just diagnosed the problem and it is in section three.
For mtr, read only the final hop's loss figure as authoritative. Loss reported at an intermediate hop that does not persist to the destination is almost always a router rate-limiting its own ICMP responses while forwarding traffic perfectly well. Chasing that number is one of the most common ways to spend an hour on a network that is fine.
3. Why Will It Not Resolve?
The critical distinction here is between what your applications do and what your diagnostic tool does. dig talks to a nameserver directly and ignores the system resolver configuration entirely. Applications go through the C library, which follows /etc/nsswitch.conf and, on most modern systems, a stub resolver. Those are two different code paths and they fail independently.
resolvectl status # per-link DNS servers and search domains in use
resolvectl query example.com # resolve the way applications actually resolve
getent hosts example.com # the same path again, via NSS, no systemd needed
resolvectl status is the first command to run on any systemd-resolved system, because it shows DNS configuration per link. A VPN interface that has installed its own search domain and DNS server can capture resolution for names you did not intend, and nothing in /etc/resolv.conf will tell you so. On those systems /etc/resolv.conf is usually a symlink pointing at a stub listener on 127.0.0.53, so reading it directly tells you almost nothing.
dig example.com # ask the configured nameserver directly
dig @1.1.1.1 example.com # ask a specific nameserver, bypassing yours
dig +short example.com # just the answer, for scripting
dig +trace example.com # walk the delegation from the root down
Compare the two paths deliberately. If dig @1.1.1.1 answers and dig alone does not, your configured nameserver is the problem. If both answer but getent hosts does not, the problem is in the resolver library or NSS configuration, not in DNS at all. That second case is the one that gets misdiagnosed for hours, because every DNS tool you reach for reports success.
dig +trace earns its place when a name resolves from one network and not another. It walks the delegation chain from the root servers down, so a broken or lagging delegation shows up as the specific level where the chain stops rather than as a generic failure.
4. What Is Listening on This Port?
ss -ltnp # listening, TCP, numeric, with process
ss -lunp # the same for UDP
ss -tnp state established # current TCP connections and who owns them
ss -tn dst 10.0.0.5 # filter by destination address
The n in that flag set is not cosmetic. Without it, ss tries to resolve every address and port to a name, so on a host with a broken resolver the command you are running to diagnose the outage hangs because of the outage. Numeric output returns instantly and always.
Read the local address column carefully, because this is where the single most common false alarm lives. A service bound to 127.0.0.1:8080 is reachable only from the host itself. A service bound to 0.0.0.0:8080 or *:8080 is reachable from the network. Both look identical to a local curl test, and only one of them explains why the load balancer reports the backend as down.
The process column requires privilege. Without root or CAP_NET_ADMIN you still see the sockets, but the process names for sockets you do not own are simply blank rather than producing an error, which reads as "nothing is listening" if you are moving fast.
ss -s # socket summary by state, useful for exhaustion
lsof -i :443 # everything touching port 443, listening or not
lsof -i -P -n # all network files, numeric, no port-name lookup
ss -s is the fast check for socket exhaustion. A large and growing count of sockets in TIME-WAIT is usually normal on a busy server. A large count in CLOSE-WAIT is an application bug: the peer closed, and your application never called close on its side.
5. Where Is the Packet Being Dropped?
By this point you know the interface is up, routing is sane, names resolve, and the service is listening on a reachable address. What remains is something in the path discarding traffic. Check the firewall before you capture packets, because the firewall is the answer far more often and takes seconds to rule out.
nft list ruleset # nftables, the current default on most distributions
iptables -S # legacy or nft-backed iptables, rules as commands
firewall-cmd --list-all # RHEL family, if firewalld is managing the rules
ufw status verbose # Ubuntu, if ufw is managing the rules
Match the tool to what is actually managing the host. Reading iptables -S on a firewalld-managed system shows you rules that firewalld generated and will regenerate, so editing at that level produces a fix that survives until the next reload and no longer. This is a genuine distribution difference rather than a preference: use the layer that owns the configuration.
tcpdump -ni eth0 port 443 and host 10.0.0.5 # numeric, no resolution, filtered
tcpdump -ni any icmp # all interfaces, ICMP only
tcpdump -ni eth0 -w capture.pcap # write for later analysis
Always filter. An unfiltered capture on a busy interface produces more output than you can read and, if you are writing to disk, more than you meant to store. The -n flag matters here for the same reason it does with ss: a capture that pauses to resolve every address is a capture that misses packets.
The diagnostic value is in the asymmetry. If you see the inbound SYN arrive and no SYN-ACK leave, the host received the connection and something local refused it, which is the firewall or a service not bound where you think. If you see the SYN-ACK leave and the client never completes the handshake, the problem is in the return path, and it is frequently asymmetric routing or a stateful device in the middle that never saw the outbound half.
When the symptom is that small transfers work and large ones hang, suspect MTU rather than a firewall. Test with ping -M do -s 1472 <host>, which sets the do-not-fragment bit at a payload size that fits exactly inside a standard 1500-byte MTU. If that fails while a smaller size succeeds, something in the path has a lower MTU and is not signalling it back correctly. Tunnels and VPNs cause this constantly.
6. It Works, But It Is Slow
"Slow" is not a diagnosis, and the first job is deciding whether you are looking at a bandwidth problem, a latency problem, or a loss problem. They have different causes and they feel identical to the person reporting them.
mtr -rwc 100 <host> # loss and latency per hop, over 100 cycles
iperf3 -s # on one host: listen
iperf3 -c <server> -t 30 # on the other: measure actual throughput
ethtool -S eth0 # driver-level statistics, including error counters
iperf3 requires a listener you control on the other end, which is exactly why it is worth having one. Measuring against a public speed test conflates your network, the public internet, and someone else's server. Measuring between two hosts you own isolates the segment you can actually change.
Sustained throughput far below the negotiated link speed, with clean interface counters and low latency, usually points at TCP window behaviour over a long path rather than at the network hardware. Throughput far below link speed with climbing error counters points at the physical layer, and you should go back to ethtool and check duplex.
If Your Muscle Memory Predates iproute2
The net-tools package is not merely discouraged on current distributions, it is usually not installed. The old commands do not give you wrong answers, they give you command not found. Worth knowing before you type one into a production incident bridge.
| Old (net-tools) | Current | Note |
|---|---|---|
| ifconfig | ip addr / ip link | Add -br for one line per interface. |
| netstat -tulpn | ss -tulpn | Same flags, considerably faster on hosts with many sockets. |
| netstat -rn | ip route | Use ip route get to test one destination. |
| arp -a | ip neigh | Adds neighbour state, which the old output did not expose. |
| route add | ip route add | Runtime only either way; persist it in your config layer. |
| nslookup | dig / resolvectl query | Use resolvectl query to match application behaviour. |
| traceroute | mtr | Still fine for one-shot; mtr wins on intermittent faults. |
Where the Distributions Genuinely Differ
Everything above is diagnosis, and diagnosis is portable. The iproute2 commands behave identically across distributions. Configuration is where they diverge, and running the right diagnostic followed by the wrong configuration command is how a fix lasts until the next reboot.
On Ubuntu, interface configuration lives in Netplan YAML under /etc/netplan/, rendered to either systemd-networkd or NetworkManager. On RHEL, Rocky, and AlmaLinux, NetworkManager owns it and nmcli is the interface to it. Older Debian systems may still use /etc/network/interfaces.
Name resolution splits the same way. systemd-resolved is standard on Ubuntu, so resolvectl is the right tool there. On RHEL-family systems it is often not enabled, in which case /etc/resolv.conf is a real file with real content and NetworkManager is what writes it. Check which situation you are in before you edit anything: resolvectl status failing with a message about the service not running is itself the answer.
The Part That Is Not a Command
The commands are the easy half. The half that determines whether the same outage happens again is what you do with the answer: whether the fix is applied to one host by hand at 2am or expressed as configuration that reaches every host that shares the defect.
A firewall rule added with nft during an incident disappears on reboot. A route added with ip route add does the same. Both are correct as emergency measures and both are incomplete as fixes. The durable version lives in the configuration layer and gets applied the same way everywhere, which is the argument for managing infrastructure with Ansible rather than with a run book of commands.
The other half is knowing what the network looked like before it broke. A current diagram, an address plan, and a record of which VLAN carries what turn most of the work above into a five-minute confirmation instead of an investigation. Our piece on network topology visualization covers keeping that documentation accurate enough to be worth consulting under pressure.
No Linux Operations Capacity In-House?
Knowing the commands is not the same as having someone on call who runs them. Bullium manages Linux infrastructure for organizations that depend on it without wanting to staff for it.
Related Reading
Linux Server Administration for SMBs
The layer above these commands: user management, systemd services, log discipline, and patch automation.
Ansible Automation for SMB Infrastructure
How a one-host fix becomes a config change that reaches every host with the same defect.
Network Topology Visualization
Knowing what the network looked like before it broke, which turns investigation into confirmation.
Linux Patch Management for SMB Production
The operational rhythm that keeps these hosts from becoming the next incident.
Vim Cheat Sheet
The other reference you end up needing on the same box, once you have found the config file to edit.
Tailscale and Zero Trust Networking
Overlay networks change what these commands show you. What a mesh VPN does to your routing table.
Related Services
Linux Administration
Managed Linux operations for organizations that run it in production without staffing for it.
Network Assessment
A documented picture of what is actually on the network, before the next incident rather than during it.
Network Design
Addressing, segmentation, and routing designed so the failure modes above are diagnosable.
Managed IT Services
Monitoring and response, so someone notices the climbing error counter before a user does.