Network Connectivity Troubleshooting Questions

Techniques and systematic approaches for diagnosing and resolving network level connectivity problems across wired and wireless links and device interfaces. Topics include checking physical connections and link status, verifying internet protocol addressing and configuration, distinguishing between dynamic addressing and static addressing issues, resolving domain name system name resolution failures, examining routing tables and route reachability, inspecting address resolution protocol entries and switch tables, validating virtual local area network and trunk configurations, and interpreting interface statistics such as errors, drops, and collisions. Emphasis is placed on using diagnostic tools such as ping and traceroute, interpreting operating system network configuration commands and device show commands, testing from multiple endpoints, and recreating problems in lab topologies to isolate where traffic is breaking.

HardTechnical

104 practiced

A load balancer marks several backend servers as unhealthy and drains them, causing application outages. Provide a concrete checklist to debug: verify health-check request path and expected HTTP response code, test the health-check from a host on the same subnet, check firewall rules between LB and backend, confirm backend process listening on expected port, examine TLS/SNI/host-header mismatches, and review LB logs for response timings or failures.

Sample Answer

**Approach / checklist (ordered, concrete steps)**

1. Confirm LB health-check config- Verify path, method, and expected status code in LB config (e.g., AWS ALB target-group -> health check path / expected 200/302).- Check for host-header or SNI settings.

2. Reproduce health-check from same subnet- SSH to an instance on LB subnet and run:

bash

# HTTP
curl -I -H "Host: backend.example.com" http://10.0.1.12:8080/health --max-time 5
# HTTPS with SNI
openssl s_client -connect 10.0.1.12:443 -servername backend.example.com </dev/null

3. Check firewall / security groups / ACLs- Confirm LB → backend port allowed:

bash

# Linux host
sudo iptables -L -n | grep 8080
# AWS
aws ec2 describe-security-groups --group-ids sg-...

- Verify network ACLs on subnet allow ephemeral return traffic.

4. Confirm backend process and listening port- On backend host:

bash

sudo ss -ltnp | grep :8080
ps aux | grep my-app

5. Inspect TLS/SNI/Host-Header mismatches- Ensure certificate CN/SAN matches SNI sent by LB.- If LB sends Host header override, backend must accept it (vhost config in nginx/apache).

6. Review LB logs & metrics- Check response codes, latency, error rate, and health-check timestamps.- Example: ELB access logs or CloudWatch metrics for 4xx/5xx counts.

7. Capture traffic if needed- tcpdump on backend to see incoming health-checks:

bash

sudo tcpdump -nn -i eth0 host 10.0.1.5 and port 8080 -w /tmp/hc.pcap

8. Fix & verify- Apply firewall, service, or LB config fix; force immediate re-check or deregister/register backend and confirm healthy in LB console; monitor for restored traffic.

Expected outcome: identify root cause (network ACL, service not listening, TLS mismatch, wrong Host/SNI) and restore healthy state with minimal disruption.

MediumTechnical

76 practiced

Compare and contrast traceroute variants (UDP, ICMP, TCP) and explain real-world scenarios where each is useful. Describe how firewalls and middleboxes can affect each variant differently and when you would use tcptraceroute or traceroute -T to debug connectivity that is otherwise filtered.

MediumTechnical

100 practiced

You capture a TCP flow exhibiting retransmissions and duplicate ACKs. Describe how you would use the capture together with system/network metrics (server CPU, NIC errors, switch interface counters) to identify whether the root cause is network congestion, packet corruption, server slowness, or a middlebox interfering. What signs in the capture point to each cause?

Sample Answer

**Approach (high-level)** Correlate the packet capture timeline with host and network counters. Use the capture to classify the TCP behavior (fast retransmit, RTO, duplicate ACKs, out-of-order) and use metrics (server CPU, NIC errors, switch counters, interface drops, queue depths) to attribute cause.

**Steps to follow**1. Anchor events by timestamps in the pcap and compare to server CPU spikes, NIC error timestamps, and switch counters.2. Inspect TCP flags (SACK, dup ACKs, RTO vs fast retransmit), RTT samples, sequence/ack progression, and any packet modifications (MSS, TTL).3. Cross-check device logs (interface drops, congestion, policers) and host stats (top, iostat, tx queue length).

**Signs & how to interpret**

- Network congestion - Capture: many duplicate ACKs followed by fast retransmit; increasing queueing RTT; packets still arrive but delayed; multiple flows show similar patterns. - Metrics: switch interface output drops, tail-drop queue depth increases, ECN marks or RED drops, high interface utilization. - Interpretation: congestion causes packet loss seen as dupACK-driven fast retransmits and higher RTTs.

- Packet corruption / link errors - Capture: retransmissions without preceding congestion signs; checksum errors visible (if capture includes NIC-calculated checksums, compare with NIC error counters); frequent single-packet losses with no correlated high utilization. - Metrics: NIC Rx/Tx errors, CRC/FCS errors, SFP optics alarms, switch CRC/FCS counters incrementing. - Interpretation: link-level errors cause packets to be dropped/corrupted, producing retransmits not correlated with congestion.

- Server slowness (application or host) - Capture: delayed ACKs, long gaps between ACKs (paused acking), zero-window or persist probes, retransmits that occur after long ACK delays (RTO pattern), limited inflight growth. - Metrics: high CPU steal/usage, high syscall latencies, full NIC TX queues, high disk I/O, socket buffers full. - Interpretation: slow processing/stack causes receiver or sender delays leading to retransmits or delayed ACK behavior rather than network drops.

- Middlebox interference - Capture: altered MSS/window scaling, abrupt resets, out-of-order sequence rewrites, duplicated packets, changes in TTL, retransmissions repeating identical payload with same timing, inconsistent ACK behavior across flows. - Metrics: firewall/IDS logs showing reassembly or connection tracking resets, NAT translations, and middlebox counters. Absence of link errors or saturation while only specific flows are affected. - Interpretation: middlebox modifying or dropping packets (e.g., TCP optimizer, proxy, NAT) shows deterministic/flow-specific anomalies.

**Practical correlation tips**- If capture shows fast retransmit (triple dupACKs) and switch shows drops -> congestion.- If capture shows single-packet corruption/retransmit patterns with NIC CRC errors -> link errors.- If ACKs are delayed and CPU/iowait spike at same time -> server slowness.- If only particular path or flow is impacted and middlebox logs match timestamps -> middlebox.

Use this checklist to rapidly narrow root cause and then reproduce with targeted tests (iperf, controlled pings, capture on both ends).

MediumTechnical

83 practiced

You suspect an ACL or firewall is blocking traffic intermittently to an application. Describe the quickest, least-invasive tests to confirm whether the firewall is the cause: what packet captures to run and where, what firewall logs to inspect, how to temporarily enable logging for specific rules, and how to validate stateful vs stateless behavior in tests.

Sample Answer

**Approach (quick, non‑invasive)** - Capture at endpoints first (client and server), then at firewall inside/outside interfaces. Compare timestamps to see where packets stop or are dropped. Inspect firewall accept/deny logs and connection/state tables.

**Packet captures to run and where** - Client: capture SYNs and application traffic.

bash

# on client
sudo tcpdump -nni eth0 host SERVER_IP and tcp port 443 and '(tcp[tcpflags] & tcp-syn) != 0'

- Server: same filter to confirm arrival.- Firewall: capture both WAN and LAN-facing interfaces to see if traffic reaches and leaves firewall.

bash

# on firewall
sudo tcpdump -nni eth0 host CLIENT_IP and host SERVER_IP

**Firewall logs to inspect** - Policy/ACL deny logs, nat logs, and intrusion/prevention drops. Look for timestamps matching missing flows, rule IDs, interfaces, source/dest, ports, verdict (deny/drop). Check syslog or management plane (e.g., /var/log/messages, auth.log, or vendor-specific).

**Temporarily enable logging for specific rules** - Add logging to the ACL or enable per-rule logging via CLI/UI. Example (Cisco ASA):

text

access-list OUTBOUND extended permit tcp any host SERVER_IP eq 443 log
logging enable

- For iptables:

bash

sudo iptables -I FORWARD 1 -p tcp --dport 443 -s CLIENT_IP -d SERVER_IP -j LOG --log-prefix "ACL_DROP: "

- Use short-lived changes and monitor syslog; remove after test.

**Validate stateful vs stateless behavior** - Stateful: SYN flows accepted then subsequent packets tracked in conntrack. Check conntrack table:

bash

sudo conntrack -L | grep SERVER_IP

- Stateless: each packet evaluated against ACL; a SYN might be allowed but subsequent responses blocked. Test by initiating a TCP handshake and noting if SYN arrives and SYN/ACK returns. For UDP, send request and confirm response; stateless devices won't auto-create return entries—use symmetric ACLs to allow both directions.

**Additional tips** - Correlate timestamps across captures and logs. Use short, repeatable tests (tcping, hping3). Reproduce during maintenance window if enabling packet logging is verbose.

MediumTechnical

73 practiced

BGP neighbors on a WAN link are flapping frequently, causing routing churn. List the diagnostic steps (check physical interface stability, examine 'show ip bgp neighbors <peer>' for errors and timers, check for authentication mismatches, monitor logs for BGP NOTIFICATION messages, and use targeted debug), and outline short-term and long-term mitigation measures.

Sample Answer

**Diagnostic stappen (ordered, actionable)**

1. **Verify physical/link stability** - Check interface counters: errors, CRC, drops, duplex/speed mismatch, SFP/cable issues. - Run carrier tests or request provider line stats (LOS, BER).

2. **Examine BGP neighbor state/details** - show ip bgp neighbors <peer> - Note state changes, Last reset reason, session uptime, message counters (opens/updates/notifications), negotiated timers and capabilities (MD5, AS_PATH, graceful restart). - Confirm TTL, ebgp multihop, update-source if applicable.

3. **Authentication and configuration** - Verify MD5/password and AS numbers match on both ends. - Confirm peer IP, route-maps, prefix-lists, and next-hop-self aren’t triggering session resets.

4. **Logs and NOTIFICATION messages** - Monitor syslog for BGP NOTIFICATIONs and reason codes (e.g., hold timer expired, finite state machine). - Correlate timestamps with interface flaps.

5. **Targeted debug** - Use debug ip bgp <peer> or debug neighbor events with care (off-peak, rate-limit). - Capture packet-level with tcpdump/wireshark to inspect BGP OPEN/NOTIFICATION/KEEPALIVE.

**Short-term mitigations**- Increase BGP timers (keepalive/hold) modestly to mask transient microbursts.- Enable BFD only if stable and supported (or temporarily disable if misbehaving).- Apply prefix-lists to reduce large UPDATE storms; flap dampening as emergency measure.- Move traffic to redundant path if available.

**Long-term fixes**- Replace faulty optics/cabling, fix duplex/speed mismatches, or upgrade port hardware.- Tune BGP design: use iBGP/route-reflectors, consistent timers, MD5 and TTL-security, graceful restart.- Implement monitoring/alerting (paired syslog + NetFlow + probe) and run root-cause analysis to eliminate provider link instability.- Document and standardize peer configs; run pre-deploy validation and scheduled maintenance windows for sensitive changes.

I would follow this sequence, correlate data across logs and packet captures, and apply short-term mitigations only after understanding root cause before committing long-term changes.

Unlock Full Question Bank

Get access to hundreds of Network Connectivity Troubleshooting interview questions and detailed answers.

Join thousands of developers preparing for their dream job.