Networking Fundamentals and Troubleshooting Questions

Comprehensive coverage of core computer networking principles and the practical diagnostic and operational skills required to design, operate, and troubleshoot production systems. Fundamental concepts include the Open Systems Interconnection model layers, the Transmission Control Protocol and the Internet Protocol stack, the User Datagram Protocol, socket and port semantics, address notation and subnetting, Network Address Translation, Dynamic Host Configuration Protocol, and the Domain Name System resolution process. Infrastructure and architectural topics include switching and virtual local area networks, routing concepts and routing table behavior including Border Gateway Protocol basics, load balancing strategies and failure modes, firewall and access control, virtual private network technologies, and container and service network communication patterns. Diagnostic and tooling skills cover connectivity testing and path analysis, process and socket inspection, packet capture and analysis, and common command line tools and utilities used for network investigation. Performance and reliability topics include latency, bandwidth and throughput, packet loss, congestion and congestion control, connection pooling, timeout and retry strategies, and approaches to optimization. Observability, monitoring, and security practices include collecting and interpreting network metrics, logs, and traces, using packet capture tools for root cause analysis, and understanding how network issues surface in distributed applications. At senior levels expect discussion of network performance tuning, capacity planning, load balancer behavior at scale, and design decisions that affect system reliability and security.

EasyTechnical

50 practiced

List six or more Linux command-line networking tools you regularly use for troubleshooting (for example ss, netstat, tcpdump, ip, ethtool). For each tool give one example command and describe a concrete scenario where that command is the best first step.

Sample Answer

**Answer (Systems Administrator perspective)**

ss — view socket state - Command:

bash

ss -tulpen

- Scenario: Quick check when a service appears unreachable on host (confirm it's LISTENing, bound IP, and PID before application-level debugging).

netstat — legacy interface for connections & routes - Command:

bash

netstat -plant

- Scenario: On older systems without iproute2, identify which process holds an established connection causing resource exhaustion.

tcpdump — packet capture/inspection - Command:

bash

tcpdump -i eth0 host 10.0.0.5 and port 443 -w capture.pcap

- Scenario: First step when intermittent HTTPS failures occur between servers — capture traffic to see TLS handshakes or retransmits.

ip (iproute2) — addresses, routes, links - Command:

bash

ip addr show dev eth0 && ip route show

- Scenario: After NIC flaps or failover, confirm IPs are on correct interface and routes point to expected gateway.

ethtool — NIC diagnostics / link settings - Command:

bash

ethtool eth0

- Scenario: When link is down or duplex mismatches suspected after physical move or switch config change.

traceroute / mtr — path and latency analysis - Command:

bash

mtr --report --tcp 8.8.8.8

- Scenario: First step to locate where high latency or packet loss occurs across network hops.

nmap — port/service discovery - Command:

bash

nmap -sT -p 1-1024 10.0.0.10

- Scenario: Verify firewall rules or service exposure during access issues from a specific host.

dig — DNS resolution checks - Command:

bash

dig +short www.example.com @8.8.8.8

- Scenario: When a host can't reach services by name, confirm authoritative and recursive resolution.

curl — HTTP(S) troubleshooting - Command:

bash

curl -vS https://api.example.internal/health

- Scenario: Validate TLS, headers, and response bodies from an API endpoint before deeper app debugging.

Each tool above is my go-to first step depending on symptom: socket/service, routing, DNS, link, path, or packet-level issues.

EasyTechnical

25 practiced

What is ARP and how does an ARP request/reply exchange work? List common causes of ARP-related reachability problems such as duplicate IPs, stale cache entries and proxy ARP. Outline step-by-step how you would diagnose an ARP problem on Linux using ip neigh, arping and tcpdump.

Sample Answer

**What is ARP & how it works**- ARP (Address Resolution Protocol) maps IPv4 addresses to MAC addresses on a local L2 network.- Typical exchange: 1. Host A needs MAC for IP B, sends ARP Request as broadcast (ff:ff:ff:ff:ff:ff) asking “who has IP B?” 2. Host B sees request, replies with ARP Reply unicast containing B’s MAC. 3. A caches the mapping in its ARP table (neighbour table).

**Common ARP-related reachability causes**- Duplicate IPs: two hosts claim same IP → intermittent or constant collisions.- Stale cache entries: device moves or interface resets but other hosts keep old MAC.- Proxy ARP misconfiguration: router responds for IPs it shouldn’t, hiding real host.- VLAN/port-security issues, asymmetric routing, or hardware offload bugs.

**Step-by-step Linux diagnosis**1. Check neighbour table:

bash

ip neigh show

- Look for REACHABLE/STALE/FAILED and unexpected MACs.

2. Probe with arping to verify who answers:

bash

sudo arping -I eth0 -c 4 10.0.0.5

- If you get replies, note the MAC; no reply → host down or filtered.

3. Detect duplicates: run arping from two switches/hosts; duplicate replies with different MACs indicate duplicate IP.

4. Passive capture with tcpdump to observe ARP traffic:

bash

sudo tcpdump -eni eth0 arp -vv

- Watch for multiple ARP replies, gratuitous ARP (GARP), or proxy ARP responses (look at sender/target IP/MAC).

5. Clear and retest:

bash

sudo ip neigh flush 10.0.0.5 dev eth0

- Then arping again to force fresh resolution.

6. If proxy suspected, check router config and source of GARP. Use switch CAM table to map MAC→port.

Outcome: combine ip neigh state, arping replies, and tcpdump traces to identify duplicate IPs, stale entries, or misconfigured proxy ARP and then correct IP assignments, flush caches, or fix router/switch configs.

EasyTechnical

36 practiced

Explain what information the Linux commands ip addr, ip route, ip neigh, and ethtool eth0 provide and how you use each during initial troubleshooting when a host reports 'network unreachable'. Provide an ordered checklist of commands and checks from link to application.

HardTechnical

28 practiced

You observe BGP route flaps and traffic shifting between autonomous systems causing intermittent reachability. Explain BGP attributes such as AS path, local preference, MED and communities, describe BGP path selection, and outline a step-by-step approach to isolate the source of flaps and stabilize routing using methods like route filters or dampening.

Sample Answer

**BGP attributes — quick definitions**- AS_PATH: ordered list of ASes a route traversed; used to detect loops and prefer shorter paths.- LOCAL_PREF: local router value (higher = more preferred) propagated inside your AS only; controls outbound exit.- MED (Multi-Exit Discriminator): suggests preferred entry into an AS when multiple links exist (lower = preferred); exchanged between neighboring ASes.- COMMUNITIES: opaque tags attached to routes to signal actions (e.g., no-export, local preferences, prepending policies) across routers.

**BGP path selection (condensed order)**1. Highest LOCAL_PREF2. Shortest AS_PATH3. Lowest ORIGIN type (IGP < EGP < INCOMPLETE)4. Lowest MED (if from same neighbor)5. eBGP over iBGP6. Lowest IGP cost to next-hop7. Older route or lowest router ID as tiebreaker

**Troubleshooting & isolation steps**1. Observe: collect MRT/route-refresh or BGP RIB snapshots and syslog timestamps; enable debug on affected peers during maintenance window.2. Correlate: map flaps to specific prefixes, peers, timestamps. Use tools: bgpdump, MRT, Zebra logs, or provider portal.3. Identify source: check frequent AS_PATH changes, suspicious AS prepends, or duplicate origin announcements. Query peers with show bgp neighbors and show bgp prefix.4. Contain: apply inbound route filters on affected peering to block malformed/unstable prefixes (prefix-lists + AS-path access-lists). Example: deny overly specific or bogon prefixes.5. Stabilize: enable/conservative route flap dampening with tuned penalties (avoid aggressive defaults) or use BGP prefix suppression on unstable prefixes.6. Policy fixes: adjust LOCAL_PREF or MED via communities from peers to steer traffic consistently; ask upstream to remove accidental announcements or adjust prepending.7. Verify: monitor RIB/NH and traffic flows, validate convergence times, and gradually relax dampening once stable.

**Best practices**- Keep clear change windows for debug.- Coordinate with upstreams and peers using communities.- Use telemetry (SNMP, flow, BGP monitoring) to detect recurrence.

HardTechnical

25 practiced

A distributed service shows high tail latency (p99) under load but median latency remains low. Discuss network phenomena that can cause tail latency such as packet loss bursts, head-of-line blocking, TCP slow start or delayed handshakes. Provide debugging steps, experiments and mitigations to reduce p99 latency in a fan-out microservice environment.

Sample Answer

**Situation / Summary**I’m a systems administrator diagnosing p99 latency spikes in a fan-out microservice setup where median latency is fine but tails are high. Common network causes: packet loss bursts, head‑of‑line (HOL) blocking (e.g., HTTP/1.1 or TCP queues), TCP slow start on new connections, delayed handshakes (SYN retries), and NIC/driver or switch buffer exhaustion.

**Debugging steps & experiments**- Observe metrics: collect per‑node p50/p95/p99, retransmits, RTT, TCP RTOs, SYN/ACK counts, NIC drops, queue sizes (ifq), and ECN marks.- Enable tcp_info export (ss/netstat) and eBPF traces for retransmits, tail retransmits and zero-window events.- Correlate with busiest flows and fan‑out degree: instrument services to log start/end and call fan‑out subcalls to find slow children.- Controlled experiments: - Replay load while toggling keepalive/connection pooling to quantify TCP slow start impact. - Switch between HTTP/1.1 and HTTP/2 or gRPC (multiplexing) to test HOL effects. - Introduce synthetic packet loss to reproduce bursts and validate retransmit patterns.

**Mitigations**- Connection management: enable connection pooling, keepalives, and long‑lived connections to avoid repeated slow start. Use TCP_FASTOPEN where safe.- Multiplexing: move to HTTP/2 or gRPC to reduce HOL blocking and fewer TCP connections.- QoS & network tuning: increase switch buffer size if possible, enable ECN, tune txqueuelen, net.core.rmem/wmem, and adjust TCP_RACK/TCP_BBR to improve loss recovery.- Load shaping: limit fan‑out concurrency per request, use hedged requests or tail‑aware retries with jitter for only high‑latency calls.- Observability: add distributed tracing with high‑resolution timestamps, per‑hop histograms for p99, and alert on retransmit or NIC drop thresholds.- Infrastructure: ensure NIC drivers/firmware up to date, offload features tuned, and colocate high‑fanout services to reduce network hops.

**Why these help**Pooling avoids slow start; multiplexing prevents per‑connection HOL; BBR/RACK and ECN shorten recovery from bursts; hedging reduces impact of one slow child. Observability and controlled experiments let you prove causality and measure improvements.

Unlock Full Question Bank

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

Join thousands of developers preparing for their dream job.