Essential Linux Networking Commands

On modern Linux, the essential networking commands come from the iproute2 suite: ip inspects interfaces and routes, ss lists sockets and listening ports, and ip neigh reads the ARP cache.

If you have ever shelled into a fresh container, typed ifconfig out of pure habit and got command not found back, this is why. The muscle memory has outlived the binaries by a good decade.

These replace the older net-tools binaries (ifconfig, route, netstat, arp), which Red Hat lists among the commands you should stop reaching for and which often aren’t installed at all on current distributions. This reference groups the commands by the job you’re doing (checking interfaces, routing, connectivity, DNS, ports, and traffic) and closes with a symptom-to-command troubleshooting flow you can follow end to end.

What replaced ifconfig, netstat, and route on Linux?

net-tools has been treated as obsolete since the early 2000s, with iproute2 as the actively developed replacement. The openSUSE net-tools-deprecated package documents the canonical one-to-one mapping:

Prefer the iproute2 form. On a minimal container or fresh server the legacy binaries may not exist, so scripts that call ifconfig or netstat break with command not found.

Interfaces and addresses

ip addr (or the alias ip a) shows every interface and its assigned IPv4/IPv6 addresses, the modern equivalent of ifconfig. Use ip link to bring an interface up or down, and hostname -I to print just the machine’s IP addresses.

ip addr                       # all interfaces + addresses (alias: ip a)
ip addr show eth0             # one interface only
sudo ip link set eth0 down    # take an interface offline
sudo ip link set eth0 up      # bring it back online
hostname -I                   # print all IP addresses, space-separated

A single binary, ip, covers addresses, interfaces, routing, and tunnels. hostname -I is the quickest way to grab an address for a script without parsing ip addr output.

Routing

ip route displays and edits the kernel routing table, replacing the legacy route command. Run it with no arguments to see where traffic goes and which gateway is the default.

ip route                                      # view the routing table
ip route get 1.1.1.1                          # show which route a destination uses
sudo ip route add 10.0.0.0/24 via 192.168.1.1 # add a static route

ip route get is the fast way to answer “which interface and gateway will this destination use?”. That helps when a host is reachable from one network but not another.

Connectivity and path

ping tests whether a host responds; traceroute and mtr show where packets travel and where they die. Always bound ping with a count: ping -c 5 example.com sends five packets and exits instead of running forever.

ping -c 5 example.com     # send 5 ICMP echoes, then stop
traceroute example.com    # trace the hop-by-hop path
sudo traceroute -T -p 443 example.com  # trace using TCP to port 443
mtr example.com           # live ping + traceroute in one view

Left alone, traceroute gives up after 30 hops and sizes each probe at 60 bytes on IPv4, 80 bytes on IPv6. Adding -T swaps the default UDP probes for TCP ones, which get through firewalls that drop the default. mtr example.com combines ping and traceroute into one live view, so you can watch per-hop packet loss update in real time. Note that traceroute and mtr are often not preinstalled: add them with sudo apt install mtr traceroute (Debian/Ubuntu) or sudo dnf install mtr traceroute (RHEL/Fedora).

DNS lookups

dig is the primary tool for DNS queries; +short trims the output to the answer, -x does a reverse lookup, and @server targets a specific resolver. nslookup and host cover the same ground more briefly.

dig +short example.com            # just the resolved A record(s)
dig -x 8.8.8.8                    # reverse lookup: IP -> hostname
dig +short example.com @8.8.8.8   # query Google's public resolver directly
host example.com                  # terse forward/reverse lookup
nslookup example.com              # interactive-capable lookup

Querying a resolver explicitly is the key isolation step: to tell a DNS failure apart from a bad local resolver, run dig +short example.com @8.8.8.8; if that resolves but your default doesn’t, the problem is your resolver, not the domain.

How do you find what’s using a port on Linux?

To find which process is holding a port, run ss -tulnp | grep :8080. The -p flag prints the PID and process name that owns the socket. This is the fix for the “port already in use” error when a server or container won’t bind.

ss -tlnp                    # all listening TCP sockets + owning process
ss -tulnp | grep :8080      # what's bound to port 8080 (TCP + UDP)

The flags read as t=TCP, u=UDP, l=listening, n=numeric (no name resolution), p=process. Seeing the process name for sockets you don’t own requires root, so prefix with sudo. ss is the modern replacement for netstat, and netstat’s own manual page calls the command mostly obsolete and sends you to the netlink-based ss when a busy server has a lot of sockets to list. That is where the speed difference comes from: ss asks the kernel over netlink, while netstat reads text files under /proc/net. Once you have the PID, stop it with kill <pid>.

Traffic and transfer

tcpdump captures live packets, while curl, wget, and nc test reachability and move files. Use tcpdump to see exactly what’s on the wire when higher-level tools give no answer.

sudo tcpdump -i eth0 port 80    # capture HTTP traffic on eth0
curl -v https://example.com     # verbose HTTP request, headers and TLS
wget -O out.html https://example.com  # download to a file
nc -zv example.com 443          # check if a port is open (no data sent)

Pulling packets off an interface with tcpdump takes elevated privileges, which in practice means running it under sudo (or granting the binary CAP_NET_RAW). nc -zv host port is the fastest single-line port check: -z scans without sending data, -v reports the result. On Docker Desktop, host.docker.internal resolves on its own, so nc -zv host.docker.internal 8080 reaches the host from inside a container. On Docker Engine for Linux you have to map it yourself, by starting the container with --add-host=host.docker.internal:host-gateway (supported since Docker Engine 20.10).

Troubleshooting flow: symptom to command

Match the symptom to a decision path and work outward from your machine.

• Host unreachable → ping -c 5 host to test reachability, then traceroute host or mtr host to find where packets die, then ip route to confirm you have a valid route and gateway.
• “Port already in use” → ss -tulnp | grep :<port> to find the owning PID, then kill <pid> or bind a different port.
• DNS failing → dig +short example.com against your resolver, then dig +short example.com @8.8.8.8 against a public one; if only the public query resolves, your local resolver is the fault.
• Slow or saturated link → sudo iftop or bmon to see per-connection bandwidth in real time (install with sudo apt install iftop bmon).

Each command in these chains confirms or eliminates one layer (link, route, name resolution, socket), so you narrow the fault instead of guessing.

Reach first for the iproute2 tools (ip, ss, ip neigh), fall back to net-tools only on systems that still ship it, and follow the symptom-to-command paths above the next time a bind fails or a host goes dark.

FAQs

What is the difference between ss and netstat, and are they interchangeable?

They are not interchangeable. ss is the modern replacement, and netstat's own manual page describes the command as mostly obsolete and points to ss instead. ss asks the kernel for socket data over netlink, while netstat reads text files under /proc/net, which is why ss holds up better on servers with a lot of sockets. Both list connections and listening ports, but scripts should call ss because netstat may not be installed.

How do I find and kill the process using a specific port on Linux?

Run ss -tulnp | grep :8080 to find the socket bound to that port; the -p flag prints the PID and process name of the owner. Seeing process names for sockets you do not own requires root, so prefix with sudo. Once you have the PID, stop it with kill followed by the PID. This resolves the 'port already in use' error when a server or container will not bind.

Why does ifconfig return command not found on my server?

Because ifconfig belongs to the net-tools package, which many modern distributions no longer install by default. Red Hat lists ifconfig and route among the commands iproute2 replaces, RHEL has skipped net-tools in its default install since version 7, and Debian has done the same since Debian 9. Use ip addr instead to view interfaces and addresses, or install net-tools manually if a legacy script requires the old binary.

How can I tell whether a DNS problem is the domain or my local resolver?

Query a public resolver directly with dig +short example.com @8.8.8.8 and compare it against dig +short example.com using your default resolver. If the public query resolves but your default does not, the fault is your local resolver, not the domain. The @server syntax forces dig to bypass your configured resolver, isolating the failure to one side without changing any system configuration.

Why is traceroute or mtr not installed on my system?

traceroute, mtr, whois, nmap, and iftop are often not included in minimal or default installations, so they return command not found. Install them with sudo apt install mtr traceroute on Debian and Ubuntu, or sudo dnf install mtr traceroute on RHEL and Fedora. Unlike ip and ss, which ship with iproute2 by default, these path and scanning tools must usually be added through the package manager.