Computer networking interviews should reveal whether a candidate can explain how traffic moves, identify where an exchange fails, and design a network that behaves predictably under load and during faults. Memorizing protocol names is not enough: a useful answer connects Ethernet forwarding, IP routing, transport behavior, and application dependencies to evidence such as route selection, interface counters, packet timing, and service symptoms.

These 120 questions move from packet and addressing foundations to protocol interactions and senior operational decisions. The focus is networking rather than a general Linux administration checklist or a cybersecurity certification syllabus. Recruiters can use the three difficulty levels to distinguish vocabulary from applied judgment, then change the topology, latency, traffic mix, or failure assumption to see whether the candidate can adapt the explanation.

How can recruiters tell whether a networking candidate can diagnose a real packet-path problem rather than repeat a memorized troubleshooting script?

Ask the candidate to draw both directions of a connection, explain which observation would distinguish a routing fault from a transport or application fault, and state what a packet capture cannot prove. A changed subnet mask or failed uplink creates a useful follow-up without requiring access to a production network.

Sherlock AI helps recruiters assess signals of potential AI cheating, deepfakes, impersonation, and unauthorized assistance during interviews.

Use those signals alongside topology walkthroughs and evidence-based technical follow-ups, not as conclusive proof of misconduct. Strong candidates identify assumptions, propose bounded tests, and explain the impact of an incorrect diagnosis.

Computer Networking Interview Questions

Select questions from this complete bank before consulting the answers. Make the topology, IP version, traffic direction, and operational constraints explicit so candidates can reason about a defined network rather than guess hidden assumptions.

Computer Networking Interview Questions for Beginners

These questions establish packet flow, Ethernet, addressing, transport, application protocols, and basic diagnostic literacy.

1. What is a computer network, and what does successful connectivity require?

2. How do the OSI and TCP/IP models help with troubleshooting?

3. What is encapsulation, and how do frames, packets, and segments differ?

4. How are MAC addresses different from IP addresses?

5. How does an Ethernet switch learn where to forward frames?

6. What are collision domains and broadcast domains?

7. How do unicast, broadcast, multicast, and anycast differ?

8. What problem does a VLAN solve?

9. What is the difference between an access port and a trunk port?

10. Why is spanning tree needed in an Ethernet network?

11. What does an IPv4 address and subnet mask tell you?

12. How does CIDR differ from historical classful addressing?

13. How do you calculate the network and usable range for 192.0.2.70/26?

14. What is the difference between private, public, and documentation addresses?

15. How is an IPv6 address written and shortened?

16. What does ARP do when an IPv4 host sends traffic?

17. How does IPv6 Neighbor Discovery differ from ARP?

18. What is a default gateway, and when is it used?

19. How does longest-prefix matching select an IP route?

20. What is ICMP, and what does a successful ping prove?

21. How do TCP and UDP differ?

22. What happens during the TCP three-way handshake?

23. What are transport ports, and how are they different from sockets?

24. What does DNS do, and why is it more than a name-to-address lookup?

25. How do A, AAAA, CNAME, and MX records differ?

26. How does DHCPv4 provide an address to a new client?

27. How do a static address and a DHCP reservation differ?

28. What is NAT, and how does port translation extend it?

29. What does TLS protect, and what does it not protect?

30. How do HTTP and HTTPS relate to transport protocols?

31. What is MTU, and how do IPv4 and IPv6 handle an oversized packet?

32. How are bandwidth, throughput, and goodput different?

33. What are latency, round-trip time, and jitter?

34. Why can packet loss occur even when the physical link is up?

35. What is the difference between full duplex and half duplex?

36. What is the difference between a router, a firewall, and a load balancer?

37. What does a VPN change about a packet's journey?

38. Which read-only commands can show a Linux host's network configuration?

39. How would you begin investigating a report that one website does not work?

40. What information makes a networking incident report useful?

Computer Networking Interview Questions for Intermediate

These questions examine switching and routing behavior, transport mechanics, IPv6 configuration, path MTU, name resolution, and practical troubleshooting.

41. What can make a VLAN work on one switch but fail across a trunk?

42. Why is a native VLAN mismatch a problem?

43. Why does adding a second LACP member not necessarily double one transfer's speed?

44. How would you investigate intermittent connectivity caused by a Layer 2 loop?

45. Why can an aggregate route look healthy while one destination range is unreachable?

46. How do route preference and a routing protocol's metric differ?

47. When are static routes preferable to dynamic routing?

48. Why might two OSPF routers fail to become fully adjacent?

49. What is the practical purpose of OSPF areas?

50. How do BGP LOCAL_PREF and AS_PATH influence route selection?

51. How do IPv6 router advertisements, SLAAC, and DHCPv6 fit together?

52. Why can a dual-stack application fail when IPv4 connectivity works?

53. What limits the number of simultaneous connections through PAT?

54. What should you infer when a TCP client repeatedly sends SYN packets without completing a handshake?

55. How do graceful TCP closure, reset, and TIME_WAIT differ?

56. How do TCP flow control and congestion control differ?

57. How does bandwidth-delay product help explain a slow long-distance TCP transfer?

58. What do retransmissions and selective acknowledgments reveal about TCP?

59. When is UDP appropriate despite its lack of built-in reliable delivery?

60. How does QUIC avoid one TCP head-of-line blocking problem?

61. Why can a DNS record change appear immediately for some users but not others?

62. How does DNS negative caching affect a newly created hostname?

63. What is a DNS delegation failure, and how is it different from a missing host record?

64. Why must DNS troubleshooting consider EDNS and TCP as well as UDP port 53?

65. Why does DHCP need a relay when clients and the server occupy different subnets?

66. Why can small requests succeed while larger transfers stall?

67. How are MTU and TCP MSS related without being identical?

68. How do shaping and policing affect traffic differently?

69. Does a DSCP marking guarantee priority across the Internet?

70. What is the difference between Layer 4 and Layer 7 load balancing?

71. Why can a load balancer report a backend healthy while user requests fail?

72. What changes when TLS terminates at a load balancer?

73. How should you compare HTTP/2 and HTTP/3 for a real deployment?

74. How would you isolate DNS, TCP, TLS, and HTTP failures in one connection attempt?

75. How can local route and socket inspection narrow a connectivity problem safely?

76. How would you review a saved packet capture without generating network traffic?

77. What should you inspect in dig output besides the returned address?

78. Why can a traceroute show asterisks even though the application works?

79. How can interface counters distinguish congestion from physical-link trouble?

80. Why can average bandwidth utilization hide a network performance problem?

Computer Networking Interview Questions for Experienced

These scenarios assess capacity planning, fault isolation, routing policy, multi-path and multi-site design, observability, and safe operational change.

81. How would you diagnose connections that fail only when return traffic uses a different path?

82. Why might an ECMP network have one congested link while its peers are mostly idle?

83. How can microbursts cause packet loss when five-minute utilization looks low?

84. How would you distinguish bufferbloat from insufficient link capacity?

85. How would you calculate oversubscription and decide whether it is acceptable?

86. How would you plan capacity for packet rate rather than just bandwidth?

87. What makes two redundant network paths share a hidden failure domain?

88. Why can faster routing failure detection still leave a long application outage?

89. How would you prevent a transit customer from accidentally turning your network into unwanted transit?

90. What does RPKI origin validation prove, and what does it leave unproven?

91. How would you design multihoming without promising perfect inbound traffic control?

92. When is anycast useful, and why can it disrupt long-lived sessions?

93. How would you investigate a slow WAN transfer when the access circuit is not saturated?

94. What would you infer if ten parallel transfers fill a WAN link but one transfer does not?

95. Why can small increases in packet loss have a large effect on application tail latency?

96. How would you diagnose a QUIC connection that fails when a client changes networks?

97. How would you diagnose outbound failures caused by NAT port exhaustion?

98. How would you migrate a production service to IPv6 without hiding failures behind IPv4 fallback?

99. How would you design DNS redundancy so that two nameservers are not one failure domain?

100. How would you evaluate a requirement for regional failover within ten seconds?

101. How would you distinguish a volumetric DDoS problem from an application capacity problem?

102. How would you protect routing protocols without breaking necessary control traffic?

103. Why are VLANs or VRFs alone insufficient evidence of secure segmentation?

104. What problem does EVPN solve in a VXLAN fabric, and what does it not solve?

105. How would you debug an overlay where small packets work but large transfers stall?

106. Why should an application avoid depending on IP fragmentation for routine delivery?

107. How would you design QoS without starving ordinary traffic?

108. How would you remove a backend from service without interrupting existing sessions?

109. How can an overly deep health check make a load-balanced outage worse?

110. What should a regional load-balancing design consider before enabling TLS 1.3 early data?

111. Why can a packet capture show bad checksums or packets larger than the interface MTU?

112. How would you localize packet loss when traceroute shows missing replies at an intermediate hop?

113. How would you choose between packet captures, flow records, and interface telemetry?

114. How would you investigate intermittent one-way audio without assuming the signaling path is healthy enough?

115. What would you check when large file transfers are healthy but interactive requests are slow?

116. How would you assess whether jumbo frames are worth deploying?

117. How would you validate a network change without running an uncontrolled production load test?

118. What makes a rollback plan credible for a routing or firewall change?

119. How would you prevent an overlapping address plan from derailing a merger or interconnection?

120. How would you summarize a network incident when the evidence does not establish one root cause?

Computer Networking Interview Questions and Answers

The answers follow the bank in exactly the same order and combine direct explanations, examples, and operational caveats. The examples distinguish IPv4 from IPv6 and OSPFv2 from OSPFv3; protocol extensions and vendor behavior are not assumed universal. TCP refers to RFC 9293, QUIC to its version 1 foundations, and TLS 1.3 to RFC 9846, which replaces RFC 8446 without defining a new TLS version. Documentation-reserved IP addresses and example domains are illustrative, not test targets. Inspection commands require the appropriate platform, privileges, and authorization; no live-network or hardware validation is claimed.

Computer Networking Interview Questions and Answers for Beginners

Look for accurate layer boundaries and a concrete explanation of what happens to a packet. Simple answers should still distinguish reachability, name resolution, and application success.

1. What is a computer network, and what does successful connectivity require?

A computer network connects devices so they can exchange data using agreed protocols. Successful application connectivity requires more than a cable or wireless association: endpoints need compatible addressing, a usable forwarding path, permitted traffic, and a responding application. For example, an interface can report link up while the host has the wrong subnet mask or its DNS resolver is unavailable. In an interview, separate physical connectivity, local-network reachability, routed reachability, and application behavior. That distinction turns a vague report such as “the network is down” into testable questions rather than an immediate equipment-replacement recommendation.

2. How do the OSI and TCP/IP models help with troubleshooting?

The OSI model describes seven conceptual layers, while the commonly used TCP/IP model groups functions into link, internet, transport, and application layers. They are reasoning aids, not guarantees that every real protocol fits one box perfectly. A failed Ethernet link suggests a different investigation from a successful TCP connection followed by an HTTP error. Work through observable dependencies without assuming every problem must be solved strictly from the bottom upward. For instance, a valid application response can establish that many lower-layer functions worked for that particular exchange, even when another path or protocol remains broken.

3. What is encapsulation, and how do frames, packets, and segments differ?

Encapsulation wraps higher-layer data in the headers, and sometimes trailers, needed by lower layers. In a common Ethernet/IP/TCP exchange, application bytes become TCP segments, those segments travel inside IP packets, and packets are carried in Ethernet frames. These names identify different boundaries rather than interchangeable sizes. A router normally removes the incoming link-layer framing and creates new framing for the next link, while forwarding the IP packet with required changes such as reducing TTL. Tunnels add further layers, which is why counting only the application payload can underestimate bandwidth use or exceed a path's available MTU.

4. How are MAC addresses different from IP addresses?

A MAC address identifies a link-layer interface within the relevant local forwarding context; an IP address supports network-layer addressing and routing. Ethernet switches typically use destination MAC addresses, whereas routers select routes using destination IP prefixes. A MAC address is not a reliable permanent identity: software can change it, devices can randomize it, and virtual interfaces have addresses too. When a host sends to a remote IP destination, the Ethernet destination is normally the local next-hop router's MAC address, not the remote server's MAC address. This distinction is central to understanding packet captures at different locations.

5. How does an Ethernet switch learn where to forward frames?

A learning switch records a frame's source MAC address and ingress port within the relevant VLAN. It then looks up the destination MAC address to choose forwarding behavior. A known unicast normally goes to the associated port; an unknown unicast is flooded within that VLAN, subject to implementation and configured controls. Learning entries age out, so a missing entry is not automatically an equipment fault. A useful diagnosis compares the expected physical or logical attachment with the learned location and checks whether the address moves unexpectedly. Do not confuse this MAC table with a host's ARP cache or a router's IP routing table.

6. What are collision domains and broadcast domains?

A collision domain describes where simultaneous transmissions can collide on a shared, half-duplex medium. Modern switched full-duplex Ethernet does not use the old shared-medium collision behavior during normal operation. A broadcast domain is the set of interfaces that can receive a link-layer broadcast, typically bounded by a VLAN in a switched Ethernet network. Routers do not simply forward Ethernet broadcasts between subnets. These concepts solve different problems: adding switch ports separates old collision domains, but does not by itself isolate broadcast traffic when all ports remain in the same VLAN. High broadcast traffic can therefore affect many otherwise independent links.

7. How do unicast, broadcast, multicast, and anycast differ?

Unicast addresses one destination, broadcast addresses all members of a broadcast domain, and multicast addresses a group whose receivers express interest through the relevant protocols. Anycast uses the same address at multiple locations, with routing directing traffic to one reachable instance according to routing policy and topology. “Nearest” in anycast therefore does not necessarily mean geographically closest. Ethernet and IPv4 support broadcast concepts, while IPv6 uses multicast rather than broadcast. A candidate should also distinguish delivery intent from reliability: selecting multicast or anycast does not itself guarantee delivery, application consistency, or that successive connections reach the same instance.

8. What problem does a VLAN solve?

A VLAN creates a logical Layer 2 broadcast domain on shared switching infrastructure. It can separate traffic groups without requiring a different physical switch for every group, and an IEEE 802.1Q tag can identify VLAN membership across suitable links. Hosts in different VLANs generally need routing to communicate, even when their cables terminate on the same switch. VLAN separation is useful but is not a complete authorization policy: permitted inter-VLAN routes, firewall rules, endpoint controls, and correct port configuration still matter. VLAN identifiers also have local administrative meaning; identical numbers in disconnected networks do not make those networks connected.

9. What is the difference between an access port and a trunk port?

An access port commonly carries one VLAN's ordinary endpoint traffic without an 802.1Q tag, while a trunk can carry multiple VLANs, usually distinguished by tags. Exact terminology, voice-VLAN behavior, and treatment of untagged traffic depend on the platform and configuration. A native or untagged VLAN mismatch can put traffic into an unexpected broadcast domain even though the physical link is healthy. During diagnosis, compare both ends' intended port mode, allowed VLANs, and untagged-traffic handling. Do not assume a trunk automatically transports every VLAN or that an endpoint cannot legitimately send tagged traffic.

10. Why is spanning tree needed in an Ethernet network?

Spanning tree prevents Layer 2 forwarding loops by selecting a loop-free active topology and placing some redundant paths into non-forwarding roles. Without suitable loop prevention, broadcasts and unknown unicasts can circulate repeatedly because ordinary Ethernet frames have no IP-style TTL. The symptoms can include traffic storms, unstable MAC learning, and severe congestion. Redundant cables alone therefore do not create safe redundancy. Rapid spanning tree improves convergence compared with the original protocol, but behavior still depends on topology and port roles. A beginner should explain the purpose of the root bridge and blocked paths before proposing timer changes or disabling protection.

11. What does an IPv4 address and subnet mask tell you?

An IPv4 address contains 32 bits, and a contiguous subnet mask identifies how many leading bits form its network prefix. The remaining bits identify addresses within that prefix. The same written address can belong to differently sized subnets depending on its mask, so an address alone is insufficient to determine local reachability. For example, 192.0.2.70/26 belongs to 192.0.2.64/26, not 192.0.2.0/26. Hosts use their interface configuration and routing information to choose a next hop. A wrong mask can cause a host to attempt local address resolution for a destination that actually requires routing.

12. How does CIDR differ from historical classful addressing?

CIDR expresses a network as an address plus a prefix length, such as /24, rather than inferring a fixed mask from an address class. It supports more flexible allocation and route aggregation. A /24 IPv4 prefix contains 256 addresses, while a /26 contains 64; the number conventionally assignable to hosts depends on the subnet's use. Historical Class A, B, and C terminology can explain older material but should not determine a modern configuration. Ask for the actual prefix length and route boundaries. Aggregation must also respect aligned address blocks rather than merely combining addresses that look numerically close.

13. How do you calculate the network and usable range for 192.0.2.70/26?

A /26 leaves six host bits, so each block contains 64 addresses and uses mask 255.255.255.192. The address 192.0.2.70 falls in the block from 192.0.2.64 through 192.0.2.127. For a conventional broadcast-capable IPv4 subnet, .64 is the network address, .127 is the broadcast address, and .65 through .126 provide 62 usable host addresses. The calculation is not “subtract two” for every possible prefix: /31 point-to-point links and /32 host routes have different semantics. This example uses documentation-reserved space and demonstrates arithmetic, not a network to contact.

14. What is the difference between private, public, and documentation addresses?

Private IPv4 space is intended for internal use and is not globally unique across organizations. Publicly routable address space can support Internet routing, but having such an address does not guarantee reachability or permission through a firewall. Documentation blocks, including 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24, exist for examples and should not be treated as real public services. Other special-purpose categories also exist, so “not private” does not imply “globally reachable.” For operational decisions, consult the special-purpose registry and actual allocation and routing state instead of classifying every address with a simple private/public binary.

15. How is an IPv6 address written and shortened?

An IPv6 address contains 128 bits and is usually written as eight hexadecimal groups. Leading zeroes within a group may be omitted, and one consecutive run of zero groups may be replaced with ::. For example, 2001:0db8:0000:0000:0000:0000:0000:0010 can be written 2001:db8::10. The double-colon compression can appear only once because otherwise expansion would be ambiguous. Prefix lengths still count bits, not hexadecimal characters. IPv6 introduces more than a larger address pool, including different neighbor discovery and broadcast behavior. The example prefix is reserved for documentation, not an implied reachable endpoint.

16. What does ARP do when an IPv4 host sends traffic?

ARP resolves an on-link IPv4 next-hop address to a link-layer address on networks such as Ethernet. The host first decides whether the destination is on-link or reached through a router. It then resolves the destination host or the selected router, respectively, commonly using a broadcast request and a reply that supplies the MAC address. The result is cached to avoid a request for every packet. ARP does not locate a remote Internet server's MAC address across routers. A missing or incorrect neighbor entry can explain a local delivery failure even when the IP route itself looks correct.

17. How does IPv6 Neighbor Discovery differ from ARP?

IPv6 Neighbor Discovery uses ICMPv6 messages and multicast rather than ARP's IPv4 mechanism. It supports link-layer address resolution as well as router discovery and neighbor reachability functions. For example, a host can use Neighbor Solicitation and Neighbor Advertisement messages to learn an on-link neighbor's link-layer address, while Router Advertisements provide information relevant to router and prefix discovery. This is why indiscriminately blocking ICMPv6 can break basic IPv6 operation, not merely remove a diagnostic utility. Neighbor Discovery is not automatically authenticated, so correct local-network security and configuration remain important even though its message format differs from ARP.

18. What is a default gateway, and when is it used?

A default gateway is a next-hop router used by a default route when no more specific applicable route matches the destination. It is not required for two hosts communicating on the same correctly configured local subnet. Conversely, a host can reach its gateway and still fail to reach a remote service because the onward route, return path, or policy is wrong. A default route is commonly written 0.0.0.0/0 for IPv4 or ::/0 for IPv6. Multiple routing tables or policy-based routing can complicate selection, so inspect the actual route decision rather than assuming one gateway controls every packet.

19. How does longest-prefix matching select an IP route?

Longest-prefix matching chooses the matching destination route with the greatest prefix length. Given illustrative routes for 192.0.2.0/24, 192.0.2.64/26, and a default route, traffic to 192.0.2.70 matches all three but prefers the /26 within the relevant forwarding table. This is more specific than simply selecting the route with the lowest metric across all entries. Metrics and protocol preferences help resolve candidate routes according to the system's rules, while forwarding still respects prefix specificity. Always distinguish a displayed routing candidate from the route actually installed and usable for packet forwarding.

20. What is ICMP, and what does a successful ping prove?

ICMP communicates network-layer control and error information; echo request and echo reply are only two examples. A successful ping demonstrates that an echo exchange worked between the selected endpoints under those test conditions. It does not prove that DNS, a TCP port, TLS validation, or an application transaction works. A failed ping is also inconclusive because filtering or rate limiting may suppress replies while other traffic succeeds. ICMP includes useful delivery errors, and ICMPv6 has essential IPv6 functions. Interpret diagnostic results according to the protocol actually tested rather than using ping as a universal health verdict.

21. How do TCP and UDP differ?

TCP provides a reliable, ordered byte stream with connection state, while UDP carries individual datagrams without built-in delivery or ordering guarantees. TCP does not preserve application message boundaries, so an application must frame its own messages. UDP preserves datagram boundaries, but applications must handle loss, duplication, or reordering when those outcomes matter. Neither choice is universally faster or better: requirements, congestion behavior, implementation, and network conditions matter. A real-time application may prefer timely incomplete data over delayed retransmissions, whereas a file transfer needs correct complete content. Protocols built above UDP can add reliability and congestion control themselves.

22. What happens during the TCP three-way handshake?

In the ordinary active-open case, the client sends SYN, the server replies with SYN-ACK, and the client acknowledges the server's SYN. This exchange establishes initial sequence-number state in both directions and negotiates relevant options. It does not authenticate the application or encrypt subsequent data. Seeing a SYN leave a host without a reply narrows the investigation but does not identify the cause: routing, filtering, a non-listening service, or a return-path problem remain possibilities. Successful connection establishment is therefore one diagnostic milestone, not proof that the application request will complete or that the peer is trustworthy.

23. What are transport ports, and how are they different from sockets?

A transport port is a 16-bit value used to distinguish traffic within a transport protocol, while a socket is an operating-system communication abstraction. For TCP, a connection is commonly distinguished by source and destination addresses and ports within its protocol context. TCP port 443 and UDP port 443 are separate transport endpoints, even though both may support web traffic. A listening socket waits for incoming communication; an established socket represents a different state. A familiar port number suggests an expected service but does not prove which application is running or whether the traffic is encrypted.

24. What does DNS do, and why is it more than a name-to-address lookup?

DNS is a distributed naming system that stores typed records under domain names. Address records are important, but DNS also supports aliases, mail routing, delegation, and other metadata. A resolver may answer from cache or obtain data through the DNS hierarchy; an authoritative server supplies data for zones it serves. A successful DNS lookup establishes only that a particular answer was obtained, not that the returned address is reachable or the application is healthy. Separate name-resolution errors from connection errors, and specify the queried name, record type, resolver, and response when reporting a DNS problem.

25. How do A, AAAA, CNAME, and MX records differ?

An A record contains an IPv4 address, an AAAA record contains an IPv6 address, a CNAME identifies a canonical name for an alias, and an MX record identifies mail exchangers with preference values. These records are not interchangeable: an MX target is a name, not a literal IP address, and a CNAME is not an HTTP redirect. A browser can follow a DNS alias while still sending the original hostname at the application layer. When checking a name such as www.example.com, ask for the relevant record type and examine alias dependencies rather than assuming one visible address represents the entire resolution path.

26. How does DHCPv4 provide an address to a new client?

The common initial DHCPv4 exchange is Discover, Offer, Request, and Acknowledgment. A client locates a server, receives an offered configuration, requests its selection, and receives confirmation of a lease. Configuration can include the address, subnet mask, routers, and DNS servers. A relay can carry DHCP exchanges between a client subnet and a server elsewhere; the server need not share every client broadcast domain. Renewals differ from the initial exchange. A valid lease does not prove every supplied option is correct, so diagnosis should inspect the assigned configuration and lease state rather than merely confirm that DHCP responded.

27. How do a static address and a DHCP reservation differ?

A static address is configured directly on the device or through its local configuration management. A DHCP reservation is a server-side rule that gives a particular client a predictable assignment through DHCP. Reservations centralize allocation and options, but the device still depends on the DHCP process and the server's client-identification rules. Neither approach excuses duplicate-address prevention or documentation. A printer with a manually configured address inside an unmanaged dynamic pool can conflict with a leased client. Choose the method according to recovery needs and administrative control, and keep the allocation source of truth consistent with the live configuration.

28. What is NAT, and how does port translation extend it?

Network Address Translation rewrites address information as traffic crosses a boundary. Port translation, often called PAT or NAPT, also uses transport ports so multiple internal flows can share an external address. The translating device commonly maintains state that maps return traffic to the original endpoint. This affects inbound connections, troubleshooting, and protocols that embed address information. NAT is not equivalent to a firewall or encryption: any filtering benefit comes from actual stateful policy and implementation behavior. In diagrams, show both sides of the translation and avoid assuming that the address visible to a remote server identifies an individual device.

29. What does TLS protect, and what does it not protect?

TLS protects application data in transit with negotiated cryptographic mechanisms and normally authenticates the server using a certificate and hostname validation. Client authentication can also be configured. TLS does not guarantee that the application is honest, protect data after a legitimate endpoint decrypts it, or fix a compromised endpoint. Certificate validation must check the intended identity and trust chain; merely presenting some certificate is insufficient. TLS 1.3 is a specific protocol version, not a synonym for all secure connections. During diagnosis, distinguish connection establishment, TLS negotiation, certificate validation, and application authorization instead of treating every HTTPS failure as one problem.

30. How do HTTP and HTTPS relate to transport protocols?

HTTP defines application-level request and response semantics; HTTPS uses an authenticated secure connection for HTTP communication. HTTP/1.1 and HTTP/2 commonly run over TCP with TLS for HTTPS, while HTTP/3 uses QUIC over UDP. Consequently, “web traffic always uses TCP” is no longer a safe assumption. A successful connection can still return an HTTP error because the application rejected or could not fulfill the request. Separate HTTP status, TLS errors, and transport failures when interpreting evidence. Also distinguish HTTPS from a VPN: securing a web request does not automatically tunnel all of the device's traffic.

31. What is MTU, and how do IPv4 and IPv6 handle an oversized packet?

The IP MTU is the largest IP packet a link can carry without fragmentation at that layer. The path can include a smaller limit than the sender's local interface, so successfully sending small packets does not establish that larger transfers will work. An IPv4 router can fragment an oversized packet when fragmentation is permitted; if the Don't Fragment flag prevents this, it drops the packet and normally reports the problem with ICMP. IPv6 routers do not fragment forwarded packets: they discard an oversized packet and normally send ICMPv6 Packet Too Big. IPv6 source fragmentation is a separate mechanism.

32. How are bandwidth, throughput, and goodput different?

Bandwidth commonly describes a link's nominal capacity, throughput is the rate actually transferred under a defined measurement, and goodput is the rate of useful application data delivered. State the measurement layer because framing, protocol headers, retransmissions, and application overhead can make results differ. A nominal 100 Mbit/s link corresponds to 12.5 MB/s before overhead when decimal units are used; it does not promise a 12.5 MB/s file download. The slowest relevant resource, competing traffic, protocol behavior, and endpoints can all reduce the observed result. Compare like-for-like units and intervals before concluding that a network underperforms.

33. What are latency, round-trip time, and jitter?

Latency is a delay measurement whose endpoints and direction must be specified. Round-trip time includes travel to a peer and back, potentially over different paths. Jitter describes variation in delay, with the precise calculation depending on the metric used. A stable 40 ms round trip is not the same experience as alternating 5 ms and 75 ms responses, even if their averages match. Voice and interactive applications can be sensitive to variation, while bulk transfer may care more about sustained throughput. Do not divide RTT by two and present the result as a measured one-way delay without a justified symmetry assumption.

34. Why can packet loss occur even when the physical link is up?

Packets can be dropped because queues fill, policy intentionally discards traffic, interfaces encounter errors, or an intermediate device cannot process the offered load. A healthy link indicator reports only a limited physical or link-state condition. Loss can also be asymmetric and specific to a traffic class or path. Compare timestamps and counters at relevant points, and separate actual data-plane loss from a device merely rate-limiting diagnostic replies. Replacing cables without evidence can miss congestion or policy problems, while assuming every drop is congestion can miss physical faults. The goal is to locate where and under what conditions traffic disappears.

35. What is the difference between full duplex and half duplex?

Full-duplex communication permits transmission and reception at the same time on the link, whereas half duplex requires sharing transmission opportunities. Modern switched Ethernet normally operates full duplex, so collision-related assumptions from hub-based networks do not describe its ordinary behavior. A duplex mismatch on equipment that permits incompatible settings can cause serious performance problems despite an apparently active connection. Check negotiated speed, duplex, and error counters together rather than interpreting link speed alone as a quality guarantee. Wireless sharing also has its own medium-access behavior and should not be treated as simply identical to a dedicated full-duplex Ethernet cable.

36. What is the difference between a router, a firewall, and a load balancer?

A router forwards packets between networks using routing information. A firewall applies traffic policy, often using connection state and sometimes application awareness. A load balancer distributes traffic across backends using transport-level or application-level decisions. One appliance or service can perform several of these roles, so product labels alone do not explain the packet path. For example, an application load balancer may terminate one client connection and create a separate backend connection, changing which source address the server sees. When troubleshooting, identify each actual function, its policy, and its state rather than assuming every intermediate device merely forwards packets unchanged.

37. What does a VPN change about a packet's journey?

A VPN creates a logical private connection across another network, commonly using encapsulation and authentication and often encryption. The original traffic becomes payload inside an outer transport, which adds overhead and can change routing, MTU requirements, and the apparent source address. Split tunneling sends only selected traffic through the VPN; a full-tunnel design routes a broader set through it. A connected VPN icon does not prove that every required subnet, DNS query, or application is using the intended path. Diagnose the effective routes and resolver behavior, and distinguish tunnel establishment from reachability of resources beyond the tunnel endpoint.

38. Which read-only commands can show a Linux host's network configuration?

On Linux with iproute2 installed, ip -brief address shows interface address summaries, ip route show displays IPv4 routes, and ip -6 route show displays IPv6 routes. ip neigh show inspects neighbor-cache entries, while ss -lnt lists listening TCP sockets without performing a port scan. These commands inspect local state; they do not establish end-to-end application health. Namespaces, permissions, installed versions, and interface naming can affect what is visible. The examples below are inspection examples, not commands to reconfigure interfaces or probe remote systems.

ip -brief address
ip route show
ip -6 route show
ip neigh show
ss -lnt

ip -brief address
ip route show
ip -6 route show
ip neigh show
ss -lnt

ip -brief address
ip route show
ip -6 route show
ip neigh show
ss -lnt

39. How would you begin investigating a report that one website does not work?

First define the failure precisely: affected URL, error, time, device, and whether other users or sites behave differently. Compare local configuration, existing resolver results, application logs, and browser error details to distinguish name resolution, connection, TLS, and HTTP failures. A working unrelated website does not prove that the affected destination uses the same route, address family, or proxy policy. Preserve useful evidence before changing anything, and only perform active tests when authorized. Avoid disabling certificate checks or security controls as a routine workaround; that can hide the cause while creating a different risk.

40. What information makes a networking incident report useful?

A useful report states the affected source, destination, protocol, time window with timezone, symptoms, and expected behavior, then separates observations from hypotheses. Include relevant interface or route state, error messages, and scope comparisons while redacting secrets and unnecessary personal information. “TCP connection timed out from this subnet after a change” is more actionable than “the Internet is slow.” Record what was actually tested and what remains unknown; a local command output is not a measurement of every network segment. This discipline helps the next engineer reproduce the reasoning without repeating disruptive experiments or mistaking an assumption for evidence.

Computer Networking Interview Questions and Answers for Intermediate

Evaluate whether the candidate can connect protocol state to observed symptoms. A useful explanation includes the relevant limits of a command, mechanism, or configuration rather than treating it as a universal fix.

41. What can make a VLAN work on one switch but fail across a trunk?

A trunk must carry the VLAN end to end, and both ends must classify its traffic consistently. Check the VLAN's existence, allowed-VLAN lists, tagging expectations, spanning-tree state, and the destination access-port assignment. A link can be physically up while a specific VLAN is filtered or blocked. Compare the affected VLAN with one that works across the same path rather than replacing cables immediately. Also separate Layer 2 delivery from inter-VLAN routing: communicating within one VLAN does not require a router, but reaching a different IP subnet normally does.

42. Why is a native VLAN mismatch a problem?

A native VLAN commonly determines how an Ethernet trunk handles untagged traffic, although exact tagging behavior is configurable and vendor-dependent. If one side assigns untagged frames to VLAN 10 and the other assigns them to VLAN 20, traffic can enter an unintended broadcast domain. Tagged VLAN traffic may still work, making the fault appear selective. Inspect both trunk endpoints and their operational state, not merely a template. Keep native-VLAN and tagging policy consistent; treating every trunk implementation as automatically stripping or preserving the same tags is unsafe.

43. Why does adding a second LACP member not necessarily double one transfer's speed?

A link aggregation group usually distributes flows across member links using a hash of selected packet fields. One flow normally stays on one member to avoid packet reordering, so its throughput remains bounded by that member's capacity. Multiple independent flows may use more aggregate bandwidth, but an uneven hash can still leave one link busier. Verify negotiated members, individual counters, hashing policy, and the actual traffic mix. Two 10 Gbit/s members provide potential aggregate capacity, not a guaranteed 20 Gbit/s for one TCP connection or every workload.

44. How would you investigate intermittent connectivity caused by a Layer 2 loop?

Look for correlated evidence such as rapidly changing MAC locations, unusually high broadcast traffic, interface congestion, and repeated spanning-tree topology changes. Inspect the root bridge, port roles, and recent link events to identify where the intended loop-free topology changed. A MAC move alone is not proof of a loop; virtualization or a legitimate host migration can also cause it. Preserve logs and topology evidence before proposing an approved corrective change. Disabling spanning tree or randomly shutting interfaces can turn an intermittent problem into a wider outage.

45. Why can an aggregate route look healthy while one destination range is unreachable?

A more-specific route can divert a subset of traffic away from an otherwise healthy aggregate path. For example, an installed 192.0.2.64/26 discard route overrides a working 192.0.2.0/24 route for destination 192.0.2.70, regardless of the aggregate's attractive metric. Inspect the actual forwarding lookup for an affected address and compare it with an unaffected address outside the /26. Then establish whether the specific route is intentional, stale, or incorrectly redistributed. An aggregate's presence proves neither that all underlying subnets are reachable nor that every packet will follow that aggregate.

46. How do route preference and a routing protocol's metric differ?

Route preference, sometimes called administrative distance, is a local implementation mechanism for choosing among route sources for the same prefix. A protocol metric compares paths according to that protocol's rules, such as OSPF cost. Metrics from unrelated protocols are not generally comparable numbers. A static route can therefore beat a dynamically learned route because of local preference even if its apparent path is worse. Explain the device's specific policy rather than assuming universal defaults, and verify next-hop reachability: selection does not guarantee that the installed path forwards successfully.

47. When are static routes preferable to dynamic routing?

Static routes suit simple, stable paths with few failure alternatives, such as a tightly controlled stub network. They are easy to understand but do not automatically learn topology changes; a route can remain installed while a remote destination is unreachable. Dynamic routing becomes useful when multiple paths, growth, and convergence requirements make manual maintenance risky. Neither is inherently safer: redistribution and overly broad static summaries can both create surprises. Choose based on topology, failure detection, operational ownership, and testing, and document how an unavailable next hop is detected and handled.

48. Why might two OSPF routers fail to become fully adjacent?

Check basic connectivity and the parameters needed for the intended adjacency: area, authentication, timers, network type, and relevant interface settings. An MTU mismatch can leave database exchange stuck even after neighbors discover one another. Also interpret the state in context: on a broadcast network, two DROTHER routers ordinarily remain in 2-Way state with each other rather than forming a full adjacency. Use neighbor-state transitions and logs to narrow the failure instead of assuming every non-Full entry is broken. OSPFv2 and OSPFv3 have related but distinct protocol and configuration details.

49. What is the practical purpose of OSPF areas?

Areas limit the scope of detailed link-state information and shortest-path calculations, helping a larger routing domain scale. Area border routers connect areas and advertise reachability between them; a conventional design uses area 0 as the backbone. Areas are not simply VLAN boundaries, and creating many small areas can add design and troubleshooting complexity. Summarization must follow deliberate address allocation or it may conceal unavailable destinations. In an interview, explain how the proposed areas reduce state and failure impact while preserving backbone connectivity, rather than presenting area count itself as an optimization.

50. How do BGP LOCAL_PREF and AS_PATH influence route selection?

LOCAL_PREF expresses preference within an autonomous system; higher values are ordinarily preferred when comparing eligible routes at that decision stage. AS_PATH records autonomous systems traversed and supports loop prevention; shorter paths are commonly preferred later, subject to policy and implementation. BGP is therefore not simply a shortest-AS-path protocol. A business policy can prefer a longer customer or private path over a shorter transit path. LOCAL_PREF is normally shared through iBGP, not sent to ordinary external peers, and exact best-path tie-breakers should be checked against the platform rather than memorized as universal.

51. How do IPv6 router advertisements, SLAAC, and DHCPv6 fit together?

Router advertisements communicate information such as default-router availability and prefixes. SLAAC lets a host form addresses from suitable advertised prefixes, while DHCPv6 can supply addresses or other configuration according to deployment and client support. An address obtained through DHCPv6 does not by itself replace router advertisements for ordinary IPv6 default-router discovery. Likewise, a prefix advertisement's on-link and autonomous-address-configuration flags have different purposes. Inspect addresses, lifetimes, routes, and resolver configuration separately; possessing a global address does not prove that the host has a usable default route or working DNS.

52. Why can a dual-stack application fail when IPv4 connectivity works?

IPv4 and IPv6 have separate addressing, routes, firewall treatment, and sometimes different upstream paths. A service with both A and AAAA records may attract IPv6 connections even when only its IPv4 path is healthy. Compare the selected destination family, listener availability, return path, and name-resolution results before blaming the application. Connection-racing mechanisms can reduce user-visible delay but do not repair broken IPv6. Test the intended service path under authorization, not only address reachability, and distinguish a resolver choosing an address from the transport successfully connecting to it.

53. What limits the number of simultaneous connections through PAT?

Port address translation needs enough usable mappings and state capacity, not just bandwidth. Constraints can include translated port availability, per-destination allocation behavior, connection-table limits, timeouts, and device processing capacity. The simplistic claim that one public address always supports exactly 65,536 connections ignores reserved ports, protocols, mapping reuse rules, and vendor policies. High connection churn can exhaust resources even when byte throughput is modest. Inspect translation-allocation failures and state usage alongside traffic rates, and consider connection reuse, additional address capacity, or architecture changes only after identifying the actual limiting resource.

54. What should you infer when a TCP client repeatedly sends SYN packets without completing a handshake?

The client has not received an acceptable response that completes connection establishment; the trace alone does not identify where traffic was lost. Possible causes include a missing listener, filtering, routing failure, return-path failure, or server overload. Capture placement matters: seeing outgoing SYN packets on the client does not prove they reached the server. Compare authorized observations at both endpoints and relevant intermediaries, including whether SYN-ACK or RST responses exist. Repeated SYNs support a transport-establishment diagnosis, not an immediate conclusion that DNS, TLS, or application authentication is broken.

55. How do graceful TCP closure, reset, and TIME_WAIT differ?

Graceful closure uses FIN exchange to finish each direction independently, allowing already-sent data to be handled according to TCP semantics. A reset aborts a connection and should not be interpreted as proof of successful application processing. TIME_WAIT retains state after an active close to handle delayed segments and retransmitted closure traffic; its presence is not automatically a leak. Diagnose excessive connection churn and endpoint behavior before trying to suppress it. Application success still needs an application-level response: even a clean transport close cannot prove that a transaction was committed.

56. How do TCP flow control and congestion control differ?

Flow control protects the receiving endpoint through its advertised receive window. Congestion control limits sending according to an estimate of what the network path can sustain. The sender is constrained by both, so increasing receive buffers cannot solve every throughput problem. A zero receive window points toward the receiver's ability to accept data, while congestion-window reductions may reflect loss or congestion signals. Implementations use different congestion-control algorithms; avoid assuming every connection follows one exact growth curve. Inspect both endpoint and path evidence before deciding whether to tune the host, application, or network.

57. How does bandwidth-delay product help explain a slow long-distance TCP transfer?

Bandwidth-delay product estimates the data that must be in flight to fill a path: bandwidth in bits per second multiplied by round-trip time in seconds. For a 1 Gbit/s path with an 80 ms RTT, it is 80,000,000 bits, or 10,000,000 bytes. A limiting 1,000,000-byte window implies a simplified ceiling of 100 Mbit/s at that RTT, before overhead, loss, and application limits. This is a diagnostic bound, not a promised throughput figure. Window scaling, congestion control, receiver buffering, and application production must all support the necessary flight size.

58. What do retransmissions and selective acknowledgments reveal about TCP?

Retransmissions show that the sender decided some data needed sending again; they do not uniquely prove physical packet loss. Reordering, delayed acknowledgments, capture gaps, or spurious timeout decisions can complicate interpretation. Selective acknowledgments report received byte ranges beyond the cumulative acknowledgment, helping a sender recover missing data without unnecessarily retransmitting everything after a gap. Check whether the feature was negotiated and correlate sequence numbers across captures. A packet analyzer's label is a hypothesis based on what it observed, especially if the capture started after connection establishment or dropped packets locally.

59. When is UDP appropriate despite its lack of built-in reliable delivery?

UDP is appropriate when an application wants independent datagrams and controls its own timing or recovery, as with some real-time media or request-response protocols. It does not automatically make an application faster, reliable, secure, or congestion-friendly. The application still needs to handle loss, duplication, reordering, message sizing, and responsible rate control where relevant. A voice application may prefer concealing a missing sample over waiting for retransmission, whereas a file-transfer application must recover missing content. Distinguish these design requirements from the mistaken assumption that UDP traffic can ignore network congestion.

60. How does QUIC avoid one TCP head-of-line blocking problem?

QUIC carries independently ordered streams over UDP, so loss affecting one stream need not prevent delivery of already-received data on an unrelated stream. HTTP/2 multiplexes application streams over one TCP byte stream, where missing transport bytes can hold up later bytes needed by several requests. QUIC does not eliminate every dependency or delay: streams still share connection congestion control, and application or compression dependencies can matter. UDP is the substrate, not a claim of unreliable application delivery. QUIC provides reliability for its streams and integrates cryptographic protection using TLS mechanisms.

61. Why can a DNS record change appear immediately for some users but not others?

Different recursive resolvers and application caches can hold answers with different remaining lifetimes, so an authoritative change is not an instant global replacement. Check the authoritative answer, the client's actual resolver, TTLs, and any application caching separately. Lowering the TTL only at cutover does not shorten the lifetime of answers already cached with the old TTL. Some resolvers also support serving stale data under defined conditions. Plan changes in advance and retain the old service appropriately; repeatedly editing the record can make diagnosis harder rather than forcing every cache to refresh.

62. How does DNS negative caching affect a newly created hostname?

Resolvers can cache that a name does not exist or that a requested record type is absent. Consequently, creating the record may not immediately help clients that recently received a negative answer. NXDOMAIN describes a nonexistent name, whereas a successful response with no requested data can indicate that the name exists but lacks that record type. Inspect response codes, authority-section SOA information, and the resolver being queried rather than treating every empty answer as equivalent. Do not confuse negative caching with SERVFAIL, which signals a resolution failure and calls for a different investigation.

63. What is a DNS delegation failure, and how is it different from a missing host record?

A delegation failure prevents a resolver from reliably reaching or using the authoritative servers for a child zone. A missing host record occurs after resolution reaches a relevant authority that can answer about the name. Check the parent delegation, child NS records, required glue, and whether the advertised authoritative servers actually serve the zone. An in-zone nameserver can require glue to break the dependency of resolving its address through the zone it serves. Editing an A record at the child will not fix a parent pointing to unreachable or incorrect nameservers.

64. Why must DNS troubleshooting consider EDNS and TCP as well as UDP port 53?

EDNS allows DNS peers to advertise capabilities including a larger UDP response size, but larger datagrams can encounter fragmentation or path-size problems. A truncated UDP answer can require retry over TCP, and DNS over TCP is not limited to zone transfers. Filtering TCP port 53 may therefore cause selective failures, especially for larger answers, while small queries still work. Compare response sizes, truncation flags, and transport behavior at authorized observation points. Increasing an advertised UDP size is not a universal fix; the response still has to traverse the actual path reliably.

65. Why does DHCP need a relay when clients and the server occupy different subnets?

An initial DHCPv4 client broadcast normally stays within its local broadcast domain, so a relay forwards the exchange between that subnet and a remote server. The relay supplies subnet-identifying context, allowing the server to select an appropriate address pool. If one VLAN fails while another works, inspect relay placement, pool availability, relay information, and the server's return route before declaring the server down. A wrongly identified client subnet can produce an unusable lease. DHCPv6 also has relay mechanisms, but its message flow and addressing should not be assumed identical to DHCPv4.

66. Why can small requests succeed while larger transfers stall?

A path-MTU problem can allow small packets through while dropping packets that exceed a narrower link's limit. Classic discovery relies on relevant ICMP feedback; blocking it can leave endpoints repeatedly sending unsuitable packet sizes. IPv6 routers do not fragment forwarded packets, making correct packet sizing and Packet Too Big handling especially important. Compare packet sizes, retransmissions, tunnel overhead, and feedback rather than assuming an application timeout proves server overload. Other causes remain possible, including buffering or application behavior, so confirm the size-dependent pattern before proposing an approved MTU or MSS change.

67. How are MTU and TCP MSS related without being identical?

MTU limits the size of an IP packet carried over a link, while TCP MSS communicates a maximum TCP payload size the peer is willing to receive in one segment. With a 1,500-byte IP MTU, ordinary IPv4 and TCP fixed headers leave 1,460 bytes; IPv6's base header and TCP fixed header leave 1,440 bytes. TCP or IP options and encapsulation can reduce actual data capacity further. An advertised MSS is not a measurement of the entire path. MSS adjustment affects TCP only and is not a general cure for oversized UDP or other traffic.

68. How do shaping and policing affect traffic differently?

Shaping generally buffers traffic to smooth its departure rate, introducing delay when offered traffic exceeds the configured rate. Policing identifies traffic outside a policy and may drop or remark it rather than queueing it for later. A shaper can help keep bursts within an upstream contract, but excessive buffering can harm interactive latency. A policer can enforce a boundary efficiently while causing retransmissions for bursty TCP traffic. Discuss rate, burst allowance, queue limits, and workload together; two configurations with the same nominal bit rate can produce very different user experiences.

69. Does a DSCP marking guarantee priority across the Internet?

No. DSCP identifies a requested per-hop treatment within a differentiated-services policy, but each network controls whether it trusts, changes, or ignores the marking. A provider contract may define treatment across a particular service boundary; that does not create a universal Internet guarantee. Inspect classification, remarking, queue assignment, and congestion behavior at the actual bottleneck. Marking every packet as high priority defeats meaningful differentiation and may trigger policing. QoS allocates constrained service according to policy; it cannot manufacture bandwidth or repair packet loss caused by a defective physical link.

70. What is the difference between Layer 4 and Layer 7 load balancing?

Layer 4 load balancing typically selects a backend using transport-level information such as addresses, ports, and connection state. Layer 7 balancing understands an application protocol and can route using attributes such as HTTP hostnames or paths. Application awareness enables finer policies but can add processing, termination requirements, and protocol-specific failure modes. The labels do not by themselves tell you whether client IPs are preserved or how return traffic flows; those depend on proxying, translation, and routing design. Evaluate connection ownership and observability along with the selection algorithm.

71. Why can a load balancer report a backend healthy while user requests fail?

A health check proves only that its specific test succeeded from its observation point. A TCP connection check can pass while authentication, database access, a particular HTTP route, or real request capacity is broken. Conversely, an overly demanding check can remove healthy capacity during a dependency slowdown and amplify an outage. Choose checks that match the service's readiness contract, with appropriate thresholds and timeouts, and compare them with actual request results. Test host headers, protocol, and credentials where relevant without embedding secrets in exposed health endpoints or diagnostic output.

72. What changes when TLS terminates at a load balancer?

The load balancer becomes a cryptographic endpoint for the client connection and can inspect the decrypted application traffic. Any backend TLS connection is a separate session with its own authentication and certificate-validation policy; client-side encryption does not automatically secure that second hop. Termination can simplify certificate management and enable application routing, but expands the set of systems that handle plaintext and key material. Explain where confidentiality ends, how backend identity is verified, and whether client identity is forwarded safely. Calling the design end-to-end encrypted without identifying its endpoints is misleading.

73. How should you compare HTTP/2 and HTTP/3 for a real deployment?

Both support multiplexed requests, but HTTP/2 ordinarily runs over TCP while HTTP/3 uses QUIC. Compare measured behavior under the deployment's RTT, loss, client mix, and network restrictions rather than assuming HTTP/3 always wins. QUIC can reduce transport-level interference between streams and support connection migration, but UDP filtering or implementation costs may change results. Preserve a working fallback path and monitor negotiated protocol, connection failures, and tail latency. HTTP version negotiation also does not by itself establish application correctness or authorize replay-sensitive operations in early data.

74. How would you isolate DNS, TCP, TLS, and HTTP failures in one connection attempt?

Treat them as distinct stages: resolve the hostname, identify the chosen address and family, establish transport, negotiate TLS where required, and inspect the application response. Record which stage actually failed and the elapsed time rather than reporting a single generic timeout. For example, a valid HTTP 503 means the observed request reached an HTTP-speaking component, although that component may be a proxy rather than the origin. Correlate client timestamps with server or proxy logs. A successful DNS lookup proves only that an answer was obtained, not that the returned endpoint is healthy.

75. How can local route and socket inspection narrow a connectivity problem safely?

Read-only inspection can reveal address selection, the kernel's selected route, and socket state without changing network configuration. On Linux, the commands below inspect local state; the route lookup does not send a probe to the documentation address. Interpret results in the correct network namespace and routing-policy context. A listening socket is not proof that a remote client can reach it, and a selected route is not proof that every hop forwards traffic. These examples are inspection guidance, not claims of an executed connectivity test.

ip -brief address show
ip route get 192.0.2.10
ss -tan

ip -brief address show
ip route get 192.0.2.10
ss -tan

ip -brief address show
ip route get 192.0.2.10
ss -tan

76. How would you review a saved packet capture without generating network traffic?

Read an existing, authorized capture offline and apply a narrowly scoped packet filter. In tcpdump, this uses libpcap filter syntax, not Wireshark display-filter syntax. The example below reads only a local file and disables address and service-name resolution; it neither captures live traffic nor scans a host. Check capture timestamps, interface placement, packet-drop information, and whether both directions are present before inferring packet loss. Protect the file because even routine captures can expose identifiers or payloads. Offload behavior can also make host-side checksums or segment sizes look unusual without corresponding wire faults.

tcpdump -nn -r authorized-sample.pcap 'tcp port 443'

tcpdump -nn -r authorized-sample.pcap 'tcp port 443'

tcpdump -nn -r authorized-sample.pcap 'tcp port 443'

77. What should you inspect in dig output besides the returned address?

Inspect the response code, question, answer and authority sections, TTLs, flags, server used, and whether the response was truncated. An address returned by a recursive resolver does not mean that resolver is authoritative, and an empty answer is not automatically NXDOMAIN. In an authorized diagnostic query, distinguish requesting recursion from receiving a final authoritative response. Also remember that ordinary dig queries generate DNS traffic, and a trace can contact multiple servers; they are not offline inspections. Compare already-collected output first when the task permits observation but not new network requests.

78. Why can a traceroute show asterisks even though the application works?

Intermediate devices may rate-limit or decline the diagnostic responses that traceroute expects while continuing to forward application traffic. Different probe types and ports can also follow different policies or ECMP paths. Therefore, a nonresponding hop is not sufficient evidence that it drops the application's packets. Evaluate destination reachability and patterns across repeated authorized measurements, recognizing that replies can take a different return path. Traceroute generates traffic; reviewing existing results is different from permission to probe a network, and intermediate-hop round-trip times are not direct measurements of each link's one-way latency.

79. How can interface counters distinguish congestion from physical-link trouble?

Counters provide clues when compared over a defined interval. Increasing CRC or alignment errors can suggest physical-layer or link-quality problems, while queue drops can indicate congestion or a configured resource limit. Exact counter meanings depend on platform and interface type, so inspect documentation and both ends rather than treating every discard as a bad cable. Normalize changes against packet volume and correlate them with user-visible incidents. Lifetime totals alone can be misleading after an old fault, and a clean local interface does not rule out a problem farther along the path.

80. Why can average bandwidth utilization hide a network performance problem?

An average can smooth away short bursts, queue buildup, packet-rate limits, and asymmetric saturation. A link averaging 30 percent utilization over five minutes may still experience brief periods of full queues that harm latency-sensitive traffic. Examine shorter-interval counters where available, queue drops, packet sizes, retransmissions, and latency distributions alongside bit rate. Small-packet workloads may exhaust forwarding capacity before reaching nominal link bandwidth. Specify the observation interval and workload before recommending an upgrade; adding capacity may help, but it does not automatically fix a faulty path, receiver bottleneck, or unsuitable queue policy.

Computer Networking Interview Questions and Answers for Experienced

Senior answers should identify competing explanations, make trade-offs explicit, and state how the decision will be validated. Measured service behavior and failure-domain reasoning matter more than naming an elaborate architecture.

81. How would you diagnose connections that fail only when return traffic uses a different path?

Investigate stateful middleboxes and source-validation policy before assuming asymmetric routing is inherently broken. IP forwarding can legitimately use different forward and return paths, but a firewall that sees only one direction may lack connection state, and strict reverse-path checks may reject a valid packet. Reconstruct both directions using routing and forwarding tables, flow records, and synchronized captures at selected boundaries. Compare a working and failing five-tuple rather than relying on a single traceroute. Remedies could include symmetric steering, correctly supported state sharing, or a source-validation mode appropriate to multihoming. Do not disable filtering globally merely to make one test pass; preserve anti-spoofing controls and verify failure-path behavior.

82. Why might an ECMP network have one congested link while its peers are mostly idle?

ECMP commonly assigns each flow to one next hop using a hash, so equal path cost does not imply equal byte rates. A few large flows, low hash-field diversity, or encapsulation hiding inner flows can concentrate traffic. Compare per-member bytes, queue drops, flow sizes, and the platform's actual hashing inputs. Adding paths might not improve a single large flow, and changing the hash can move established flows and cause reordering. Consider more diverse flows, supported inner-header hashing, or an appropriate load-balancing design after measuring the workload. Validate both steady-state distribution and redistribution after a member fails; aggregate utilization can hide the hot path that determines user experience.

83. How can microbursts cause packet loss when five-minute utilization looks low?

Short simultaneous bursts can exceed an egress port's service rate and fill its queue long before a coarse average shows congestion. For example, synchronized senders can overwhelm one destination even if their average demand is modest. Look for queue occupancy peaks, discard counters, and higher-resolution telemetry aligned with application latency. Distinguish these drops from physical errors and capture loss. Potential responses include pacing senders, spreading synchronized work, improving fan-in capacity, or using appropriate queue management. Larger buffers can absorb a bounded burst but may also increase delay under persistent overload. The success criterion is reduced loss and acceptable tail latency, not merely fewer drops or a low utilization chart.

84. How would you distinguish bufferbloat from insufficient link capacity?

Measure latency while the bottleneck is idle and while realistic traffic fills it. A large increase under load, together with persistent queue occupancy, suggests excessive queueing; the link can still be genuinely capacity-constrained. Estimate the scale: an 8 MB queue draining at 100 Mb/s adds about 0.64 seconds, using decimal units and ignoring overhead. Active queue management, suitable scheduling, and shaping slightly below an uncontrollable bottleneck may control delay, while capacity expansion addresses sustained demand. Avoid declaring victory from lower queue depth alone: compare application throughput, loss, fairness, and latency under the same offered load. More buffering is not a substitute for a capacity plan.

85. How would you calculate oversubscription and decide whether it is acceptable?

Compare potential access demand with usable uplink capacity, then test the traffic model rather than treating the ratio as a verdict. Forty-eight 1 Gb/s access ports feeding two active 10 Gb/s uplinks have a nominal 48:20, or 2.4:1, ratio. Losing one uplink changes that to 4.8:1. Actual capacity can also be constrained by per-flow hashing, packet-processing limits, or fabric design. Assess simultaneous demand, east-west versus north-south traffic, latency objectives, and maintenance scenarios. Oversubscription can be economical for lightly correlated workloads but risky for synchronized transfers. Document the failure-state operating envelope and what traffic can degrade; a steady-state average does not establish resilience.

86. How would you plan capacity for packet rate rather than just bandwidth?

Model packet sizes and processing work because the same bit rate can impose very different forwarding costs. Ignoring link overhead, 10 Gb/s divided by 1,000-byte packets is 1.25 million packets per second, while 100-byte packets imply 12.5 million. Real Ethernet calculations must include framing and on-wire overhead, so these are simplified payload-size comparisons, not line-rate guarantees. Check forwarding, ACL, encapsulation, and state-creation limits using the actual feature combination. Small packets may exhaust processing before bandwidth; many short connections may exhaust state creation separately. Define headroom for bursts and failover, and validate in an authorized test environment with a representative size distribution rather than a single favorable benchmark.

87. What makes two redundant network paths share a hidden failure domain?

Paths are not independent merely because diagrams show different lines. They may share a conduit, optical system, power feed, upstream router, control-plane dependency, or configuration automation. Map the physical and logical dependencies that can remove both paths together, including maintenance and operator error. Ask providers for diversity evidence rather than inferring it from different circuit identifiers. Then test bounded failures against a declared availability objective, including the surviving path's capacity. Diversity introduces cost and operational complexity, so prioritize failures that materially affect the service. A useful design states exactly which failures it tolerates and which remain common-mode risks instead of claiming that redundancy eliminates outages.

88. Why can faster routing failure detection still leave a long application outage?

Detection is only the first stage of recovery. Routing convergence, forwarding-table programming, neighbor resolution, middlebox state, DNS caches, and client retry behavior can each delay restoration. A control-plane adjacency may recover before packets follow a working path, and packets may briefly loop during inconsistent updates. Build a timeline from failure detection through successful application requests, not just routing logs. Faster timers can increase sensitivity to congestion or CPU pauses, so validate their stability under load. Set the objective in service terms, such as the duration and fraction of failed requests, then determine which stage dominates. Tune the relevant stage rather than shortening every timer indiscriminately.

89. How would you prevent a transit customer from accidentally turning your network into unwanted transit?

Make import and export policy explicit for each commercial relationship. Accept only authorized customer prefixes, apply sensible prefix-count limits, and export routes according to the intended customer, peer, and provider relationships. Verify the policy against representative route sets before deployment. BGP Roles and the Only-to-Customer attribute defined in RFC 9234 can support route-leak prevention where peers and implementations support them; they do not replace basic policy hygiene. Monitor unexpected announcements and keep an emergency containment plan. A route can have a plausible origin yet violate export policy, so origin validation alone cannot establish that its propagation is legitimate.

90. What does RPKI origin validation prove, and what does it leave unproven?

Origin validation checks whether a route's origin AS and announced prefix length are authorized by available validated ROA data. Its results distinguish Valid, Invalid, and NotFound; NotFound is not proof of an attack, and Invalid can result from an operator's configuration mistake. It does not validate the full AS path, contractual routing policy, or the destination service itself. Operationally, manage ROAs alongside address and routing changes, monitor validator freshness, and define failure behavior if validation infrastructure is unavailable. Before enforcing rejection, understand legitimate announcements and alert on unexpected state changes. Combining origin validation with relationship-aware filtering addresses more risks than treating either mechanism as a complete BGP security solution.

91. How would you design multihoming without promising perfect inbound traffic control?

Separate outbound policy, which you can control directly, from inbound selection, which depends on remote networks. Local preference can choose your egress, while advertisements, supported provider communities, and AS-path prepending may influence inbound paths without guaranteeing them. Check address portability, accepted prefix lengths, provider policy, and the capacity of either surviving circuit. Stateful services must tolerate asymmetric paths or deliberately preserve symmetry. Monitor actual traffic and test withdrawal in an approved window. Avoid excessive deaggregation simply to chase balance: it increases routing-table cost and may be filtered. The design should deliver a clear failover objective even when remote networks choose an unexpected but valid ingress.

92. When is anycast useful, and why can it disrupt long-lived sessions?

Anycast lets multiple sites advertise reachability to the same service address so routing selects a reachable instance. It can distribute DNS or other services and limit some failure impact, but routing chooses according to policy and topology rather than application load or geographic distance alone. A routing change can send an established session to a different site that lacks its state. Assess connection duration, state replication, withdrawal timing, and whether the application can reconnect safely. Health-based advertisements should reflect useful service readiness without excessive flapping. Anycast is not automatic overload protection: the remaining sites must absorb redirected traffic, and routing convergence does not guarantee immediate session continuity.

93. How would you investigate a slow WAN transfer when the access circuit is not saturated?

Determine whether the transfer is sender-limited, receiver-window-limited, congestion-limited, or constrained by another resource such as storage or encryption. Compare application bytes, RTT, retransmissions, congestion-window observations, and advertised receive windows where available. A high-bandwidth path with substantial RTT needs enough data in flight, but blindly enlarging buffers cannot fix loss, CPU saturation, or application serialization. Compare a single transfer with a carefully authorized parallel test to expose per-flow limits, while recognizing that extra flows can mask unfairness. Correlate endpoints with intermediate counters rather than treating one capture as complete evidence. Report the limiting factor and measured improvement under comparable conditions, not just the circuit's headline speed.

94. What would you infer if ten parallel transfers fill a WAN link but one transfer does not?

The result suggests a per-flow or endpoint constraint, but it does not identify which one. For a 10 Gb/s path with a 40 ms RTT, the bandwidth-delay product is 50,000,000 bytes using decimal units. A single flow with an effective 5,000,000-byte flight limit has a simplified ceiling of 1 Gb/s, while ten such flows could collectively approach the link rate before overhead. Compare advertised receive windows, congestion-window observations, loss, pacing, and application production rates. Parallel flows can hide loss sensitivity, per-flow shaping, or application serialization and may obtain an unfair share of capacity. Use the comparison to choose the next measurement, not as proof that increasing socket buffers is the correct fix.

95. Why can small increases in packet loss have a large effect on application tail latency?

Loss can trigger retransmission and recovery delays, and requests often depend on several sequential exchanges or on the slowest of many parallel calls. The application therefore experiences more than the average packet delay. Investigate where loss occurs, whether it is bursty, and whether transport recovery or application retries amplify the impact. Distinguish actual path loss from ICMP rate limiting and missed packets at the capture host. A useful analysis compares latency percentiles, retransmissions, timeout rates, and request fan-out over aligned intervals. Removing a tiny average loss rate may matter greatly for a latency-sensitive service, but no universal percentage predicts the impact across transports, RTTs, and workloads.

96. How would you diagnose a QUIC connection that fails when a client changes networks?

Check whether the endpoint and deployment support migration, whether the new UDP path is reachable, and whether packets still reach the server holding the connection state. QUIC connection IDs can identify a connection independently of its address tuple, but a load balancer that relies only on the old five-tuple may steer migrated traffic incorrectly. Path validation is also necessary; an address change is not permission to send unrestricted traffic to an unverified destination. Compare endpoint transport logs with load-balancer and network observations, since encryption limits passive inspection. Test NAT rebinding and deliberate client migration separately, and distinguish a valid policy restriction from a broken forwarding implementation. Reconnection may be an acceptable fallback if the application handles it safely.

97. How would you diagnose outbound failures caused by NAT port exhaustion?

Correlate failed connection attempts with translation allocation failures, active mappings, connection churn, destination concentration, and timeout behavior. The available mappings depend on the NAT implementation and reuse rules, so counting public addresses times 65,536 is not a reliable universal capacity model. A sudden fan-out or retry storm can consume mappings while bandwidth remains low. Examine whether connection pooling, appropriate application timeouts, or an expanded translation pool addresses the cause. Reducing mapping lifetimes too aggressively can break legitimate idle sessions. Monitor state occupancy and allocation rate separately, verify recovery under realistic bursts, and preserve enough logging to investigate behavior without claiming that one translated address identifies one user.

98. How would you migrate a production service to IPv6 without hiding failures behind IPv4 fallback?

Treat IPv6 as a complete service path: addressing, routing, firewall policy, DNS, load balancing, observability, and upstream reachability all need validation. Roll out to a bounded population, compare IPv4 and IPv6 success and latency separately, and verify large-packet behavior as well as simple connectivity. Client fallback can make the aggregate success rate look healthy while IPv6 remains broken. Check address selection, certificate and hostname behavior, and dependencies that still assume IPv4 literals. Keep a clear rollback path for advertisement or DNS changes, while accounting for caches. Dual stack increases operational surface area, so explicitly test both families through normal traffic, maintenance, and failure scenarios.

99. How would you design DNS redundancy so that two nameservers are not one failure domain?

Separate authoritative service, recursive resolution, delegation, and the management systems that configure them. Multiple nameserver names provide little protection if they share a network, deployment pipeline, credentials, or broken zone data. Evaluate provider and network diversity, reachable address families, delegation correctness, and the availability of required glue. Monitor answers from independent vantage points and distinguish resolver caching from authoritative health. Replication and change validation must keep data consistent without making a bad update instantly universal. DNS TTLs affect recovery timing but are not an outage switch. Document how changes are validated and rolled back, and test the service's behavior when one authoritative location is unreachable.

100. How would you evaluate a requirement for regional failover within ten seconds?

Translate the requirement into measurable client behavior: new requests, existing sessions, and in-flight operations may have different recovery objectives. DNS changes alone cannot guarantee ten-second migration because caches, connection reuse, and client retry policies are outside immediate authoritative control. Consider health-based routing or load-balancing mechanisms, the capacity and state available in the destination region, and safe application retry semantics. Measure from the onset of an actual service impairment to successful client operations across representative networks. Include detection time, convergence, reconnection, and any dependency recovery. If the proposed architecture cannot meet the requirement, state the gap explicitly rather than equating a fast control-plane update with end-to-end recovery.

101. How would you distinguish a volumetric DDoS problem from an application capacity problem?

Identify the first resource that saturates: upstream bandwidth, forwarding packet rate, state tables, connection handling, or application work. Compare ingress traffic, accepted requests, queue drops, connection rates, and service errors, taking care not to label an unexpected traffic spike malicious without evidence. If the access circuit is already full, filtering only on the destination host cannot restore lost upstream capacity; provider-side mitigation or upstream diversion may be necessary. Application exhaustion can require a different control even when bandwidth is modest. Follow an authorized response plan, preserve useful telemetry, and avoid broad filters that block legitimate clients. Recovery should be measured by usable service, not simply lower inbound traffic.

102. How would you protect routing protocols without breaking necessary control traffic?

Inventory traffic destined to the router separately from traffic it forwards. Permit required routing peers, management paths, and essential control messages, then apply platform-appropriate filtering and rate limits with headroom for legitimate bursts. An overly strict policy can destabilize adjacencies or suppress useful ICMP errors, creating an outage it was meant to prevent. Check the actual hardware and software treatment of punted packets, since not all control traffic follows the same path. Stage changes with out-of-band access and rollback available. Validate normal operation and bounded failure events, and monitor drops by class; a single total counter cannot show whether the policy is protecting or harming the control plane.

103. Why are VLANs or VRFs alone insufficient evidence of secure segmentation?

They separate forwarding contexts, but the effective boundary depends on every path that connects those contexts. Route leaking, shared services, firewall rules, trunk configuration, and management access can unintentionally bridge the separation. Define permitted communication by source, destination, protocol, and business purpose, then examine the actual forwarding and enforcement points. A VRF can make overlapping addresses manageable without encrypting traffic or authenticating users. Test representative allowed and denied flows in an authorized environment, including failover paths, rather than assuming a naming convention proves isolation. Keep the policy understandable enough to review; a complex segmentation design that nobody can validate can conceal broad accidental access.

104. What problem does EVPN solve in a VXLAN fabric, and what does it not solve?

VXLAN provides an overlay encapsulation across an IP underlay, while EVPN can distribute reachability and multihoming information through BGP instead of relying only on data-plane learning and flooding. RFC 7432 defines the original MPLS-based EVPN procedures; RFC 8365 applies EVPN to network virtualization overlays including VXLAN. This distinction matters when interpreting implementation features. EVPN does not remove the need for a healthy underlay, adequate MTU, consistent tenant policy, or capacity planning. Diagnose control-plane advertisement, next-hop reachability, and data-plane encapsulation separately. An established BGP session alone does not prove that a tenant's traffic can traverse the fabric or that isolation rules are correct.

105. How would you debug an overlay where small packets work but large transfers stall?

Suspect an MTU mismatch or blocked path-MTU feedback, but verify rather than immediately increasing every interface MTU. Calculate the actual encapsulation overhead for the deployed tunnel stack, inspect underlay and endpoint MTUs, and correlate stalls with packet size and ICMP errors. The inner packet may fit the tenant interface yet exceed a physical path after encapsulation. Use authorized, bounded tests and capture at both tunnel boundaries if available. Correct the inconsistent path or supported discovery behavior; TCP MSS adjustment can mitigate some TCP cases but does not fix every transport. Validate alternate routes and failover paths too, because a normally unused lower-MTU link can reintroduce the failure.

106. Why should an application avoid depending on IP fragmentation for routine delivery?

Fragments are more fragile across middleboxes, load balancers, and filtered paths, and losing one fragment prevents reassembly of the original packet. Fragment handling also consumes resources and complicates diagnostics. Prefer packet sizes supported by the path and transport mechanisms such as packetization-layer path MTU discovery where available. For UDP applications, define a safe message-sizing and recovery strategy instead of assuming a large datagram will arrive intact. IPv6 routers do not fragment forwarded packets, so IPv4 habits do not transfer directly. This is not a claim that fragmentation never works; it means a robust design should not require permissive fragmentation behavior across networks it does not control.

107. How would you design QoS without starving ordinary traffic?

Start with application requirements and a limited number of meaningful classes, then map them to supported scheduling and policing behavior. Delay-sensitive traffic may need priority, but an unbounded priority class can consume the link and starve everything else. Set trust boundaries so untrusted endpoints cannot promote all traffic by marking it, and verify how markings survive tunnels and provider boundaries. Allocate reasonable capacity to bulk and default traffic, then test under congestion because QoS has little visible effect when queues are empty. Measure latency, loss, and throughput by class. QoS chooses how scarce capacity is shared; it does not create bandwidth or guarantee identical treatment across administrative domains.

108. How would you remove a backend from service without interrupting existing sessions?

Stop assigning new work to it, allow established work to finish within a defined drain window, and terminate only according to the application's explicit policy. The details depend on connection reuse, long-lived streams, load-balancer mode, and whether a connection can carry new requests after removal. DNS changes alone do not drain existing sessions. Coordinate readiness, deployment state, and shutdown so the process does not exit before the load balancer stops forwarding. Watch active sessions and errors rather than waiting an arbitrary interval. Have a bounded policy for sessions that never end and test it with representative clients; indefinite draining can block maintenance, while immediate termination can break valid work.

109. How can an overly deep health check make a load-balanced outage worse?

A check that depends on every downstream service can declare all otherwise useful backends unhealthy during a shared dependency failure. Traffic may then be concentrated on the few remaining instances, creating overload and further removals. A shallow check has the opposite risk: it can pass while the application cannot serve requests. Define readiness in terms of the work that should be routed to that instance, and separate liveness from dependency health where appropriate. Use thresholds, bounded check load, and hysteresis supported by the platform. Test partial failures and capacity after removals. The right check helps routing choose useful capacity without turning one impaired dependency into a cascading outage.

110. What should a regional load-balancing design consider before enabling TLS 1.3 early data?

TLS 1.3 0-RTT early data can reduce latency for resumed connections, but it does not provide the same replay guarantees as ordinary handshake-protected application data. Only permit operations whose application semantics tolerate the relevant replay risk, and examine how ticket handling and replay defenses behave across servers and regions. A failover can send a client to an instance with different resumption state; rejection of early data must lead to safe application behavior rather than accidental duplicate execution. Sharing ticket keys is an operational and security decision, not a universal requirement. Measure the actual latency benefit and test rejection, retry, key rotation, and regional failover before broad rollout. Network encryption alone does not make repeated transactions safe.

111. Why can a packet capture show bad checksums or packets larger than the interface MTU?

A host capture may observe packets before transmit checksum completion or segmentation offload, or after receive aggregation. Those artifacts can differ from the frames actually transmitted on the wire. First identify the capture point, direction, offload behavior, and tool interpretation; compare with a suitable external observation when necessary and authorized. Do not conclude that the network is delivering giant corrupt frames from a host trace alone. Capture drops and truncated packets create additional limitations. Changing offload settings can alter performance and is not a harmless diagnostic step in production, so prefer inspection and a controlled comparison. State what the capture proves and what remains invisible at that observation point.

112. How would you localize packet loss when traceroute shows missing replies at an intermediate hop?

Check whether the loss continues to the destination and affects real application traffic. A router may rate-limit or deprioritize replies addressed to its control plane while forwarding transit traffic normally. Different probes can also follow different ECMP paths, and the return path can differ from the outbound path. Correlate destination measurements with interface errors, queue drops, and observations on either side of the suspected boundary. Avoid treating a single silent hop as proof that it discards user packets. A stronger diagnosis identifies a repeatable loss pattern for the affected flow and brackets where packets disappear, while accounting for limitations in every measurement source.

113. How would you choose between packet captures, flow records, and interface telemetry?

Choose based on the hypothesis. Captures reveal packet-level sequencing and headers at a particular point, flow records summarize conversations and traffic distribution, and interface telemetry shows utilization, physical errors, queues, and drops. None provides a complete picture by itself. Sampled flow data can miss short flows, captures can drop packets or expose sensitive content, and coarse counters can hide bursts. Align timestamps, identify sampling and reset behavior, and collect the smallest dataset that can distinguish the competing explanations. For example, a hot-link hypothesis needs member-level counters and flow distribution before a large payload capture. Preserve data handling controls and document blind spots in the incident conclusion.

114. How would you investigate intermittent one-way audio without assuming the signaling path is healthy enough?

Separate call signaling from media forwarding and trace the negotiated media addresses, ports, and direction. Successful signaling does not prove that return media can traverse NAT, firewalls, or a different route. Compare a working call and a failing call, inspect relevant mapping lifetimes and packet counters, and correlate loss, jitter, and queue behavior with the reported symptom. Encryption may limit payload inspection but not all timing and flow evidence. Avoid opening broad port ranges as an unreviewed fix. Validate the documented media policy, session renewal behavior, and failover paths in a controlled test, then confirm that both directions remain usable for a representative call duration.

115. What would you check when large file transfers are healthy but interactive requests are slow?

Separate throughput from request latency and break the request into DNS, connection establishment, TLS, application processing, and response transfer. A bulk flow can amortize setup costs and keep the path busy while a short request repeatedly pays several round trips. Queueing behind bulk traffic, connection churn, a remote dependency, or synchronous application exchanges can therefore harm interactivity without reducing total bandwidth much. Compare latency under idle and loaded conditions, connection reuse, and endpoint timing. Potential improvements depend on the cause: reuse connections, reduce unnecessary round trips, control queue delay, or address a slow dependency. A faster circuit is not a universal remedy for latency dominated by distance or application sequencing.

116. How would you assess whether jumbo frames are worth deploying?

Evaluate the specific workload and complete path rather than assuming larger frames always improve performance. Fewer packets can reduce processing overhead for large transfers, but endpoint offloads may already provide much of that benefit, and one lower-MTU segment can cause failures. Inventory switches, tunnels, host interfaces, storage paths, and failover routes; distinguish IP MTU from vendor-specific frame-size settings. Test useful throughput, CPU cost, latency, and recovery with realistic traffic in a bounded environment. Larger packets can also increase serialization delay for other traffic. Retain a clear rollback plan and avoid extending jumbo-frame assumptions onto uncontrolled Internet paths. The benefit must justify the extra configuration and troubleshooting complexity.

117. How would you validate a network change without running an uncontrolled production load test?

Write down the expected forwarding or policy change, the traffic it should affect, and the failure signals that require rollback. Use configuration review, route-policy fixtures, lab or staging tests, and read-only production baselines first. If live validation is authorized, choose bounded representative probes with explicit targets, duration, rate, and ownership. Verify both the intended improvement and unaffected critical paths, including management access and the surviving path after failure. Do not interpret a successful ping as proof that application traffic, MTU, and security policy are correct. Preserve before-and-after evidence and stop when the declared acceptance criteria are met, rather than expanding testing opportunistically across the network.

118. What makes a rollback plan credible for a routing or firewall change?

A credible plan identifies the exact prior state, who can restore it, how access remains available, and the measurable conditions that trigger reversal. It also accounts for effects that configuration restoration does not instantly undo: established sessions, stale caches, converging routes, or redistributed traffic. Validate the restoration procedure and any platform-specific commit-confirm behavior before depending on it. Stage the change so the blast radius is limited and the team can distinguish new symptoms from baseline noise. After rollback, verify service health rather than merely checking that the old configuration appears. If the change can isolate its own management path, independent access is a prerequisite rather than an optional convenience.

119. How would you prevent an overlapping address plan from derailing a merger or interconnection?

Inventory actual prefixes, routing domains, dependencies, and embedded address assumptions before connecting networks. Overlap can make a destination ambiguous, and a more specific route may send traffic somewhere unintended even when both networks worked independently. Compare renumbering, scoped routing domains, proxies, and carefully bounded translation against application requirements and operational cost. NAT may provide a transition mechanism but complicates troubleshooting and protocols that carry addresses. Build an explicit ownership and migration plan, test name resolution and return paths, and document temporary exceptions with an exit strategy. Do not advertise overlapping ranges broadly and hope routing metrics will preserve two different meanings for the same destination.

120. How would you summarize a network incident when the evidence does not establish one root cause?

Separate observed facts, supported inferences, and unresolved hypotheses. State the affected service and time window, the packet or request behavior observed, the measurements' blind spots, and why the chosen mitigation was reasonable. For example, queue drops correlated with latency can support a congestion hypothesis without proving which sender caused it. Preserve the timeline and note whether rollback or traffic reduction changed the symptoms under comparable conditions. Assign a bounded follow-up measurement that can distinguish the remaining explanations instead of declaring a root cause for closure. A useful incident record enables safer future decisions and identifies missing observability; confidence should reflect evidence, not pressure to produce a single definitive narrative.

Computer Networking Documentation and Further Reading

These primary references cover protocol foundations and practical switching guidance. Read RFC status, errata, and linked updates alongside the base specification: older publication dates do not make an active foundational standard obsolete, and a base RFC is not a complete catalog of later extensions. Vendor guidance must be checked against the deployed platform and release. TLS 1.3 is referenced through RFC 9846 rather than its superseded RFC 8446 text.

• RFC 9293: Transmission Control Protocol

• RFC 8200: IPv6 specification

• RFC 9000: QUIC transport

• RFC 9846: TLS 1.3

• RFC 4271: BGP-4 and linked updates

• RFC 2328: OSPF version 2 and linked updates

• RFC 1034: DNS concepts and facilities

• RFC 2131: DHCP for IPv4

• RFC 4861: IPv6 Neighbor Discovery

• RFC 8899: Datagram packetization-layer path MTU discovery

• RFC 9110: HTTP semantics

• RFC 9114: HTTP/3

• IANA: IPv4 special-purpose address registry

• RFC 7567: Active queue management recommendations

• Juniper: Spanning Tree Protocol overview