Think You Know Linux Networking? Test Yourself

ip -br addr show            # one line per interface: name, state, addresses
ip route show               # routing table, look for "default via ..."
ip route get 8.8.8.8        # which interface + gateway the kernel actually picks
ip -s link show dev eth0    # RX/TX counters, errors, drops

# ifconfig/route live in net-tools, which minimal RHEL/Rocky and Ubuntu images skip

✅ Interview Answer:

"I use ip -br addr for a fast overview and ip route get when I want to know the exact path the kernel will choose, because with multiple NICs the routing table alone can fool you. I also check the error and drop counters, since a link can be UP and still be dropping packets."

# Listening TCP + UDP sockets, numeric, with the owning process (-p needs sudo)
sudo ss -tulpn

# Just port 53, both protocols
sudo ss -tulpn 'sport = :53'

# Force DNS over TCP: proof that DNS is not "UDP only"
dig +tcp example.com A

✅ Interview Answer:

"TCP does a handshake, orders packets and retransmits, UDP just sends. I check what a service really uses with ss -tulpn. And one gotcha I always mention: DNS falls back to TCP for large responses and zone transfers, so a firewall that only allows UDP 53 will break things eventually."

grep '^hosts:' /etc/nsswitch.conf   # lookup order, usually "files" before "dns"
getent ahosts app.internal          # resolves the way the app does
dig +short app.internal             # DNS only, skips /etc/hosts
grep app.internal /etc/hosts        # the usual culprit

# Which DNS server is the box using?
# Ubuntu (systemd-resolved): resolvectl status
# RHEL/Rocky (NetworkManager): cat /etc/resolv.conf  or  nmcli dev show

✅ Pro Move:

"When dig and the app disagree, I compare getent ahosts against dig. Usually it's a stale /etc/hosts entry someone added during a migration, or a local cache. Then I'd name the fix and who should have cleaned it up."

sudo ss -tlnp 'sport = :8080'
# LISTEN 0 4096 127.0.0.1:8080 ...   <- loopback only, remote clients never get in

# Does it answer locally?
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/health

# Then the firewall
sudo firewall-cmd --list-all       # RHEL/Rocky
sudo ufw status verbose            # Ubuntu
sudo nft list ruleset              # what the kernel actually has loaded

✅ Interview Answer:

"First I check the listen address with ss -tlnp. If it's 127.0.0.1, that's a config problem, not a network one. If it's 0.0.0.0 and curl works locally, I move to the host firewall, then the cloud security group. Also, 'connection refused' and 'timeout' mean different things, so I ask which one the user saw."

#!/bin/bash
set -euo pipefail

ip2int() {
  local a b c d
  IFS=. read -r a b c d <<< "$1"
  echo $(( (a << 24) | (b << 16) | (c << 8) | d ))
}

in_subnet() {    # usage: in_subnet 10.0.5.200 10.0.4.0/23
  local ip net prefix mask
  ip=$(ip2int "$1")
  net=$(ip2int "${2%/*}")
  prefix="${2#*/}"
  mask=$(( prefix == 0 ? 0 : (0xFFFFFFFF << (32 - prefix)) & 0xFFFFFFFF ))
  (( (ip & mask) == (net & mask) ))
}

if in_subnet 10.0.5.200 10.0.4.0/23; then echo "same subnet"; else echo "needs a router"; fi

✅ Interview Answer:

"Yes. A /23 masks off 9 host bits, so the range runs 10.0.4.0 through 10.0.5.255 with 510 usable hosts. I AND both addresses with the mask and compare. This matters in practice when someone sets a /24 on one host and /23 on another, and half the traffic goes to the gateway for no obvious reason."

# RHEL / Rocky (firewalld)
sudo firewall-cmd --add-service=https              # runtime only, lost on reload/reboot
sudo firewall-cmd --permanent --add-service=https  # written to config
sudo firewall-cmd --reload
sudo firewall-cmd --list-services
# Already tested at runtime? Save it all in one go:
sudo firewall-cmd --runtime-to-permanent

# Ubuntu (ufw rules persist by default)
sudo ufw allow 443/tcp
sudo ufw status numbered

✅ Interview Answer:

"The rule was added to the runtime config only. I test at runtime first so a bad rule can't lock me out, then commit with --runtime-to-permanent. On a fleet I'd put it in Ansible so nobody's hand-editing firewalls on prod."

ping -c 3 api.partner.example                 # small packets, fine
curl -v --max-time 10 https://api.partner.example   # stalls mid-TLS or mid-body

# Don't-Fragment probes: 1472 bytes + 28 bytes of IP/ICMP headers = 1500
ping -c 3 -M do -s 1472 api.partner.example
ping -c 3 -M do -s 1372 api.partner.example  # works? the path is smaller than 1500

tracepath -n api.partner.example             # shows pmtu hop by hop
ip link show dev eth0 | grep -o 'mtu [0-9]*'

✅ Interview Answer:

"Small packets working while large ones hang is my MTU alarm. I probe with ping -M do at decreasing sizes and confirm with tracepath. The fix is either allowing ICMP 'fragmentation needed' through, lowering the interface MTU, or MSS clamping on the tunnel. I'd push for the first one, because blocking all ICMP is usually what caused it."

# Bounded: 2000 packets max, headers only (-s 128), no name lookups (-nn)
sudo tcpdump -i eth0 -nn -s 128 -c 2000 -w /tmp/api-443.pcap \
  'tcp port 443 and host 10.20.1.15'

# SYNs with no ACK flag: count them, then look for missing SYN-ACK replies (timeouts)
sudo tcpdump -nn -r /tmp/api-443.pcap 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn'

# RSTs: something actively refused or killed the connection
sudo tcpdump -nn -r /tmp/api-443.pcap 'tcp[tcpflags] & tcp-rst != 0'

✅ Interview Answer:

"I always cap the capture with a filter, -c and a small snaplen, write to a file, and read it offline. Then I look for SYNs that never got a SYN-ACK, which points at drops, versus RSTs, which point at the backend or a load balancer refusing. On a HIPAA or SOC2 box I'd also make sure I'm not capturing payloads I'm not allowed to keep."