A curated set of counter-intuitive traps interviewers love. Each is a short question, the trap it hides, and the correct reasoning — the stuff that separates people who memorized from people who understand.
Most "gotchas" are the same shape: the observed symptom points at the obvious-but-wrong layer, and the real answer is one layer away. Train yourself to name the trap, state the mechanism, then give the fix. That structure alone reads as senior.
The trap is assuming only too little light is a fault. Too much RX power (overload) is equally a fault — a short fibre into a high-power transmitter saturates the receiver's photodiode and drives errors, and the fix is a physical attenuator, not more signal. Always compare RX against both the min and max of the optic's spec. See Optical power & dBm.
No — fibre carries photons, so optics are immune to electromagnetic interference. A reading pinned near −30 to −40 dBm is the photodiode's noise floor: it means no light is arriving (dark fibre, dirty/unseated connector, TX off, or a break), not "electrical noise." See Optical power & dBm.
The trap is thinking dB is linear. dB is logarithmic: −3 dB is half the power, −10 dB is one tenth, −20 dB is one hundredth. A budget of −6 dB is a factor of 4, not "6% worse." See Optical power & dBm.
Counter-intuitively, microwave through air wins. Light in glass travels at ~2/3 c
(~5 µs/km) because the fibre's refractive index slows it and the cable rarely runs straight;
radio through air is near c and line-of-sight. That is why HFT firms pay for microwave towers between exchanges. See
Low-latency & trading.
No — 64 bytes is the minimum frame size. Anything shorter is padded up to 64 by the sender; a frame that arrives shorter than 64 is a runt and is dropped. The 64-byte floor exists so CSMA-CD collision detection works over the maximum cable length (the slot time). See L2 forwarding & the minimum frame.
The trap: TTL saves you at L3, but a bridge forwards frames unchanged, so nothing in the frame expires. A loop broadcasts forever (a broadcast storm). The only thing that prevents it is STP/RSTP building a loop-free tree by blocking redundant ports — there is no L2 equivalent of TTL.
Classic duplex mismatch: one side full-duplex, one side half. Small packets (ping) pass, but under load you see CRC/runt errors on the full-duplex side and late collisions on the half-duplex side. The fix is matching speed/duplex (usually both to auto). See Troubleshooting scenarios.
It forwards after reading only the destination MAC, before the FCS arrives, so it can propagate a corrupt or runt frame it hasn't checked yet. Store-and-forward validates the FCS first and drops bad frames. Cut-through trades correctness for a few hundred nanoseconds — a deliberate choice in trading fabrics. See Low-latency & trading.
Almost never. The same MAC being learned on two ports means the frames arrive via two paths: a Layer-2 loop (STP failing), a legitimately dual-homed host / mislabelled link, or — if the ports are AP uplinks — a client roaming between Wi-Fi APs (normal, just noisy). Chase the topology, not the hardware.
Classic STP waits out timer-based states (listening 15 s + learning 15 s, plus max-age) before a port forwards. RSTP replaces timers with an explicit proposal/agreement handshake between neighbours and adds edge/point-to-point port roles, so an alternate port can go active almost immediately without waiting for timers to expire.
Gratuitous ARP is a host ARPing for its own IP to announce a MAC change — used to detect duplicate IPs and to fail over a VIP/VRRP address by updating everyone's ARP cache. Proxy ARP is a router answering ARP for an IP that isn't on this segment, pretending to be the destination so a mis-subnetted host still reaches it.
The trap is ARPing for the destination. ARP only resolves addresses on the local subnet; for anything off-subnet the host ARPs for its default gateway and sends the frame there. You never ARP for a host in another subnet — the router does the next hop for you.
Yes, on point-to-point links (RFC 3021). Normally the all-zeros and all-ones host addresses are the network and broadcast, so a /30 gives only 2 usable hosts out of 4. On a P2P link there's no need for either, so a /31 gives both endpoints and wastes nothing. IPv6's equivalent is a /127.
Because it was redundant work at every hop. L2 already has an FCS and L4 (TCP/UDP) has a mandatory checksum covering the addresses, so the network layer's checksum mostly just forced routers to recompute it on every TTL decrement. Dropping it speeds up forwarding and pushes integrity to the layers that already do it.
For plain routing, asymmetric routing is normal and fine — each direction independently takes its best path. It only breaks stateful devices — firewalls, NAT, stateful load balancers — that must see both directions of a flow to keep state. The fix is to pin the flow to one device or make the path symmetric.
Only NAT. Routers rewrite L2 headers (src/dst MAC) hop by hop and decrement TTL, but they leave the IP addresses alone. NAT is the exception — it edits the L3 address, and therefore must also fix the L4 checksum (which covers the pseudo-header of IP addresses). See Life of a packet.
IPv4 multicast maps only the low 23 bits of the group address into the MAC (01:00:5e +
23 bits), but the group has 28 significant bits. Five bits are lost, so 2⁵ = 32 different groups collide onto one
destination MAC — a NIC may receive multicast it didn't join, and the OS filters it in software. See
Advanced packet walkthrough.
. then !!!! — did we lose a packet?No packet was lost. The first echo has to wait while the router resolves ARP and builds the CEF/adjacency
for the next hop; that first probe times out (the .) and the rest succeed. It's a control-plane warm-up,
not loss. See Ping & traceroute.
Both sides must synchronise an Initial Sequence Number and confirm the peer can both send and receive. Two messages can't confirm the client's receive path or protect against a delayed duplicate SYN opening a phantom connection. Note the SYN and FIN each consume one sequence number even though they carry no data. See TCP theory.
No. TIME_WAIT lives on the active closer for 2×MSL so a lost final ACK can be re-sent and
old duplicates die before the 4-tuple is reused — it's correct behaviour. What is a bug is piling-up
CLOSE_WAIT: the peer closed but your application never called close(). See
TCP theory.
It's the Nagle × delayed-ACK deadlock: the sender holds a small write waiting for an ACK (Nagle)
while the receiver holds the ACK waiting to piggyback it (delayed ACK, up to ~200 ms). The fix is
TCP_NODELAY on latency-sensitive sockets. See
TCP theory.
Different problems, different windows. Flow control (the receiver's advertised rwnd) stops a
fast sender from overrunning a slow receiver. Congestion control (the sender's cwnd)
stops senders from overrunning the network. The amount sent is min(rwnd, cwnd).
The window is smaller than the bandwidth-delay product. On a long-RTT path you need
BDP = bandwidth × RTT bytes in flight; the classic 64 KB window caps throughput no matter how fast the
link. The fix is TCP window scaling. See TCP theory.
Classic PMTUD black hole: small packets (handshake) pass, but the first full-MTU segment hits a smaller-MTU link and the router's ICMP "fragmentation needed" is filtered, so the sender never learns to shrink. The fix is MSS clamping at the tunnel edge (or unblocking that ICMP). See TCP theory.
No, it's the rule: a route learned from one iBGP peer is never passed to another iBGP peer (loop prevention, since AS-path doesn't grow inside the AS). That's why you need a full mesh or route reflectors, and why the edge often sets next-hop-self so internal peers have a reachable next hop.
The trap: LOCAL_PREF only steers your own outbound traffic and never leaves your AS. To influence what neighbours send to you, you change what you advertise — AS-path prepending, MED, or communities. Inbound is only ever a hint; the far side decides.
Not the AS-path length (a common guess). Weight (Cisco-local) then LOCAL_PREF outrank AS-path. So a longer AS-path route can still win if it has higher LOCAL_PREF — policy beats topology.
Penultimate Hop Popping (PHP): the egress advertises an implicit-null, so the penultimate router removes the transport label. That way the egress does a single lookup (IP or VPN label) instead of popping a label and then doing a second lookup. See MPLS theory.
Zero. P routers only switch on the outer transport label and know nothing about customer VRFs — the customer routes live only on the PE routers. That's the whole point: the core scales because it's oblivious to customer state. See MPLS theory.
SR encodes the path as a label/SID stack in the packet itself, so the core keeps no per-flow state and LDP/RSVP are eliminated — the IGP distributes SIDs and the source picks the path. Less protocol machinery, source-routed traffic engineering. See Segment Routing theory.
"Up/up" only means L1 light and L2 keepalives are fine — it says nothing about forwarding. Enumerate the layers: wrong VLAN / access-vs-trunk, an ACL or firewall drop, no route (or wrong VRF), a control-plane policer, MTU black-holing, or a unidirectional link (fixed by UDLD). Naming several buckets is the win.
Ping only proves basic L3 reachability. Walk a checklist: MTU/PMTU (small pings pass, big transfers fail), firewall / wrong port, DNS resolution, asymmetric path through a stateful device, and application health (process/listener up, TLS, backend). See Troubleshooting scenarios.
Usually not. Intermediate hops reply by punting the TTL-expired packet to their control-plane CPU, which is rate-limited and deprioritised, so a slow-looking hop can be perfectly healthy at forwarding. Judge latency by the end-to-end number and by whether it persists to later hops. See Ping & traceroute.
Every trap answer fits one template — say it in this order and you sound senior:
TCP_NODELAY, MSS clamp, route reflector, UDLD.Symptom → wrong layer → right layer → remedy. If you can also say how you'd confirm it (the counter you'd check, the capture you'd take), that's the senior tell.