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
31 practiced
Explain how the IP Time-To-Live (TTL) field is used to prevent routing loops and how traceroute leverages TTL to discover intermediate hops. Describe one operational scenario where incorrect TTL handling (for example, in tunnels) can cause connectivity problems and how you would detect it.
Sample Answer
**How TTL prevents routing loops**- TTL is an 8-bit field in the IP header decremented by 1 at each router hop. - If TTL reaches 0, the router discards the packet and returns an ICMP "Time Exceeded" message. - This ensures a packet cannot circulate forever; loops cause packets to die quickly instead of congesting the network.**How traceroute uses TTL**- Traceroute sends packets with increasing TTL values (1, 2, 3...). - Each hop that decrements TTL to 0 returns ICMP Time Exceeded, revealing that hop’s IP and RTT. - By collecting responses per TTL, traceroute maps the path and measures latency to each intermediate hop.**Operational scenario with incorrect TTL handling**- In a tunnel (GRE/IPsec), some devices encapsulate packets but fail to decrement or correctly handle inner/outer TTLs. Example: tunnel endpoint copies outer TTL into inner packet, so inner TTL doesn’t decrease across the tunnel — causing packets to expire unexpectedly beyond the tunnel or appear to skip hops.- Impact: asymmetric routing, unreachable subnets, or traceroute showing a single hop across the tunnel with later drops.**How to detect and troubleshoot**- Run traceroute from both sides; compare hop counts and where packets stop. - Use ping with increasing packet sizes and record TTL in replies (ping -t / -i where supported). - Inspect tunnel configuration for "ttl propagate" / "ttl copy" settings and router OS docs. - Enable packet captures at tunnel endpoints to see outer vs inner TTL values. - Fix by configuring correct TTL propagation or explicitly setting inner TTL decrement behavior, then validate with traceroute.
EasyTechnical
33 practiced
You receive an alert 'service unreachable' for a web application. For initial triage, describe when and why you'd use each of the following tools: ping, traceroute (or mtr), dig/nslookup, arp, ss/netstat, and tcpdump. For each tool give one succinct command example you would run against host 10.0.1.10 and explain what evidence each command provides.
Sample Answer
**Overview**When a web app is "service unreachable" I pick tools to isolate layer: ICMP reachability, path, DNS, ARP/L2, socket state, and packet-level traffic.**ping — quick reachability**When/why: Verify basic IP reachability and latency.Command:
bash
ping -c 4 10.0.1.10
Evidence: ICMP replies or timeouts, RTT and packet loss indicating host/network reachability or high latency.**traceroute / mtr — path and per-hop latency**When/why: Identify where packets are dropped or delayed along the route.Command:
bash
mtr -rw 10.0.1.10
Evidence: Per-hop loss/latency shows which hop is failing or congested.**dig / nslookup — DNS resolution**When/why: Confirm hostname resolves to correct IP; rule out DNS misconfiguration.Command:
bash
dig +short web.example.com
Evidence: Resolved IPs; mismatches or no answer point to DNS issues (not suggested by ping to 10.0.1.10).**arp — L2 neighbor mapping**When/why: Check ethernet MAC for IP on same subnet; detect duplicate IPs or missing ARP entry.Command:
bash
arp -n | grep 10.0.1.10
Evidence: MAC address presence or “no entry” helps decide if host is on-link or ARP failing.**ss / netstat — socket and listener state**When/why: Verify service is listening and connections on the host (run on host or via SSH).Command:
bash
ss -ltnp | grep :80
Evidence: Shows if web server is listening on port 80 and which process owns it.**tcpdump — packet-level verification**When/why: Capture traffic to see requests, responses, retransmits, or firewall drops.Command:
bash
tcpdump -nni any host 10.0.1.10 and port 80 -c 100
Evidence: Actual packets, TCP handshake status, RST/ICMP errors—confirms if traffic reaches host and how it’s handled.Use these in sequence to narrow from network to service.
EasyTechnical
32 practiced
Given the IPv4 block 192.168.100.0/24: calculate the network address, broadcast address, usable host range, and the subnet mask in dotted-decimal. Then split that /24 into four equal-sized subnets and list the CIDR and usable ranges for each. Explain your method clearly.
Sample Answer
**Answer (Systems Engineer perspective)****Given**- Block: 192.168.100.0/24- Subnet mask (dotted): 255.255.255.0**Whole /24 details**- Network address: 192.168.100.0- Broadcast address: 192.168.100.255- Usable host range: 192.168.100.1 – 192.168.100.254- Usable hosts: 254**Method**- /24 has 256 addresses. Splitting into 4 equal subnets means each subnet has 256 / 4 = 64 addresses → increment (block size) = 64.- A 64-address block corresponds to /26 because 2^(32-26)=64.- /26 mask (dotted): 255.255.255.192 (because 192 = 11000000 -> block size 64)**Four /26 subnets**1. 192.168.100.0/26 - Usable: 192.168.100.1 – 192.168.100.62 - Broadcast: 192.168.100.632. 192.168.100.64/26 - Usable: 192.168.100.65 – 192.168.100.126 - Broadcast: 192.168.100.1273. 192.168.100.128/26 - Usable: 192.168.100.129 – 192.168.100.190 - Broadcast: 192.168.100.1914. 192.168.100.192/26 - Usable: 192.168.100.193 – 192.168.100.254 - Broadcast: 192.168.100.255This approach (compute block size from mask, increment network by block size) is standard for planning subnets in infrastructure design.
MediumTechnical
31 practiced
Define bandwidth, throughput, and goodput. Explain five reasons an application might measure lower throughput or goodput than the link bandwidth (e.g., retransmissions, protocol overhead, congestion, flow-control limits, and application inefficiencies) and propose measurement steps to identify which reason applies.
Sample Answer
**Definitions**- **Bandwidth**: Maximum raw capacity of a link (e.g., 1 Gbps) — the physical layer bit-rate.- **Throughput**: Actual amount of data delivered over the network per unit time (bits/sec) including all protocol bytes.- **Goodput**: Application-level useful payload rate (bits/sec) — excludes retransmitted and protocol overhead.**Five reasons throughput/goodput < bandwidth**1. **Retransmissions (loss/bit errors)** — TCP/ARQ resend reduces goodput and increases on-wire bytes.2. **Protocol overhead** — Ethernet/IP/TCP headers, TLS, ACKs consume bandwidth.3. **Congestion** — queues, packet loss, and TCP congestion control lower throughput.4. **Flow-control / window limits** — small TCP window or application read-blocking prevents full pipe utilization (esp. high RTT).5. **Application inefficiencies** — small writes, synchronous I/O, poor batching, or excessive encryption CPU bottlenecks.**Measurement steps to identify cause**1. Establish baseline: measure link bandwidth (e.g., port speed) and run iperf3 for raw TCP/UDP throughput.2. Capture packets (tcpdump) and inspect with Wireshark: - Check retransmissions, dup ACKs => loss/retransmits. - Measure header-to-payload ratio => overhead.3. Monitor queueing/latency (ping/OWD, tc qdisc stats) and interface drops => congestion.4. Check TCP state (ss -ti) for window sizes and RTT to detect flow-control limits.5. Profile hosts (top, iostat, perf) and instrument application logs to find CPU, IO, or architectural bottlenecks (small writes, sync waits).Use comparative tests (large vs small MTU, UDP vs TCP, local loopback, increasing parallel streams) to isolate the factor.
HardSystem Design
33 practiced
Design a hybrid-cloud network to support synchronous database replication between an on-prem datacenter and two cloud providers. Your design must meet low-latency requirements and 99.99% availability. Describe whether you'd use direct dedicated links (e.g., AWS Direct Connect), VPN, or both; how BGP and private ASNs would be used; encryption strategy; routing and failover behavior; and how you'd monitor and test the links.
Sample Answer
**High-level approach (goal)** I would build redundant low-latency, deterministic paths from the on‑prem datacenter to each cloud provider using dedicated direct links as primary paths and encrypted VPNs as automatic backups. Design targets: synchronous DB replication latency budget, geo-path diversity, and 99.99% availability via active/standby multi-paths and fast failover.**Connectivity choice**- Primary: Provider direct dedicated links (e.g., AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect) for predictable latency and bandwidth.- Secondary: IPsec VPN over independent internet circuits to each cloud provider for failover and encryption diversity.- Always provision at least two physical providers and dual links per provider (diverse carriers) to hit 4‑9s of redundancy.**BGP and private ASNs**- Use eBGP between on‑prem edge routers and each provider's edge; assign a private ASN on our side per RFC 6996.- Peer with both provider edge routers; advertise only required prefixes.- Implement route policies: local‑pref to prefer direct links, MED and AS‑path prep for planned failover, route‑maps and prefix lists to limit routes.**Fast failover and routing behavior**- Use BFD to detect link failures sub-50ms and trigger BGP withdrawals.- Normal: traffic flows over Direct Connect; on failure BFD + BGP withdraw switches to VPN path automatically.- For multi‑site availability, prefer the lowest-latency path with local‑pref; use AS‑path prep on backup to ensure deterministic selection.- For cross‑cloud replication, implement active‑active replication where supported, or active‑passive with automated promotion scripts guarded by quorum and consistency checks.**Encryption strategy**- On direct links enable provider MACsec/Link‑level encryption if available; still run end‑to‑end encryption.- DB traffic: use TLS (mutual TLS) for replication and application connections; database-level encryption (TDE) for data at rest.- VPN: IPsec with robust ciphers (AES‑256-GCM, ECDHE) and IKEv2; manage keys with an HSM/KMS and rotate regularly.**Operational controls: monitoring & testing**- Real‑time telemetry: SNMP/NetFlow/sFlow, BGP session metrics, BFD status, interface counters, and cloud link health (CloudWatch/Stackdriver/Azure Monitor). Centralize in observability platform (Prometheus + Grafana / ELK).- Synthetic checks: continuous latency/jitter probes and replication health checks (transaction timestamps, write LSN lag).- Alerts & runbooks: SLOs for latency and availability with automated paging and playbooks for failover/drills.- Testing: quarterly failover drills (planned withdrawals), chaotic drills (simulate path loss), and annual full DR test. Validate failover timing meets RPO/RTO targets.**Security & compliance**- ACLs, prefix filtering, RPKI validation/route auth, and strict BGP session ACLs.- Audit logs forwarded to SIEM; encryption keys audited and rotated.Outcome: predictable low latency via direct links, resilient automated failover via BGP + BFD to VPN backups, end‑to‑end encryption, and continuous monitoring + testing to sustain 99.99% availability for synchronous replication.
Unlock Full Question Bank
Get access to hundreds of Networking Fundamentals and Troubleshooting interview questions and detailed answers.
