A user says, "the site is slow" or "DNS is broken." Naming a protocol is not a diagnosis. A strong interview answer localises the failure from evidence, states what remains unknown, and chooses a test that separates two competing explanations. Server wait, stale DNS, and a TCP reply lost on the return path produce different evidence. Each diagnosis connects the symptom, layer, observation, interpretation, and next separating test.
Computer network troubleshooting starts with a testable path
The lab path is client 10.10.20.15, resolver 10.10.20.53, gateway 10.10.20.1, NAT address 203.0.113.10, host api.campus.example, and origin 198.51.100.20:443. 198.51.100.0/24 and 203.0.113.0/24 are documentation ranges, not live production addresses.
Use this six-part answer frame:
Define the symptom precisely.
Scope it to one user, host, service, or every destination.
Map name resolution, route, transport, and application.
Observe each relevant boundary.
State the narrowest supported conclusion.
Choose a test that could falsify it.
A DNS answer does not prove reachability; a TCP connection does not prove a correct application response. Technical Interview: OS, DBMS, CN & OOP Prep supports a bounded chain, not a tool list. Say, "the evidence localises the delay after TLS," not, "the network is fine."
Latency scenario: split 650 ms by phase
Five pings to 198.51.100.20 show 0% loss and min/average/max RTTs of 18/20/24 ms. For https://api.campus.example/report, curl reports time_namelookup=0.012, time_connect=0.034, time_appconnect=0.110, time_starttransfer=0.610, and time_total=0.650 seconds. These timestamps are cumulative, so subtract adjacent values:
DNS:
0.012 x 1000 = 12 ms.TCP setup:
(0.034 - 0.012) x 1000 = 22 ms.TLS:
(0.110 - 0.034) x 1000 = 76 ms.Wait after TLS for the first response byte:
(0.610 - 0.110) x 1000 = 500 ms.Body transfer:
(0.650 - 0.610) x 1000 = 40 ms.
Check: 12 + 22 + 76 + 500 + 40 = 650 ms. The dominant phase is application or upstream work after TLS, not DNS or body transfer.
Repeat with --resolve api.campus.example:443:198.51.100.20: 0 ms DNS, 21 ms TCP, 76 ms TLS, 501 ms server wait, and 40 ms transfer. Thus 0 + 21 + 76 + 501 + 40 = 638 ms. DNS saves only 12 ms; the roughly 500 ms wait remains. Inspect server timing, database calls, or upstream services. For handshake foundations, review TCP vs UDP: Transport Layer Explained.
DNS scenario: stale answer or failed resolver?
At 10:00:00, dig api.campus.example @10.10.20.53 A returns NOERROR, answer 198.51.100.10, remaining TTL 42, in 6 ms. The lab authoritative server 203.0.113.53 returns 198.51.100.20, TTL 300, in 18 ms.
The quick cached answer differs from the authoritative answer. This is neither timeout nor NXDOMAIN. curl --resolve api.campus.example:443:198.51.100.20 returns HTTP 200 in 86 ms; old 198.51.100.10 gets a TCP reset. The supported diagnosis is stale recursive cache.
At 10:00:43, after expiry, query 10.10.20.53 again. If the old address remains, compare another resolver and inspect split-horizon or cache behaviour.
Observation | Interpretation |
|---|---|
| Investigate the answer path or cache |
| The queried name is reported absent |
| The resolver could not complete resolution |
No response before timeout | Test reachability, firewall policy, and resolver availability |
For the recursive and authoritative lookup foundation, see Application Layer Protocols: DNS and HTTP Guide.
Packet-flow scenario: locate a missing TCP reply
Client 10.10.20.15:51514 opens HTTPS to 198.51.100.20:443; NAT rewrites it to 203.0.113.10:40001. The client captures SYNs at 0.000 s, 1.000 s, and 3.000 s, all with initial sequence 1000, but no SYN-ACK. The server receives them at 0.022 s, 1.022 s, and 3.022 s, then sends SYN-ACKs at 0.023 s, 1.023 s, and 3.023 s with acknowledgement 1001.
Forward routing and port reachability work, and the server TCP stack responds. The application has not seen HTTPS. Failure is after the server NIC and before the client capture. Reverse routing, an upstream ACL, a stateful firewall, and NAT state remain possible.
Capture simultaneously on the gateway WAN and LAN using host 198.51.100.20 and tcp port 443. If SYN-ACK reaches WAN as 198.51.100.20:443 -> 203.0.113.10:40001 but not LAN as 198.51.100.20:443 -> 10.10.20.15:51514, inspect NAT state and the gateway firewall. If it never reaches WAN, inspect reverse routing and upstream filtering. Traceroute alone cannot identify the dropper.
Packet evidence changes the next test
Observation | What it proves | What it does not prove | Next test |
|---|---|---|---|
TCP RST | Active rejection | Rejecting listener or policy | Check listener and policy |
Three unanswered SYNs over | Timeout | Drop location | Capture next boundary |
Handshake, then HTTP | Application path returned error | Failing server or upstream | Inspect server or upstream service |
Handshake, then repeated data retransmissions | Delivery fails after setup | Loss direction or boundary | Compare captures and packet sizes |
Flags and direction are more precise than "packet loss." SYN without SYN-ACK, RST, retransmissions, duplicate ACKs, and zero-window advertisements indicate different mechanisms. One capture cannot locate loss, so move one boundary at a time.
Use this sentence pattern: "I observed X at point A, so Y is known; Z is still possible; I would run test B because its outcomes separate Z1 from Z2."
Network troubleshooting tools belong in a sequence
Match tool to question: ip addr and ip route for addressing and routes; dig for DNS status, answer, TTL, and time; ping for ICMP reachability and RTT; tracepath or traceroute for path clues; nc -vz host 443 or TCP connect for service reachability; curl for phases; ss for sockets; tcpdump or Wireshark for flags, retransmissions, and direction.
Twenty ICMP echoes may show 0% loss and 20 ms average RTT while 4 of 10 TCP connections to 443 time out. Ping proves neither TCP permission nor application health. Blocked ping does not prove HTTPS is down.
Avoid four evidence traps:
Changing DNS, VPN, and firewall together destroys causality. Change one variable.
Fast DNS may be wrong. Inspect the answer.
A TCP handshake does not prove HTTP success. Inspect status and timing.
One endpoint capture cannot locate a drop. Compare boundaries.
How technical interviews test these scenarios
Prompts ask you to interpret timings, compare recursive and authoritative DNS, or reason from SYN, SYN-ACK, ACK, RST, and retransmissions. State scope and assumptions first. For wider revision, use CS Fundamentals for Placements.
In 60 seconds, restate the symptom, draw its path, mark the last good boundary, cite one observation, name at most two hypotheses, choose a splitting test, and name the next owner, such as resolver, firewall, network path, or application team. Models: 500 ms server wait, stale 198.51.100.10 versus current 198.51.100.20, and SYN-ACK lost on return.
Computer network troubleshooting: the short version and next step
Wrong or slow lookup: inspect DNS status, answer, and TTL. Failure before SYN-ACK: inspect route, policy, and transport evidence. Long wait after a handshake: split TLS and application timing. Retransmissions after setup: compare packet direction and size across boundaries.
Without looking, split 650 ms into 12 + 22 + 76 + 500 + 40; explain the TTL 42 versus 300 cache discrepancy; then localise failure when SYNs arrive and SYN-ACKs leave.
For structured revision, CS Fundamentals for Placements by Sanchit Sir is optional. Turn each symptom into a path, observation, bounded conclusion, and decisive test.
