Computer NetworksInterview Preparation

Network Interview Preparation

LevelAdvanced

Duration90 mins

TopicInterview Preparation

3 / 5

Protocol Knowledge for Interviews

Demonstrating Protocol Expertise

Protocol knowledge is the technical bedrock of network engineering interviews. While memorizing RFC numbers impresses no one, deep understanding of how protocols work, why they were designed that way, and how they fail separates candidates who can troubleshoot production issues from those who merely configure devices.

This page covers the protocol knowledge interviewers expect at various levels, organized by protocol category. For each protocol area, we'll cover:

Core concepts you must know cold — The fundamentals that should be automatic
Deep-dive topics for senior roles — Advanced understanding that demonstrates expertise
Common interview questions and ideal answers — Preparing for exactly what you'll be asked
Failure modes and troubleshooting — Showing operational experience

What You Will Learn

By the end of this page, you will understand the depth and breadth of protocol knowledge expected in network interviews, have concrete examples of how to articulate this knowledge effectively, and know where to focus your study based on target role level.

TCP/IP Protocol Suite Mastery

TCP/IP is the foundation—expect extensive questioning here regardless of role. Interviewers probe at multiple levels: basic mechanics, edge cases, performance implications, and security considerations.

TCP Deep Knowledge

TCP Knowledge by Interview Level
Topic	Junior Expectation	Senior Expectation	Principal/Architect Expectation
Connection Lifecycle	3-way handshake, 4-way close	ISN generation, TIME_WAIT purpose, half-open connections	TCP state machine, simultaneous open/close, attack vectors
Flow Control	Sliding window concept	Window scaling, receiver window dynamics	Zero window probes, window update races, Silly Window Syndrome
Congestion Control	Slow start, AIMD concept	CWND/ssthresh interaction, fast retransmit/recovery	CUBIC vs BBR trade-offs, fairness issues, ECN implementation
Options	Aware that options exist	MSS, Window Scale, Timestamps, SACK	Option negotiation failures, middlebox interference, TCP extensions
Performance	TCP is reliable	BDP, latency impact, connection reuse benefits	TCP performance tuning, sysctl parameters, kernel bypass

Critical TCP Topics for Interviews

The TCP State Machine: Understanding this separates confident candidates from uncertain ones.

TCP State Transitions
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
# TCP State Machine - Key States and Transitions
 
             ┌──────────────────────────────────────────────────────────┐
             │                        CLOSED                            │
             └──────────┬─────────────────────────────────┬─────────────┘
                        │ passive open                    │ active open
                        │ (listen)                        │ (connect)
                        ▼                                 ▼
             ┌──────────────────┐                ┌──────────────────┐
             │     LISTEN       │                │    SYN_SENT      │
             └────────┬─────────┘                └────────┬─────────┘
                      │ rcv SYN                           │ rcv SYN-ACK
                      │ send SYN-ACK                      │ send ACK
                      ▼                                   ▼
             ┌──────────────────┐                ┌──────────────────┐
             │   SYN_RECEIVED   │                │   ESTABLISHED    │◄───────┐
             └────────┬─────────┘                └────────┬─────────┘        │
                      │ rcv ACK                           │ close            │
                      └───────────────────────────────────┤ send FIN         │
                                                          ▼                  │
                                                 ┌──────────────────┐        │
                                                 │    FIN_WAIT_1    │        │
                                                 └────────┬─────────┘        │
                                rcv FIN+ACK               │ rcv ACK          │
                                send ACK ────────────┐    │                  │
                                          │          │    ▼                  │
                                          │   ┌──────────────────┐           │
                                          │   │    FIN_WAIT_2    │           │
                                          │   └────────┬─────────┘           │
                                          │            │ rcv FIN             │
                                          │            │ send ACK            │
                                          │            ▼                     │
                                          │   ┌──────────────────┐           │
                                          └──►│    TIME_WAIT     │───────────┘
                                              └────────┬─────────┘    2MSL timeout
                                                       │
                                                       ▼ (back to CLOSED)
 
# Interview-Critical Knowledge:
 
1. TIME_WAIT (2MSL = ~60-120 seconds)
   - Purpose: Ensures delayed packets don't confuse new connections
   - Problem: Can exhaust local ports for high-connection-rate servers
   - Tuning: tcp_tw_reuse, tcp_tw_recycle (deprecated), time_wait buckets
 
2. SYN_RECEIVED accumulation = SYN flood attack or backlog overflow
   - Defense: SYN cookies, increase backlog, rate limiting
 
3. CLOSE_WAIT accumulation = Application not closing sockets properly
   - Indicates: Application bug, resource leak on server side
 
4. FIN_WAIT_2 accumulation = Remote end acknowledged close but hasn't closed
   - May indicate: Remote application hung, network partition during close

IP Protocol Deep Knowledge

IP seems simple but has surprising depth. Focus on addressing, routing behavior, and fragmentation.

IPv4 Header Fields to Know

•Version (4 bits) — IPv4 = 4. Why is IPv6 = 6 and not 5? (IPv5 was experimental Stream Protocol)
•IHL (4 bits) — Header length in 32-bit words. Minimum 5 (20 bytes), max 15 (60 bytes with options)
•DSCP/ECN (8 bits) — DiffServ for QoS, ECN for congestion signaling without packet drops
•Total Length (16 bits) — Max 65,535 bytes. Why jumbo frames work: they're ethernet-level, IP stays under limit
•Identification/Flags/Fragment Offset — Fragmentation handling. DF bit critical for PMTUD
•TTL (8 bits) — Prevents routing loops. Decremented at each hop. Traceroute exploits TTL expiry messages
•Protocol (8 bits) — 6=TCP, 17=UDP, 1=ICMP, 50=ESP, 51=AH, 89=OSPF
•Header Checksum — Covers only header, not payload. Must recompute at each hop (TTL changes)
•Options — Source routing (mostly blocked now), timestamps, record route

Common Interview Trap: MTU vs MSS

MTU (Maximum Transmission Unit) is Layer 2—the largest frame a link can carry (Ethernet: 1500 bytes). MSS (Maximum Segment Size) is TCP's payload size per segment (typically MTU - 40 bytes for IP+TCP headers = 1460 bytes). Confusion here is common and immediately signals surface-level knowledge. Know: MTU is L2, affects fragmentation. MSS is L4, negotiated in TCP handshake.

Routing Protocol Expertise

Routing protocol knowledge separates network engineers from generalists. Interviewers expect understanding of protocol categories, algorithms, and operational characteristics.

Distance Vector vs Link State Fundamentals

Distance Vector (RIP, EIGRP)

•Bellman-Ford algorithm — Iterative, distributed
•Shares routing table with neighbors only
•Routing by rumor — Trusts neighbors' information
•Slow convergence — Count-to-infinity problem
•Simple configuration — Minimal topology knowledge
•Limited scalability — Periodic full updates

Link State (OSPF, IS-IS)

•Dijkstra's SPF algorithm — Complete path calculation
•Floods LSAs — All routers have complete topology
•Complete view — Each router calculates independently
•Fast convergence — Changes propagate quickly
•More complex — Area design, DR/BDR election
•Highly scalable — Incremental, event-driven updates

OSPF Deep Dive

OSPF is the most commonly tested IGP. Senior candidates should understand multi-area design, LSA types, and adjacency formation.

OSPF LSA Types
LSA Type	Name	Originated By	Flooded Within	Purpose
Type 1	Router LSA	Every router	Area	Describes router's directly connected links
Type 2	Network LSA	DR on multi-access networks	Area	Describes all routers attached to segment
Type 3	Summary LSA	ABR	Other areas	Summarizes routes between areas
Type 4	ASBR Summary LSA	ABR	Other areas	Advertises reachability to ASBR
Type 5	External LSA	ASBR	Entire domain	Redistributed external routes
Type 7	NSSA External LSA	ASBR in NSSA	NSSA only	External routes in Not-So-Stubby-Areas

OSPF Adjacency Formation
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
# OSPF Neighbor States - Interview Essential
 
Down → Init → 2-Way → ExStart → Exchange → Loading → Full
 
┌──────────────────────────────────────────────────────────────────────────┐
│ DOWN     │ No Hello received from neighbor                              │
├──────────────────────────────────────────────────────────────────────────┤
│ INIT     │ Hello received, but own Router ID not seen in neighbor's     │
│          │ Hello (one-way communication)                                │
├──────────────────────────────────────────────────────────────────────────┤
│ 2-WAY    │ Bidirectional communication established                      │
│          │ ★ DR/BDR election happens here on multi-access networks     │
│          │ ★ Non-DR/BDR routers stop here (DROTHER state)              │
├──────────────────────────────────────────────────────────────────────────┤
│ EXSTART  │ Master/slave negotiation for database exchange               │
│          │ Higher Router ID becomes master                              │
├──────────────────────────────────────────────────────────────────────────┤
│ EXCHANGE │ Database Description (DBD) packets exchanged                 │
│          │ Routers learn what LSAs each other has                       │
├──────────────────────────────────────────────────────────────────────────┤
│ LOADING  │ Link State Requests (LSR) and Updates (LSU)                  │
│          │ Routers request missing/newer LSAs                           │
├──────────────────────────────────────────────────────────────────────────┤
│ FULL     │ Databases synchronized, adjacency complete                    │
│          │ Now participate in SPF calculations together                 │
└──────────────────────────────────────────────────────────────────────────┘
 
# Common Interview Question: "Why is neighbor stuck in EXSTART/EXCHANGE?"
 
Causes:
1. MTU mismatch (DBD packets too large)
2. Duplicate Router IDs
3. Area type mismatch
4. Authentication failure (after Hello succeeds)
5. DBD sequence number mismatch
 
# Key Timers (defaults, seconds):
Hello Interval: 10 (broadcast/p2p), 30 (NBMA)  
Dead Interval:  40 (broadcast/p2p), 120 (NBMA)
LSA Refresh:    1800 (30 minutes)
MaxAge:         3600 (1 hour, then LSA deleted)

BGP Expertise (Required for Senior Roles)

BGP knowledge is essential for anyone working with internet connectivity, cloud networking, or large enterprises. The depth expected is significant.

BGP Knowledge Checklist

•eBGP vs iBGP — eBGP between ASes, TTL=1 by default. iBGP within AS, full mesh or route reflectors required (split-horizon rule)
•Path Selection Algorithm — Weight → Local Pref → Originate → AS_PATH length → Origin Type → MED → eBGP over iBGP → IGP metric → Router ID
•Attributes — Well-known mandatory (AS_PATH, NEXT_HOP, ORIGIN), Well-known discretionary (LOCAL_PREF, ATOMIC_AGGREGATE), Optional transitive (COMMUNITY), Optional non-transitive (MED)
•Route Reflectors — Solve iBGP full mesh requirement. RR reflects routes from clients. Cluster-ID prevents loops
•Confederations — Alternative to RR. Divide AS into sub-ASes with private AS numbers internally
•Communities — Route tagging for policy. Well-known: NO_EXPORT, NO_ADVERTISE, LOCAL_AS
•AS_PATH Manipulation — Prepending for traffic engineering. Longer AS_PATH = less preferred
•Route Filtering — Prefix lists, AS_PATH regex, community matching. Critical for security

BGP Security Knowledge

Senior candidates should discuss: RPKI/ROA for route origin validation, BGPsec for path validation (limited deployment), MANRS (Mutually Agreed Norms for Routing Security), and prefix filtering best practices (max-prefix limits, bogon filtering, IRR validation).

Application Layer Protocol Knowledge

Application layer protocols come up frequently because they represent what users actually experience. DNS and HTTP are particularly common interview topics.

DNS Protocol Deep Knowledge

DNS Message Structure
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
# DNS Message Format - Interview Reference
 
┌───────────────────────────────────────────────────────────┐
│                     HEADER (12 bytes)                      │
├───────────────────────────────────────────────────────────┤
│ Transaction ID (16 bits)       │ Flags (16 bits)          │
│                                │  QR: 0=query, 1=response │
│                                │  OPCODE: 0=standard      │
│                                │  AA: Authoritative Answer│
│                                │  TC: Truncated           │
│                                │  RD: Recursion Desired   │
│                                │  RA: Recursion Available │
│                                │  RCODE: 0=OK, 3=NXDOMAIN │
├───────────────────────────────────────────────────────────┤
│ QDCOUNT (questions)   │ ANCOUNT (answer RRs)              │
│ NSCOUNT (authority)   │ ARCOUNT (additional RRs)          │
├───────────────────────────────────────────────────────────┤
│                     QUESTION SECTION                       │
│ QNAME: Domain name in labels (e.g., \x03www\x07example...) │
│ QTYPE: Record type (1=A, 28=AAAA, 15=MX...)              │
│ QCLASS: Usually 1 (IN = Internet)                         │
├───────────────────────────────────────────────────────────┤
│                     ANSWER SECTION                         │
│ NAME, TYPE, CLASS, TTL, RDLENGTH, RDATA                   │
├───────────────────────────────────────────────────────────┤
│                   AUTHORITY SECTION                        │
│ NS records for the zone                                    │
├───────────────────────────────────────────────────────────┤
│                   ADDITIONAL SECTION                       │
│ Glue records, EDNS0 OPT record                            │
└───────────────────────────────────────────────────────────┘
 
# Key DNS Interview Points:
 
1. UDP vs TCP:
   - UDP port 53: Standard queries (< 512 bytes traditional, EDNS0 allows larger)
   - TCP port 53: Zone transfers (AXFR), large responses, DNS-over-TCP for reliability
 
2. EDNS0 (Extension mechanisms for DNS):
   - Larger UDP messages (up to 4096 bytes typically)
   - Required for DNSSEC
   - OPT pseudo-record in Additional section
 
3. DNSSEC:
   - RRSIG: Signature over RRset
   - DNSKEY: Public key for zone
   - DS: Delegation Signer, links parent to child
   - NSEC/NSEC3: Authenticated denial of existence

HTTP Protocol Evolution

HTTP Protocol Versions Deep Comparison
Aspect	HTTP/1.0	HTTP/1.1	HTTP/2	HTTP/3
Connection Model	New connection per request	Persistent connections (Keep-Alive)	Single connection, multiplexed streams	QUIC connection, independent streams
Head-of-Line Blocking	N/A (no multiplexing)	Yes (pipelining rarely used)	Solved at HTTP level, persists at TCP level	Fully solved (independent streams)
Header Compression	None	None	HPACK (static + dynamic table)	QPACK (handles out-of-order delivery)
Server Push	No	No	Yes (PUSH_PROMISE)	Yes (limited adoption)
Request Prioritization	No	No (implicit with separate connections)	Yes (dependency tree, deprecated)	Yes (simplified priority scheme)
Binary vs Text	Text	Text	Binary framing	Binary framing
TLS Requirement	Optional	Optional	Practically required (ALPN)	Built-in (TLS 1.3 in QUIC)

HTTP Interview Depth Points

Impress interviewers by discussing: (1) Why 6 parallel connections was the HTTP/1.1 workaround and its inefficiency. (2) How ALPN (Application-Layer Protocol Negotiation) in TLS enables version selection. (3) HPACK's vulnerability to CRIME-like attacks and QPACK's solution. (4) Why connection migration matters for mobile—IP changes don't break QUIC connections.

Security Protocol Expertise

Security protocol knowledge is increasingly expected across all network roles. TLS, IPsec, and authentication protocols are common interview topics.

TLS/SSL Deep Knowledge

TLS Version Comparison
Feature	TLS 1.2	TLS 1.3	Why It Matters
Handshake RTT	2 RTT	1 RTT (0-RTT resumption)	Significant latency reduction
Key Exchange	RSA or DHE/ECDHE	DHE/ECDHE only (PFS mandatory)	RSA key exchange removed—no forward secrecy risk
Cipher Suites	Many legacy options	Only 5 AEAD suites	Removed weak algorithms (CBC, SHA-1)
Handshake Encryption	ClientHello/ServerHello cleartext	Encrypted after ServerHello	Privacy: hides certificate, extensions
0-RTT	Not supported	Supported (with replay caveats)	Faster repeat connections, security trade-off
Session Resumption	Session ID, Session Ticket	PSK (Pre-Shared Key)	Simpler, more secure resumption

TLS 1.3 Cipher Suite Example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# TLS 1.3 Cipher Suites (all AEAD)
 
TLS_AES_128_GCM_SHA256        (0x1301) - Most common
TLS_AES_256_GCM_SHA384        (0x1302) - Higher security
TLS_CHACHA20_POLY1305_SHA256  (0x1303) - Good for mobile (no AES-NI)
TLS_AES_128_CCM_SHA256        (0x1304) - IoT focused
TLS_AES_128_CCM_8_SHA256      (0x1305) - IoT, shorter tag
 
# Cipher Suite Structure Explanation:
# [AEAD Algorithm]_[Key Size]_[Mode]_[Hash for HKDF]
 
# Interview Question: "What is AEAD?"
# AEAD = Authenticated Encryption with Associated Data
# - Combines encryption and authentication in one operation
# - Protects both confidentiality and integrity
# - Examples: GCM (Galois/Counter Mode), ChaCha20-Poly1305
# - Replaces separate Encrypt-then-MAC constructions
 
# Forward Secrecy Explanation:
# - Each session generates unique ephemeral keys (ECDHE)
# - Compromise of server's long-term private key doesn't 
#   decrypt past sessions
# - Critical for protecting recorded traffic
# - Why TLS 1.3 removes RSA key exchange: no forward secrecy

IPsec Fundamentals

IPsec Interview Knowledge

•Two Modes: Transport (host-to-host, original IP header retained) vs Tunnel (gateway-to-gateway, entire original packet encapsulated with new IP header)
•Two Protocols: AH (Authentication Header, integrity only, IP protocol 51) vs ESP (Encapsulating Security Payload, integrity + confidentiality, IP protocol 50)
•IKE (Internet Key Exchange): Phase 1 establishes IKE SA (secure channel). Phase 2 negotiates IPsec SAs (data protection). IKEv2 simplifies to 4 messages.
•Security Association (SA): Unidirectional; defined by SPI (Security Parameter Index), protocol (ESP/AH), destination IP. Two SAs per bidirectional connection.
•Perfect Forward Secrecy: Optional DH exchange in Phase 2 provides unique keys per SA, limiting damage from key compromise.
•NAT Traversal (NAT-T): Encapsulates ESP in UDP (port 4500) when NAT detected, since ESP has no port numbers for NAT to rewrite.

IPsec vs TLS Interview Question

Be prepared to compare: IPsec operates at Layer 3 (protects all IP traffic, transparent to applications) while TLS operates at Layer 4/5 (application-aware, per-socket configuration). IPsec is typically for site-to-site VPN or remote access; TLS is for application-level security. IPsec requires OS/network config; TLS is application-controlled.

Wireless Protocol Knowledge

Wireless networking appears in many roles, especially with the growth of remote work and IoT. Key areas include 802.11 standards and security protocols.

802.11 Standards Overview

802.11 Standards Comparison
Standard	Band(s)	Max Speed	Channel Width	Key Features
802.11n (Wi-Fi 4)	2.4/5 GHz	600 Mbps	20/40 MHz	MIMO (4x4), channel bonding, frame aggregation
802.11ac (Wi-Fi 5)	5 GHz only	6.9 Gbps	20-160 MHz	MU-MIMO (downlink), 8 spatial streams, beamforming
802.11ax (Wi-Fi 6)	2.4/5 GHz	9.6 Gbps	20-160 MHz	OFDMA, MU-MIMO (up+down), TWT, 1024-QAM
802.11ax (Wi-Fi 6E)	2.4/5/6 GHz	9.6 Gbps	Up to 160 MHz	6 GHz band: 7 additional 160 MHz channels
802.11be (Wi-Fi 7)	2.4/5/6 GHz	46 Gbps	Up to 320 MHz	4K-QAM, Multi-Link Operation, CMU-MIMO

Wireless Security Evolution

Wi-Fi Security Standards

•WEP (Wired Equivalent Privacy) — Broken. 24-bit IV, RC4 cipher, easily cracked in minutes. Never use.
•WPA (Wi-Fi Protected Access) — Interim fix. TKIP (Temporal Key Integrity Protocol). Also broken (TKIP attacks).
•WPA2 — Current standard. CCMP (AES-128). Personal (PSK) or Enterprise (802.1X/RADIUS). KRACK vulnerability patched.
•WPA3 — Latest. SAE (Simultaneous Authentication of Equals) replaces PSK handshake. Forward secrecy, protected management frames, 192-bit for enterprise.

Enterprise Wireless Interview Topics

For enterprise roles, know: 802.1X/EAP authentication (EAP-TLS, PEAP), RADIUS integration, controller-based vs controller-less architectures, RF planning basics (channel planning, power levels), and roaming protocols (802.11r for fast BSS transition, 802.11k for neighbor reports).

Protocol Troubleshooting Patterns

Interviewers often present protocol-specific troubleshooting scenarios. Having known patterns accelerates diagnosis and demonstrates experience.

Common Protocol Issues and Diagnostics

Protocol Troubleshooting Quick Reference
Protocol	Common Issue	Symptoms	Diagnostic Approach
TCP	Retransmission storm	Slow transfers, high latency	Packet capture, check for duplicate ACKs, verify MTU/MSS
TCP	Connection reset (RST)	Connection immediately closed	Firewall dropping, port not listening, TCP wrapper deny
DNS	SERVFAIL responses	Applications fail to resolve names	Check upstream servers, DNSSEC validation, resolver logs
DNS	High query latency	Slow initial page loads	Measure each resolution stage, check caching, forwarder health
OSPF	Neighbor stuck in EXSTART	No routes learned	Check MTU match, Router ID uniqueness, authentication
BGP	Session flapping	Route instability, brief outages	Check hold timer, keepalive, interface stability, peer config
TLS	Handshake failure	HTTPS not loading	openssl s_client output, check ciphers, SNI, cert chain
ARP	Duplicate IP detection	Intermittent connectivity	Check ARP table, look for MAC changes, gratuitous ARP

Essential Diagnostic Commands

Demonstrate command-line fluency for common troubleshooting scenarios:

Protocol Diagnostic Commands
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
# TCP/IP Diagnostics
 
# Check listening ports and connections
netstat -tulpn                  # Linux: all TCP/UDP listeners
ss -tulpn                       # Linux: modern alternative
netstat -an | findstr LISTENING # Windows
 
# Trace TCP connection
tcpdump -i eth0 port 443        # Linux: capture HTTPS traffic
wireshark                       # GUI analysis with protocol decode
 
# DNS Diagnostics
dig example.com +trace          # Follow delegation chain
dig example.com @8.8.8.8        # Query specific resolver
nslookup -query=MX example.com  # Specific record type
host -t AAAA example.com        # Simple lookup
 
# Routing Diagnostics
ip route show                   # Linux routing table
route print                     # Windows routing table
traceroute -n example.com       # Path without DNS (Linux)
tracert -d example.com          # Path without DNS (Windows)
mtr example.com                 # Combined ping+traceroute
 
# OSPF/BGP (Cisco-style)
show ip ospf neighbor           # OSPF adjacencies
show ip ospf database           # LSDB contents
show ip bgp summary             # BGP peer status
show ip bgp neighbors x.x.x.x   # Detailed peer info
 
# TLS Diagnostics
openssl s_client -connect host:443 -servername host  # TLS handshake
openssl s_client -connect host:443 -showcerts        # Full cert chain
curl -v --tlsv1.2 https://host                       # HTTP + TLS verbose
 
# ARP/MAC Diagnostics
arp -a                          # ARP cache
ip neigh show                   # Linux: neighbor table
show mac address-table          # Switch: MAC learning

Protocol Design Thinking

Senior interviews may probe your understanding of why protocols are designed the way they are. This demonstrates architectural thinking and the ability to evaluate new protocols or design extensions.

Key Protocol Design Trade-offs

Protocol Design Considerations

•Reliability vs Latency — TCP guarantees delivery but adds overhead. UDP is faster but unreliable. QUIC brings reliability to UDP substrate with per-stream independence.
•State vs Stateless — Stateful (TCP, BGP sessions) enables advanced features but requires state management. Stateless (UDP, IP routing) scales better but limits features.
•In-band vs Out-of-band Signaling — Control information alongside data (TCP flags in header) vs separate channels (ICMP for error messages). Trade-off: simplicity vs flexibility.
•Push vs Pull — Server pushes updates (routing protocols) vs client pulls (HTTP 1.x). Push is timely but can overwhelm; pull is predictable but may miss urgent changes.
•Encryption Overhead vs Security — TLS adds latency and CPU cost. IPsec adds overhead but is transparent to applications. Trade-off: security level vs performance.
•Backward Compatibility vs Evolution — IP options enable extension but are often blocked. QUIC runs on UDP to avoid middlebox ossification. Trade-off: deployment ease vs clean design.

Example: Why Did HTTP/3 Choose QUIC over TCP?

This question tests protocol design understanding. A strong answer covers:

TCP Limitations for HTTP/2

• TCP HOL blocking — Single lost packet blocks all streams because TCP guarantees order across entire connection

• Handshake latency — TCP 3-way + TLS handshake = 2-3 RTT before first byte

• Connection migration — TCP 4-tuple (IPs + ports) fixed; IP change breaks connection

• Ossification — Middleboxes interfere with TCP extensions; hard to evolve TCP

QUIC Solutions

• Stream independence — Loss in one stream doesn't block others; QUIC handles reliability per-stream

• 0-RTT possible — Integrates TLS 1.3; combined handshake for repeat visits

• Connection ID — Connections identified by ID, not IPs; survives network changes

• UDP encapsulation — Runs on UDP; kernel bypass, avoids middlebox interference, enables in-application evolution

Protocol Evolution Pattern

Notice the pattern: When lower layers become ossified (TCP extensions blocked by middleboxes), innovation moves up the stack (QUIC runs on UDP). When higher layers add too much complexity (HTTP/1.1 workarounds), new protocols emerge (HTTP/2). Understanding these evolutionary pressures helps predict future protocol development.

Summary: Protocol Knowledge Mastery

We've covered the essential protocol knowledge expected in network interviews. Remember: depth matters more than breadth. It's better to thoroughly understand TCP than to superficially know 20 protocols.

Key Takeaways

•TCP/IP is foundational — Know connection lifecycle, congestion control, and failure modes cold. These come up in virtually every interview.
•Routing protocols differentiate — OSPF and BGP knowledge signals senior capability. Understand algorithms, not just configuration.
•Application protocols are visible — DNS and HTTP questions let interviewers assess practical troubleshooting experience.
•Security is mandatory — TLS knowledge is expected at all levels. Understanding IPsec adds value for infrastructure roles.
•Troubleshooting patterns — Having diagnostic approaches for common protocol issues demonstrates operational experience.
•Design reasoning — Understanding why protocols are designed as they are shows architectural thinking.

Page Complete

You now have a comprehensive framework for the protocol knowledge expected in network interviews. The next page covers Practical Scenarios—applying this knowledge to real-world interview problems that test your ability to synthesize multiple concepts under pressure.

3 / 5

Loading learning content...

Network Interview Preparation - Page 3 of 5 | OneNoughtOne

Computer NetworksInterview Preparation

Network Interview Preparation

LevelAdvanced

Duration90 mins

TopicInterview Preparation

3 / 5

Protocol Knowledge for Interviews

Demonstrating Protocol Expertise

This page covers the protocol knowledge interviewers expect at various levels, organized by protocol category. For each protocol area, we'll cover:

Core concepts you must know cold — The fundamentals that should be automatic
Deep-dive topics for senior roles — Advanced understanding that demonstrates expertise
Common interview questions and ideal answers — Preparing for exactly what you'll be asked
Failure modes and troubleshooting — Showing operational experience

What You Will Learn

TCP/IP Protocol Suite Mastery

TCP Deep Knowledge

TCP Knowledge by Interview Level
Topic	Junior Expectation	Senior Expectation	Principal/Architect Expectation
Connection Lifecycle	3-way handshake, 4-way close	ISN generation, TIME_WAIT purpose, half-open connections	TCP state machine, simultaneous open/close, attack vectors
Flow Control	Sliding window concept	Window scaling, receiver window dynamics	Zero window probes, window update races, Silly Window Syndrome
Congestion Control	Slow start, AIMD concept	CWND/ssthresh interaction, fast retransmit/recovery	CUBIC vs BBR trade-offs, fairness issues, ECN implementation
Options	Aware that options exist	MSS, Window Scale, Timestamps, SACK	Option negotiation failures, middlebox interference, TCP extensions
Performance	TCP is reliable	BDP, latency impact, connection reuse benefits	TCP performance tuning, sysctl parameters, kernel bypass

Critical TCP Topics for Interviews

The TCP State Machine: Understanding this separates confident candidates from uncertain ones.

TCP State Transitions
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
# TCP State Machine - Key States and Transitions
 
             ┌──────────────────────────────────────────────────────────┐
             │                        CLOSED                            │
             └──────────┬─────────────────────────────────┬─────────────┘
                        │ passive open                    │ active open
                        │ (listen)                        │ (connect)
                        ▼                                 ▼
             ┌──────────────────┐                ┌──────────────────┐
             │     LISTEN       │                │    SYN_SENT      │
             └────────┬─────────┘                └────────┬─────────┘
                      │ rcv SYN                           │ rcv SYN-ACK
                      │ send SYN-ACK                      │ send ACK
                      ▼                                   ▼
             ┌──────────────────┐                ┌──────────────────┐
             │   SYN_RECEIVED   │                │   ESTABLISHED    │◄───────┐
             └────────┬─────────┘                └────────┬─────────┘        │
                      │ rcv ACK                           │ close            │
                      └───────────────────────────────────┤ send FIN         │
                                                          ▼                  │
                                                 ┌──────────────────┐        │
                                                 │    FIN_WAIT_1    │        │
                                                 └────────┬─────────┘        │
                                rcv FIN+ACK               │ rcv ACK          │
                                send ACK ────────────┐    │                  │
                                          │          │    ▼                  │
                                          │   ┌──────────────────┐           │
                                          │   │    FIN_WAIT_2    │           │
                                          │   └────────┬─────────┘           │
                                          │            │ rcv FIN             │
                                          │            │ send ACK            │
                                          │            ▼                     │
                                          │   ┌──────────────────┐           │
                                          └──►│    TIME_WAIT     │───────────┘
                                              └────────┬─────────┘    2MSL timeout
                                                       │
                                                       ▼ (back to CLOSED)
 
# Interview-Critical Knowledge:
 
1. TIME_WAIT (2MSL = ~60-120 seconds)
   - Purpose: Ensures delayed packets don't confuse new connections
   - Problem: Can exhaust local ports for high-connection-rate servers
   - Tuning: tcp_tw_reuse, tcp_tw_recycle (deprecated), time_wait buckets
 
2. SYN_RECEIVED accumulation = SYN flood attack or backlog overflow
   - Defense: SYN cookies, increase backlog, rate limiting
 
3. CLOSE_WAIT accumulation = Application not closing sockets properly
   - Indicates: Application bug, resource leak on server side
 
4. FIN_WAIT_2 accumulation = Remote end acknowledged close but hasn't closed
   - May indicate: Remote application hung, network partition during close

IP Protocol Deep Knowledge

IP seems simple but has surprising depth. Focus on addressing, routing behavior, and fragmentation.

IPv4 Header Fields to Know

•Version (4 bits) — IPv4 = 4. Why is IPv6 = 6 and not 5? (IPv5 was experimental Stream Protocol)
•IHL (4 bits) — Header length in 32-bit words. Minimum 5 (20 bytes), max 15 (60 bytes with options)
•DSCP/ECN (8 bits) — DiffServ for QoS, ECN for congestion signaling without packet drops
•Total Length (16 bits) — Max 65,535 bytes. Why jumbo frames work: they're ethernet-level, IP stays under limit
•Identification/Flags/Fragment Offset — Fragmentation handling. DF bit critical for PMTUD
•TTL (8 bits) — Prevents routing loops. Decremented at each hop. Traceroute exploits TTL expiry messages
•Protocol (8 bits) — 6=TCP, 17=UDP, 1=ICMP, 50=ESP, 51=AH, 89=OSPF
•Header Checksum — Covers only header, not payload. Must recompute at each hop (TTL changes)
•Options — Source routing (mostly blocked now), timestamps, record route

Common Interview Trap: MTU vs MSS

Routing Protocol Expertise

Routing protocol knowledge separates network engineers from generalists. Interviewers expect understanding of protocol categories, algorithms, and operational characteristics.

Distance Vector vs Link State Fundamentals

Distance Vector (RIP, EIGRP)

•Bellman-Ford algorithm — Iterative, distributed
•Shares routing table with neighbors only
•Routing by rumor — Trusts neighbors' information
•Slow convergence — Count-to-infinity problem
•Simple configuration — Minimal topology knowledge
•Limited scalability — Periodic full updates

Link State (OSPF, IS-IS)

•Dijkstra's SPF algorithm — Complete path calculation
•Floods LSAs — All routers have complete topology
•Complete view — Each router calculates independently
•Fast convergence — Changes propagate quickly
•More complex — Area design, DR/BDR election
•Highly scalable — Incremental, event-driven updates

OSPF Deep Dive

OSPF is the most commonly tested IGP. Senior candidates should understand multi-area design, LSA types, and adjacency formation.

OSPF LSA Types
LSA Type	Name	Originated By	Flooded Within	Purpose
Type 1	Router LSA	Every router	Area	Describes router's directly connected links
Type 2	Network LSA	DR on multi-access networks	Area	Describes all routers attached to segment
Type 3	Summary LSA	ABR	Other areas	Summarizes routes between areas
Type 4	ASBR Summary LSA	ABR	Other areas	Advertises reachability to ASBR
Type 5	External LSA	ASBR	Entire domain	Redistributed external routes
Type 7	NSSA External LSA	ASBR in NSSA	NSSA only	External routes in Not-So-Stubby-Areas

OSPF Adjacency Formation
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
# OSPF Neighbor States - Interview Essential
 
Down → Init → 2-Way → ExStart → Exchange → Loading → Full
 
┌──────────────────────────────────────────────────────────────────────────┐
│ DOWN     │ No Hello received from neighbor                              │
├──────────────────────────────────────────────────────────────────────────┤
│ INIT     │ Hello received, but own Router ID not seen in neighbor's     │
│          │ Hello (one-way communication)                                │
├──────────────────────────────────────────────────────────────────────────┤
│ 2-WAY    │ Bidirectional communication established                      │
│          │ ★ DR/BDR election happens here on multi-access networks     │
│          │ ★ Non-DR/BDR routers stop here (DROTHER state)              │
├──────────────────────────────────────────────────────────────────────────┤
│ EXSTART  │ Master/slave negotiation for database exchange               │
│          │ Higher Router ID becomes master                              │
├──────────────────────────────────────────────────────────────────────────┤
│ EXCHANGE │ Database Description (DBD) packets exchanged                 │
│          │ Routers learn what LSAs each other has                       │
├──────────────────────────────────────────────────────────────────────────┤
│ LOADING  │ Link State Requests (LSR) and Updates (LSU)                  │
│          │ Routers request missing/newer LSAs                           │
├──────────────────────────────────────────────────────────────────────────┤
│ FULL     │ Databases synchronized, adjacency complete                    │
│          │ Now participate in SPF calculations together                 │
└──────────────────────────────────────────────────────────────────────────┘
 
# Common Interview Question: "Why is neighbor stuck in EXSTART/EXCHANGE?"
 
Causes:
1. MTU mismatch (DBD packets too large)
2. Duplicate Router IDs
3. Area type mismatch
4. Authentication failure (after Hello succeeds)
5. DBD sequence number mismatch
 
# Key Timers (defaults, seconds):
Hello Interval: 10 (broadcast/p2p), 30 (NBMA)  
Dead Interval:  40 (broadcast/p2p), 120 (NBMA)
LSA Refresh:    1800 (30 minutes)
MaxAge:         3600 (1 hour, then LSA deleted)

BGP Expertise (Required for Senior Roles)

BGP knowledge is essential for anyone working with internet connectivity, cloud networking, or large enterprises. The depth expected is significant.

BGP Knowledge Checklist

•eBGP vs iBGP — eBGP between ASes, TTL=1 by default. iBGP within AS, full mesh or route reflectors required (split-horizon rule)
•Path Selection Algorithm — Weight → Local Pref → Originate → AS_PATH length → Origin Type → MED → eBGP over iBGP → IGP metric → Router ID
•Attributes — Well-known mandatory (AS_PATH, NEXT_HOP, ORIGIN), Well-known discretionary (LOCAL_PREF, ATOMIC_AGGREGATE), Optional transitive (COMMUNITY), Optional non-transitive (MED)
•Route Reflectors — Solve iBGP full mesh requirement. RR reflects routes from clients. Cluster-ID prevents loops
•Confederations — Alternative to RR. Divide AS into sub-ASes with private AS numbers internally
•Communities — Route tagging for policy. Well-known: NO_EXPORT, NO_ADVERTISE, LOCAL_AS
•AS_PATH Manipulation — Prepending for traffic engineering. Longer AS_PATH = less preferred
•Route Filtering — Prefix lists, AS_PATH regex, community matching. Critical for security

BGP Security Knowledge

Application Layer Protocol Knowledge

Application layer protocols come up frequently because they represent what users actually experience. DNS and HTTP are particularly common interview topics.

DNS Protocol Deep Knowledge

DNS Message Structure
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
# DNS Message Format - Interview Reference
 
┌───────────────────────────────────────────────────────────┐
│                     HEADER (12 bytes)                      │
├───────────────────────────────────────────────────────────┤
│ Transaction ID (16 bits)       │ Flags (16 bits)          │
│                                │  QR: 0=query, 1=response │
│                                │  OPCODE: 0=standard      │
│                                │  AA: Authoritative Answer│
│                                │  TC: Truncated           │
│                                │  RD: Recursion Desired   │
│                                │  RA: Recursion Available │
│                                │  RCODE: 0=OK, 3=NXDOMAIN │
├───────────────────────────────────────────────────────────┤
│ QDCOUNT (questions)   │ ANCOUNT (answer RRs)              │
│ NSCOUNT (authority)   │ ARCOUNT (additional RRs)          │
├───────────────────────────────────────────────────────────┤
│                     QUESTION SECTION                       │
│ QNAME: Domain name in labels (e.g., \x03www\x07example...) │
│ QTYPE: Record type (1=A, 28=AAAA, 15=MX...)              │
│ QCLASS: Usually 1 (IN = Internet)                         │
├───────────────────────────────────────────────────────────┤
│                     ANSWER SECTION                         │
│ NAME, TYPE, CLASS, TTL, RDLENGTH, RDATA                   │
├───────────────────────────────────────────────────────────┤
│                   AUTHORITY SECTION                        │
│ NS records for the zone                                    │
├───────────────────────────────────────────────────────────┤
│                   ADDITIONAL SECTION                       │
│ Glue records, EDNS0 OPT record                            │
└───────────────────────────────────────────────────────────┘
 
# Key DNS Interview Points:
 
1. UDP vs TCP:
   - UDP port 53: Standard queries (< 512 bytes traditional, EDNS0 allows larger)
   - TCP port 53: Zone transfers (AXFR), large responses, DNS-over-TCP for reliability
 
2. EDNS0 (Extension mechanisms for DNS):
   - Larger UDP messages (up to 4096 bytes typically)
   - Required for DNSSEC
   - OPT pseudo-record in Additional section
 
3. DNSSEC:
   - RRSIG: Signature over RRset
   - DNSKEY: Public key for zone
   - DS: Delegation Signer, links parent to child
   - NSEC/NSEC3: Authenticated denial of existence

HTTP Protocol Evolution

HTTP Protocol Versions Deep Comparison
Aspect	HTTP/1.0	HTTP/1.1	HTTP/2	HTTP/3
Connection Model	New connection per request	Persistent connections (Keep-Alive)	Single connection, multiplexed streams	QUIC connection, independent streams
Head-of-Line Blocking	N/A (no multiplexing)	Yes (pipelining rarely used)	Solved at HTTP level, persists at TCP level	Fully solved (independent streams)
Header Compression	None	None	HPACK (static + dynamic table)	QPACK (handles out-of-order delivery)
Server Push	No	No	Yes (PUSH_PROMISE)	Yes (limited adoption)
Request Prioritization	No	No (implicit with separate connections)	Yes (dependency tree, deprecated)	Yes (simplified priority scheme)
Binary vs Text	Text	Text	Binary framing	Binary framing
TLS Requirement	Optional	Optional	Practically required (ALPN)	Built-in (TLS 1.3 in QUIC)

HTTP Interview Depth Points

Security Protocol Expertise

Security protocol knowledge is increasingly expected across all network roles. TLS, IPsec, and authentication protocols are common interview topics.

TLS/SSL Deep Knowledge

TLS Version Comparison
Feature	TLS 1.2	TLS 1.3	Why It Matters
Handshake RTT	2 RTT	1 RTT (0-RTT resumption)	Significant latency reduction
Key Exchange	RSA or DHE/ECDHE	DHE/ECDHE only (PFS mandatory)	RSA key exchange removed—no forward secrecy risk
Cipher Suites	Many legacy options	Only 5 AEAD suites	Removed weak algorithms (CBC, SHA-1)
Handshake Encryption	ClientHello/ServerHello cleartext	Encrypted after ServerHello	Privacy: hides certificate, extensions
0-RTT	Not supported	Supported (with replay caveats)	Faster repeat connections, security trade-off
Session Resumption	Session ID, Session Ticket	PSK (Pre-Shared Key)	Simpler, more secure resumption

TLS 1.3 Cipher Suite Example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# TLS 1.3 Cipher Suites (all AEAD)
 
TLS_AES_128_GCM_SHA256        (0x1301) - Most common
TLS_AES_256_GCM_SHA384        (0x1302) - Higher security
TLS_CHACHA20_POLY1305_SHA256  (0x1303) - Good for mobile (no AES-NI)
TLS_AES_128_CCM_SHA256        (0x1304) - IoT focused
TLS_AES_128_CCM_8_SHA256      (0x1305) - IoT, shorter tag
 
# Cipher Suite Structure Explanation:
# [AEAD Algorithm]_[Key Size]_[Mode]_[Hash for HKDF]
 
# Interview Question: "What is AEAD?"
# AEAD = Authenticated Encryption with Associated Data
# - Combines encryption and authentication in one operation
# - Protects both confidentiality and integrity
# - Examples: GCM (Galois/Counter Mode), ChaCha20-Poly1305
# - Replaces separate Encrypt-then-MAC constructions
 
# Forward Secrecy Explanation:
# - Each session generates unique ephemeral keys (ECDHE)
# - Compromise of server's long-term private key doesn't 
#   decrypt past sessions
# - Critical for protecting recorded traffic
# - Why TLS 1.3 removes RSA key exchange: no forward secrecy

IPsec Fundamentals

IPsec Interview Knowledge

•Two Modes: Transport (host-to-host, original IP header retained) vs Tunnel (gateway-to-gateway, entire original packet encapsulated with new IP header)
•Two Protocols: AH (Authentication Header, integrity only, IP protocol 51) vs ESP (Encapsulating Security Payload, integrity + confidentiality, IP protocol 50)
•IKE (Internet Key Exchange): Phase 1 establishes IKE SA (secure channel). Phase 2 negotiates IPsec SAs (data protection). IKEv2 simplifies to 4 messages.
•Security Association (SA): Unidirectional; defined by SPI (Security Parameter Index), protocol (ESP/AH), destination IP. Two SAs per bidirectional connection.
•Perfect Forward Secrecy: Optional DH exchange in Phase 2 provides unique keys per SA, limiting damage from key compromise.
•NAT Traversal (NAT-T): Encapsulates ESP in UDP (port 4500) when NAT detected, since ESP has no port numbers for NAT to rewrite.

IPsec vs TLS Interview Question

Wireless Protocol Knowledge

Wireless networking appears in many roles, especially with the growth of remote work and IoT. Key areas include 802.11 standards and security protocols.

802.11 Standards Overview

802.11 Standards Comparison
Standard	Band(s)	Max Speed	Channel Width	Key Features
802.11n (Wi-Fi 4)	2.4/5 GHz	600 Mbps	20/40 MHz	MIMO (4x4), channel bonding, frame aggregation
802.11ac (Wi-Fi 5)	5 GHz only	6.9 Gbps	20-160 MHz	MU-MIMO (downlink), 8 spatial streams, beamforming
802.11ax (Wi-Fi 6)	2.4/5 GHz	9.6 Gbps	20-160 MHz	OFDMA, MU-MIMO (up+down), TWT, 1024-QAM
802.11ax (Wi-Fi 6E)	2.4/5/6 GHz	9.6 Gbps	Up to 160 MHz	6 GHz band: 7 additional 160 MHz channels
802.11be (Wi-Fi 7)	2.4/5/6 GHz	46 Gbps	Up to 320 MHz	4K-QAM, Multi-Link Operation, CMU-MIMO

Wireless Security Evolution

Wi-Fi Security Standards

•WEP (Wired Equivalent Privacy) — Broken. 24-bit IV, RC4 cipher, easily cracked in minutes. Never use.
•WPA (Wi-Fi Protected Access) — Interim fix. TKIP (Temporal Key Integrity Protocol). Also broken (TKIP attacks).
•WPA2 — Current standard. CCMP (AES-128). Personal (PSK) or Enterprise (802.1X/RADIUS). KRACK vulnerability patched.
•WPA3 — Latest. SAE (Simultaneous Authentication of Equals) replaces PSK handshake. Forward secrecy, protected management frames, 192-bit for enterprise.

Enterprise Wireless Interview Topics

Protocol Troubleshooting Patterns

Interviewers often present protocol-specific troubleshooting scenarios. Having known patterns accelerates diagnosis and demonstrates experience.

Common Protocol Issues and Diagnostics

Protocol Troubleshooting Quick Reference
Protocol	Common Issue	Symptoms	Diagnostic Approach
TCP	Retransmission storm	Slow transfers, high latency	Packet capture, check for duplicate ACKs, verify MTU/MSS
TCP	Connection reset (RST)	Connection immediately closed	Firewall dropping, port not listening, TCP wrapper deny
DNS	SERVFAIL responses	Applications fail to resolve names	Check upstream servers, DNSSEC validation, resolver logs
DNS	High query latency	Slow initial page loads	Measure each resolution stage, check caching, forwarder health
OSPF	Neighbor stuck in EXSTART	No routes learned	Check MTU match, Router ID uniqueness, authentication
BGP	Session flapping	Route instability, brief outages	Check hold timer, keepalive, interface stability, peer config
TLS	Handshake failure	HTTPS not loading	openssl s_client output, check ciphers, SNI, cert chain
ARP	Duplicate IP detection	Intermittent connectivity	Check ARP table, look for MAC changes, gratuitous ARP

Essential Diagnostic Commands

Demonstrate command-line fluency for common troubleshooting scenarios:

Protocol Diagnostic Commands
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
# TCP/IP Diagnostics
 
# Check listening ports and connections
netstat -tulpn                  # Linux: all TCP/UDP listeners
ss -tulpn                       # Linux: modern alternative
netstat -an | findstr LISTENING # Windows
 
# Trace TCP connection
tcpdump -i eth0 port 443        # Linux: capture HTTPS traffic
wireshark                       # GUI analysis with protocol decode
 
# DNS Diagnostics
dig example.com +trace          # Follow delegation chain
dig example.com @8.8.8.8        # Query specific resolver
nslookup -query=MX example.com  # Specific record type
host -t AAAA example.com        # Simple lookup
 
# Routing Diagnostics
ip route show                   # Linux routing table
route print                     # Windows routing table
traceroute -n example.com       # Path without DNS (Linux)
tracert -d example.com          # Path without DNS (Windows)
mtr example.com                 # Combined ping+traceroute
 
# OSPF/BGP (Cisco-style)
show ip ospf neighbor           # OSPF adjacencies
show ip ospf database           # LSDB contents
show ip bgp summary             # BGP peer status
show ip bgp neighbors x.x.x.x   # Detailed peer info
 
# TLS Diagnostics
openssl s_client -connect host:443 -servername host  # TLS handshake
openssl s_client -connect host:443 -showcerts        # Full cert chain
curl -v --tlsv1.2 https://host                       # HTTP + TLS verbose
 
# ARP/MAC Diagnostics
arp -a                          # ARP cache
ip neigh show                   # Linux: neighbor table
show mac address-table          # Switch: MAC learning

Protocol Design Thinking

Key Protocol Design Trade-offs

Protocol Design Considerations

•Reliability vs Latency — TCP guarantees delivery but adds overhead. UDP is faster but unreliable. QUIC brings reliability to UDP substrate with per-stream independence.
•State vs Stateless — Stateful (TCP, BGP sessions) enables advanced features but requires state management. Stateless (UDP, IP routing) scales better but limits features.
•In-band vs Out-of-band Signaling — Control information alongside data (TCP flags in header) vs separate channels (ICMP for error messages). Trade-off: simplicity vs flexibility.
•Push vs Pull — Server pushes updates (routing protocols) vs client pulls (HTTP 1.x). Push is timely but can overwhelm; pull is predictable but may miss urgent changes.
•Encryption Overhead vs Security — TLS adds latency and CPU cost. IPsec adds overhead but is transparent to applications. Trade-off: security level vs performance.
•Backward Compatibility vs Evolution — IP options enable extension but are often blocked. QUIC runs on UDP to avoid middlebox ossification. Trade-off: deployment ease vs clean design.

Example: Why Did HTTP/3 Choose QUIC over TCP?

This question tests protocol design understanding. A strong answer covers:

TCP Limitations for HTTP/2

• TCP HOL blocking — Single lost packet blocks all streams because TCP guarantees order across entire connection

• Handshake latency — TCP 3-way + TLS handshake = 2-3 RTT before first byte

• Connection migration — TCP 4-tuple (IPs + ports) fixed; IP change breaks connection

• Ossification — Middleboxes interfere with TCP extensions; hard to evolve TCP

QUIC Solutions

• Stream independence — Loss in one stream doesn't block others; QUIC handles reliability per-stream

• 0-RTT possible — Integrates TLS 1.3; combined handshake for repeat visits

• Connection ID — Connections identified by ID, not IPs; survives network changes

• UDP encapsulation — Runs on UDP; kernel bypass, avoids middlebox interference, enables in-application evolution

Protocol Evolution Pattern

Summary: Protocol Knowledge Mastery

Key Takeaways

•TCP/IP is foundational — Know connection lifecycle, congestion control, and failure modes cold. These come up in virtually every interview.
•Routing protocols differentiate — OSPF and BGP knowledge signals senior capability. Understand algorithms, not just configuration.
•Application protocols are visible — DNS and HTTP questions let interviewers assess practical troubleshooting experience.
•Security is mandatory — TLS knowledge is expected at all levels. Understanding IPsec adds value for infrastructure roles.
•Troubleshooting patterns — Having diagnostic approaches for common protocol issues demonstrates operational experience.
•Design reasoning — Understanding why protocols are designed as they are shows architectural thinking.

Page Complete

3 / 5