Linux network commands I actually reach for

When something's off with networking on a Linux box, you don't need to know fifty commands — you need to know the right four or five. This post is a tour of the ones that actually live in my muscle memory, plus the patterns I run when I'm debugging a real problem.

A note on tooling: the classic ifconfig, route, and arp commands ship from the net-tools package and have been deprecated for a decade. Their replacements live in iproute2: ip addr, ip route, ip neigh. The old commands still work via compat shims on most distros, but new scripts and habits should use ip. This post leads with ip.

Interfaces — ip addr / ip link

ip addr shows every interface and the addresses bound to each.

1ip addr

11: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 ...2    inet 127.0.0.1/8 scope host lo3    inet6 ::1/128 scope host42: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...5    inet 10.0.1.42/24 brd 10.0.1.255 scope global dynamic eth06    inet6 fe80::abcd:1234/64 scope link73: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 ...8    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0

The classic interface name conventions:

• lo — loopback (the host itself)
• eth0, enpXsY — wired Ethernet
• wlan0, wlpXsY — wireless
• docker0 / br-… — Docker / bridge interfaces
• cniX / vethXXX — Kubernetes / container networks

Single interface only:

1ip addr show eth0

ip link is similar but shows just the link layer (state, MAC, MTU) without IP addresses — handy when you only care about whether an interface is up.

1ip link2ip link set eth0 up      # bring up3ip link set eth0 down    # bring down

Reachability — ping, mtr

ping sends ICMP echo requests and reports round-trip time. It's still the fastest way to confirm a host is reachable.

1ping example.com2ping -c 4 example.com    # send exactly 4 packets and exit3ping -i 0.2 example.com  # 200 ms between packets

For tracing where a connection breaks down, mtr is traceroute and ping rolled into one — it traces the path hop-by-hop and updates the packet-loss/latency columns continuously. It's the tool I reach for when latency is bad and I need to find which hop is dropping packets.

1mtr example.com2mtr -r -c 50 example.com  # report mode, 50 packets per hop, then exit

If mtr isn't installed, plain traceroute still works:

1traceroute example.com

Routing — ip route

The kernel's routing table tells you where traffic for a given destination goes.

1ip route

1default via 10.0.1.1 dev eth0 proto dhcp src 10.0.1.42 metric 100210.0.1.0/24 dev eth0 proto kernel scope link src 10.0.1.423172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1

Reading it: anything matching 10.0.1.0/24 goes directly out eth0; everything else (the default route) gets sent to the gateway 10.0.1.1.

To check which route the kernel picks for a specific destination — useful when there are multiple interfaces or VPN tunnels in play:

1ip route get 8.8.8.8

18.8.8.8 via 10.0.1.1 dev eth0 src 10.0.1.42 uid 1000

DNS — dig, host

DNS issues are the source of an outsized share of "the network is broken" pages. Two tools cover almost everything:

• host — quick name → IP / IP → name lookup
• dig — full-featured, tells you exactly which record type, TTL, and which resolver answered

1host example.com2dig example.com3dig +short example.com    # just the IP, scriptable4dig example.com @1.1.1.1  # query a specific resolver5dig MX example.com        # specific record type

For a deeper walkthrough of dig's flags, see my dig post.

Listening sockets — ss

ss (from iproute2) replaces netstat and is significantly faster on busy hosts. The flag combo I use almost daily:

1ss -tulpn

• -t TCP, -u UDP, -l listening sockets only, -p show owning process, -n numeric (don't resolve)

1Netid  State   Recv-Q  Send-Q  Local Address:Port    Peer Address:Port  Process2tcp    LISTEN  0       128     0.0.0.0:22           0.0.0.0:*          users:(("sshd",pid=1065,fd=3))3tcp    LISTEN  0       511     0.0.0.0:80           0.0.0.0:*          users:(("nginx",pid=742,fd=11))4tcp    LISTEN  0       511     0.0.0.0:443          0.0.0.0:*          users:(("nginx",pid=742,fd=14))5tcp    LISTEN  0       70      127.0.0.1:3306       0.0.0.0:*          users:(("mariadbd",pid=23070,fd=24))

Filter to a single port — handy when you're trying to figure out what's already squatting on it:

1ss -tulpn 'sport = :443'

I covered the same ground from a different angle in listing the ports in use on Linux.

Live packet inspection — tcpdump

When a service "isn't reachable" and you've ruled out DNS and routing, the next stop is watching the actual packets.

1sudo tcpdump -i eth0 -n

1sudo tcpdump -n port 80                  # only HTTP2sudo tcpdump -n host 1.2.3.4             # only a specific peer3sudo tcpdump -n -i any port 5432         # any interface, Postgres4sudo tcpdump -n -w out.pcap port 443     # write to a pcap for later analysis

-n skips DNS resolution — both faster and more useful when you're debugging DNS itself. For deeper analysis, wireshark (or its CLI sibling tshark) is the next stop.

ARP / Neighbour table — ip neigh

The kernel's local-network neighbour table — IP-to-MAC mappings it has learned about peers on the same L2 segment.

1ip neigh

110.0.1.1   dev eth0 lladdr 00:1a:2b:3c:4d:5e REACHABLE210.0.1.50  dev eth0 lladdr aa:bb:cc:dd:ee:ff STALE

Useful when you're chasing duplicate IPs, dead gateways, or STALE/FAILED entries that tell you a peer disappeared.

DNS resolver config — /etc/resolv.conf

The system's recursive DNS resolvers live here:

1cat /etc/resolv.conf

1nameserver 1.1.1.12nameserver 8.8.8.8

Heads up: on most modern distros, /etc/resolv.conf is managed by systemd-resolved or NetworkManager. Edits get clobbered on reboot. To change resolvers permanently, configure the manager (e.g. nmcli or /etc/systemd/resolved.conf) instead of the file.

Local hostname overrides — /etc/hosts

A hand-edited override that's consulted before DNS. Convenient for testing things against an IP without touching real DNS.

1cat /etc/hosts

Add a line like:

1127.0.0.1 my-app.local

…and my-app.local resolves to localhost on this machine.

A real debugging workflow

When someone hands me a "the app can't reach the database" ticket, the rough sequence is:

1. DNS works? dig db.internal +short — does it resolve?
2. Route works? ip route get $(dig +short db.internal) — which interface, which gateway?
3. L4 reachable? nc -vz db.internal 5432 (or curl -v telnet://...) — is the port open?
4. Service listening? On the DB host, ss -tulpn | grep 5432
5. Packets making it? On both ends, sudo tcpdump -n port 5432

That five-step sweep eliminates the vast majority of "it's the network" pages without leaving the terminal.

Cheat sheet

That's the toolkit. Combined with curl, nc, and a healthy distrust of "it works on my machine," this covers most of what you'll need on any Linux host.