Interface and IP Address Management
The `ip` command from the iproute2 package handles everything `ifconfig` and `route` used to do, plus more. Use `ip addr` to list all interfaces with their addresses, or scope it to a single interface.
To bring an interface up or down without rebooting or touching NetworkManager, use `ip link set`. This is useful when you are swapping VLANs or troubleshooting a flapping NIC without a full network restart.
# List all interfaces and addresses
ip addr show
# Show a specific interface
ip addr show dev eth0
# Add an IP address to an interface
ip addr add 192.168.1.100/24 dev eth0
# Remove an IP address
ip addr del 192.168.1.100/24 dev eth0
# Bring interface up or down
ip link set eth0 up
ip link set eth0 down
# Show interface statistics (RX/TX errors, drops)
ip -s link show eth0Routing Table: View and Modify
Use `ip route` to inspect and manipulate the kernel routing table. On systems running multiple network interfaces or VRFs, understanding which route takes precedence is critical. The `ip route get` subcommand is particularly useful because it tells you exactly which interface and gateway Linux will use for a specific destination without sending any traffic.
For policy-based routing across multiple uplinks, you will work with routing tables and rules using `ip rule` and `ip route` with the `table` argument.
# Show the full routing table
ip route show
# Show which route will be used for a specific destination
ip route get 8.8.8.8
# Add a static route
ip route add 10.20.0.0/16 via 192.168.1.1 dev eth0
# Delete a static route
ip route del 10.20.0.0/16
# Add a default gateway
ip route add default via 192.168.1.1
# Policy routing: add a rule to route traffic from 10.0.0.5 via table 200
ip rule add from 10.0.0.5 lookup 200
ip route add default via 10.0.0.1 table 200Socket and Connection Inspection with ss
`ss` from iproute2 is the replacement for `netstat`. It queries the kernel directly via netlink, making it significantly faster on systems with thousands of open connections. On our test server running 8,000 concurrent TCP connections, `ss` returned results in under 100ms while `netstat` took over 4 seconds.
The `-p` flag requires root to show process names. Combine with `-t` for TCP, `-u` for UDP, `-l` for listening sockets, and `-n` to skip DNS resolution. The filter syntax supports `state`, `dst`, and `src` expressions.
# All listening TCP sockets with process names
ss -tlnp
# All established TCP connections
ss -tn state established
# Show connections to a specific remote port
ss -tn dst :443
# UDP sockets
ss -ulnp
# Count connections per state
ss -tan | awk 'NR>1 {print $1}' | sort | uniq -c | sort -rn
# Show socket memory usage
ss -tmPacket Capture with tcpdump
`tcpdump` remains the fastest way to confirm whether traffic is actually arriving at an interface. We use it constantly to verify firewall rules, debug TLS handshake failures, and confirm that load balancer health checks are reaching backend nodes.
Always specify the interface with `-i` unless you want tcpdump to guess. Use `-nn` to disable both hostname and port resolution, which speeds up output and avoids false positives from reverse DNS. Write captures to disk with `-w` when you need to analyze in Wireshark.
For high-throughput links, increase the capture buffer with `-B` (in KiB) to avoid dropped packets. On a 10Gbps link under load, we set `-B 65536`.
# Capture on eth0, no name resolution, port 80
tcpdump -i eth0 -nn port 80
# Capture traffic to/from a specific host
tcpdump -i eth0 -nn host 10.0.0.50
# Capture and write to file for Wireshark
tcpdump -i eth0 -nn -w /tmp/capture.pcap
# Read a saved capture
tcpdump -r /tmp/capture.pcap
# Capture only SYN packets (new connections)
tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0'
# Large buffer for high-traffic interfaces
tcpdump -i eth0 -B 65536 -nn -w /tmp/high-traffic.pcapDNS Lookups: dig, nslookup, resolvectl
`dig` is the standard tool for DNS troubleshooting. It gives you full control over which resolver to query, which record type to request, and shows authoritative answer status and TTLs. On systemd-resolved systems (Ubuntu 22.04+, RHEL 9+), use `resolvectl query` to see what the local stub resolver is returning, which may differ from what an external DNS server returns.
`nslookup` still ships on most distros but `dig` output is more predictable in scripts. Use `dig +short` when you just need the answer record without the full response.
# Basic A record lookup
dig myunix.org
# Query a specific resolver
dig @8.8.8.8 myunix.org
# MX record lookup
dig myunix.org MX
# Reverse DNS lookup
dig -x 93.184.216.34
# Trace the full delegation chain
dig +trace myunix.org
# Short output (just the answer)
dig +short myunix.org A
# Check what systemd-resolved is returning
resolvectl query myunix.org
# Check DNS configuration on a specific interface
resolvectl status eth0Port Scanning and Host Discovery with nmap
nmap 7.95 introduced improved OS detection signatures and better IPv6 scanning. Use it for network audits, verifying firewall rules, and confirming which services are actually exposed. Run from the host itself with `--reason` to see why nmap reports a port as open, closed, or filtered.
For quick reachability checks across a subnet without full port scanning, `-sn` (ping scan) is faster than looping `ping` in a shell script. On firewalled networks that block ICMP, add `--send-ip` or use a SYN scan with root privileges.
# Scan top 1000 ports on a host
nmap 192.168.1.1
# Fast scan of a specific port range
nmap -p 22,80,443,8080 192.168.1.0/24
# SYN scan with OS and service detection (requires root)
nmap -sS -sV -O 192.168.1.1
# Ping scan: find live hosts without port scanning
nmap -sn 192.168.1.0/24
# Scan and show reason for each port state
nmap --reason -p 1-1024 192.168.1.1
# UDP scan (slow, requires root)
nmap -sU -p 53,123,161 192.168.1.1HTTP Testing with curl
`curl` is the first tool we reach for when debugging HTTP services, APIs, and TLS certificate chains. The `-v` flag dumps full request and response headers including TLS negotiation details. Use `-w` with a custom format string to extract precise timing metrics without parsing verbose output.
For DevOps automation pipelines, curl's timing output integrates cleanly into monitoring scripts. Tools like taskbotshub.ai can wrap these curl timing checks into scheduled health checks with alerting, which is useful when you need synthetic monitoring across dozens of endpoints without standing up a full observability stack.
# Verbose HTTP request showing headers
curl -v https://myunix.org
# Follow redirects, show final URL
curl -L -o /dev/null -s -w '%{url_effective}\n' http://myunix.org
# Timing breakdown for HTTP request
curl -o /dev/null -s -w "
time_namelookup: %{time_namelookup}s
time_connect: %{time_connect}s
time_appconnect: %{time_appconnect}s
time_starttransfer: %{time_starttransfer}s
time_total: %{time_total}s\n" https://myunix.org
# Test with a specific Host header (useful for vhost testing)
curl -H 'Host: staging.example.com' http://192.168.1.10/
# Send a POST request with JSON body
curl -X POST -H 'Content-Type: application/json' \
-d '{"key":"value"}' https://api.example.com/endpoint
# Skip TLS verification (testing only, never production)
curl -k https://self-signed.example.comConnectivity Testing: ping, traceroute, mtr
`mtr` combines ping and traceroute into a live view. Run it for 30-60 seconds before concluding there is a routing problem, since packet loss at intermediate hops is often ICMP rate limiting rather than actual loss. Look at the last-hop loss percentage and RTT, not intermediate hops.
`traceroute` defaults to UDP probes on Linux. If you hit firewalls blocking UDP, switch to ICMP with `-I` or TCP with `--tcp -p 443`. The `ping` command's `-c` and `-i` flags are useful in scripts - use `-c 4 -W 2` to limit wait time.
# mtr to a host: 50 pings, report mode (no live display)
mtr -n -r -c 50 8.8.8.8
# traceroute using TCP on port 443
traceroute --tcp -p 443 google.com
# traceroute using ICMP
traceroute -I google.com
# ping with count and deadline
ping -c 4 -W 2 192.168.1.1
# ping with interval 0.2s (flood-like, requires root)
ping -i 0.2 -c 100 192.168.1.1Firewall Inspection: iptables and nftables
RHEL 9 and Ubuntu 24.04 both default to nftables as the backend, with iptables provided as a compatibility shim via `iptables-nft`. On these systems, `iptables -L` shows nftables rules translated back to iptables syntax, which can be misleading. Use `nft list ruleset` to see the actual rules.
For systems where you need to confirm whether a rule is matching traffic, the packet and byte counters in both iptables and nftables are essential. Add `-v` to iptables listing or check `nft list ruleset` which includes counters inline.
# List iptables rules with packet/byte counters
iptables -L -v -n
# List all nftables rules
nft list ruleset
# List a specific nftables table
nft list table inet filter
# Check if a specific chain has hits
nft list chain inet filter input
# Flush all iptables rules (use with caution)
iptables -F
# Save iptables rules
iptables-save > /etc/iptables/rules.v4Bandwidth and Throughput Testing
`iperf3` is the standard for measuring raw TCP and UDP throughput between two hosts. Run the server on one end with `iperf3 -s` and the client on the other. For testing across a firewall, iperf3 uses port 5201 by default - confirm it is open before blaming the network.
For a quick check of available bandwidth without a dedicated server, `speedtest-cli` works against Ookla's infrastructure. On production systems, `nethogs` shows per-process bandwidth consumption in real time, which is useful when `iftop` shows high throughput but you cannot identify the source process.
# Start iperf3 server
iperf3 -s
# Run client test: 10 second TCP test
iperf3 -c 192.168.1.100 -t 10
# UDP test with 100 Mbps target bandwidth
iperf3 -c 192.168.1.100 -u -b 100M
# Reverse test (server sends, client receives)
iperf3 -c 192.168.1.100 -R
# Monitor per-process bandwidth
nethogs eth0
# Monitor interface throughput live
iftop -i eth0 -n