Guide Linux Intermediate

Networking Commands

ip, ss, curl, dig, and the essential command-line tools for configuring, inspecting, and troubleshooting networking on Linux.

3 min read

Interfaces & Addresses

ip addr show               # all interfaces + their IPs (modern replacement for ifconfig)
ip a                          # short form
ip link show                    # interface state (up/down), MAC address
sudo ip addr add 192.168.1.50/24 dev eth0   # assign an IP (non-persistent)
sudo ip link set eth0 up                       # bring an interface up

Routing

ip route show                       # full routing table
ip route show default                 # just the default gateway
ip route get 8.8.8.8                    # which interface/route would be used to reach a target
traceroute example.com                    # hop-by-hop path
mtr example.com                             # continuous traceroute + loss stats (best for flaky links)

Sockets & Ports: ss

ss -tulnp                   # TCP/UDP listening sockets, numeric, with owning process
ss -tan state established     # established TCP connections only
ss -s                           # summary statistics

sudo lsof -i :8080                # what's using port 8080?
sudo fuser -k 8080/tcp               # kill whatever is using port 8080

DNS Lookups

dig example.com                    # detailed DNS query and response
dig +short example.com               # just the answer, no extra output
dig -x 8.8.8.8                          # reverse lookup (IP to hostname)
nslookup example.com                      # older alternative to dig
getent hosts example.com                    # resolve exactly like the system resolver would (checks /etc/hosts too)
host example.com                              # quick, simple lookup

HTTP & Connectivity Testing

curl https://api.example.com                       # basic GET request
curl -v https://api.example.com                       # verbose — shows full request/response + TLS handshake
curl -X POST -d '{"a":1}' -H "Content-Type: application/json" https://api.example.com
curl -o /dev/null -s -w "%{http_code} %{time_total}s\n" https://example.com   # status code + timing only
curl -I https://example.com                             # headers only (HEAD request)

wget https://example.com/file.tar.gz                       # download a file

ping -c 4 8.8.8.8            # 4 ICMP echo requests (note: often blocked by firewalls)
nc -zv host 443                # quick TCP port-open check
telnet host 443                  # older alternative for the same check

Firewall Inspection

sudo iptables -L -n -v          # list current iptables rules with packet/byte counters
sudo nft list ruleset              # nftables (modern) equivalent
sudo firewall-cmd --list-all         # firewalld front-end (RHEL/CentOS)
sudo ufw status verbose                # ufw front-end (Ubuntu/Debian)

Bandwidth & Traffic

sudo iftop                    # live per-connection bandwidth usage
sudo nload                      # simple in/out bandwidth graph
ss -i                              # socket-level TCP info: RTT, congestion window, retransmits

Production Considerations

  • Prefer ip/ss over the deprecated ifconfig/netstat — they’re not installed by default on many minimal/modern distros anymore.
  • A failed ping doesn’t prove a service is down — ICMP is commonly blocked while the actual TCP/UDP service traffic flows fine. Verify with curl/nc against the real port.
  • dig/nslookup bypass /etc/hosts and query DNS directly — if application behavior differs from what dig shows, check /etc/hosts and /etc/nsswitch.conf resolution order.

Quick Interview Answer

ip configures interfaces and routes, ss inspects sockets and listening ports, curl/wget test HTTP endpoints, and dig/nslookup do DNS lookups. For troubleshooting connectivity, ping only tests ICMP reachability — which is often blocked — so curl or nc against the actual port is the more reliable check for whether a service is really reachable.”

Common Mistakes

  • Concluding a service is down from a failed ping alone, without testing the actual port/protocol.
  • Using legacy ifconfig/netstat on systems where they’re not installed by default anymore.
  • Forgetting /etc/hosts can silently override what dig shows as the “real” DNS answer.

Add More Questions to This Guide

Know a question that should be here? Share it and help the community!

Open Google Form