Networking Fundamentals Questions

Foundational knowledge of how networks operate and how to reason about network behavior. Core concepts include the TCP IP model and common protocols such as IP, TCP, UDP, DNS, and DHCP; subnetting and address allocation; routing and switching fundamentals; VLANs and layer two segmentation; NAT and private addressing; firewall and access control behavior; VPNs and tunneling; ports and application layer protocols. Candidates should also be able to apply these fundamentals to troubleshoot connectivity and performance issues at a conceptual level, explain the TCP three way handshake, congestion and retransmission causes, and reason about where problems occur in the stack.

HardSystem Design

49 practiced

Design a scalable monitoring architecture for network devices across three global regions and multiple datacenters. Include data collection methods (SNMP, sFlow/NetFlow, syslog), central storage/processing, alerting, retention strategy, and how you would handle noisy alerts and on-call rotation considerations.

Sample Answer

**Clarify requirements**- Three global regions, multiple DCs each, millions of flows/day, SLA 99.9%, retention: short-term hot (30d), cold (1–3y).

**High-level architecture**- Regional collectors per region (HA pair): receive SNMP polls/traps, sFlow/NetFlow, syslog. Forward normalized events/metrics to central processing over TLS/VPN.- Central processing: Kafka for ingestion, stream processing (Flink/Logstash) for enrichment, Cassandra/ClickHouse for metrics/flow storage, Elasticsearch for logs, object store (S3) for raw/archival.- UI/alerting: Grafana for metrics, Kibana/ElastAlert or Prometheus Alertmanager for metric alerts, PagerDuty for on-call.

**Data collection**- SNMP: polling for device status/ifIn/ifOut, traps for async events. Poll cadence tiered (core: 15s–30s, access: 60–300s).- sFlow/NetFlow: export to nearest regional collector; sample rates adjusted by device.- Syslog: centralized syslog-ng/rsyslog (TLS), structured parsing (Grok), drop noisy/known patterns at collector.

**Storage & retention**- Hot metrics in ClickHouse/Prometheus for 30d; aggregated downsampled metrics (1h) stored for 1–3y in long-term DB/object store.- Flows in ClickHouse for 90d raw, aggregated nightly to S3.- Logs in ES 90d hot, cold to S3 with searchable snapshots.

**Alerting & noisy alert handling**- Multi-stage alerts: detection → enrichment → suppression. Use anomaly detection + threshold rules.- Rate-limit and dedupe in Alertmanager; maintain suppression rules for maintenance windows and known noisy sources.- Feedback loop: every alert labeled with runbook link; use alert-ticket correlation to identify noisy rule owners and fix at source (filtering, device config, sampling).- Auto-silence noisy alerts using ML only after manual review.

**Scalability & resilience**- Regional collectors scale horizontally; Kafka topics partitioned by region/device; stateless processors; replication for critical stores.- Health checks, metrics for pipeline lag, and automated failover to global collectors.

**On-call considerations**- SRE-style rotations: primary (handles pager), secondary (escalation), SME for network devices. 8–12 week schedules, follow-the-sun across regions.- Playbooks/runbooks per alert; runbook-run ratio monitored. Weekly burn-down of noisy alerts; regular postmortems and capacity planning.

This design balances low-latency detection, long-term analytics, and operational practicality for a Systems Administrator running global network monitoring.

HardTechnical

60 practiced

Some protocols (e.g., SIP, FTP active) embed IP addresses or use dynamic ports that NAT breaks. Explain why NAT causes problems for these protocols and describe two practical solutions (one network-level and one application-level) to make these protocols work across NAT.

MediumTechnical

65 practiced

You capture TCP packets showing a client sending SYN, server responding with SYN-ACK, and the client immediately sending RST. Explain at least three possible root causes for this pattern and what additional packet capture or host-level checks you would perform to identify the real issue.

Sample Answer

**Brief answer (what the pattern means)** A client SYN → server SYN-ACK → immediate client RST means the client (or a device pretending to be the client) aborted the handshake right after seeing the SYN-ACK. Root causes are usually client-side, network middlebox, or server/port mismatch issues.

**At least three possible root causes**- Client application/OS rejects the connection - Example: no process is listening on that port (race between connect and close), or the app timed out and closed the socket.- Host-based firewall / security software or anti-virus on the client - Local firewall or endpoint protection detects the SYN-ACK and injects RST to block the flow.- Middlebox or network device injecting RST (IDS/IPS, NAT timeout, load balancer misbehavior) - A firewall or intrusion system along the path may generate spoofed RSTs to tear down perceived unwanted connections.- Additional common causes: asymmetric routing / wrong IP (SYN-ACK reaches a different host), TCP stack issues (RST because seq/ack invalid), or NAT translation mismatch.

**What packet-capture checks I’d perform**- Capture on both ends and along path (client-side, server-side, and ideally an upstream mirror) - Compare timestamps, sequence/ack numbers, TTL and IP ID fields to confirm the RST source is the client IP and not spoofed.- Use tcpdump/wireshark filters: - tcpdump -i any host <client> and host <server> and port <p> -w capture.pcap - Inspect TCP flags, window size, and duplicate packets; check whether RST has matching seq/ack (indicates legitimate TCP stack response).- Check for asymmetric captures: does server see RST? Does RST appear before SYN-ACK reaches client?

**What host-level checks I’d perform**- On client: - ss -tnp | grep <port> or netstat -anp to see if a local process is handling the port/closing sockets. - sudo iptables -L/-nv or nft list rules to find rules that could reject or reset connections. - Check endpoint protection logs (AV/EDR) and OS kernel logs (dmesg, /var/log/syslog).- On server: - Confirm service is actually listening: systemctl status, ss -ltnp. - Check server firewall (iptables/nft/csf), connection tracking (cat /proc/net/nf_conntrack) for NAT timeouts. - Application logs for errors or rapid connection closes.- On intermediate devices: - Review load balancer/NAT timeouts, IDS/IPS logs; check for TCP reset policies.- Additional validation: - Reproduce from client with verbose curl/telnet; run tcpdump while reproducing. - Use hping3 to craft packets to see if RST persists (helps detect middlebox).

**How I’d conclude root cause**- If RST’s IP/TCP fields and capture on client show the RST generated locally and process closed socket → client app/OS issue.- If server sees SYN-ACK returned but client capture lacks it and RST appears with inconsistent TTL/IP ID → likely spoofed by middlebox.- If endpoint security/firewall logs correlate with timestamps → host-based blocking.

This combination of multi-point captures and targeted host checks quickly isolates whether the reset is local, network-induced, or server-side.

HardTechnical

53 practiced

Explain how a stateful firewall tracks TCP connections. Provide an example firewall rule set (conceptual, not vendor-specific) that allows outbound connections from the internal network and ensures return traffic is allowed, but blocks unsolicited inbound connections. Explain how the state table affects permitted traffic.

Sample Answer

**Brief explanation of connection tracking**

A stateful firewall inspects packet headers and records connection state (e.g., SYN, ESTABLISHED, FIN) in a state table. For TCP it tracks the 5-tuple (src IP, src port, dst IP, dst port, protocol) plus sequence/ack hints and state (SYN_SENT, ESTABLISHED, FIN_WAIT). Packets matching an existing entry are allowed according to that entry’s policy without re-evaluating full ACL logic.

**Conceptual rule set (not vendor-specific)**

text

1. allow from internal_net any to any tcp established
2. allow from internal_net any to any tcp syn       # allow outbound connection attempts
3. allow from internal_net any to any udp           # allow outbound UDP
4. allow from any any to internal_net related,established  # implicit by state table
5. deny from any any to internal_net                # block unsolicited inbound
6. allow from internal_net any to any icmp          # optional outbound ICMP
7. deny any any any                                  # default deny

**How the state table affects traffic**

- When an internal host sends TCP SYN outbound, the firewall creates a state entry (SYN_SENT). The explicit outbound rule permits the SYN and the state entry allows subsequent SYN-ACK and ACK packets from the remote host because they match the existing 5-tuple and state transitions (becoming ESTABLISHED).- An unsolicited inbound SYN from the internet has no matching state entry, so rule 5/7 blocks it.- State entries expire after inactivity or proper teardown; improper TCP teardowns may rely on timeouts.- Stateful inspection reduces rule complexity and prevents spoofed/unsolicited inbound connections while allowing return traffic for legitimate sessions.

**Operational notes**

- Monitor state table size; heavy NAT or high connection rates can exhaust capacity.- Tune timeouts for long-lived connections (e.g., databases, HTTP keep-alive) and consider conntrack limits and logging for blocked unsolicited attempts.

MediumTechnical

63 practiced

Compare Layer 2 switches and Layer 3 switches: explain three technical differences, give two example scenarios where each device type is appropriate, and describe routing behavior you expect from a Layer 3 switch implementing inter-VLAN routing.

Unlock Full Question Bank

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

Join thousands of developers preparing for their dream job.