Linux Networking Configuration and Troubleshooting Questions

Network interfaces and configuration files. IP addressing and routing configuration. Using netstat, ss, ip, ifconfig commands. DNS configuration and troubleshooting. Network connectivity testing (ping, traceroute, telnet, curl). Network statistics and monitoring. Firewall basics (iptables/firewalld). Understanding network namespaces.

MediumTechnical

74 practiced

Write iptables commands to allow SSH (port 22) only from subnet 10.5.0.0/16, log other SSH connection attempts with a custom log prefix, and ensure the logging is rate-limited to avoid flooding the logs.

Sample Answer

Approach: Allow established connections, accept SSH from 10.5.0.0/16, log other SSH attempts with a custom prefix and rate-limit the logs, then drop them. Persist rules with iptables-save/restore or your distro's firewall tool.

# Allow established/related traffic
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow SSH from the trusted subnet
iptables -A INPUT -p tcp -s 10.5.0.0/16 --dport 22 -m conntrack --ctstate NEW -j ACCEPT

# Log other SSH attempts with rate limiting (1 per minute burst 5) and custom prefix
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m limit --limit 1/min --limit-burst 5 -j LOG --log-prefix "SSH-DROP: " --log-level 4

# Drop remaining SSH attempts
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j DROP

Key points:- Place ACCEPT before LOG/DROP so trusted subnet is allowed.- Use conntrack to target NEW connections only.- limit module prevents log flooding (tune --limit/--limit-burst as needed).- Use --log-prefix to identify events in syslog/journald.- Persist rules (iptables-save > /etc/iptables/rules.v4 or use firewalld/nftables conversion).- Test with a safe maintenance window and ensure lockout prevention (e.g., temporary allow your admin IP).

MediumTechnical

138 practiced

Describe methods to persist `iptables` rules across reboots on Debian/Ubuntu: using `iptables-save`/`iptables-restore`, `netfilter-persistent`, or migrating to `nftables` via `iptables-translate`. Compare pros and cons of each approach for a production environment.

Sample Answer

For production SREs you want persistence that’s reliable, auditable, and integrates with automation. Three common options:

1) iptables-save / iptables-restore (classic)- How: save rules, restore on boot.

bash

# Save current rules
sudo iptables-save > /etc/iptables/rules.v4
# Restore on boot (systemd unit or /etc/network/if-pre-up.d script)
sudo iptables-restore < /etc/iptables/rules.v4

- Pros: simple, stable, minimal dependencies, exact iptables semantics preserved. Good when you manage rules as files and apply with config management (Ansible/Chef).- Cons: no builtin atomic reload, manual restore wiring needed, harder to manage incremental changes, less visibility/validation tooling.

2) netfilter-persistent / iptables-persistent- How: Debian package that uses iptables-save/restore and integrates with init/systemd.

bash

sudo apt install netfilter-persistent iptables-persistent
# saves automatically on package scripts or via:
sudo netfilter-persistent save

- Pros: packaged, automatic restore on boot, integrates with system services, easier operational workflows; supports both IPv4/IPv6.- Cons: still fundamentally file-based snapshots (less transactional control), upgrades sometimes overwrite files—ensure CI-managed rule sources.

3) Migrate to nftables (iptables-translate)- How: translate rules, use nftables native persistence.

bash

# Translate iptables chains to nft format
iptables-translate -A INPUT -p tcp --dport 80 -j ACCEPT
# Apply and persist via /etc/nftables.conf or systemd nftables.service
sudo nft -f /etc/nftables.conf

- Pros: modern, single kernel API (nftables), atomic rulesets, better performance/scalability, richer semantics, easier programmatic management, better tooling and stateful set support.- Cons: migration risk—translation may be imperfect for complex chains/conntrack behavior; ecosystem tooling historically iptables-first (some workflows require change); learning curve.

Recommendation for production:- Short term/simple: use netfilter-persistent + config management to keep authoritative files in source control and CI deployments.- Long term: plan migration to nftables—test translation with iptables-translate, validate in staging (traffic tests, conntrack behavior), update runbooks and automation. Use automated test/CI to validate rule changes and deploy atomically.

MediumTechnical

104 practiced

Intermittent packet loss is observed on a VM. Propose a diagnosis plan using `mtr`, continuous `ping` with varying packet sizes, `ethtool` and driver stats, and host/logging checks. Include how to determine whether the issue is the VM guest, the hypervisor, or the physical NIC.

Sample Answer

Start with goals: reproduce/measure loss, narrow scope (guest vs hypervisor vs NIC), collect artifacts for postmortem.

1) Baseline network path with mtr- Run:

bash

mtr -rwzbc 1000 <target-ip>

- Look for where loss first appears and increasing RTT/jitter. If loss starts at first hop (gateway) suspect local host/hypervisor/NIC.

2) Continuous ping with varying packet sizes (guest)- Small packets: `ping -i 0.2 -s 64 -c 1000 <target>`- Large packets (MTU stress): `ping -i 0.2 -s 1400 -M don't -c 1000 <target>`- Compare loss patterns. Loss only at large sizes → MTU/fragmentation or offload/driver issue.

3) Check guest NIC stats & offloads- `ip -s link show dev eth0`- `ethtool -S eth0` (driver stats)- `ethtool -k eth0` (offload settings)- Look for rx/tx errors, dropped, fifo, checksum, skb_overflow counters. If guest shows errors, suspect virtual NIC or host steal.

4) Host/hypervisor checks- On host, correlate timestamps of guest loss. Check host interface and bridge/vswitch:

bash

ip -s link show dev vnetX; ethtool -S vhost0; dmesg | tail -n 200

- Inspect host CPU steal, load, IO wait (top, vmstat). High steal can cause drops.

5) Physical NIC and driver- On host: `ethtool -S eno1`, `ethtool -i eno1` (driver/version), `ethtool -k eno1`- Check firmware, NIC queue drops, FEC, link flaps: `dmesg` and `journalctl -k`- Try toggling offloads (e.g., disable GRO/TSO) to see if problem disappears.

6) Correlation & isolation- If mtr shows loss only from guest but host NIC counters are clean → guest-side virtual driver or VM scheduling.- If host counters show drops or physical link flaps → physical NIC/driver/firmware.- If multiple VMs on same host experience same patterns → host/NIC issue.- If loss disappears when moving VM to another host or using a different vNIC type (virtio vs emulated) → hypervisor/driver.

7) Logging & next steps- Collect: mtr, ping logs with timestamps, `ethtool -S` outputs, host NIC logs, dmesg, hypervisor logs (libvirt/KVM), and metric graphs (packet drops, CPU steal).- Mitigations: toggle offloads, update NIC driver/firmware, adjust MTU, migrate VM, schedule maintenance for firmware/driver upgrade.

EasyTechnical

100 practiced

Explain MTU and Path MTU Discovery (PMTUD). Show the command to set MTU on `eth0` (`ip link set dev eth0 mtu 1400`) and demonstrate how to detect an MTU black hole using `ping -M do -s` and `tracepath`. Explain why tunnels often require MTU adjustments.

Sample Answer

MTU (Maximum Transmission Unit) is the largest IP packet (including headers) that can be transmitted on a network link without fragmentation. Path MTU Discovery (PMTUD) lets endpoints learn the smallest MTU along the path by sending packets with the DF (Don't Fragment) bit set; routers that cannot forward a DF packet send back ICMP "Fragmentation Needed" messages with the next-hop MTU.

Set MTU on eth0:

bash

ip link set dev eth0 mtu 1400

Detecting an MTU black hole: if intermediate devices drop DF packets but block ICMP "Fragmentation Needed", PMTUD fails and connections stall (black hole). You can probe manually:

1) Ping with DF and varying sizes (payload size; adjust for IP+ICMP headers ~28 bytes):

bash

# try payload 1372 -> 1372 + 28 = 1400 total
ping -M do -s 1372 <destination>
# reduce size until it succeeds
ping -M do -s 1200 <destination>

If larger pings silently hang or never succeed while smaller ones work, that indicates an MTU/ICMP blocking problem.

2) Use tracepath (user-level PMTUD tool):

bash

tracepath <destination>

tracepath reports the discovered path MTU (look for “pmtu” or a line showing reduced MTU). If tracepath shows a lower MTU than your interface, PMTUD is working; if TCP stalls but tracepath can't determine PMTU (or ICMP responses absent), suspect an MTU black hole.

Why tunnels need MTU adjustments: tunnels (GRE, IPsec, VXLAN, etc.) add extra headers encapsulating original packets, reducing effective payload room. For example, a 1500 MTU on the outer interface minus ~50 bytes of tunnel overhead means inner packets must be <=1450. Without adjusting MTU or using MSS clamping on TCP, packets will be fragmented or dropped, causing performance problems. Typical mitigations: lower interface MTU, enable MSS clamping on firewalls/load balancers, or use TCP Path MTU-aware stacks.

MediumTechnical

102 practiced

You observe a very large number of sockets in TIME_WAIT on a busy web server. Explain why TIME_WAIT exists, how to inspect aggregate counts with `ss -s` and `ss -tan`, and discuss mitigation techniques and trade-offs such as kernel tuning and TCP termination placement.

Sample Answer

TIME_WAIT exists to ensure reliable TCP connection teardown: the endpoint that actively closes (sends the first FIN) stays in TIME_WAIT for 2*MSL (typically ~60–120s) to (1) allow retransmission of the final ACK in case the peer retransmits FIN, and (2) prevent delayed packets from a previous connection (same 4-tuple) being interpreted by a new connection.

Inspecting counts:- Aggregate summary: `ss -s` shows overall socket states and TIME-WAIT count.- Detailed list: `ss -tan state time-wait` lists TIME_WAIT TCP sockets; use `ss -tan | wc -l` for totals or `ss -tan | awk '{print $5}' | cut -d: -f2 | sort | uniq -c` to see per-port breakdown.

Example:

ss -s
Total: 12345 (kernel 20000)
TCP:   8000 (estab 120, closed 7000, orphaned 0, timewait 7880/0), ports 0
ss -tan state time-wait | wc -l
7880

Mitigation techniques and trade-offs:- Move TCP termination to a load balancer or reverse proxy (connection pooling): reduces TIME_WAIT on backend app servers but concentrates sockets on the LB; increases complexity and single-point capacity planning.- Use keep-alive / HTTP persistent connections to reduce connection churn.- Kernel tuning (trade correctness vs resource use): - Lower `net.ipv4.tcp_fin_timeout` to shorten TIME_WAIT (may risk dropped final ACK retransmissions). - `net.ipv4.tcp_tw_reuse=1` allows reuse of TIME_WAIT sockets for new outgoing connections (Linux 3.9+); safe mainly for clients initiating lots of outbound connections, not recommended for servers accepting inbound. - `net.ipv4.tcp_tw_recycle` is deprecated/unsafe behind NAT — avoid. - Increase ephemeral port range (`net.ipv4.ip_local_port_range`) and decrease `tcp_max_syn_backlog`? (increase backlog if needed).- Application-level: use connection pooling (keep connections open), HTTP/2 or multiplexing to reduce parallel TCPs.- Architecture: scale horizontally (more IPs/servers) to avoid port exhaustion.

Monitoring & safety:- Alert on rising TIME_WAIT relative to ephemeral ports exhaustion.- Prefer moving termination to an LB and using connection reuse/pooling before aggressive kernel knobs. Kernel flags can help short-term but may introduce subtle correctness/security issues.

Unlock Full Question Bank

Get access to hundreds of Linux Networking Configuration and Troubleshooting interview questions and detailed answers.

Join thousands of developers preparing for their dream job.