Network command-line tools

Why this matters

Every network fault is answered by one of about a dozen commands, and the skill is knowing which one answers which question. Is there an address? Is there a route? Is the port open? Where does the path break? Is the DNS answer right?

The ip command in particular has replaced a whole generation of tools — ifconfig, route, netstat, arp — and the exam expects the new ones. Old tutorials will teach you commands that are not installed on a current server.

The lesson

ip: addresses, links and routes

One command with subcommands, each replacing an older tool.

ip address show            # or: ip a
ip addr show eth0
ip -4 addr                 # IPv4 only
ip -br addr                # brief, one line per interface — very readable

ip link show               # or: ip l — layer 2: interfaces, MAC, MTU, state
ip link set eth0 up
ip link set eth0 down
ip link set eth0 mtu 9000

ip route show              # or: ip r — the routing table
ip route get 8.8.8.8       # WHICH route would be used for this destination?

ip address is layer 3 and ip link is layer 2. An interface can be physically up (ip link shows state UP) while having no address at all, which is precisely the DHCP-failed case: the cable is fine and nothing works. Checking both tells you which.

Adding configuration by hand:

ip addr add 192.168.1.50/24 dev eth0
ip addr del 192.168.1.50/24 dev eth0
ip route add default via 192.168.1.1
ip route add 10.0.0.0/8 via 192.168.1.254
ip route del 10.0.0.0/8

Everything ip changes is lost on reboot. It edits the running kernel state, not configuration. That makes it perfect for testing — try a route, confirm it fixes the problem, then write it into NetworkManager or Netplan properly. It also means a reboot is a guaranteed way back out of a mistake.

ip route get is underused and excellent: rather than reading the table and working out which entry wins, you ask the kernel which route it would use for a specific destination, and it tells you, including the source address and interface.

hostname reports or sets the system name, though hostnamectl set-hostname is the durable way:

hostname                  # short name
hostname -f               # fully qualified
hostname -I               # all IP addresses — handy in scripts

Sockets: what is listening

ss -tuln                  # TCP+UDP, listening, numeric — the everyday one
ss -tulnp                 # ...with the process (needs root)
ss -t state established   # active TCP connections
ss -tn dst 10.0.0.5       # connections to one host
ss -s                     # summary counts

The flags decode as: t TCP, u UDP, l listening only, n numeric (do not resolve names, which is much faster), p process.

ss -tulnp is the answer to "is the service actually listening, and on what?" — and the address it reports matters as much as the port. A service bound to 127.0.0.1:5432 accepts only local connections; bound to 0.0.0.0:5432 it accepts from anywhere. "The firewall must be blocking it" is very often a service bound to loopback instead.

ss replaced netstat, which is frequently not installed at all now.

Reachability and paths

ping -c 4 192.168.1.1        # four packets and stop
ping6 -c 4 2001:4860:4860::8888
ping -c 100 -i 0.2 host      # a quick loss test

traceroute example.com       # the path, hop by hop (UDP by default)
traceroute -I example.com    # using ICMP
tracepath example.com        # no root needed; also discovers MTU
mtr example.com              # traceroute + ping, continuously — the best of the three

mtr is what you actually want. A single traceroute is one sample and is easily misread; mtr keeps pinging every hop and shows sustained loss and latency per hop, so you can distinguish a router that merely deprioritises ICMP (loss at one hop, none after it) from a genuine problem (loss at that hop and every hop beyond).

That distinction is the single most misread thing in network diagnosis: loss shown at an intermediate hop that does not continue to the destination is not a fault. Routers rate-limit their own ICMP responses while forwarding traffic perfectly.

tracepath needs no privileges and reports path MTU, which matters for the classic "small requests work, large ones hang" fault.

Ports, scanning and ad-hoc connections

nc -zv example.com 443        # is the port open? (-z scan, -v verbose)
nc -zv 10.0.0.5 20-25         # a range
nc -l 9000                    # LISTEN on 9000 — a throwaway server
nc 10.0.0.5 9000              # connect to it
echo "GET / HTTP/1.0" | nc example.com 80

nmap -sS 10.0.0.0/24          # SYN scan a subnet (needs root)
nmap -p 1-1000 10.0.0.5       # port range
nmap -sV 10.0.0.5             # identify service versions
nmap -A 10.0.0.5              # aggressive: OS, versions, scripts

nc (netcat) is the two-ended test. Run nc -l 9000 on one host and nc host 9000 on the other, and you have proven end-to-end TCP connectivity independent of any application — which settles arguments about whether a firewall or the app is at fault.

Only scan hosts you are authorised to scan. nmap against infrastructure you do not own is, depending on where you are, a disciplinary matter or a criminal one. On your own network it is the right tool for finding what is listening that should not be.

DNS from the command line

nslookup example.com
nslookup example.com 1.1.1.1     # ask a specific server

nslookup is the older, more portable tool and is present on Windows too, which is why it persists. dig gives more detail and is preferred on Linux — but nslookup appears in the objectives and is worth being able to read.

Interface hardware

ethtool eth0               # speed, duplex, link detected
ethtool -S eth0            # per-interface statistics, including errors
ethtool -s eth0 speed 1000 duplex full autoneg off
ethtool -i eth0            # which driver and firmware

ethtool answers a specific and important question: is this link running at the speed you think? A gigabit port negotiated down to 100 Mb half-duplex — usually a bad cable or a mismatched switch port — produces a network that works, slowly, in a way nothing else reports. ethtool -S then shows rising error and drop counters, confirming a physical problem rather than a configuration one.

Measuring throughput

iperf3 -s                        # on the receiving host
iperf3 -c 10.0.0.5               # on the sending host
iperf3 -c 10.0.0.5 -R            # reverse direction
iperf3 -c 10.0.0.5 -P 4          # four parallel streams
iperf3 -c 10.0.0.5 -u -b 100M    # UDP at a target rate

iperf3 measures what the network can actually carry between two points, which is the only way to settle "the network is slow". Test both directions — they are frequently asymmetric — and remember you are also measuring the two endpoints' CPUs on fast links.

Capturing packets

tcpdump -i eth0                        # everything (noisy)
tcpdump -i eth0 port 443               # one port
tcpdump -i eth0 host 10.0.0.5          # one host
tcpdump -i eth0 -n                     # no name resolution
tcpdump -i eth0 -c 100 -w capture.pcap # 100 packets to a file for Wireshark
tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0'   # SYNs only

tcpdump is the last resort and the final arbiter. When two teams disagree about whether traffic is arriving, a capture settles it — you can see the SYN arrive and see whether anything answered. Seeing SYNs with no SYN-ACK means the packets reach the host and something is refusing or dropping them locally, which points at the firewall rather than the network.

Always use -n. Reverse-resolving every address is slow and, on a busy interface, generates its own DNS traffic that then appears in your capture.

On the exam

• ip replaces ifconfig, route, netstat and arp. Know ip a, ip r, ip link.
• Anything set with ip is lost on reboot — it is for testing, not configuration.
• ss -tulnp shows listening sockets and their processes; a service on 127.0.0.1 is not reachable remotely regardless of the firewall.
• mtr beats a single traceroute; loss at an intermediate hop that does not continue is ICMP rate-limiting, not a fault.
• nc -zv host port tests one port; nc -l makes a throwaway listener.
• ethtool reveals a link negotiated to the wrong speed or duplex.
• iperf3 needs a server end (-s) and a client end (-c).
• tcpdump -n avoids DNS lookups polluting the capture.
• ping6 for IPv6; nslookup is the portable DNS lookup.