Network Protocols and Diagnostics Questions

Comprehensive coverage of core network protocols and the diagnostic techniques used to verify and resolve issues across the data link, network, and transport layers. Topics include how Ethernet frames are constructed, how media access control addresses are used, the operation of the address resolution protocol for neighbor discovery, virtual local area network basics, and data link layer switching behavior. It covers the Dynamic Host Configuration Protocol flow for automated address assignment, common DHCP options and failure modes, and methods to validate address assignment. It explains the Domain Name System operation, common record types such as address and canonical name records, the resolution process, and tools for diagnosing name resolution problems. It details the differences between the Transmission Control Protocol and the User Datagram Protocol including connection establishment, reliability, flow control, ordering, typical use cases, and port concepts. It also covers the Internet Control Message Protocol and how reachability and path diagnostics use it, explains what ping and traceroute actually test, and how to interpret traceroute output. Practical diagnostic techniques are included such as packet capture and analysis, tcpdump and Wireshark usage, common symptoms like maximum transmission unit mismatches and fragmentation, and structured approaches to isolate protocol level failures.

HardSystem Design

18 practiced

Design a monitoring and alerting strategy to detect ARP spoofing, DHCP starvation, and DNS hijacking across an enterprise network. Specify telemetry sources (switch logs, DHCP server logs, DNS query/response logs, packet samples), detection signatures or rules, thresholds that should trigger alerts, automatic containment actions (isolate port, rate-limit, block IP), and approaches to reduce false positives in environments with high churn (cloud instances, containers).

Sample Answer

**Clarify goals & constraints**- Detect ARP spoofing, DHCP starvation, DNS hijack quickly with low FP in high-churn cloud/container environments; integrate with existing NMS/SIEM and orchestration (K8s, cloud APIs).

**Telemetry sources**- Switch CAM/MAC table change logs, Gratuitous ARP events, 802.1X/auth logs- DHCP server/relay logs: lease requests, NAKs, declined, rapid-request counts- DNS query/response logs (authoritative + recursive), DNSSEC validation results, response IPs, TTLs, RCODEs- Full packet samples / PCAP triggers for suspicious flows (first N packets)- Netflow/sFlow for rate baselining- Cloud metadata / orchestration events, IPAM records

**Detection signatures / rules**- ARP spoofing: - MAC for an IP changes > X times in Y seconds on same VLAN/port group - Gratuitous ARP with conflicting MACs observed from multiple ports - ARP replies without prior ARP requests- DHCP starvation: - Single port sending > N DISCOVERs per second or > M total without successful lease - High ratio of DISCOVER:REQUEST or many malformed DHCP options- DNS hijack: - Recursive answers that differ from multiple upstream resolvers - Sudden authoritative NS changes for an internal zone - DNS responses with very low TTLs + new IPs not in IPAM - DNSSEC validation failures or forged RRSIGs

**Threshold examples (tunable)**- MAC flip: >3 MAC changes for same IP within 60s → alert; >5 → auto-contain- Gratuitous ARP from port: ≥2 conflicting gratuitous ARPs in 30s → isolate- DHCP DISCOVER rate: >50/sec per port OR >500 in 5min → alert; >100/sec → rate-limit- DNS divergence: answer differs from 2 trusted resolvers OR DNSSEC fail → alert

**Automatic containment actions**- 1st tier (automated, reversible): - Apply per-port rate-limit or storm-control - Temporary port isolate (shutdown) with auto-reenable after soak time - Dynamic ACL blocking offending MAC/IP via switch API or SDN controller - Quarantine via VLAN move to remediation VLAN- 2nd tier (escalation): - Revoke DHCP lease via server API, add to deny-list for short window - Block upstream DNS/egress for source; send PCAP to analyst- All actions logged and require approval for persistent blocks

**Reduce false positives in high-churn**- Correlate signals: require 2+ independent telemetry hits (e.g., CAM change + gratuitous ARP + netflow anomaly) before auto-contain- Maintain dynamic allowlists from orchestration/IPAM (tags for ephemeral VMs/containers)- Adaptive thresholds from baselining per-segment (machine learning or rolling window percentiles)- Grace windows for known scaling events (deploy hooks from CI/CD to suppress alerts)- Tag and exempt known NAT/load-balancer behaviors; require DNS divergence against multiple resolvers- Provide dry-run alert-only mode; run simulated containment in staging

**Operational notes**- Integrate with SIEM/ChatOps for analyst review; keep PCAP snippets for forensic retention- Regularly tune thresholds and expand allowlists via post-incident reviews- Enforce DHCP snooping, Dynamic ARP Inspection, IP Source Guard on switches to prevent many attacks by design

EasyTechnical

16 practiced

Describe the ARP (Address Resolution Protocol) process used to map an IPv4 address to a MAC address on an Ethernet LAN. Walk through an ARP request and reply, explain ARP cache behavior and timeouts, the purpose of gratuitous ARP, and how proxy ARP and static ARP entries alter normal resolution. What packet fields are broadcast vs unicast during the process?

MediumTechnical

24 practiced

You have a pcap containing multiple TCP flows. Describe how to use Wireshark to: 1) identify and filter the TCP three-way handshake for a single flow, 2) detect retransmissions, duplicate ACKs, and out-of-order segments using built-in analysis flags and display filters, and 3) use Wireshark statistics (e.g., TCP stream graphs, IO graphs) to summarize performance issues and RTT distribution.

Sample Answer

**Identify & isolate a single TCP three‑way handshake**- Open pcap, sort by time.- Find SYN packet: use display filter to show initial SYNs:

text

tcp.flags.syn == 1 && tcp.flags.ack == 0

- Note the tcp.stream value (right‑click packet → “Follow → TCP Stream” or “Apply as Filter → Selected”).- Filter the whole flow:

text

tcp.stream == N

- Within that stream look for sequence: SYN (S), SYN+ACK (S+ A), ACK (A) — those three confirm the handshake.

**Detect retransmissions, duplicate ACKs, out‑of‑order**- Enable analysis flags: analyze → display filter examples:

text

tcp.analysis.retransmission
tcp.analysis.fast_retransmission
tcp.analysis.duplicate_ack
tcp.analysis.out_of_order

- Use:

text

tcp.stream == N && tcp.analysis.retransmission

to focus on retransmits in one flow.- Use Expert Information (Analyze → Expert Information) to get a summary of anomalies (retransmits, dup ACKs, zero window, etc.).

**Summarize performance & RTT distribution with statistics**- TCP Stream Graphs (Statistics → TCP Stream Graphs → Round Trip Time, Time‑Sequence, Throughput): pick the stream (wireshark prompts) to view per‑flow RTT, inflight segments, and gaps.- IO Graphs (Statistics → IO Graphs): plot packet count/bytes and overlay filters such as

text

tcp.stream == N && tcp.analysis.retransmission

to correlate loss bursts with throughput drops.- RTT distribution: use TCP Round Trip Time graph or export “tcp.analysis.ack_rtt” values (apply filter and export packet list) to compute percentiles.- Interpretation: repeated duplicate ACKs followed by fast retransmission ⇒ packet loss. High variance in ACK RTTs ⇒ jitter/congestion. Long gaps and reduced throughput in Time‑Sequence ⇒ loss/retransmit recovery.

Practice using combined filters and Expert Information to quickly triage which flows need deeper router/firewall/host investigation.

HardSystem Design

20 practiced

Design a DNS architecture for a global, multi-region service that supports fast failover and internal/external resolution. Include split-horizon DNS considerations, authoritative server placement (anycast vs regional), health-check based failover with low TTLs, handling apex records and CNAMEs, caching implications, expected query load, and operational consistency across authoritative servers and registrars.

Sample Answer

**Clarify goals & constraints**- Global multi-region service, fast failover (<secs to tens secs), both internal (VPC) and external resolution, secure and operable by network team.

**High-level design**- Public authoritative: global anycast network (e.g., Route53/NS1/Cloudflare) for low-latency query front door and consistent NS set.- Regional authoritative instances (private) inside each cloud region for internal/resolution (split-horizon) using regional unicast servers or cloud DNS private zones.

**Split-horizon DNS**- External zone served by anycast authoritative servers.- Internal/private zones per VPC/region with identical names but different records (internal IPs, private load balancers). Synchronize zone metadata but keep record sets separate.

**Anycast vs Regional**- Anycast: fast path, DDoS resilience, single global NS set — good for public queries.- Regional unicast: preferred for internal traffic to expose private IPs and avoid hairpin/egress. Use private views or conditional forwarding.

**Health-check based failover & TTLs**- Use health checks at edge (DNS provider) + active monitoring from multiple locations.- Set low public record TTLs (30–60s) for failover, but balance with cache churn.- For internal: slightly higher TTL (60–120s) to reduce chattiness within private networks.- Implement staged failover: update authoritative record -> EP/edge ads propagate -> traffic shifts.

**Apex records & CNAMEs**- Use ALIAS/ANAME or provider-specific apex flattening to point apex to load balancers or CDN while preserving root record.- Avoid CNAME at apex; use CNAMEs for service subdomains where supported.- Maintain health-driven IP mapping behind ALIAS.

**Caching & resolver behavior**- Expect intermediate resolver caching ignoring low TTLs (ISP constraints). Design for eventual consistency and use active probes to confirm failover.- Use short TTLs for critical endpoints but accept some clients may honor minimum TTLs.

**Expected query load & scaling**- Estimate qps = (peak users * lookups/user) + service probes + telemetry. Plan for spikes (use 10x headroom).- Anycast providers scale horizontally; regional private DNS use autoscaling or highly-available servers.

**Operational consistency**- CI/CD for zone changes; GitOps push to both public and private zone providers.- Use atomic change APIs to avoid record drift; include versioning and planned rollbacks.- Coordinate registrar settings (NS, glue records) — keep TTLs and DS records stable; update registrar for any NS changes with ample lead time.- DNSSEC: sign zones and automate key rolls uniformly across authoritative endpoints.

**Monitoring & runbook**- Monitor query latency, error rates, propagation time, and health-checks.- Runbooks: failover steps, registrar contact, rollback, TTL tuning, and postmortem checklist.

Trade-offs: lower TTLs improve failover but increase query volume and cost; anycast simplifies public resilience but requires private regional DNS for internal IPs.

MediumTechnical

23 practiced

Scenario: In a single VLAN, Host A (10.0.1.10) cannot reach Host B (10.0.1.20). You capture traffic and see A sending ARP requests for B's IP but no ARP replies. Provide a step-by-step diagnostic process to identify the root cause. Consider host configuration, duplex/link status, switch port state, CAM table entries, duplicate IPs, ARP rate limiting, and possible software firewall or NIC issues.

Sample Answer

**Step 1 — Confirm symptoms & capture**- I verify A (10.0.1.10) issues ARP for 10.0.1.20 and sees no replies (tcpdump/wireshark on A).- Command examples:

bash

# Linux on A
sudo tcpdump -i eth0 arp
ip neigh show
arp -n

**Step 2 — Host configuration checks**- Confirm B’s IP, mask, gateway, and ARP table on A. On B: ensure interface up and correct IP.

bash

# On B
ip addr show
sudo tcpdump -i eth0 arp

**Step 3 — Link/duplex and NIC health**- Check link/state/duplex on both ends (ethtool) and retransmits/errors.

bash

ethtool eth0
cat /sys/class/net/eth0/statistics/*

- Fix mismatched duplex or failing NIC.

**Step 4 — Switch port state & CAM table**- Verify switch ports for A and B are up, in same VLAN, not err-disabled.

bash

# On switch
show interface Gi1/0/1 status
show vlan brief
show mac address-table address <MAC-of-B>

- If CAM missing, traffic won’t forward.

**Step 5 — Duplicate IP / ARP conflicts**- Search for another device owning 10.0.1.20 via ARP scans, DHCP leases, or:

bash

arping -D -I eth0 10.0.1.20

- Check DHCP server logs.

**Step 6 — Security features and rate-limiting**- Check switch features: DHCP snooping, ARP inspection, port-security, ARP rate-limit could block replies. Inspect logs and run:

bash

show ip arp inspection statistics
show port-security

**Step 7 — Host firewall / OS issues**- On B, ensure local firewall not blocking ARP (rare) or NIC driver bug. Temporarily disable firewall and retest.

bash

# Linux
sudo iptables -L
sudo systemctl stop firewalld

**Step 8 — Isolate & test**- Move B to a known-good switch port or bring up a laptop with 10.0.1.20 to validate ARP replies.- Use packet captures on switch mirror or on B to confirm whether ARP requests reach B and whether B transmits replies.

**Root-cause reasoning**- If A’s ARPs leave but never hit B: switch/VLAN/cam or physical/link problem.- If B sees ARP but doesn’t reply: host config, firewall, NIC/driver, or duplicate IP.- If replies sent but not learned: CAM table or port-security/ARP inspection blocking.

I systematically progress from host → link → switch → security → host internals until the failing component is isolated, then remediate (fix duplex, remove duplicate IP, adjust switch security, update NIC driver).

Unlock Full Question Bank

Get access to hundreds of Network Protocols and Diagnostics interview questions and detailed answers.

Join thousands of developers preparing for their dream job.