Linux for Network Engineers: The Commands You'll Use Every Day

Most of the signal a network engineer gets about the health of the network arrives through a terminal: an odd latency spike, a hostname that resolves on Monday and not on Tuesday, a connection that resets after exactly 64 kilobytes. These are messages from the kernel, and the commands in this guide are how you read them. The tools ship with essentially every Linux distribution, so they are the one skill that transfers from a carrier router you log into once a quarter to a cloud VM you have two minutes to inspect. Learning them is not about memorizing flags; it is about knowing what each command can prove and which question it answers next.

This guide covers the handful of commands you will actually reach for every day: ping, traceroute, mtr, dig, ss, nc, tcpdump, ip, and ethtool. For each one you will learn the single question it answers, the flags that matter in production, the failure modes that quietly mislead you, and where the tool sits in a troubleshooting sequence. By the end you will have a repeatable workflow you can run from muscle memory, which is the difference between engineers who find faults and engineers who collect output.

The Commands Map to the Layers

The fastest way to start using these tools well is to stop thinking of them as a bag of utilities and start thinking of them as a set of layer probes. Every command in the table answers exactly one question about one part of the stack, and a symptom implies which question to ask first. When a service is unreachable, checking interface counters first is usually a detour, and reaching for a packet capture before you know whether DNS resolves turns a two minute diagnosis into a twenty minute one. Pick the tool by the symptom, read the output as a layer verdict, and let that verdict choose the next tool.

The classic mistake is treating the commands as interchangeable. A host that answers ping and a service that is dead can both be true at once, because ICMP proves the host is up and says nothing about what listens on port 443. A port that is open, proven by nc, says nothing about the firewall standing between you and it. Each tool tests one layer, so the output is always interpreted as a narrow result, never as a general health check. That discipline keeps you from declaring a network problem fixed when you have only confirmed that a single layer works.

Reachability: ping, traceroute, and mtr

ping is the first command you run and the easiest to misread. By default most distributions run it forever, so form the habit of -c 4 (or -c 100 when you want numbers worth graphing) the moment you type it. The output gives you three things: whether the destination answers, how many replies are lost, and the round trip time of each. Repeat a test 100 times and you get a loss percentage that actually means something, which is the number you want when someone says the link is slow. ping -f floods as fast as the kernel allows and needs root, and it is the fastest way to force a marginal link to drop packets on a fixed schedule.

ping only proves the far end answers. To learn where a path is failing you need traceroute, which sends probes with increasing time to live and names each hop the traffic passes through. Use -n so every output line is an IP address instead of a DNS lookup you will have to verify anyway. Many routers drop the UDP probes traceroute uses by default, so keep -T for a TCP SYN probe and -I for ICMP in mind; one of the three almost always gets an answer. mtr does the same job continuously, which makes it the better tool for intermittent loss: run it for a few minutes and the hop level loss percentages tell you whether the trouble is on your last mile or somewhere in the middle.

The way to interpret any of these outputs is the same. The last hop that answers and the first one that goes silent enclose the failing segment, so replies stopping at your ISP edge and replies stopping at the remote edge are two completely different problems, even though both look identical in a screenshot. Latency that climbs steadily across two or three hops usually means a congested or oversubscribed link, while a single hop that spikes and then falls back can be a router spending its CPU on something else. Reachability tools tell you where a path breaks, and they cannot tell you why it breaks.

Ports and Listeners: ss and nc

Once a path is reachable, the next question is whether the port you need is actually open. On the local host, ss is the tool: ss -tlnp lists every TCP socket that is listening, with the process that owns it, and ss -tunap adds UDP and every connection state. The process column alone settles most why is my service not reachable calls, because a listener bound to 127.0.0.1:8080 is listening and still unreachable from anywhere else on the network. netstat still exists on many distributions, but ss is the modern, faster, and more detailed replacement, and there is no reason to learn the old one.

Across the network, nc (netcat) is the one liner for opening a socket on purpose: nc -zv 10.0.0.5 443 connects, prints whether the port accepts the connection, and closes, which makes it a clean check that works in scripts. A plain nc -l 8080 turns a host into an impromptu listener you can point another machine at to test connectivity with no service installed, which is invaluable in locked down environments. When a port is refused from one host and works from another, the failure is almost always a firewall between the two. When the port times out instead, a firewall is silently dropping packets, and that difference tells you a good deal about the security posture between you and the target.

DNS: dig Is the Only Proof

dig is the command that makes DNS auditable. Start every lookup with +short to suppress everything but the answer, then add the record type you actually care about: dig +short A example.com, then AAAA, MX, TXT, NS. Use @ to choose the server, dig @8.8.8.8 example.com A, which is how you test a zone against the public recursion instead of the resolver your local machine happens to trust. And dig +trace replays the whole iterative walk from root to authoritative server, which exposes delegation mistakes, stale glue records, and out of date answers in one screen of output.

Two pitfalls account for most confusing dig sessions. The first is caching: repeat a query and it returns instantly because something between you and the origin cached the answer, so timing slow lookups is meaningless unless you point at the authoritative server directly and read the TTL in the answer. The second is the local resolver: distributions with systemd-resolved hand dig replies from a local stub, which is correct for everyday use and wrong for diagnosing someone else’s zones. When you need the truth about a record, ignore the local path and query the authoritative name servers the NS records name. DNS is the layer where you can prove things, and dig is the proof tool.

Packets: tcpdump

When the layers above are clean and the problem persists, the last question is what the packets are actually doing, and tcpdump shows you. The workflow that stays fast under pressure is a capture with a tight filter: tcpdump -i any -nn port 443, which reads every interface, skips name resolution, and shows only the traffic you asked about. Add host 10.0.0.5 to narrow by destination, tcp or icmp to narrow by protocol, and -c 50 to stop after a workable sample. Capture to a file with -w /tmp/capture.pcap when you need evidence, and read it back with -r when you want to look again without the live feed.

Packet captures earn their keep when they make a distinction visible. If an application times out but tcpdump shows requests going out and no response, the fault is between the client and the server. If the server receives the request, the fault is on the server side or in the application. A rising count of retransmissions points at loss or a congested path, while zero traffic at all points at routing or a firewall further up. Captures need root, so on production hosts keep them temporary, filter hard, and never leave one running unattended; a few seconds of the right filter answers most questions, and a capture left running answers none of them faster.

The Interface Level: ip and ethtool

The ip suite from iproute2 is the modern replacement for ifconfig, route, and arp, and it is where you confirm what the operating system believes about the hardware. ip link lists interfaces and their states, ip addr adds every assigned address, ip route shows the routing table, and ip neigh shows the neighbor table, the ARP and NDP cache that tells you whether the second hop actually resolves. On hosts using network namespaces, ip netns moves you into the container or VM’s view of the stack, which is exactly where a packet that reaches the host disappears before reaching a workload.

ethtool reports the physical facts the operating system cannot guess: ethtool eth0 shows link state, speed, duplex, and what the other end negotiated, and ethtool -i eth0 names the driver. The counters in ethtool -S distinguish the two failure families at the NIC boundary: a climbing rx_errors or rx_crc_errors count means a physical or cabling problem, while rising drops usually mean the interface is doing more than the buffer can hold. Between the neighbor table, the routing table, and the interface counters, the interface level tells you whether the network in front of the host and the stack inside it agree with each other, and when they disagree, that disagreement is the bug.

Turn the Commands Into a Routine

Used one at a time these commands answer questions; used in a sequence they resolve incidents. The order that covers the most ground fastest starts at the bottom of the stack: confirm the interface is up with ip link, resolve the name with dig, prove end to end reachability with ping, trace the path with mtr, test the port with nc, check the listener with ss, and only then look at packets with tcpdump. Each result is a layer verdict, and the first verdict that disagrees with your expectation names the fault. Most network incidents do not require more than the first three steps, and the discipline is knowing that output is evidence, not an endpoint.

The same routine pays off before there is any incident at all. A baseline is just the normal answer to each command: the expected round trip times to your core devices, the name servers that should answer, the ports that should be listening. When the output deviates from that baseline you are not diagnosing from scratch, you are measuring the delta, and the delta always points somewhere useful. That comparison only works if someone records what the network is supposed to look like, which is the reason to keep your device inventory and topology map current instead of trusting memory. Every command you run then has a known frame of reference, and when the tools disagree with the record, they have caught a real drift.

This is the practical loop that makes the command line so effective for network work: your records tell you what should be true, and ping, dig, ss, and the rest tell you what is true within a second or two. Master the nine commands in this guide and you can localize almost any failure to a layer, which is the entire job of a network engineer in one sentence. If you want to go deeper on how discovery and inventory tooling relate to the manual probes in this article, the discovery versus IPAM versus monitoring comparison is a good next read.

The commands in this article tell you what your network is doing right now. Keeping the baseline they compare against is the other half. Obelinf gives you a place to keep addresses, devices, VLANs, and topology together, so the state you compare against remains documented as your lab changes.