44 Network Engineer Interview Questions That Separate Recall From Reasoning

TCP sits at Layer 4, Transport. IP sits at Layer 3, Network. An 802.1Q VLAN tag gets inserted at Layer 2, specifically between the source MAC address and the EtherType field in the Ethernet frame header, not somewhere vaguely "in the frame."

The pitfall interviewers watch for: candidates who can list all seven layers cold but can't map an actual protocol header to any of them. Memorizing the diagram and understanding where a packet's bytes actually live are two different skills, and this question is designed to catch the gap.

A switch operates at Layer 2, forwarding frames within a single broadcast domain based on MAC addresses. A router operates at Layer 3, forwarding packets between different networks based on IP addresses. Put plainly, a switch connects devices on the same network, a router connects different networks to each other.

The switch inspects the source MAC address of every incoming frame and associates it with the port that frame arrived on, building a CAM table. Unknown unicast traffic (a destination MAC the switch hasn't learned yet) gets flooded out every port except the one it arrived on. Entries age out after a period of inactivity, typically 300 seconds by default, so a device that's been quiet for five minutes forces a fresh flood the next time something is addressed to it.

An IP address only gets you to Layer 3. Actually putting a frame on the wire and delivering it on a local Ethernet segment requires a Layer 2 MAC address, and IP has no idea what that is. ARP broadcasts a "who has this IP" request to every device on the segment, the owner replies directly with its MAC address, and that mapping gets cached so the broadcast doesn't have to repeat for every packet that follows.

Bidirectional Forwarding Detection is a lightweight hello protocol built purely to detect link or path failure fast, running at sub-second intervals. Routing protocols have their own native timers, but BGP's default hold timer is around 90 seconds, which is far too slow for anything that actually needs fast failover. Pairing BFD with OSPF or BGP means the routing protocol reacts to BFD's failure detection instead of waiting on its own, much slower, hello timeout.

A management station polls an agent's MIB using a GET request against a specific OID, pulling a value on demand. A trap flips that around, the agent proactively sends a message to the manager the moment a threshold breaches, without waiting to be asked. The community string that authenticates SNMPv1 and v2c is a plaintext shared secret, weak enough that SNMPv3 exists specifically to add real authentication and encryption on top of it.

Most ACL and firewall engines evaluate rules top to bottom and stop at the first match. A broad permit rule placed above a narrower deny rule makes that deny unreachable, silently, with no error thrown anywhere.

The fix is ordering specific rules ahead of general ones, and closing every rule set with an explicit deny even on platforms that already have an implicit one, purely so the next engineer reading the config can see the intent instead of guessing at it.

Telnet sends everything, including the login password, in plaintext over the wire. Anyone with a tap, or a compromised switch port, can read admin credentials straight off a packet capture with no special tooling at all. SSH encrypts the entire session end to end and, in modern deployments, supports key-based authentication instead of relying on a password alone.

If Telnet shows up anywhere on a real network today, it's almost always a legacy device nobody's gotten around to replacing yet, not an active design decision anyone would defend in an interview.

Bottom-up. Physical first, link lights, interface error counters. Then Layer 2, VLAN membership, STP state, MAC table. Then Layer 3, routing table, next-hop reachability, ARP table. Then transport, TCP state, port reachability. Then application, last, not first.

Going top-down instead wastes real time chasing an application symptom that turns out to be a bad cable three layers below where anyone started looking.

For an early-career candidate, yes, it's a reasonable proxy for actually knowing the protocols covered on this page instead of picking them up piecemeal on the job over a few stressful years. For someone with five-plus years of hands-on experience, a specific portfolio of incidents actually debugged carries more weight in the room than a certification badge does.

Here's an opinion that could be wrong: the candidates who do best in the loops I've seen reviewed are the ones who can describe one real OSPF adjacency reset they chased down at 2 a.m., not the ones who can recite an RFC number from memory. I don't have a clean percentage to put on that gap, only that it shows up often enough to flag here.

A collision domain is a segment where two devices transmitting at the same time can produce a collision. That's the old hub-and-coax world. Every port on a switch is its own collision domain because a switch buffers frames and won't let two of them collide on the wire. A broadcast domain is bigger, it's the set of devices that receive a broadcast frame (destination FF:FF:FF:FF:FF:FF), and that boundary is set at Layer 3, meaning a router or a VLAN boundary is what stops a broadcast from spreading further.

So a 48-port switch with no VLANs configured is 48 collision domains but a single broadcast domain. Split that same switch into 4 VLANs and you get 4 broadcast domains, still 48 collision domains. This matters in practice because ARP requests, DHCP discovers, and other broadcast-heavy traffic flood every device in a broadcast domain. An oversized flat network, a /16 with tens of thousands of hosts, generates real CPU load on every endpoint just from processing broadcasts it doesn't care about, which is one of the concrete reasons VLANs and subnetting exist beyond just tidy organization.

A /22 means 22 bits are network, leaving 32 minus 22, or 10 bits, for host addressing. That's 2 to the 10th, 1024 total addresses in the block. Subtract the network address (all host bits zero) and the broadcast address (all host bits one) and you land on 1022 usable host addresses.

The block covers 10.0.4.0 through 10.0.7.255, which is four full /24s worth of space, because a /22 borrows 2 bits from what would otherwise be a /24, and 2 bits gives four combinations in that third octet: 4, 5, 6, 7. The fast mental shortcut for an interview: each bit you shrink below /24 doubles the block size, so /23 covers 2 /24s, /22 covers 4, /21 covers 8, and so on. Getting this wrong either wastes address space at scale or forces a re-IP of a live segment later, and re-IPing production is never a fun way to spend a Friday.

An access port belongs to exactly one VLAN and carries untagged frames. That's what you plug an end device like a laptop or a printer into, since the NIC has no idea what an 802.1Q tag even is. A trunk port carries traffic for multiple VLANs over one physical link by tagging each frame with its VLAN ID, and that's what runs between switches, between a switch and a router doing router-on-a-stick, or to a hypervisor host running several VM VLANs.

Get it backwards and you get one of two failure modes. Configure an access port where a trunk was needed, connecting to another switch, say, and every VLAN except the one that access port is assigned to just silently disappears across that link. Configure a trunk where access was needed, plugging a laptop into a trunk port, and the host either gets no connectivity at all, or if the native VLAN happens to line up, it lands on the wrong network without anyone noticing until someone can't reach a file share and you spend twenty minutes staring at show interface trunk before it clicks.

RFC 1918 carved out three blocks, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16, specifically so organizations could build internal networks without burning through the pool of public IPv4 addresses. Since these ranges aren't globally routable, any number of companies can reuse 192.168.1.0/24 internally at zero cost to anyone else, because internet routers drop packets sourced from or destined to those ranges by convention.

The problem shows up the moment two networks on the same private range need to talk directly, which happens constantly during company mergers, site-to-site VPNs with a vendor, or a data center migration. If both sides run 10.0.0.0/8 with overlapping subnets, you can't just route between them, the addressing is ambiguous. The usual fix is NAT at the boundary, rewriting one side's addresses into a separate translation range so both networks reach a mutually agreed set of addresses without a full renumbering, which is exactly the kind of unglamorous problem that eats a week of a network engineer's time during an acquisition.

Full duplex means both ends can transmit and receive at the same time on separate channels, no collisions possible. Half duplex, the old Ethernet default from hub days, means only one side transmits at a time, and if both try at once you get a collision that both back off from using CSMA/CD. A duplex mismatch is when one end of a link is set to full duplex and the other to half, usually because autonegotiation failed or someone hardcoded one side and left the other on auto.

What makes this nasty is that the link comes up fine, ping works, everything looks green in show interface status. But the half-duplex side is watching for collisions on a link where the full-duplex side never checks for them and just sends whenever it wants. So the half-duplex side sees what look like late collisions and starts incrementing runts, CRC errors, and late collision counters, while throughput craters under load, sometimes down to a tenth of what the link should support. The fix is almost always to hardcode both ends to full duplex and matching speed rather than leaving one side on autonegotiate and the other forced, since a failed autonegotiation is the actual root cause in most real mismatches.

The tag is 4 bytes, inserted between the source MAC and the EtherType field. Inside it, a 12-bit VLAN ID field caps the usable range at 4094 VLANs (0 and 4095 are reserved). The native VLAN on a trunk carries untagged frames, and it defaults to VLAN 1 unless someone changes it, which matters more than it sounds like it should (more on that in the security section below).

OSPF is an Interior Gateway Protocol, link-state, fast convergence, built for one organization's internal topology. BGP is an Exterior Gateway Protocol, path-vector, policy-driven, built for internet-scale routing between organizations (RFC 4271 is still the current BGP-4 specification).

Large networks run iBGP internally anyway, because it scales to a far larger prefix count than OSPF comfortably handles, and because it gives operators the exact same policy tooling, route-maps, communities, local-preference, inside the network that they already use at the edge. Big cloud providers and large enterprises run iBGP route reflectors specifically to distribute prefixes across thousands of internal routers without needing a full mesh between all of them.

Administrative distance is a trust score for where a route came from, lower numbers win. Connected interfaces sit at 0, static routes at 1, EIGRP at 90, OSPF at 110, RIP at 120, external EIGRP at 170, and iBGP at 200.

It matters most during redistribution, when a router is learning the same destination from two different protocols and has to pick one to install. A floating static route (deliberately configured with a higher AD than the primary protocol) is a common failover trick, it only gets installed in the table once the protocol-learned route disappears, and stays invisible the rest of the time.

STP solves broadcast storms in redundant, loop-prone switched topologies by electing a root bridge (lowest bridge ID, priority plus MAC) and blocking every port that isn't on the shortest path to it.

What it creates is slow convergence. Classic 802.1D STP can take up to 50 seconds to reconverge after a topology change, which is an eternity for anything latency-sensitive. RSTP (802.1w) cuts that down to seconds. MSTP (802.1s) maps groups of VLANs to separate spanning tree instances so a large environment isn't running one monolithic tree for every VLAN. There's also a subtler failure mode: a misconfigured switch with an accidentally lower priority can become root and silently reroute traffic across the whole topology, which is exactly why PortFast and BPDU Guard exist on access ports, to stop an end-user device from ever participating in the STP conversation in the first place.

All three give hosts a virtual gateway IP and MAC backed by more than one physical router. HSRP is Cisco proprietary, active/standby, one router forwards at a time. VRRP (RFC 5798) is the open standard, functionally almost identical, master/backup instead of active/standby.

GLBP is the odd one out, and it's Cisco proprietary too. It lets multiple routers stay active at once by handing out different virtual MAC addresses to different hosts' ARP requests, so traffic actually load-balances across the group instead of sitting idle on a standby box. I'd argue GLBP is underused for a boring reason, most engineers never think about gateway-side load balancing as a problem worth solving, and the configuration is unfamiliar enough that people default back to HSRP even when GLBP would use the hardware better.

Three-tier (core, distribution, access) was built for north-south traffic, clients hitting servers. East-west traffic, server to server, which dominates in a microservices-heavy environment, had to travel all the way up to the core and back down, adding hops and latency on every single request between two boxes that might be racks apart.

Spine-leaf fixes that by connecting every leaf switch to every spine switch, so any two leaves are at most two hops apart no matter how large the fabric grows. The trade-off is wiring complexity and a real requirement for all-active forwarding across every link, which in practice means ECMP, and ECMP in a modern spine-leaf fabric almost always means BGP running between leaves and spines instead of a traditional IGP.

Equal-Cost Multi-Path routing kicks in when a router has more than one route to the same destination with an identical cost, and instead of picking just one, it load-balances traffic across all of them. The router typically hashes on a 5-tuple, source IP, destination IP, source port, destination port, protocol, to decide which path a given packet takes, and that hash stays consistent for the life of a flow so packets belonging to the same connection don't arrive out of order.

TCP buys reliability, ordering, and retransmission at the cost of latency and connection setup overhead. UDP is a fire-and-forget datagram with none of that, which sounds worse until you hit a workload where the guarantees actually cost more than they're worth.

DNS defaults to UDP because a request and response fit in one small round trip with no need for connection setup. VoIP runs on UDP because a voice frame that arrives 400 milliseconds late is worse than one that's simply dropped, retransmitting it just delays the next one. Financial market data feeds want the latest tick, not a queue of old ones waiting to be delivered in order. QUIC, the protocol underneath HTTP/3, is itself built on UDP specifically so it can implement its own reliability logic instead of inheriting TCP's.

NAT rewrites IP headers at the router boundary. PAT additionally rewrites ports, which is what lets an entire household or office share one public IP address across dozens of devices.

What it breaks: protocols that embed IP addresses inside the payload itself, FTP in active mode, SIP for VoIP, H.323, none of which expect their addressing to change mid-flight. IPsec in transport mode needs NAT-T encapsulation to survive a NAT boundary at all. Peer-to-peer connectivity needs STUN, TURN, or ICE to work around the fact that neither side can be reached directly anymore. IPv6 was supposed to make NAT unnecessary by solving address scarcity outright. It largely hasn't, mostly because organizations kept NAT around for the address-hiding side effect long after the scarcity problem it was built for stopped applying to them.

DHCP's Discover message is a broadcast, and broadcasts don't cross a router by default, so a client on VLAN 20 can't reach a DHCP server sitting on VLAN 10 without help. The fix is a DHCP relay agent, an ip helper-address configured on each VLAN's SVI, which unicasts the broadcast to the DHCP server's real IP and stamps the packet with the relay's own subnet information (the giaddr field) so the server knows which address pool to hand out from.

interface Vlan20
 ip address 10.20.30.1 255.255.255.0
 ip helper-address 10.10.10.5

Without that relay configuration, the DHCP server never sees the request at all, and the client just times out waiting for an offer that was never going to arrive.

QoS prioritizes certain traffic over other traffic using four steps: classification (matching by protocol, port, or existing DSCP value), marking (setting the DSCP bits in the IP header, EF, value 46, is the standard marking for voice), queuing (holding lower-priority packets back), and scheduling (deciding which queue actually gets serviced next).

It's the wrong tool when a link is consistently running at 90 percent utilization or higher. At that point QoS just decides whose traffic suffers, it doesn't make the underlying congestion go away. The actual fix there is more capacity, not a cleverer queuing policy on top of a link that's genuinely full.

Tunnel mode encapsulates the entire original IP packet inside a new IP header, which is what site-to-site VPNs use, since the endpoints doing the encrypting are gateways, not the actual hosts communicating. Transport mode encrypts only the payload and keeps the original IP header intact, used for genuine end-to-end encryption between two hosts that are themselves the IPsec endpoints.

MPLS forwards traffic based on a label assigned at the ingress edge router, swapped at each hop along the way, instead of running a full IP lookup at every single router in the path. That enables traffic engineering (steering specific flows down a specific path regardless of what the IGP would normally choose), L2 and L3 VPN services for carrying customer traffic across a shared provider network, and the ability to carry multiple protocols underneath the same label-switched path.

An attacker crafts a frame carrying two 802.1Q tags. The outer tag matches the trunk's native VLAN, so the first switch in the path strips it off (native VLAN traffic isn't expected to be tagged in the first place) and forwards the frame using the inner tag, which lands it on a VLAN the attacker was never supposed to reach.

The fix is boring and everyone still skips it, never leave the native VLAN at the default of VLAN 1, move it to something unused, and explicitly tag native VLAN traffic on trunks so there's no untagged frame left for the attack to exploit in the first place.

Stateless firewalls, ACLs, match individual packets against rules, source IP, destination IP, port, protocol, with zero connection tracking. Fast, simple, and a good fit for coarse filtering at the network edge where line rate matters more than nuance.

Stateful firewalls track sessions and automatically permit return traffic for a connection they've already approved, which is what belongs at a real zone boundary, DMZ to internal, internet to inside. NGFWs layer application-aware inspection on top of that. Zero-trust architectures push the model further still, shifting the real enforcement point from the network perimeter to workload-level micro-segmentation, which gets its own question below.

Port security caps how many MAC addresses a port will learn and can shut the port down (err-disable) the moment an unrecognized MAC shows up. 802.1X goes further, requiring an actual authentication exchange through RADIUS before the port passes anything beyond EAP frames at all.

The gap between them: port security alone is trivially defeated by cloning an already-allowed MAC address onto the rogue device. 802.1X closes that gap because it authenticates the device (or the user) itself, something a rogue laptop can't spoof the way it can spoof a bare MAC address in under a minute.

An attacker on the segment, or a misconfigured device that shouldn't be participating at all, can inject fake routing updates and redirect traffic without ever touching a router's actual configuration. MD5 or keyed-hash authentication on OSPF or BGP neighbor sessions means a router only accepts updates carrying a valid shared-secret hash, so an injected update from an unauthenticated source gets silently dropped instead of accepted into the routing table.

The perimeter model assumes anything already inside the firewall is trusted, which means one compromised internal host can often move laterally with very little resistance. Zero trust drops that assumption entirely, enforcing identity- and policy-based access at every hop through micro-segmentation, so a compromised "trusted" internal host still can't reach systems it was never explicitly authorized to talk to.

It doesn't replace the firewall. It changes what the firewall is allowed to assume about where a request came from.

No, and conflating them is a common mistake. CRC errors mean frames are arriving corrupted, a physical-layer problem, a bad cable, a failing SFP, a marginal NIC, and the fix is almost always swapping hardware rather than touching a config file. Output drops mean the interface is trying to send more than it can queue, which is a congestion or buffering problem, and the fix there is QoS, more bandwidth, or finding whatever's actually saturating the link. Reading both as interchangeable "the interface is unhealthy" symptoms sends you down the wrong remediation path.

Identify the port or ports with runaway traffic first, packets-per-second climbing across multiple ports simultaneously is the tell, and shut the specific port causing the loop. If you can't isolate it fast enough, start disabling ports methodically until storm traffic actually drops, since every second a storm keeps running compounds the damage.

STP is supposed to prevent this from happening at all, so a live broadcast storm usually means STP itself failed somewhere, a misconfiguration, a switch that crashed mid-negotiation, or someone disabled STP on a port "temporarily" and never turned it back on.

Traditionally, every device runs its own independent control plane (routing protocols, STP) right alongside its own data plane. SDN centralizes control logic in a controller that programs switches through OpenFlow or a similar protocol.

Day to day, that means consistent policy pushed from one location instead of touching every device individually, and automation that's an API call instead of a config template pasted across a hundred boxes. The trade-off is the controller becoming a single point of failure for policy, though most SDN hardware keeps forwarding on whatever rules it already cached if the controller drops offline. AWS, Google, and Azure all run SDN fabrics internally, their VPC and VNet constructs are SDN, most engineers just never see the controller layer directly.

Show commands tell you what a device believes about its own state, counters, routes, neighbor tables. They can't tell you what's actually moving across the wire between two devices, or whether a packet that left one interface arrived intact at the next hop. A capture on both ends of a suspect path, with clock-synchronized timestamps, is the only way to prove whether a drop happened before or after a specific device, and that answer changes what you fix next.

LACP, 802.3ad, bundles multiple physical links between two devices into one logical interface. Both sides negotiate bundle membership by exchanging LACPDUs, which lets them agree on which ports actually participate, detect a misconfigured or half-connected link, and pull a port out of the bundle automatically if it stops receiving LACPDUs. That gets you both bandwidth aggregation and resilience: if one link in a 4x10G bundle dies, traffic redistributes across the remaining three without the connected devices ever seeing the logical interface go down.

The mistake that bites people constantly is assuming LACP load-balances traffic per packet across the member links, round robin style. It doesn't, not on virtually any real switch implementation, because per-packet distribution would cause massive reordering for any single TCP flow crossing multiple links with different latencies. Instead the hash algorithm, commonly based on source and destination MAC, IP, or a combination, configurable on most platforms, picks one member link per flow and pins that flow to it for the session's life. A single elephant flow, one big file transfer between two servers, only ever uses one physical link's worth of bandwidth no matter how many links are in the bundle. If your traffic is dominated by a handful of high-volume flows rather than many small ones, you can end up with a nominally 40G bundle where one 10G member is saturated and the other three sit idle. Fixing that usually means tuning the hash to include L4 port numbers so multiple flows between the same two IPs actually spread across different links.

Traceroute exploits IP's time-to-live field. It sends a probe (ICMP echo on Windows, UDP to a high port on traditional Linux) with TTL set to 1. The first router in the path decrements TTL to 0, discards the packet, and returns an ICMP Time Exceeded message, revealing itself as hop 1. Traceroute then sends a probe with TTL 2, gets a Time Exceeded from hop 2, and repeats, incrementing TTL by one each round until a probe reaches the destination and gets a real reply, or until it hits the configured max hop count with nothing back.

Asterisks mean that particular hop didn't respond inside the timeout, and that's genuinely ambiguous. It could mean an actual link problem or a device silently dropping the probe. But very commonly it just means that router's control plane deprioritizes generating ICMP Time Exceeded messages, which is standard practice on carrier and backbone routers, since replying to every traceroute probe from every source on the internet would burn CPU better spent on forwarding. A perfectly healthy hop can show three stars and traffic keeps flowing fine past it. The other wrinkle worth knowing: because each hop's return traffic can take a different path back due to asymmetric routing or ECMP, the round-trip times per hop aren't necessarily measuring the same physical path each time, so jitter between consecutive hops in one traceroute run isn't reliable evidence of where latency is actually being introduced.

Which offices are bandwidth-heavy and for what, video, large file transfer, VoIP. Whether there's a real primary data center or the whole environment is cloud-only. How much WAN downtime the business can actually tolerate per office. Whether inter-office traffic needs to route through a central firewall or can go direct.

Once you have those answers, a typical shape emerges: an access layer per office with separate VLANs for guest, corporate, VoIP, and management traffic, a distribution layer, and MPLS or SD-WAN tying the sites together. SD-WAN tends to win when the WAN mix is heterogeneous, broadband plus MPLS plus LTE, because of automatic path selection and failover across dissimilar links. The actual mistake interviewers are watching for is a candidate who starts drawing routers before asking a single one of these questions out loud.

The order, per RFC 4271 and vendor implementations built on it: Weight (Cisco-local, not standard), Local Preference (highest wins), locally originated routes, shortest AS-path, lowest Origin code, lowest MED, eBGP preferred over iBGP, lowest IGP metric to the next hop, oldest eBGP path, and finally lowest router ID as the tiebreaker of last resort.

In practice, Local Preference is what operators actually tune, since it determines which upstream ISP gets preferred for outbound traffic. AS-path prepending is the usual lever for influencing inbound traffic from external networks. MED is supposed to signal a preferred entry point to a neighboring AS, but plenty of ISPs just ignore it, so don't lean on it as a reliable control.

First, routing loops. Redistributing at more than one point between two protocols lets a route ping-pong back and forth, each protocol thinking it learned the route fresh from the other. The fix is route-maps that tag redistributed routes on the way out and filter them on the way back in.

Second, metric incompatibility. OSPF measures cost, RIP measures hop count, and a route crossing from one protocol into another needs an explicit seed metric or it either gets rejected or defaults to something meaningless. Always set an explicit metric on your redistribution statements. Don't assume the defaults make sense for your topology, because they usually don't.

On a multi-access segment, OSPF elects a Designated Router and Backup Designated Router to cut down on flooding, every other router forms an adjacency only with the DR and BDR, not with each other. Election goes by highest OSPF priority (default 1, a priority of 0 disqualifies a router entirely), tie-broken by highest router ID (RFC 2328).

The part most candidates miss: OSPF doesn't preempt. A new router with a higher priority joining the segment does not remove an existing DR. So when a DR genuinely flaps, every re-election floods LSAs across the whole area, triggers SPF recalculations on every router in it, and shows up as CPU spikes on boxes that weren't anywhere near the actual failing link. Fixes are boring but effective: tune hello and dead timers, set priority 0 on unstable routers so they can never win the election in the first place, or switch the segment to a point-to-point network type where DR election doesn't apply at all.

VXLAN encapsulates Layer 2 Ethernet frames inside UDP packets (port 4789), which lets you stretch a Layer 2 domain across a routed Layer 3 network instead of being boxed in by physical adjacency. The 24-bit VNI gives roughly 16.7 million possible virtual networks against the 4094 hard ceiling of classic VLAN tagging.

The complexity isn't in the encapsulation itself, it's in the control plane. Early VXLAN deployments leaned on multicast flooding to handle BUM traffic (broadcast, unknown unicast, multicast), which doesn't scale cleanly. Modern deployments use EVPN over BGP instead, distributing MAC and IP reachability information the same way BGP distributes routes, which avoids the flooding entirely and enables active-active multihoming that flood-and-learn VXLAN can't do on its own.

The browser checks its own DNS cache first, then the OS cache. On a miss, it queries the configured resolver, which recurses from a root server to the relevant TLD server to the domain's authoritative server, and the answer gets cached according to its TTL at every level along the way.

With an IP address in hand, the browser opens a TCP connection to port 443, the standard SYN, SYN-ACK, ACK handshake. Before a single byte of the page loads, a TLS handshake runs on top of that connection, negotiating a cipher suite, exchanging and validating a certificate, and deriving a shared session key (commonly via ECDHE). Only then does the actual HTTP request go out, encrypted. For a senior candidate, the follow-up usually goes to HTTP/2 and HTTP/3, HTTP/2 multiplexes multiple request streams over a single TCP connection instead of opening one per asset, and HTTP/3 runs over QUIC, which is UDP-based and removes head-of-line blocking at the transport layer entirely, something HTTP/2 still suffers from underneath TCP.

OSPF floods LSAs the moment it detects a topology change, recalculates SPF quickly, and updates the RIB fast, on the order of seconds.

BGP is intentionally slower, and that's a design choice, not a limitation. Route flap dampening, hold timers around 90 seconds by default, and MRAI rate-limiting on updates all exist to keep internet-scale routing stable, where instant reaction to every blip would create far more churn than it prevents. Inside a single data center, though, operators tune BGP aggressively, sub-second BFD for failure detection, one-second hold timers, and get OSPF-like convergence speed while keeping BGP's richer policy model. It's not that BGP can't converge fast. It's that converging fast by default at internet scale would be a bad idea.

An attacker sends unsolicited ARP replies claiming to own a victim's IP address, poisoning the neighbor caches of nearby hosts and positioning the attacker for a man-in-the-middle intercept, since traffic meant for the real owner now gets sent to the attacker's MAC instead.

Dynamic ARP Inspection is the practical defense, it cross-checks every ARP reply against a DHCP snooping binding table and drops anything that doesn't match a device the network already knows about. Private VLANs limit which hosts can even talk to each other in the first place, shrinking the blast radius regardless. IPv6's equivalent, NDP, has a very similar exposure, and SEcure Neighbor Discovery exists to close it, but I'd be surprised if you found it deployed at more than a handful of the networks you'll actually interview about.

Identify the attack signature fast, netflow or sflow data usually shows which destination IP is absorbing the flood. Remote-triggered black hole routing (RTBH), a null route pushed at the edge, or via a BGP community upstream to your provider, sacrifices that one destination IP to keep the rest of the link usable. For anything sustained past the first few minutes, redirecting traffic through a scrubbing provider via a BGP announcement is the actual fix.

Worth saying plainly: RTBH is a blunt instrument. You're effectively finishing the attacker's job for them on one specific IP so everything else survives. It's a stopgap, not a solution, and interviewers who've actually run one of these in production want to hear you say that instead of presenting RTBH as a clean fix.

Start with show ip ospf neighbor, since a state cycling between INIT and FULL points to a different root cause than one stalling at EXSTART. debug ip ospf adj usually names the actual reset reason directly.

$ show ip ospf neighbor
Neighbor ID   Pri  State      Dead Time  Address
10.0.0.2     1  EXSTART/ -   00:00:34  10.0.0.2

From there, check in rough priority order: mismatched hello or dead timers (show ip ospf interface on both sides), mismatched area type (stub vs normal), MTU mismatches causing DBD packets to oversize and silently drop, a physically flapping interface, authentication mismatches, and duplicate router IDs. A senior-level answer also asks what changed recently, because on an existing network that's been stable, a new problem is far more likely to be a config change than a sudden protocol bug that's been dormant for years.

VRFs give each tenant its own routing table on the same physical router or switch, tenant A's routes are structurally invisible to tenant B, not just filtered from view. MPLS L2VPN and L3VPN extend that isolation across a provider's network. VXLAN VNIs provide the equivalent at Layer 2, cloud scale. Public cloud platforms wrap all of this in VPC and VNet abstractions that most tenants never see underneath.

Enforcement in practice comes down to strict VRF-boundary ACLs plus route-targets controlling exactly which prefixes get imported and exported between VRFs, with monitoring specifically watching for cross-tenant access attempts. A config mistake here is a customer-facing incident, not an internal one, which is why this design question tends to get asked with more follow-up pressure than the others in this section.

BGP's loop prevention for eBGP is simple, a router rejects any route whose AS_PATH already contains its own AS number. That mechanism doesn't work for iBGP, since routes learned via iBGP never get the local AS prepended, prepending only happens on eBGP advertisements. Instead, iBGP prevents loops with a different rule: a router will never re-advertise a route learned from one iBGP peer to another iBGP peer. That stops loops cleanly, but it has a nasty side effect. If router A learns a route from router B over iBGP, A can't pass it along to router C over iBGP even if C needs it. The only way to guarantee every iBGP router in the AS learns every route is to mesh every router to every other router directly, which is O(n squared) sessions and becomes unmanageable past a few dozen routers, both operationally and in the control-plane load of maintaining that many sessions and running best-path selection against that many copies of each route.

Route reflectors carve out an exception to that reflection rule for a designated set of routers. A route reflector is allowed to take a route learned from one of its iBGP clients and reflect it to other clients, and also reflect between clients and non-client iBGP peers, exactly the behavior that was previously forbidden. Loop prevention survives through two new attributes rather than the old peer-based rule: ORIGINATOR_ID, which records the router ID that first injected the route into the AS, and CLUSTER_LIST, which records every route reflector cluster the route has passed through. A reflector that sees its own cluster ID already in the CLUSTER_LIST, or its own router ID as the ORIGINATOR_ID, knows the route already looped through this part of the topology and drops it.

In practice this turns an O(n squared) full mesh into a hub-and-spoke topology where clients only peer with their route reflectors. Confederations solve a related but different problem, splitting a single AS into sub-ASes to shrink the mesh, and that's a separate tool you reach for when you also want IGP-style summarization boundaries inside the AS rather than just fixing the peering count.

Same-building traffic between two servers is almost certainly a Layer 1 to Layer 3 issue, not something exotic at the application layer. Start with a large-packet ping to surface anything MTU-related. Check interface error counters on both ends and on every switch in between, input errors, CRC errors, output drops, all point in different directions.

If the counters are clean, check whether the loss is periodic. Periodic loss often traces back to an STP topology change event, a TCN flushes the CAM table across the affected switches, and everything gets flooded again until MAC addresses relearn. For anything still unexplained after that, simultaneous tcpdump or Wireshark captures on both ends, with synchronized timestamps, are the only reliable way to prove whether a given drop happened before or after a specific device in the path.