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
34 practiced
Compare TCP and UDP in terms of connection setup, reliability, ordering, congestion control, and latency. Give examples of real workloads where each is a better fit, and explain how your answer would change if the service were a security control, telemetry pipeline, or DNS resolver.
Sample Answer
**TCP vs. UDP****TCP** establishes a connection, provides reliable delivery, preserves order, and includes congestion control. It has more overhead, but it is predictable for stateful applications.**UDP** is connectionless, does not guarantee delivery or ordering, and has lower latency because it avoids handshake and retransmission complexity at the transport layer.**Good fits**- **TCP:** web apps, APIs, file transfer, SSH, databases- **UDP:** DNS, VoIP, gaming, multicast, telemetry where freshness matters more than perfect delivery**How I’d choose by workload**- **Security control:** often TCP for reliable control-plane communication, though some sensors use UDP for simple heartbeats. If I need guaranteed event delivery, I’d add acknowledgments or use TCP/message queues.- **Telemetry pipeline:** UDP can work for high-volume metrics if occasional loss is acceptable, but critical security telemetry usually benefits from TCP or a buffered agent to avoid blind spots.- **DNS resolver:** usually UDP for speed and low overhead, with TCP fallback for large responses, zone transfers, or truncation.From a cybersecurity perspective, I also consider detection fidelity: UDP loss can hide attacks, while TCP gives stronger delivery guarantees but more state to monitor and protect.
EasyTechnical
26 practiced
Explain the TCP three-way handshake and what repeated SYN retransmissions usually indicate. How would you distinguish a server that is down, a firewall that is dropping packets, and a routing problem where traffic is taking the wrong path?
Sample Answer
The TCP three-way handshake establishes a reliable connection before data flows:1. Client sends **SYN**2. Server replies **SYN-ACK**3. Client sends **ACK**Repeated SYN retransmissions usually mean the client is not receiving a valid SYN-ACK, so the problem is somewhere on the path or at the destination.**How I’d distinguish the causes**- **Server down:** no SYN-ACK at all, and the host may not respond to anything except maybe ICMP if another system is answering. `ss -lnt` shows no listener, or the host is unreachable entirely.- **Firewall dropping packets:** SYN leaves the client, but no response returns. `tcpdump` on the server may show nothing, or a security control may silently discard the traffic.- **Routing problem:** packets take the wrong path or return path is broken. `traceroute` and bidirectional packet captures help here; I’d look for asymmetric routing or missing routes.A good workflow is: verify listener, check firewall policy, then validate routing in both directions. SYN retransmits tell me the connection is failing before establishment, so I focus on reachability and policy rather than application logic.
HardTechnical
34 practiced
You are given metrics, logs, traces, and a packet capture from a distributed application outage. What signals would you inspect first to determine whether the root cause is DNS, routing, firewall policy, or an application timeout, and how would you correlate the evidence across layers?
Sample Answer
I’d start by answering one question: is the failure at name resolution, packet delivery, policy enforcement, or the application itself?**First signals to inspect**- **Metrics:** Spike in DNS latency, TCP retransmits, SYN timeouts, 4xx/5xx rates, or dependency-specific error budgets.- **Logs:** Resolver errors, connection refused, timeout messages, TLS failures, or app-level upstream errors.- **Traces:** Look for the first slow span. If the trace stalls before the request reaches the service, DNS or routing is likely. If it reaches the app and then stalls, it may be firewall or downstream timeout.- **PCAP:** Confirm whether packets leave the client, whether SYN/SYN-ACK completes, whether DNS responses arrive, and whether ICMP fragmentation-needed messages appear.**Correlation approach**- Build a timeline with timestamps from all layers.- Match a single failed request ID across trace logs and packet capture timestamps.- If DNS fails, pcap shows repeated queries or no responses.- If routing is broken, packets go out but never return, or they follow an unexpected next-hop.- If firewall blocks, pcap often shows SYNs with no SYN-ACK, or RSTs from an inline device.- If it’s an app timeout, transport succeeds but the server-side trace shows the request hanging on an upstream call.I’d use this layered evidence to avoid guessing and to narrow the fault domain quickly.
HardTechnical
55 practiced
An application shows high p95 latency but low overall bandwidth usage. How would you distinguish whether the bottleneck is DNS lookup time, TCP slow start, Nagle or delayed ACK behavior, queueing delay, server saturation, or client-side connection reuse?
Sample Answer
I’d decompose p95 latency into network setup, transport behavior, queueing, and server-side service time.**1. DNS lookup time**If the first request is slow but reused connections are fast, I’d inspect resolver latency, cache hit rate, and NXDOMAIN retries. A simple client-side timing breakdown often reveals this immediately.**2. TCP slow start / connection reuse**If each request opens a new connection, throughput can be low even with modest bandwidth. I’d compare new-connection latency versus keep-alive or HTTP/2 reuse. A burst of small requests can look fine in average throughput but bad at p95.**3. Nagle or delayed ACK**If tiny writes are being buffered, I’d look for request/response ping-pong patterns and disable Nagle only when justified. This is common in chatty protocols.**4. Queueing delay**High p95 with low bandwidth often means low utilization but high burstiness. I’d inspect thread pools, connection pools, and server queue depth. Latency spikes before CPU saturation are a classic early warning.**5. Server saturation**Even if overall bandwidth is low, a single resource like DB connections, locks, or crypto can saturate. I’d correlate p95 with GC, lock waits, and upstream dependency time.**6. Client connection reuse**If the client isn’t reusing sockets, every call pays handshake cost. I’d verify keep-alive settings and pool hit rates.The fastest path is to time each phase separately and compare cold versus warm requests. That usually identifies whether the problem is network setup or application processing.
HardTechnical
34 practiced
A Kubernetes service mesh introduces mTLS and sidecars, and now only a subset of service-to-service calls fail after a deployment. How would you determine whether the issue is NetworkPolicy, service discovery, readiness or liveness probes, CNI behavior, or the mesh configuration itself?
Sample Answer
I’d isolate the failure by testing each layer independently.**Step 1: Confirm workload readiness**- Check whether the failing pods became Ready before traffic was sent.- Compare readiness and liveness probe behavior before and after the deployment.- If sidecars start slower than the app, readiness may be true too early, causing calls to hit an unready proxy.**Step 2: Validate service discovery**- Confirm service endpoints and pod IPs are present.- Verify the mesh control plane pushed the correct listeners and clusters.- A subset failure often points to stale endpoints or misrouted virtual service rules.**Step 3: Check NetworkPolicy and CNI**- Test pod-to-pod connectivity with and without the sidecar.- Review whether NetworkPolicy blocks the sidecar port range, DNS, or health-check traffic.- Some CNIs handle SNAT, hairpinning, or policy enforcement differently after rollout.**Step 4: Inspect mesh config**- Look at mTLS mode, peer authentication, destination rules, and port naming.- If only some calls fail, it may be a namespace-specific policy mismatch or protocol detection issue.**Step 5: Use telemetry**- Compare app logs, sidecar logs, and trace spans.- If the app sees no request, it’s likely routing or policy. If the app sees it but upstream fails, it may be mTLS/cert or timeout related.In a security role, I’d prioritize least-privilege policies but validate them with staged rollouts and canaries to avoid breaking east-west traffic.
Unlock Full Question Bank
Get access to hundreds of Networking Fundamentals and Troubleshooting interview questions and detailed answers.
