Top 100 Network Engineer Interview Questions and Answers

The first thing I would establish about longest-prefix match is which forwarding entry the packet actually hits.

Forwarding selects the longest matching destination prefix first. Preference, metric, and administrative distance decide only among candidates for the same prefix length, so a /16 wins over a /8 even when the /8 is from a more-trusted source.

Concretely, list every destination match for the packet, pick the greatest prefix length, then inspect that winner's next hop, recursion, and FIB adjacency, and refuse any diagnosis that compared OSPF distance with BGP distance across different lengths.

The reason for that specificity is a failure I have seen: An operator withdrew the OSPF default after seeing 10.0.0.0/8 in the table and left a stale BGP /16 in place. Traffic to 10.4.1.7 followed the /16 for 18 minutes, and 47,200 packets hit a dead next hop while the /8 remained installed.

Lookup for 10.4.1.7 against two overlapping prefixes.

Prefix	Source	Administrative distance	Match length	Packets forwarded
10.0.0.0/8	OSPF	110	8	0
10.4.0.0/16	BGP	20	16	47,200
time until the /16 was withdrawn	—	—	—	18 minutes

I would not consider it settled without evidence: run an exact-prefix lookup for 10.4.1.7 on the forwarding table and record the winning length and next hop, not the protocol of the less-specific.

Specificity is evaluated before preference.

I would start RIB versus FIB from the packet and the return path, not from the protocol adjacency.

The RIB holds selected control-plane candidates. The FIB is the programmed forwarding structure the ASIC or forwarding process actually uses, and it can lag, omit, or differ after recursion, hardware capacity, or line-card programming fails.

Concretely, compare the selected RIB prefix against a platform forwarding lookup and hardware adjacency, count RIB versus FIB entries, and treat a missing FIB hit as a programming fault rather than as a routing-protocol adjacency fault.

The reason for that specificity is a failure I have seen: A line card accepted 14,112 BGP prefixes into the RIB and programmed 12,004 into the FIB. The remaining 2,108 prefixes black-holed for 3 hours 20 minutes while every BGP session stayed Established.

Control-plane count versus programmed forwarding.

Table	Entries	Destinations that forwarded
RIB (selected BGP)	14,112	not measured here
FIB (hardware)	12,004	12,004
missing from FIB	2,108	0 for 3 hours 20 minutes

I would not consider it settled without evidence: issue a hardware exact-route lookup for the failing destination and require a programmed adjacency, not only a RIB row.

A RIB row is a candidate; a FIB hit is forwarding.

This is an area where a green session and a working path are different observations.

An Ethernet frame has no hop limit, so a Layer 2 loop multiplies frames until the broadcast domain saturates. An IP forwarding loop decrements TTL and dies at a finite hop count, which shows as alternating traceroute hops rather than as a storm.

Concretely, measure unknown-unicast and broadcast rates per VLAN, inspect MAC move counters, and look for TTL-expired ICMP; treat a storm with zero TTL expiry as Layer 2, and treat alternating L3 hops with decaying TTL as a routing loop.

The reason for that specificity is a failure I have seen: A redundant access cable without spanning tree filled VLAN 40 to 98 percent of a 1.2 Gbps uplink in 4 minutes. Traceroute to the gateway still completed in 1 hop, and 0 TTL-expired messages were logged because the frames never left Layer 2.

Two loops, two counters.

Observation	Layer 2 storm	IP TTL loop
VLAN utilisation	98 percent of 1.2 Gbps	4 percent
minutes to saturation	4	not applicable
TTL-expired ICMP	0	1,900 per minute
traceroute	1 hop to gateway	alternating 2 hops

I would not consider it settled without evidence: compare VLAN flood counters with ICMP time-exceeded counters on the same interval and require the diagnosis to name which counter actually moved.

Ethernet does not age a looping frame; IP TTL does.

My answer to STP root placement begins with which plane is making the decision: control, forwarding, or policy.

The root is the reference for every path cost in the VLAN. A root in an access closet forces core-to-core traffic through that closet, adding hops and concentrating failure on a device that was never sized for it.

Concretely, set bridge priority so the intended core pair are primary and secondary root, verify root port and designated roles after convergence, and refuse any topology whose shortest path to the root leaves the distribution layer.

The reason for that specificity is a failure I have seen: A new access switch kept the default priority 32768 matching the core, won on MAC address, and increased the path from 2 hops to 11 over a 1 Gbps uplink. East-west latency rose from 6 ms to 41 ms and stayed there for 2 days until someone listed the root.

Path after the closet won root.

Path	Hops	Latency	Duration
designed, core as root	2	6 ms	intended
after closet election	11	41 ms	2 days
uplink speed at the accidental root	1 Gbps	—	—

I would not consider it settled without evidence: show spanning-tree root and the hop count from each distribution switch, and require the core pair to own root and secondary.

Root placement is the traffic map, not a cosmetic priority.

I would treat VLAN trunk allowed list as a claim about a specific five-tuple, VRF, and direction.

A trunk forwards only VLANs that exist, are allowed, and are in forwarding state on both sides. Line protocol up does not mean the allowed list, pruning, or STP state carried the VLAN.

Concretely, compare operational allowed VLANs, VLAN database membership, and per-VLAN STP state in both directions, then capture a tagged frame of that VLAN on the trunk rather than inferring carriage from the interface being up.

The reason for that specificity is a failure I have seen: VLAN 47 was pruned on the far end of an otherwise healthy LAG. 1,840 endpoints on that VLAN lost the gateway for 7 hours while the trunk stayed up and VLAN 10 continued to pass.

Two VLANs on one trunk.

VLAN	Allowed both ends	STP forwarding	Silent endpoints	Hours until noticed
10	yes	yes	0	—
47	no, pruned far end	blocked	1,840	7

I would not consider it settled without evidence: capture an 802.1Q frame with VLAN 47 on the trunk and confirm the same VLAN is forwarding on both member switches.

An up trunk is not an allowed-VLAN list.

The useful question for native VLAN mismatch is what a hash-diverse probe would show on the other members.

The native VLAN is the untagged broadcast domain on a trunk. If the two ends disagree, untagged control and data frames cross into a foreign VLAN, which is a segmentation failure, not a cosmetic numbering issue.

Concretely, set the native VLAN explicitly and identically, tag the native VLAN where the platform allows it, and refuse trunks whose untagged VLAN numbers differ even by one.

The reason for that specificity is a failure I have seen: One side used native VLAN 1 and the other native VLAN 99. 312 CDP and untagged user frames crossed the boundary over 14 days, and a workstation in VLAN 99 obtained a VLAN 1 address.

Untagged frames on a mismatched trunk.

End	Native VLAN	Untagged frames learned	Days until found
switch A	1	312	14
switch B	99	312	14
workstations that received the wrong subnet	—	1	—

I would not consider it settled without evidence: send a known untagged test frame and require it to be learned in the same VLAN identifier on both switches.

Disagreeing native VLANs are a VLAN merge.

I would settle MAC flapping by capturing both sides of the encapsulation, not by reading the neighbour table.

A switch learns a source MAC on an ingress VLAN and port. Rapid moves mean either a Layer 2 loop, a duplicated adapter, or an unexpected active-active attachment, not a routing metric problem.

Concretely, record move rate, VLAN, and both ports, trace those ports through trunks, LAGs, and hypervisors, and contain flood first only if the domain is already saturating; then remove the second source or the loop.

The reason for that specificity is a failure I have seen: A mis-bundled dual-homed server presented one MAC on two access ports. The table recorded 8,400 moves per minute for 22 minutes, unknown-unicast flooded the VLAN, and the first ticket was filed as a gateway ARP fault.

One MAC, two ports.

Port	Moves per minute	Minutes observed	First ticket category
Gi1/0/12	4,200	22	gateway ARP
Gi1/0/18	4,200	22	gateway ARP
total	8,400	22	wrong plane

I would not consider it settled without evidence: export MAC-move timestamps for that address and require a single stable port before declaring the VLAN healthy.

A flapping MAC is a Layer 2 topology statement.

The judgement in LACP member data-plane failure is which state the packet uses, not which state the operator intended.

A member that LACP suspends is normally removed from the aggregate's distribution set. But LACP can remain healthy when its control frames pass and ordinary payload traffic does not, so collecting-distributing state is not proof of the member's data path.

Concretely, compare actor and partner state, key, speed, and VLAN on every member, then probe with hash-diverse five-tuples and verify payload counters and loss per member rather than relying on LACP state or a single ping through the bundle.

The reason for that specificity is a failure I have seen: One member remained collecting and distributing while a data-plane fault dropped ordinary payloads. Hashing sent 25 percent of flows onto it for 90 minutes, and 1 in 4 application sessions failed while the port-channel showed up/up.

Four LACP members, one payload path failed.

Member	LACP state	Hash share	Sessions that failed
1	collecting, distributing	25 percent	0 of 100
2	collecting, distributing	25 percent	0 of 100
3	collecting, distributing	25 percent	0 of 100
4	collecting, distributing; payload fault	25 percent	100 of 100
minutes until the failed member was removed from hash	—	—	90

I would not consider it settled without evidence: send at least one flow per member hash bucket and require each member's TX/RX counters to move only on collecting-distributing ports.

Bundle line protocol is not the member distribution set.

Where candidates lose the interview on OSPF adjacency versus advertised prefix is calling the tunnel or the BGP session the path.

FULL means the link-state database for that adjacency synchronized. It does not mean the desired prefix was originated, passed area policy, won preference, or was programmed. Adjacency is a transport for LSAs, not a list of routes.

Concretely, check the expected LSA type and advertising router, confirm area and redistribution policy, then look up the prefix in RIB and FIB; treat a missing Type-5 external, Type-3 summary, or intra-area prefix advertisement as a generation or policy fault.

The reason for that specificity is a failure I have seen: Two cores stayed FULL while redistribution of 64 static prefixes was left in a deny-all route-map. The prefixes were absent for 5 hours, and every health check that stopped at neighbour state reported green.

Adjacency versus origin.

Check	Result	Hours until the route-map was found
neighbour state	FULL	5
Type-5 LSAs for the statics	0	5
prefixes missing from RIB	64	5

I would not consider it settled without evidence: show the specific LSA for the missing prefix and a FIB lookup, and require both, not the neighbour state machine.

FULL is database sync, not prefix presence.

I would answer OSPF area 0 by separating reachability, policy, and observed delivery.

Non-backbone areas exchange inter-area routing through area 0. A disjoint backbone, or areas that only touch each other, cannot compute a correct inter-area path without a virtual link or a redesigned backbone.

Concretely, draw area 0 so every ABR has a resilient backbone link, refuse area-to-area shortcuts that bypass it, and test ABR and backbone-link loss before calling the area design done.

The reason for that specificity is a failure I have seen: Sites A and B were placed in area 1 and 2 with an extra link between them and no area-0 path after a core failure. Inter-area prefixes disappeared for 40 minutes, and 3 areas partitioned even though intra-area neighbours stayed FULL.

Partition after the backbone link failed.

Path	Areas involved	Prefixes retained	Minutes of partition
designed via area 0	3	all inter-area	0
leftover A-to-B extra link	1 and 2 only	intra-area only	40

I would not consider it settled without evidence: fail the backbone path in a change window and require inter-area prefixes to remain installed through the remaining area-0 ABR.

Area 0 is the inter-area spine, not a label.

The engineering content of BGP Established versus advertised is the return path and the more-specific prefix, not the protocol name.

Established means the TCP session and OPEN completed. Import, export, address-family activation, and outbound policy decide which NLRI actually leave. A quiet session can be a policy deny, not a healthy default.

Concretely, compare advertised and received prefix counts per address family with the intended policy, and require an explicit outbound permit rather than treating session state as an advertisement.

The reason for that specificity is a failure I have seen: A new peering stayed Established while the IPv4 unicast family was never activated. 0 prefixes were advertised for 2 hours, and 1,100 customer prefixes stayed inside the AS until someone counted Adj-RIB-Out.

Session versus NLRI.

Observation	Count	Duration
BGP state	Established	2 hours
address families activated	0	2 hours
prefixes in Adj-RIB-Out	0	2 hours
customer prefixes held in	1,100	2 hours

I would not consider it settled without evidence: show advertised routes to that neighbour and require a non-zero, policy-expected count.

Established is transport; Adj-RIB-Out is the advertisement.

Before calling RFC 8212 default-reject done I would write down the ECMP member, VLAN, or VRF nobody hashed onto.

RFC 8212 requires default-reject import and export on eBGP sessions. Without explicit policy, a new neighbour is a full-table leak and a full-table advertisement.

Concretely, configure inbound and outbound policy that permits only the intended prefixes and AS paths, set a max-prefix, and refuse any eBGP neighbour whose policy is implicit-allow.

The reason for that specificity is a failure I have seen: A lab router with implicit-allow eBGP accepted 84,000 prefixes from a transit test peer and advertised them internally for 11 minutes, attracting production traffic onto a 100 Mbps lab link.

Implicit-allow versus default-reject.

Policy	Prefixes accepted	Minutes until withdrawn	Link
implicit allow	84,000	11	100 Mbps lab
RFC 8212 default-reject	0	—	—

I would not consider it settled without evidence: bring up an eBGP session with no policy and require 0 prefixes accepted and 0 advertised.

eBGP without policy is a leak waiting for a neighbour.

The first thing I would establish about BGP local preference versus MED is which forwarding entry the packet actually hits.

Local preference is compared inside the AS and typically wins early in the decision process, so it selects the exit for outbound traffic. MED is a hint to an external neighbour and is compared later, often only among routes from the same AS, so it does not steer your own outbound path.

Concretely, set local preference on inbound advertisements to choose your outbound exit, use MED or communities only as a request to a neighbour, and never treat a lower MED as beating a higher local preference inside your AS.

The reason for that specificity is a failure I have seen: A team lowered MED on the primary exit and left local preference equal. Internal routers kept the secondary exit because of IGP metric, adding 180 ms for 6 hours, while the neighbour never compared the MED at all.

Same prefix, two attributes.

Attribute set on primary	Internal winner	Extra latency	Hours
MED 50, local pref 100	secondary (IGP)	180 ms	6
local pref 200, MED unchanged	primary	0 ms	—

I would not consider it settled without evidence: show the BGP decision trace for a prefix and require local preference, not MED, to be the first differing attribute among internal candidates.

Local preference chooses your exit; MED asks a neighbour.

I would start AS_PATH is not cable distance from the packet and the return path, not from the protocol adjacency.

AS_PATH length is a policy loop-prevention and preference signal, not geographic or latency distance. A short AS_PATH can traverse a congested or distant cable; a longer path can be the close peering.

Concretely, measure RTT and loss on the forwarding path you actually install, and if latency matters, set local preference or communities from that measurement rather than from AS hop count.

The reason for that specificity is a failure I have seen: Outbound policy preferred a 2-AS transit over a 4-AS peering. The 2-AS path added 91 ms versus 12 ms on the peering, and a voice cluster stayed on the long path for 3 days because the attribute looked shorter.

Path length versus delay.

Path	AS hops	RTT	Days selected
transit	2	91 ms	3
peering	4	12 ms	0 until policy change

I would not consider it settled without evidence: compare RTT of hash-pinned probes on each candidate next hop and install from that, not from AS_PATH length.

AS hops are not milliseconds.

This is an area where a green session and a working path are different observations.

Route origin validation can mark a route valid, not found, or invalid against ROAs. Invalid means either the origin AS is unauthorized or the route is more specific than the ROA's maxLength permits; accepting it can admit a hijack or a legitimate route broken by stale ROA data. RFC 6811 leaves treatment to local policy, and not found is not the same as valid.

Concretely, make invalid routes ineligible under the documented import policy, keep not-found routes unless policy says otherwise, and monitor the invalid count so a stale ROA does not silently drop a legitimate more-specific.

The reason for that specificity is a failure I have seen: Invalids were accepted to "avoid risk." One hijacked /24 stayed in the FIB for 6 hours and 19,000 packets followed it, while the valid covering /22 remained unused because of longest match.

Hijack that won on length.

Prefix	RPKI	Installed	Packets
203.0.112.0/22	valid	no, less specific	0
203.0.113.0/24	invalid	yes for 6 hours	19,000

I would not consider it settled without evidence: inject a test invalid in a lab VRF and require it to be discarded before RIB installation.

Invalid is not a softer unknown.

My answer to route leak begins with which plane is making the decision: control, forwarding, or policy.

A route leak is an advertisement of prefixes beyond the intended customer/provider/peer relationship, often visible as an unexpected AS_PATH or as more-specifics that attract a continent. Peering policy and prefix filters exist to stop that role change.

Concretely, apply role-based export (customer may send only their prefixes), max-prefix, RPKI, and IRR filters, and treat a sudden more-specific from a customer as a leak until proven otherwise.

The reason for that specificity is a failure I have seen: A customer advertised 0.0.0.0/1 and 128.0.0.0/1 learned from another ISP. Four of our peers preferred those more-specifics for 37 minutes, and 2.1 Gbps of foreign traffic entered a 1 Gbps access circuit.

Leak of default-like more-specifics.

Prefix from customer	Intended	Peers that preferred it	Minutes	Traffic on 1 Gbps access
0.0.0.0/1	no	4	37	2.1 Gbps offered
128.0.0.0/1	no	4	37	included above

I would not consider it settled without evidence: alarm on prefix count and unexpected default-like more-specifics from customers, and require filters that would have dropped both /1s.

A customer session is not a transit settlement.

I would treat mutual redistribution loop as a claim about a specific five-tuple, VRF, and direction.

Mutual redistribution without tagging or filters re-injects the same prefix with a new source, which can loop, inflate the table, and oscillate SPF or BGP churn. Each redistribution point is a new origin unless you mark and deny re-entry.

Concretely, tag or community-stamp on export, deny tagged routes on the reverse redistribution, prefer a single redistribution point, and count prefixes before and after.

The reason for that specificity is a failure I have seen: Two ABRs redistributed BGP into OSPF and OSPF into BGP with no tags. The LSDB gained 2,400 extra external prefixes, SPF ran 9 times per minute, and the loop lasted 50 minutes until one redistribution was shut.

Table growth during the loop.

Metric	Before	During the 50 minutes
OSPF external prefixes	120	2,520 (120 + 2,400)
SPF runs per minute	0.1	9
redistribution points with tags	0 of 2	0 of 2

I would not consider it settled without evidence: trace one prefix's path attributes and LSA advertising-router across both borders and require a tag that stops re-entry.

Untagged mutual redistribution is a prefix photocopier.

The useful question for ECMP one-ping fallacy is what a hash-diverse probe would show on the other members.

ECMP hashes a flow onto one member. A single five-tuple samples one bucket. A failed member, a polarized hash, or a one-way path on another member stays invisible until a different tuple is used.

Concretely, install the full next-hop set, generate many controlled tuples covering each member, and measure loss and latency per member rather than averaging one success.

The reason for that specificity is a failure I have seen: Operators signed off a new core after one ping. Three of eight members dropped 100 percent of hashed flows because of a unicast RPF failure. The outage lasted until 8 minutes of user traffic filled the other buckets.

Eight members, one ping.

Member	Ping used	Loss	User flows after 8 minutes
1–5	not sampled	0 percent	healthy
6–8	not sampled	100 percent	all hashed flows failed
member 1 (the ping)	1 tuple	0 percent	proved only itself

I would not consider it settled without evidence: map each next hop to at least one probe five-tuple and require all eight members to forward.

One flow is one hash bucket.

I would settle asymmetric routing through a stateful firewall by capturing both sides of the encapsulation, not by reading the neighbour table.

A stateful firewall forwards only packets that match created state. Asymmetry that splits the handshake across two unsynchronized devices looks like an unsolicited SYN-ACK and is dropped, even though IP routing itself allows asymmetry.

Concretely, keep both directions of a flow on the same firewall cluster, enable state sync only where it actually shares the table, or use external routing that pins the pair; never assume routing symmetry from a successful traceroute in one direction.

The reason for that specificity is a failure I have seen: After an ECMP change, SYN-ACKs hashed to the other firewall. 100 percent of new TCP sessions died for 8 minutes, and both firewalls showed healthy CPU while dropping 22,000 unsolicited SYN-ACKs.

Handshake split across two firewalls.

Packet	Firewall	State present	Action	Minutes
SYN	A	created	allow	8
SYN-ACK	B	no	drop 22,000	8
new TCP sessions completing	—	—	0 percent	8

I would not consider it settled without evidence: capture the SYN and SYN-ACK at both firewalls and require them to hit the same state table.

Statefulness makes asymmetry a drop, not a curiosity.

The judgement in uRPF strict versus loose is which state the packet uses, not which state the operator intended.

Strict uRPF requires the source to be reachable via the ingress interface. Loose uRPF requires the source to be reachable via any interface. Asymmetric multihoming fails strict and usually passes loose.

Concretely, use loose or feasible-paths uRPF on asymmetric edges, reserve strict for single-homed access where spoofing risk dominates, and test inbound from each provider with a source that returns via the other.

The reason for that specificity is a failure I have seen: Strict uRPF on both ISP interfaces dropped 31 percent of inbound customer replies for 4 hours because return routing preferred the other ISP, while spoofed packets were not the traffic that failed.

Two ISPs, strict mode.

Mode	Inbound dropped	Hours	Cause
strict	31 percent	4	source not via ingress
loose (after change)	0 percent of legitimate	—	any-interface reachability

I would not consider it settled without evidence: send a packet whose source prefix is installed only on the other ISP interface and require strict to drop it and loose to accept it.

Strict uRPF assumes symmetric routing.

Where candidates lose the interview on VRRP versus session state is calling the tunnel or the BGP session the path.

VRRP moves a virtual IP and MAC. It does not copy NAT or firewall session tables. The new master answers ARP for the VIP and then drops packets that belong to state it never saw.

Concretely, place stateful devices in an active/standby pair that syncs sessions, or accept that failover resets sessions; do not quote VRRP advertisement timers as a session-preservation SLA.

The reason for that specificity is a failure I have seen: The VIP moved in 3 seconds. 12,600 NAT translations existed only on the old master, and every translated TCP session reset. Users saw a 3-second ICMP recovery and a 12-minute application rebuild.

VIP move versus NAT table.

Object	On old master	On new master at +3 s	Application rebuild
virtual IP	released	owned	—
NAT sessions	12,600	0	12 minutes
ICMP to VIP	fails 3 s	succeeds	not the app

I would not consider it settled without evidence: count session-table entries on the new master immediately after failover and require either sync or an explicit reset budget.

VRRP moves the address, not the flow table.

I would answer BFD false positives by separating reachability, policy, and observed delivery.

BFD is a forwarding-path liveness detector, not an application health check. Aggressive timers trip on queueing, CoPP, or control-plane scheduling, tearing down clients that were still forwarding user packets.

Concretely, size interval and multiplier to the platform's control-plane budget, protect BFD in CoPP, and correlate flaps with CPU and drop counters before blaming the optical path.

The reason for that specificity is a failure I have seen: Timers of 50 ms × 3 produced 14 flaps per hour for 2 hours during a control-plane spike at 88 percent CPU. User packet loss on the same interfaces stayed at 0 percent; only protocol adjacencies died.

Liveness versus user frames.

Signal	Value during the 2 hours
BFD interval × multiplier	50 ms × 3
adjacency flaps per hour	14
user packet loss	0 percent
control-plane CPU	88 percent

I would not consider it settled without evidence: show BFD drop and CoPP counters alongside interface error counters, and require optical errors before calling the path dead.

BFD can kill a healthy adjacency.

The engineering content of summary black hole is the return path and the more-specific prefix, not the protocol name.

A summary asserts reachability for its entire range. If a covered more-specific fails and no discard or withdrawal policy exists, the aggregate keeps attracting traffic into a hole or a loop.

Concretely, install a discard route for the summary, advertise only when components justify it, and leak more-specifics or withdraw the aggregate when the last component dies.

The reason for that specificity is a failure I have seen: An ABR kept advertising the /16 after the site's only component /24 failed. All 256 addresses covered by that /24, including its live hosts, were black-holed for 1 hour 15 minutes because the aggregate was not withdrawn.

Covered prefix down, aggregate still out.

Prefix	State	Attracts 10.8.4.10	Duration
10.8.4.0/24	down	no, absent	1 hour 15 minutes
10.8.0.0/16	still advertised	yes	1 hour 15 minutes
discard for 10.8.0.0/16	missing	loop or hole	1 hour 15 minutes

I would not consider it settled without evidence: fail the component prefix in a lab and require either aggregate withdrawal or a discard that does not loop.

An aggregate is a reachability promise.

Before calling VXLAN underlay MTU done I would write down the ECMP member, VLAN, or VRF nobody hashed onto.

VXLAN adds outer Ethernet, IP, UDP, and VXLAN headers (commonly 50 bytes, more with options). If the underlay MTU cannot carry inner 1500 plus overhead, large inner frames drop. Overlay control plane can stay up.

Concretely, raise underlay MTU or clamp inner MSS, account for the actual header stack, and test 1500-byte inner frames on every underlay ECMP member.

The reason for that specificity is a failure I have seen: Underlay MTU stayed 1500. Inner 1500-byte frames needed 1550 on the wire and dropped. Small pings worked for 3 hours while file copies failed; EVPN sessions remained Established.

Inner 1500 on a 1500 underlay.

Frame	Size on underlay	Forwarded	Hours of silent large-drop
ICMP 64-byte inner	~114	yes	3
inner 1500	1550	no	3
EVPN BGP state	—	Established	3

I would not consider it settled without evidence: send a 1500-byte inner frame and capture the encapsulated size on the underlay, requiring the underlay MTU to be at least that size.

Overlay adjacency does not enlarge underlay MTU.

The first thing I would establish about EVPN control plane versus data plane is which forwarding entry the packet actually hits.

EVPN advertises reachability. Encapsulation, VNI mapping, underlay next hop, and the actual VXLAN data path are separate. A Type-2 without a working VTEP data plane is a directory entry, not a delivered frame.

Concretely, resolve the next-hop VTEP, confirm VNI and encapsulation counters increment, and ping or capture inner traffic rather than stopping at the BGP EVPN table.

The reason for that specificity is a failure I have seen: Type-2 routes were present while a mis-set VNI dropped data-plane decapsulation. Inner frames produced 0 encap hits for 45 minutes; the control plane stayed full.

Type-2 present, data plane silent.

Plane	Observation	Minutes
EVPN Type-2	installed	45
VXLAN encap hits for the VNI	0	45
inner frames delivered	0	45

I would not consider it settled without evidence: require VXLAN encap/decap counters to move for that VNI, not only a Type-2 show command.

EVPN is the directory; VXLAN counters are delivery.

I would start overlay versus underlay failure from the packet and the return path, not from the protocol adjacency.

Overlay sessions ride hashed underlay paths. Overlay control-plane health does not prove every underlay member. A single bad underlay next hop takes the overlay flows that hash onto it.

Concretely, measure underlay member loss with diverse hashes, map overlay VTEP pairs onto those members, and repair the underlay rather than restarting BGP EVPN.

The reason for that specificity is a failure I have seen: One of four underlay members dropped 12 percent of large packets. Overlay BGP stayed up. Flows that hashed onto that member failed for 6 hours while a VTEP ping that hashed elsewhere succeeded.

One underlay member, overlay still Established.

Path	Loss on large packets	Overlay BGP	Hours
underlay members 1–3	0 percent	Established	6
underlay member 4	12 percent	Established	6
VTEP ping on members 1–3	0 percent	—	6

I would not consider it settled without evidence: probe each underlay member between VTEPs with large packets and require all members below a stated loss bound.

Overlay green is not underlay ECMP green.

This is an area where a green session and a working path are different observations.

VRF isolation is the import and export of route targets, plus the routing table the packet is classified into. An extra import RT, a leaked static, or a global leak undoes the tenant boundary even when interfaces stay in the right VRF.

Concretely, inventory route targets per VRF, deny unexpected imports, and traceroute inside the tenant VRF to see whether the next hop belongs to another tenant.

The reason for that specificity is a failure I have seen: An extra import RT copied 17 prefixes from tenant A into tenant B. The leak lasted 9 days, and 1 billing query from B reached A's database because longest match preferred the leaked /32.

Unintended import.

VRF	Extra import RT	Foreign prefixes	Days	Packets that crossed
tenant B	one	17	9	1 documented query plus unknown

I would not consider it settled without evidence: show the tenant VRF RIB for foreign prefixes and require zero unless a documented leak with policy exists.

The VRF name on the interface is not the import policy.

My answer to IPsec SA up versus selector begins with which plane is making the decision: control, forwarding, or policy.

An SA is a keyed channel for packets that match its traffic selectors. If the ACL or TS is wrong, packets miss the SA and follow the normal route, while the SA idles in the up state.

Concretely, compare the selector to the actual inner five-tuple, confirm encapsulating counters increment for that flow, and never treat IKE or SA up as proof of match.

The reason for that specificity is a failure I have seen: The SA covered 10.8.0.0/24 while the application used 10.8.1.0/24 inside 10.8.0.0/16. The SA stayed up with 0 matching bytes for 2 hours, and 880 MB left unencrypted.

Idle SA beside cleartext.

Prefix	In selector	Application traffic	SA bytes	Hours
10.8.0.0/24	yes	no	0	2
10.8.1.0/24	no	yes, 880 MB	0	2

I would not consider it settled without evidence: generate the application five-tuple and require IPsec encapsulating byte counters to rise by the payload size.

SA up is a channel; selectors are admission.

I would treat tunnel versus encryption as a claim about a specific five-tuple, VRF, and direction.

GRE encapsulates; it does not encrypt. Confidentiality requires a crypto transform such as IPsec. A tunnel icon is reachability of the outer header, not secrecy of the inner.

Concretely, place GRE inside IPsec or use a crypto tunnel, and verify ESP or equivalent byte counters rather than GRE keepalive state.

The reason for that specificity is a failure I have seen: A "VPN" built as GRE-only carried 4.1 GB of inner cleartext for 1 day on a shared underlay; the tunnel stayed up and the ticket closed as encrypted.

GRE without a crypto transform.

State	Value
GRE tunnel	up for 1 day
IPsec transform	none
inner bytes on the underlay	4.1 GB readable

I would not consider it settled without evidence: capture the underlay and require the inner payload to be unreadable, not merely GRE-encapsulated.

Encapsulation is not confidentiality.

The useful question for NAT-T is what a hash-diverse probe would show on the other members.

Ordinary port-mapped NAT cannot distinguish naked ESP flows because ESP has no transport ports; IPsec-aware pass-through is special handling. NAT-Traversal wraps ESP in UDP 4500 so a normal mapping can exist. Blocking 4500 after allowing 500 yields a control plane with no data plane.

Concretely, allow UDP 500 and 4500 plus the return mapping, detect NAT via the NAT-D payloads, and refuse designs that permit IKE only.

The reason for that specificity is a failure I have seen: A firewall allowed UDP 500 and denied 4500. 1,200 remote SAs reached IKE then passed 0 ESP for 70 minutes until NAT-T was unblocked.

Control allowed, data blocked.

Port or protocol	Policy	SAs	Data bytes	Minutes
UDP 500	allow	1,200 IKE	0	70
UDP 4500	deny	—	0	70
ESP protocol 50	n/a behind NAT	—	0	70

I would not consider it settled without evidence: place a NAT in the path and require ESP-in-UDP 4500 counters to increment.

IKE on 500 is not ESP through NAT.

I would settle VPN MTU black hole by capturing both sides of the encapsulation, not by reading the neighbour table.

IPsec and tunnel headers reduce effective inner MTU. If PMTUD is blocked and MSS is not clamped, large inner packets drop. The SA remaining up is expected.

Concretely, compute inner MTU from outer MTU minus headers, clamp TCP MSS on the VPN path, and test large inner packets in both directions.

The reason for that specificity is a failure I have seen: Inner 1500-byte packets needed a 1400-byte inner MTU. 22 percent of application writes failed for 5 hours; keepalives at 64 bytes succeeded and the SA stayed up.

Size-dependent drop on an up SA.

Inner size	Forwarded	Application writes failed	Hours
64	yes	—	5
1400	yes	—	5
1500	no	22 percent	5

I would not consider it settled without evidence: send inner packets from 64 to 1500 bytes and record the first size that dies, then set MSS and MTU from that size.

An up SA still has an inner MTU.

The judgement in split tunnel versus full tunnel is which state the packet uses, not which state the operator intended.

Split tunnel sends listed prefixes in the clear to the local network. Full tunnel sends all user traffic to the concentrator. Exclusion is a trust decision about those destinations, not a performance toggle.

Concretely, enumerate excluded prefixes, treat them as off-VPN, and put host firewall and DNS policy on that path; do not exclude "private ranges" that include attacker-controlled space.

The reason for that specificity is a failure I have seen: Eight RFC1918 exclusions included a hotel LAN. Three malware C2 hosts on 10.0.0.0/8 were reachable in the clear for 14 days while the VPN icon stayed connected.

Exclusions that leaked.

Excluded prefixes	C2 hosts reached in the clear	Days
8 RFC1918 summaries	3	14
full-tunnel (after)	0	—

I would not consider it settled without evidence: from a tunneled client, traceroute an excluded prefix and require it to be either intended or removed from the split list.

Split tunnel is a bypass list.

Where candidates lose the interview on default-route tunnel recursion is calling the tunnel or the BGP session the path.

If the tunnel destination recurses through the tunnel itself, the next hop is undefined and the tunnel collapses. The tunnel destination must resolve via a more-specific underlay route that does not use the tunnel.

Concretely, install a more-specific for the tunnel endpoint via the underlay, never via 0.0.0.0/0 through the tunnel, and test by withdrawing the more-specific in a lab.

The reason for that specificity is a failure I have seen: A static default into the tunnel removed the only route to the tunnel destination. The interface stayed administratively up with 0 next hops for 11 minutes, taking the site offline.

Recursive default.

Route	Next hop	Minutes of 0 forwarding
0.0.0.0/0	tunnel	11
tunnel destination /32	0.0.0.0/0 (recursive)	11
underlay more-specific	missing	11

I would not consider it settled without evidence: lookup the tunnel destination and require a non-tunnel next hop.

The tunnel endpoint cannot live inside the tunnel.

I would answer IKE versus ESP data path by separating reachability, policy, and observed delivery.

IKE negotiates keys; ESP carries the data. Filtering ESP or UDP 4500 after IKE succeeds is a data-path drop with a green control plane. Phase 1 is not the payload path.

Concretely, permit the negotiated data protocol or NAT-T port end to end, and confirm ESP or ESP-in-UDP counters, not only IKE state.

The reason for that specificity is a failure I have seen: IKE and IPsec SAs showed up while ESP was filtered. 0 data bytes passed for 4 hours; both vendors' "VPN up" tiles stayed green.

Keys without payload.

Channel	State	Bytes in 4 hours
IKE (UDP 500)	up	negotiation only
ESP (protocol 50)	filtered	0
application through the VPN	—	0

I would not consider it settled without evidence: capture beyond the middlebox and require ESP (or UDP 4500) packets, not only ISAKMP.

IKE is the handshake; ESP is the path.

The engineering content of ESP anti-replay is the return path and the more-specific prefix, not the protocol name.

ESP anti-replay rejects packets whose sequence number falls too far behind the highest seen. A window of 64 means 64 packets of slack. ECMP reordering or QoS can look like a replay attack.

Concretely, size the window to observed reorder depth, keep a flow on one path where possible, and distinguish replay drops from integrity failures.

The reason for that specificity is a failure I have seen: Window 64 met a two-member ECMP that reordered by 80 packets. 2,200 ESP packets dropped in 18 minutes after the reorder began; IKE stayed up.

Reorder deeper than the window.

Replay window	Observed reorder	ESP drops	Minutes
64	80 packets	2,200	18
128 (after)	80 packets	0	—

I would not consider it settled without evidence: count anti-replay drops versus integrity failures and measure reorder depth on the underlay.

Anti-replay is a sequence window, not a virus scanner.

Before calling round robin unequal work done I would write down the ECMP member, VLAN, or VRF nobody hashed onto.

Round-robin equalises request count, not work. Unequal capacity means the smallest member reaches 100 percent while others idle, which looks like a random latency spike.

Concretely, weight by capacity or use a load signal, and measure per-member utilisation rather than request share.

The reason for that specificity is a failure I have seen: Equal round-robin sent 25 percent of requests to a 2-core node. That node hit 100 percent CPU and 4× latency for 35 minutes while the 32-core node sat at 12 percent.

Four members, round-robin.

Cores	Request share	CPU	Latency vs baseline	Minutes
2	25 percent	100 percent	4×	35
8	25 percent	40 percent	1.1×	35
8	25 percent	41 percent	1.1×	35
32	25 percent	12 percent	1.0×	35

I would not consider it settled without evidence: compare request share with CPU per member and require weights that keep utilisation within a stated band.

Equal requests are not equal work.

The first thing I would establish about HTTP/2 least-connections is which forwarding entry the packet actually hits.

HTTP/2 multiplexes many streams on one TCP connection. A least-connections balancer that counts TCP sessions, not streams, parks work on whichever connection opened first.

Concretely, balance on stream count, request rate, or HTTP/1.1 where session count equals work, and do not read TCP connection count as concurrency.

The reason for that specificity is a failure I have seen: One HTTP/2 connection to a warm backend counted as 1. 80 percent of streams landed there for 26 minutes; three other backends each showed 1 idle connection.

Connections versus streams.

Backend	TCP connections	Streams	Share of work	Minutes
A	1	800	80 percent	26
B	1	70	~7 percent	26
C	1	70	~7 percent	26
D	1	60	~6 percent	26

I would not consider it settled without evidence: compare stream or request counters with TCP connection counters per member.

One HTTP/2 connection is many requests.

I would start TCP health check shallowness from the packet and the return path, not from the protocol adjacency.

A TCP connect check proves the handshake, not that the application will complete a request. Shallow health hides 503, TLS failures, and dependency errors behind an open port.

Concretely, check an HTTP path that exercises the dependency, require a success status, and fail the member when that path fails even if TCP still completes.

The reason for that specificity is a failure I have seen: TCP checks stayed green while the app returned 503. The pool served errors for 14 minutes to 9,400 requests; the balancer never marked a member down.

Open port, failing handler.

Check	Result	Requests served 503	Minutes
TCP 443	up	9,400	14
HTTP GET /health	503	—	14
members marked down	0	—	14

I would not consider it settled without evidence: fail the application handler with the port still open and require the member to be removed.

SYN-ACK is not an application response.

This is an area where a green session and a working path are different observations.

Liveness means the process should be restarted. Readiness means it should receive traffic. Using liveness for a busy or slow-but-alive process causes kill-restart loops and 502s.

Concretely, point liveness at a cheap alive check, point readiness at dependency-complete, and never kill a process for being overloaded if the fix is to stop sending it work.

The reason for that specificity is a failure I have seen: A slow handler tripped liveness. 3,200 requests returned 502 over 9 minutes while pods restarted; readiness had been passing until the kill.

Wrong probe kills a live worker.

Probe	Should do	Did	502s	Minutes
liveness	restart if dead	killed slow pods	3,200	9
readiness	stop traffic	still passing until kill	—	9

I would not consider it settled without evidence: induce slowness without deadlock and require readiness to drop while liveness stays passing.

Not ready is not dead.

My answer to retry amplification begins with which plane is making the decision: control, forwarding, or policy.

Independent attempts multiply. Three total attempts at each of three layers can produce 3 × 3 × 3 = 27 downstream attempts, which turns a timeout into a self-DDoS. If "three retries" means three retries after the initial try, the corresponding maximum is 4³ = 64.

Concretely, budget attempts end to end, define whether a count includes the initial attempt, use idempotency keys, and fail fast on a known-bad member rather than stacking timeouts.

The reason for that specificity is a failure I have seen: A 1-second dependency timeout with up to 3 total attempts at each of 3 layers produced 27 attempts per click. The dependency's 8-minute brownout ran at 27× offered load and took a second pool with it.

One click, three layers.

Layer	Total attempts per layer	Downstream attempts per click	Offered load vs baseline	Minutes
edge	3	3	—	8
mid	3	9	—	8
data	3	27	27×	8

I would not consider it settled without evidence: count attempts per user request at each layer during a fault injection and require the product to stay inside a stated budget.

Retries are load.

I would treat graceful drain as a claim about a specific five-tuple, VRF, and direction.

A hard remove resets or black-holes existing connections. Graceful drain stops new work, waits for in-flight requests, then removes the member. Connection count at pull time is the blast radius.

Concretely, enable connection draining with a timeout greater than the longest in-flight request, and refuse changes that set the member down with a non-zero connection count.

The reason for that specificity is a failure I have seen: A member was set down with 940 connections and 0 drain. Clients saw 940 RSTs over 4 minutes; in-flight checkouts rolled back.

Hard pull versus drain.

Method	Open connections at change	RSTs	Minutes
hard down	940	940	4
drain then down	940 then 0	0	—

I would not consider it settled without evidence: remove a member under load and require in-flight requests to finish or be handed off, not RST.

Down is not drain.

The useful question for Forwarded header trust is what a hash-diverse probe would show on the other members.

Forwarded and X-Forwarded-For are hop-by-hop claims. Only a trusted proxy should be allowed to set them; an edge that appends without stripping attacker values lets the attacker pick the client identity.

Concretely, strip or overwrite incoming Forwarded headers at the first trusted proxy, append the true socket IP, and ignore those headers from untrusted sources.

The reason for that specificity is a failure I have seen: The edge appended without stripping. 1 spoofed X-Forwarded-For value passed 6,100 admin-panel requests as an internal IP over 2 days.

Forged client identity.

Header handling	Admin requests as internal IP	Days
append without strip	6,100	2
strip then append socket IP	0	—

I would not consider it settled without evidence: send a request with a forged X-Forwarded-For from the internet and require the app to see the real socket address.

A header is not a source address.

I would settle sticky sessions by capturing both sides of the encapsulation, not by reading the neighbour table.

Stickiness pins a client to a member. If that member is gone and the cookie is still honoured, the client is pinned to a hole until the cookie expires or the balancer fails over.

Concretely, fail sticky when the member is down, keep a shared session store, and treat stickiness as a cache, not as a hard location.

The reason for that specificity is a failure I have seen: Cookie stickiness kept 28 percent of clients on a dead member for 20 minutes. New clients hashed to live members; returning clients got errors.

Dead member, live cookie.

Client class	Share	Outcome	Minutes
new	72 percent	live member	20
returning sticky	28 percent	dead member	20

I would not consider it settled without evidence: kill a member and require sticky clients to be remapped before the cookie TTL.

A sticky cookie can outlive the member.

The judgement in DNS TTL is not a global flush is which state the packet uses, not which state the operator intended.

TTL is the maximum cache reuse interval for resolvers that fetched the previous answer. It is not a push flush. Resolvers that cached at the old TTL 3600 keep the old answer until that remaining lifetime elapses.

Concretely, lower TTL well before the change, wait the previous TTL, then cut over, and measure remaining cache with diverse resolvers rather than with a local lookup.

The reason for that specificity is a failure I have seen: The cutover happened immediately after setting TTL 3600 to 60. Caches that had 47 minutes remaining on the old 3600-second answer kept the old IP; 41 percent of queries missed the new address for that remaining window.

Cutover without waiting out the old TTL.

Resolver class	Remaining cache	Queries on old IP	Window
cold after TTL 60	0	0 percent	—
cached at TTL 3600	up to 47 minutes	41 percent	47 minutes

I would not consider it settled without evidence: query resolvers that cached before the TTL change and record remaining lifetime, not only a recursive lookup from a cold cache.

TTL is cache reuse, not a global flush.

Where candidates lose the interview on negative DNS cache is calling the tunnel or the BGP session the path.

Negative answers are cached for the smaller of the SOA MINIMUM field and the SOA record's TTL, not the new record's positive TTL. Creating the record does not erase remote negative cache.

Concretely, keep negative TTL short on zones you edit live, and wait out the SOA negative cache or use a different name rather than expecting instant presence.

The reason for that specificity is a failure I have seen: SOA negative TTL was 1800 seconds. After creating the A record, 18 minutes of remaining negative cache served NXDOMAIN to 1,200 clients; the authoritative server already had the record.

Positive record, leftover negative cache.

Source	Answer	Clients	Remaining negative TTL
authoritative	A record	—	—
recursive that cached NXDOMAIN	NXDOMAIN	1,200	18 minutes of an 1800-second cache

I would not consider it settled without evidence: query a resolver that received NXDOMAIN before the create and require it to keep NXDOMAIN until its negative TTL, matching the SOA.

NXDOMAIN is cached too.

I would answer recursive versus authoritative by separating reachability, policy, and observed delivery.

Authoritative servers answer from zone data. Recursive resolvers answer from cache. Debugging the wrong one "fixes" nothing. Stub clients rarely query authority directly.

Concretely, query the authoritative name servers by address, then the recursive the client actually uses, and compare TTLs; fix the recursive cache or wait, not the zone that is already right.

The reason for that specificity is a failure I have seen: Operators edited the zone three times in 11 hours because a corporate recursive still held 2 stale answers. Authority had been correct after the first edit.

Authority right, recursion stale.

Server	Answer	Stale records	Hours of extra edits
authoritative NS	new	0	0 after first edit
corporate recursive	old	2	11

I would not consider it settled without evidence: dig the record at NS addresses and at the client's resolver and require the two answers to be labelled as such.

Fix the cache that answered the client.

The engineering content of lame delegation is the return path and the more-specific prefix, not the protocol name.

A lame delegation is an NS set that names servers which refuse or are not authoritative for the zone. Resolvers then SERVFAIL or serve stale, and the parent looking "correct" in whois is not a working delegation.

Concretely, query each parent-listed NS for the child SOA with AA bit set, and replace any that do not answer as authority.

The reason for that specificity is a failure I have seen: One of two NS hosts was a web box not running DNS. 35 percent of queries hit SERVFAIL for 3 days depending on which NS the resolver tried first.

One lame NS in a set of two.

NS	AA SOA	Queries that SERVFAIL	Days
ns1	yes	0 percent when chosen	3
ns2 (web host)	no	35 percent overall	3

I would not consider it settled without evidence: require AA SOA from every NS in the parent delegation.

An NS name is not a running authority.

Before calling CNAME coexistence done I would write down the ECMP member, VLAN, or VRF nobody hashed onto.

A CNAME cannot coexist with A, MX, NS, or other ordinary data at the same owner name; DNSSEC proof and signature records are the narrow exception. The CNAME says the name is an alias, so pairing it with address or service data creates an inconsistent zone that conforming authorities must reject.

Concretely, put the CNAME on a name that has no other records, or use ALIAS/ANAME at the apex only if the product is explicit, and never pair CNAME with A at the same owner.

The reason for that specificity is a failure I have seen: Apex CNAME plus A was loaded on 1 of 3 nameservers and rejected on 2. Resolvers saw a mix for 2 hours; 1 of 3 authorities answered CNAME, the others kept the A.

Split authorities after an illegal pair.

Authority	Loaded	Answer	Hours
1	CNAME+A accepted	CNAME	2
2	rejected	old A	2
3	rejected	old A	2

I would not consider it settled without evidence: load the zone on every authority and require either CNAME-only or A-only at that owner.

CNAME occupies the owner.

The first thing I would establish about DNSSEC versus DoH is which forwarding entry the packet actually hits.

DoH encrypts the stub-to-resolver channel. DNSSEC authenticates zone data with signatures and a chain to a trust anchor. DoH without DNSSEC still accepts a lying resolver; DNSSEC without DoH is visible on the path but authenticable.

Concretely, validate DNSSEC at a resolver you control, and treat DoH as privacy of the query path, not as origin authentication.

The reason for that specificity is a failure I have seen: A team enabled DoH and skipped DS records. For 9 days the zone had 0 DNSSEC authentication; the selected DoH resolver could still return injected answers over its encrypted channel.

Encrypted channel, unsigned zone.

Control	Present	Days	Injected answers possible
DoH to the resolver	yes	9	yes, by that resolver
DS at parent	no	9	—
AD bit on answers	no	9	—

I would not consider it settled without evidence: check DS at the parent and AD bit on a validating resolver, separately from whether the stub used DoH.

DoH hides the path; DNSSEC proves the data.

I would start DHCP reservation is not authentication from the packet and the return path, not from the protocol adjacency.

A reservation is a DHCP server policy to offer that address to that chaddr. It is not 802.1X, not DHCP snooping binding enforcement by itself, and not a check that the MAC is authentic. MAC addresses are spoofable.

Concretely, bind DHCP snooping and port security or 802.1X if the address must be exclusive, and treat reservations as convenience, not as access control.

The reason for that specificity is a failure I have seen: A spoofed MAC obtained the reserved 10.20.20.8. The legitimate printer was offline for 40 minutes; the server log showed a normal ACK to the reservation.

Reservation honoured for a spoof.

Client	MAC	Address	Minutes printer offline
printer	real	none, offline	40
laptop	spoofed	10.20.20.8 ACK	40

I would not consider it settled without evidence: spoof the reserved MAC from a second port and require the offer to be denied unless port-level control is in place.

A reservation is an offer policy.

This is an area where a green session and a working path are different observations.

DORA is Discover, Offer, Request, Ack. A relay sets giaddr so the server can select the relayed subnet. Option 82 can additionally identify the access circuit or remote device when clients sharing that subnet need circuit-specific policy; it is not a substitute for a correct giaddr.

Concretely, set giaddr to the client-facing relayed subnet, insert trusted option 82 circuit-id or remote-id when circuit-specific policy is required, and match that policy without accepting forged option 82 from clients.

The reason for that specificity is a failure I have seen: Two access circuits used the same giaddr and required different gateway policy, but the trusted relays omitted option 82. For 2 hours, 1,100 clients on the second circuit received the first circuit's policy even though DORA completed successfully.

Two circuits, one relayed subnet, no option 82.

Building	Option 82	Clients with wrong gateway	Hours
1	absent	0	2
2	absent	1,100	2

I would not consider it settled without evidence: capture Discover at the server and require option 82 plus a giaddr that maps to one scope.

A completed DORA can still be the wrong subnet.

My answer to IPv6 RA versus DHCPv6 gateway begins with which plane is making the decision: control, forwarding, or policy.

IPv6 default routers come from Router Advertisements, not from DHCPv6. DHCPv6 can assign addresses and options; it does not replace RA for on-link routers. RA is ICMPv6 from the router, not a DHCPv6 message.

Concretely, send RAs with the intended prefix and router lifetime, use DHCPv6 if you need extra options, and never expect a default route from DHCPv6 alone.

The reason for that specificity is a failure I have seen: DHCPv6 assigned addresses with 0 default routes because RA was disabled. Dual-stack hosts sat with IPv6 addresses and no gateway for 26 minutes; IPv4 kept working.

Address without a router.

Source	IPv6 address	Default route	Minutes
DHCPv6 only	yes	0	26
RA enabled	yes	1	—

I would not consider it settled without evidence: show a host's IPv6 route table after DHCPv6-only and require a default only after RA.

DHCPv6 is not the IPv6 default-gateway protocol.

I would treat dual-stack Happy Eyeballs IPv6 black hole as a claim about a specific five-tuple, VRF, and direction.

Happy Eyeballs gives IPv6 an initial preference but races a later IPv4 attempt after a short connection-attempt delay; it should not wait for the IPv6 connect timeout before trying working IPv4. A broken or disabled fallback implementation can still turn an IPv6 black hole into user-visible delay or failure.

Concretely, do not publish AAAA until the IPv6 path forwards, and test that real clients launch and complete the IPv4 fallback within the configured Happy Eyeballs delay when IPv6 is silently filtered.

The reason for that specificity is a failure I have seen: AAAA returned 200 ms faster than A and IPv6 was filtered. A client implementation with IPv4 fallback disabled waited for the IPv6 connect timeout and failed 100 percent of new sessions for 7 minutes despite healthy IPv4.

Faster AAAA into a hole.

Record	Resolve time	Path	New sessions	Minutes
AAAA	200 ms faster than A	black hole	0 percent success	7
A	slower	working	fallback disabled	7

I would not consider it settled without evidence: publish AAAA toward a filtered path in a lab and require the client either to fail over within the Happy Eyeballs timer or not to receive the AAAA.

A published AAAA is a promise of a working IPv6 path.

The useful question for incomplete ARP is what a hash-diverse probe would show on the other members.

ARP incomplete means no neighbour Ethernet address is known. The router cannot build an L2 rewrite and drops or queues the packet. IP reachability of a prefix does not populate ARP; a reply to who-has does.

Concretely, capture ARP request and reply on the VLAN, fix L2 connectivity or filtering, and refuse to troubleshoot IGP until the adjacency MAC exists.

The reason for that specificity is a failure I have seen: 1,024 incomplete entries sat behind a VLAN ACL that dropped ARP. Packets to those next hops dropped for 15 minutes while ICMP to the router's own interface address still worked.

Incomplete neighbour table.

ARP state	Entries	Forwarded to those next hops	Minutes
incomplete	1,024	0	15
ICMP to router interface	—	yes	15

I would not consider it settled without evidence: require a complete ARP entry with a MAC before blaming the routing protocol.

No MAC, no rewrite.

I would settle NDP versus ARP by capturing both sides of the encapsulation, not by reading the neighbour table.

NDP uses ICMPv6 neighbour solicitation and advertisement, multicast to solicited-node groups, and router advertisements. It is not ARP with a different name; filters that allow ARP ethertype 0x0806 can still drop ICMPv6 type 135/136.

Concretely, permit ICMPv6 NS/NA and RA on the segment, and diagnose IPv6 neighbour with ndp tables, not with arp -a.

The reason for that specificity is a failure I have seen: A VLAN ACL allowed ARP and dropped ICMPv6 NS. IPv4 forwarded; 44 percent of dual-stack sessions failed IPv6 neighbour for 1 hour 10 minutes.

ARP allowed, NS dropped.

Protocol	Adjacency	Dual-stack sessions failing IPv6	Duration
IPv4 ARP	complete	—	1 hour 10 minutes
IPv6 NS/NA	filtered	44 percent	1 hour 10 minutes

I would not consider it settled without evidence: capture NS/NA and require them, not ARP, for IPv6 adjacency.

IPv6 neighbours are ICMPv6, not ARP.

The judgement in PMTUD black hole is which state the packet uses, not which state the operator intended.

PMTUD relies on ICMP type 3 code 4 (or IPv6 packet too big) to shrink the path MTU. Without that signal, 1500-byte DF packets drop at the 1400 hop and never retry smaller.

Concretely, permit the needed ICMP, clamp MSS, or raise MTU, and test with DF set at 1500.

The reason for that specificity is a failure I have seen: A GRE hop of 1400 with filtered ICMP 3/4 black-holed 1500-byte DF packets for 4 hours. Small packets and traceroute (often smaller) succeeded.

DF 1500 into MTU 1400 without ICMP.

Packet	DF	Forwarded	Hours
1400	yes	yes	4
1500	yes	no	4
ICMP 3/4 returned	—	0	4

I would not consider it settled without evidence: send DF 1500 and DF 1400; require 1500 to fail and ICMP 3/4 to be visible, or MSS clamped.

PMTUD is an ICMP protocol, not magic.

Where candidates lose the interview on filtering ICMP is calling the tunnel or the BGP session the path.

Echo is a convenience. Destination unreachable, packet too big, and time exceeded are control messages for fragmentation, PMTUD, and traceroute. Filtering "ICMP except ping" breaks those.

Concretely, allow the ICMP types the path needs, rate-limit rather than blanket-deny, and test large DF packets and traceroute after the ACL.

The reason for that specificity is a failure I have seen: Echo was allowed; dest-unreach was dropped. 19 percent of large transfers failed for 6 hours while ping stayed green.

Echo versus dest-unreach.

ICMP	ACL	Large transfer loss	Hours
echo	allow	—	6
dest-unreach	deny	19 percent	6

I would not consider it settled without evidence: block dest-unreach in a lab and require large DF transfers to fail even as echo succeeds.

Ping is not the ICMP you needed.

I would answer incomplete TCP handshake by separating reachability, policy, and observed delivery.

A missing SYN-ACK is either the SYN not arriving, the listener not answering, or the SYN-ACK not returning. One capture on the client cannot distinguish those. You need both ends and the middle.

Concretely, capture at client, at server, and at the stateful midpoint, and classify by where the SYN is last seen and whether a SYN-ACK is generated.

The reason for that specificity is a failure I have seen: Client captures showed 8,400 embryonic SYNs. The server had generated SYN-ACKs that a return ACL dropped. The ticket stayed on "application down" for 21 minutes.

SYNs without completing handshake.

Location	SYNs	SYN-ACKs	Minutes misdiagnosed
client	8,400	0	21
server	8,400	8,400	21
return ACL	—	0 passed	21

I would not consider it settled without evidence: show the SYN-ACK leaving the server and dying on the return ACL, or show the SYN never arriving.

Embryonic on one side is not a closed listener.

The engineering content of TCP RST provenance is the return path and the more-specific prefix, not the protocol name.

A RST can come from the server, from a middlebox, or from an old stack sending on a closed 4-tuple. Sequence validity, TTL/hop-limit evidence, and captures at multiple points can localize it; a TTL alone does not prove the sender. Blaming the server process without a capture is a guess.

Concretely, compare sequence validity and captures before and after each suspected middlebox, using TTL only as supporting evidence; a RST absent at the server-side capture but present downstream was injected on that segment.

The reason for that specificity is a failure I have seen: A middlebox injected 2,200 RSTs over 16 minutes. Server logs showed accepted handshakes; the app team was paged for a crash that did not occur.

Injected RSTs.

Claimed sender	RSTs captured	Server crash logs	Minutes
application	2,200 at client	0	16
middlebox (TTL too high)	2,200	—	16

I would not consider it settled without evidence: capture the RST at two points and require its first appearance and sequence validity to match the claimed sender.

A RST has a source; name it.

Before calling TSO/GSO capture illusion done I would write down the ECMP member, VLAN, or VRF nobody hashed onto.

TCP segmentation offload and GSO let the stack hand large buffers to the NIC, which segments them. A capture before segmentation shows huge segments that never existed on the Ethernet. Jumbo is a different configuration.

Concretely, capture after the NIC or on a TAP, or disable TSO on the capture host, before concluding jumbo or MSS failure.

The reason for that specificity is a failure I have seen: A 64 KB capture led to a 3-hour jumbo hunt. On-wire frames were 1,460-byte payload; 0 jumbo frames existed.

Two capture points, one flow.

Point	Segment size	Jumbo frames	Hours of wrong hunt
before TSO	64 KB	n/a	3
TAP	1,460-byte payload	0	3

I would not consider it settled without evidence: compare host capture size with TAP capture size for the same flow.

TSO is a host buffer, not a wire frame.

The first thing I would establish about traceroute caveats is which forwarding entry the packet actually hits.

Classic traceroute sends UDP to high ports or ICMP echo with incrementing TTL. Firewalls treat that unlike the application's TCP/TLS path. Missing hops are often filtered TTL-exceeded, not a forwarding hole.

Concretely, use TCP traceroute to the application port, compare with a working transaction, and do not change routing because UDP 33434 was dropped.

The reason for that specificity is a failure I have seen: UDP traceroute to 33434 was blocked at hop 6. The HTTP path of 6 hops worked. A 90-minute routing change was proposed for a filter that was working as designed.

UDP 33434 versus TCP 443.

Probe	Hops shown	Application	Minutes of proposed change
UDP 33434	dies at 6	not HTTP	90
TCP 443	6 working	success	0 needed

I would not consider it settled without evidence: run traceroute with the application's protocol and port and require agreement with a successful transaction capture.

Traceroute is not the application five-tuple.

I would start one retransmission is not a location from the packet and the return path, not from the protocol adjacency.

A retransmission says a segment was not ACKed in time. It does not name the hop. Loss could be anywhere on the forward or reverse path, or be delay that was not loss.

Concretely, sample loss with captures at multiple points or with instrumented hops, and refuse a "the problem is hop 3" conclusion from one retransmit counter.

The reason for that specificity is a failure I have seen: One retransmission on a 40 ms path was blamed on the WAN. Three possible hops were later instrumented; the drop was the access switch buffer for 90 minutes of wrong WAN tickets.

One loss, three suspects.

Hop blamed first	Drops actually counted	Minutes of WAN tickets
WAN	0	90
access switch buffer	the loss	90
other two hops	0	90

I would not consider it settled without evidence: place counters or captures on each candidate hop during the loss and require the drop to increment in one place.

A retransmit is a symptom, not a coordinate.

This is an area where a green session and a working path are different observations.

TLS Server Name Indication tells the terminator which certificate to present. Connecting by IP omits SNI or sends a mismatch, so you get the default cert, which will not match the name you intended.

Concretely, connect with the hostname in SNI, and do not validate a service by IP unless that IP has its own cert.

The reason for that specificity is a failure I have seen: Health checks used the IP. 12 name-based hosts presented the default cert; checks failed for 1 hour even though clients using SNI succeeded.

Default cert without SNI.

Handshake	Hosts	Cert	Hours of failed IP checks
no SNI (by IP)	12	default	1
SNI = hostname	12	matching	0 client impact

I would not consider it settled without evidence: compare a handshake with SNI to one without and require different certificates where vhosts differ.

The IP is not the name the cert binds.

My answer to interface UP is not carrier begins with which plane is making the decision: control, forwarding, or policy.

Admin up is the configured desire. Carrier/line protocol is photons or a negotiated link. Protocol up/up is still not proof of the intended VLAN or IPv6 ND. Empty pps with no optics is a physical or negotiation fault.

Concretely, read optics, line protocol, and speed/duplex, then pps, and do not start IGP debug on an interface with no carrier.

The reason for that specificity is a failure I have seen: A shutdown was removed but the SFP sat unseated. The interface stayed admin up, protocol down, 0 pps for 25 minutes while OSPF was restarted twice.

Admin up, no photons.

State	Value	Minutes of OSPF restarts
admin	up	25
line protocol	down	25
pps	0	25
OSPF restarts	2	25

I would not consider it settled without evidence: require carrier and non-zero light levels before protocol debug.

Admin up is a command, not a link.

I would treat bidirectional path mapping as a claim about a specific five-tuple, VRF, and direction.

Forward and return paths can differ. A filter, NAT, or firewall on the return path drops the response while the forward traceroute looks clean. Mapping one direction is half a path.

Concretely, trace or capture both directions, include the stateful midpoint, and treat one-way success as a return-path incident until proven otherwise.

The reason for that specificity is a failure I have seen: Forward ACL allowed the app; return ACL dropped it. 100 percent of sessions failed one-way for 16 minutes; forward traceroute was clean.

Clean forward, dead return.

Direction	Traceroute	Application packets	Minutes
forward	success	SYN arrives	16
return	not mapped	100 percent drop	16

I would not consider it settled without evidence: capture the response leaving the server and not arriving at the client, and name the return hop that counters it.

A path has two directions.

The useful question for TCP flow control versus congestion control is what a hash-diverse probe would show on the other members.

Flow control is the receiver's window. Congestion control is the sender's cwnd from loss or ECN. A tiny window is an application or socket issue, not WAN congestion.

Concretely, read rwnd and cwnd from a capture, and only tune the path when cwnd is the limiter.

The reason for that specificity is a failure I have seen: A 40 ms RTT path was blamed for roughly 0.6 Mbps throughput. rwnd was 2 × 1460-byte segments; cwnd never collapsed. The advertised receive window was about 2.9 KB for 2 hours of WAN tickets.

Window versus cwnd.

Signal	Value	WAN tickets	Hours
rwnd	2 segments	opened	2
cwnd	large	—	2
throughput	~0.6 Mbps	—	2
RTT	40 ms	blamed	2

I would not consider it settled without evidence: require a capture that shows whether rwnd or cwnd is the min.

A closed window is not a congested path.

I would settle UDP application semantics by capturing both sides of the encapsulation, not by reading the neighbour table.

UDP has no transport retry. ICMP unreach is a hint the stack may surface. If the application ignores it, the user sees silence. That is application semantics, not a missing TCP feature on the router.

Concretely, document whether the app retries, and do not "fix UDP" in the network when the payload protocol has no retransmission.

The reason for that specificity is a failure I have seen: A syslog over UDP was sent once. ICMP unreach from a closed port was ignored. Operators spent 22 minutes looking for packet loss that was a closed collector and 0 app retries.

One datagram, no retry.

Event	Count	Minutes of loss hunt
UDP datagrams sent	1	22
ICMP unreach received	1	22
application retries	0	22

I would not consider it settled without evidence: show the ICMP unreach at the sender and 0 retransmission from the application.

UDP will not save an application that does not retry.

The judgement in NAT mapping expiry is which state the packet uses, not which state the operator intended.

A NAT mapping exists only while traffic refreshes it. If the idle timer is shorter than the keepalive, the mapping dies and return traffic hits a foreign 5-tuple.

Concretely, set idle timers longer than keepalives, or send keepalives inside the timer, and test after silence longer than the timer.

The reason for that specificity is a failure I have seen: 30-second UDP mappings met 45-second keepalives. 1,800 flows per hour dropped after silence; the VPN looked up while voice media died.

Keepalive longer than idle.

Timer	Value	Drops per hour
NAT UDP idle	30 s	1,800
keepalive	45 s	1,800

I would not consider it settled without evidence: silence a UDP flow for longer than the NAT timer and require the mapping to be gone, then fix the timer.

The mapping timer is the session.

Where candidates lose the interview on anycast TCP state is calling the tunnel or the BGP session the path.

Anycast shares an address, not a TCP table. A mid-flow move to another PoP meets a stack with no TCB and typically a RST. Long TCP therefore needs route stability, flow pinning, shared state, or an explicit reset budget.

Concretely, pin a TCP flow to one PoP with ECMP stability or use a connection-aware front, and do not announce anycast from PoPs that cannot share state.

The reason for that specificity is a failure I have seen: Two PoPs advertised the same VIP. 14 percent of long TCP flows moved after a routing change and were RST for 6 minutes.

Mid-flow PoP move.

PoPs	Flows that moved	Result	Minutes
2 anycast	14 percent	RST	6

I would not consider it settled without evidence: change IGP cost so a flow's next hop moves and require either pinning or an accepted reset budget.

Anycast is an address, not a shared TCB.

I would answer DNS steering cache by separating reachability, policy, and observed delivery.

Geo-DNS steering is cached like any A/AAAA. Draining a PoP in the geo map does not evict caches. Remaining TTL is the drain tail.

Concretely, lower TTL before drain, wait the old TTL, then withdraw, and measure application requests still arriving at the drained PoP.

The reason for that specificity is a failure I have seen: PoP drain was immediate with TTL 3600. After 8 minutes, 36 percent of application requests still arrived at the drained PoP because clients retained cached steering answers.

Drain versus TTL 3600.

Time after geo change	Application requests still at drained PoP
8 minutes	36 percent
designed wait of 3600 s	near 0

I would not consider it settled without evidence: count application requests at the drained PoP versus time since the geo change and match the remaining TTL curve.

Steering is DNS cache, not an instant map.

The engineering content of TLS termination at a load balancer is the return path and the more-specific prefix, not the protocol name.

TLS terminated at the balancer decrypts there. The backend hop is whatever you configured: cleartext HTTP, or a new TLS session. Users seeing a padlock have not encrypted the backend hop.

Concretely, encrypt the backend if that hop is untrusted, and inventory hop-by-hop TLS rather than quoting the browser padlock.

The reason for that specificity is a failure I have seen: The balancer terminated TLS and forwarded HTTP. 2.4 GB of backend cleartext crossed 5 hops of a shared VLAN for 3 days.

Browser TLS, backend HTTP.

Hop	Encrypted	Bytes captured	Days
client to LB	TLS	—	3
LB to backend	HTTP	2.4 GB	3
L2 hops on that VLAN	5	—	3

I would not consider it settled without evidence: capture behind the balancer and require TLS or an isolated segment.

The padlock stops at the terminator.

Before calling circuit breaker done I would write down the ECMP member, VLAN, or VRF nobody hashed onto.

A circuit breaker stops sending when error rate crosses a threshold, then probes half-open. Without it, retries and timeouts pile onto a dead dependency.

Concretely, open on a measured error ratio, cap half-open probes, and apply it per dependency, not per process.

The reason for that specificity is a failure I have seen: No breaker opened. 100 percent of traffic hit a dead pool for 11 minutes; timeouts occupied every worker.

No open state.

Breaker	Traffic to dead pool	Minutes	Workers blocked on timeout
never opens	100 percent	11	all
opens at 50 percent errors	probe only	—	few

I would not consider it settled without evidence: fail a dependency and require sending to drop to probe rate, not stay at 100 percent.

A closed breaker on a dead pool is a flood.

The first thing I would establish about unbounded proxy queue is which forwarding entry the packet actually hits.

An unbounded queue trades drop for latency. Requests sit until they are stale, then fail anyway, after occupying memory. A bounded queue with 503 is a faster signal.

Concretely, cap queue depth and time, reject overflow, and alert on queue age, not only on CPU.

The reason for that specificity is a failure I have seen: The queue hit 48,000. p99 rose to 9 seconds with 0 rejects for 13 minutes, then clients timed out anyway.

Queue instead of 503.

Queue depth	p99	Rejects	Minutes
48,000	9 s	0	13
bounded 2,000	200 ms	overflow 503	—

I would not consider it settled without evidence: load past capacity and require either a bound with rejects or a stated latency budget that was met.

Infinite queue is delayed failure.

I would start consistent hashing hot key from the packet and the return path, not from the protocol adjacency.

Consistent hashing maps a key to a node. A hot key is not spread by adding nodes unless you shard the key. The node that owns it takes that share plus its fair keys.

Concretely, split hot keys, add a local cache, or use bounded loads, and measure per-key rate before scaling the ring.

The reason for that specificity is a failure I have seen: One key was 38 percent of requests. That node ran at 91 percent CPU for 17 minutes while 11 others sat near 20 percent.

Hot key on a 12-node ring.

Nodes	Hottest key share	That node's CPU	Minutes
12	38 percent	91 percent	17
other 11	remainder	~20 percent	17

I would not consider it settled without evidence: rank keys by rate and require the hottest key's node utilisation to be explained by that key.

The ring does not shard a single key.

This is an area where a green session and a working path are different observations.

GRE adds a header. Anyone who can see the underlay packet can see the inner IP unless a crypto transform is applied. Isolation of VNI or VRF at the edge does not encrypt the underlay.

Concretely, add IPsec or equivalent, and treat GRE as topology, not as a confidentiality boundary.

The reason for that specificity is a failure I have seen: GRE-only tenant links leaked 880 MB of inner traffic to a SPAN on the underlay for 1 afternoon; VRFs at the PE stayed correctly separated.

VRF correct, underlay readable.

Plane	Isolated	Inner bytes on SPAN	Duration
PE VRF	yes	—	1 afternoon
GRE underlay	no crypto	880 MB	1 afternoon

I would not consider it settled without evidence: SPAN the underlay and require inner payloads to be unreadable.

GRE is a pipe, not a vault.

My answer to VXLAN is not confidential begins with which plane is making the decision: control, forwarding, or policy.

VXLAN identifies a VNI; it does not encrypt. A VTEP or tap that receives the UDP packet can parse the inner frame. Confidentiality needs crypto (MACSec, IPsec, or encrypted overlays), plus control-plane auth.

Concretely, restrict who can be a VTEP, encrypt the underlay, and do not quote VNI as encryption.

The reason for that specificity is a failure I have seen: VNI 10010 was visible to 3 tenants' debug taps on a shared underlay with 0 IPsec for 5 days.

Shared underlay, tagged only.

VNI	IPsec	Tenants that could read inner	Days
10010	0	3	5

I would not consider it settled without evidence: decap a captured VXLAN packet without keys and require the inner Ethernet to be readable unless crypto is present.

A VNI is a tag.

I would treat route-based versus policy-based VPN as a claim about a specific five-tuple, VRF, and direction.

Policy-based VPN encrypts what the ACL/selector lists. Route-based VPN encrypts what is routed into a tunnel interface. A missed ACL entry is cleartext or unrouted, while the SA for other prefixes stays up.

Concretely, prefer a tunnel interface with routes for changing prefixes, and audit selectors when policy-based is required.

The reason for that specificity is a failure I have seen: PBR/ACL missed 17 prefixes. Those flows left in the clear for 3 hours; the SA for the listed prefixes stayed up.

Missed ACL entries.

Prefixes	In selector	Path	Hours
intended set	yes	encrypted	3
17 missed	no	clear default	3

I would not consider it settled without evidence: traceroute a prefix that should be encrypted and require the next hop to be the tunnel, not the clear default.

Selectors are a static list; a tunnel interface follows the RIB.

The useful question for overlapping RFC1918 is what a hash-diverse probe would show on the other members.

Overlapping RFC1918 means the same address is two different hosts. Without NAT or re-addressing, selectors and return routes cannot name a unique endpoint.

Concretely, nAT one or both sides to unique ranges, or renumber, and put the translated prefixes in the selectors.

The reason for that specificity is a failure I have seen: Both campuses used 10.0.0.0/8. 64 connections hit the local host instead of the remote for 2 hours; the SA was up.

Two 10/8s, one SA.

Side	Prefix	Connections to local-by-mistake	Hours
A	10.0.0.0/8	included in 64	2
B	10.0.0.0/8	included in 64	2
SA	up	0 unique remote	2

I would not consider it settled without evidence: show a destination 10.1.1.1 routing to the tunnel translated prefix, not to the local LAN.

The same 10/8 is not a unique locator.

I would settle L3VPN route distinguisher versus route target by capturing both sides of the encapsulation, not by reading the neighbour table.

The route distinguisher combines with an IPv4 prefix to form the VPN-IPv4 NLRI. Reusing the same RD for the same overlapping IPv4 prefix makes those routes the same NLRI, so BGP path selection can hide one; different IPv4 prefixes do not collide merely because the RD matches. The route target is the import/export community that selects VRFs, so different RTs still mean no import.

Concretely, use unique RDs per VRF (or per PE+VRF), set RTs for the intended topology, and never treat RD as the import policy.

The reason for that specificity is a failure I have seen: Identical RDs collided two tenants' 10.0.0.0/24 in VPNv4. Different RTs meant 0 import into the other VRF, and the collision hid one prefix for 3 hours.

Same RD, different RT.

VRF	RD	RT import	10.0.0.0/24 visible	Hours
tenant A	65000:1	65000:10	yes, won collision	3
tenant B	65000:1	65000:20	hidden in VPNv4	3
cross import	—	none	0	3

I would not consider it settled without evidence: show VPNv4 for that RD and the import RT list, and require unique RD plus intended RT.

RD uniqueness is not RT policy.

The judgement in always-on VPN kill switch is which state the packet uses, not which state the operator intended.

A kill switch blocks traffic when the tunnel is down. Without it, always-on VPN fails open to the local default, which is a leak. Split tunnel already defined some leaks; this is the rest.

Concretely, enable fail-closed, test by killing IKE, and require 0 bytes on the physical default except the tunnel outer.

The reason for that specificity is a failure I have seen: IKE died. With no kill switch, 100 percent of user traffic leaked to the local LAN for 12 minutes while the client icon showed reconnecting.

Tunnel down, switch off.

Kill switch	Inner traffic on LAN	Minutes
off	100 percent	12
on	0	—

I would not consider it settled without evidence: kill the tunnel and capture the physical interface for inner destinations.

Always-on without fail-closed is sometimes-on.

Where candidates lose the interview on first-hop redundancy versus upstream routing is calling the tunnel or the BGP session the path.

First-hop redundancy shares a gateway address. Upstream routing on that master is separate. A master without a default still answers ARP and then drops.

Concretely, track the upstream default in VRRP, preempt to a master that can forward, and ping past the VIP, not only the VIP.

The reason for that specificity is a failure I have seen: The master had 0 default after an upstream BGP drop. Hosts ARPed the VIP successfully and black-holed for 7 minutes.

VIP up, default gone.

Object	State	Minutes of host black hole
VRRP master	elected	7
default route on master	0	7
ARP for VIP	success	7

I would not consider it settled without evidence: fail upstream on the master and require VIP ownership to move, or tracking to decrement priority.

Owning the VIP is not owning a default.

I would answer administrative distance versus longest match by separating reachability, policy, and observed delivery.

Longest match is first, so the /24 wins regardless of AD, and AD is compared only among same-prefix-length candidates.

Concretely, state the match length first, then AD among ties, and use a forwarding lookup to prove it rather than quoting AD as the reason the /16 lost.

The reason for that specificity is a failure I have seen: An operator deleted the BGP /24 because "OSPF AD is worse so it cannot be used," leaving the /16. Traffic followed the remaining /16 into a hole for 27 minutes.

Different lengths, AD is irrelevant.

Prefix	AD	Winner for 10.4.1.9	Minutes after /24 deleted
10.4.1.0/24 BGP	20	yes while present	—
10.0.0.0/16 OSPF	110	after deletion	27

I would not consider it settled without evidence: lookup 10.4.1.9 with both routes present and require the /24.

AD does not beat a longer prefix.

The engineering content of more-specific broken path beating default is the return path and the more-specific prefix, not the protocol name.

A more-specific that is still installed wins forever against a default. Withdrawal, tracking, or a worse AD on failure is required; otherwise the default never sees the packet.

Concretely, track the next hop, remove or degrade the /32 on failure, and test by failing the next hop.

The reason for that specificity is a failure I have seen: A /32 static stayed up with an unresolved next hop for 55 minutes. The default would have worked; 100 percent of that host's traffic died.

Stuck /32 versus healthy default.

Route	Next hop	Packets to the host	Minutes
host /32	unresolved	100 percent of them	55
0.0.0.0/0	healthy	0	55

I would not consider it settled without evidence: fail the /32 next hop and require either removal or a working tracked backup, not a stuck more-specific.

A dead more-specific beats a live default.

Before calling control-plane CPU done I would write down the ECMP member, VLAN, or VRF nobody hashed onto.

The forwarding plane can keep switching while the control plane starves. Hellos, BGP keepalives, and BFD then time out, which looks like a link failure. CoPP exists to protect that CPU.

Concretely, read control-plane CPU and CoPP drops separately from interface drops, and protect protocol traffic before adding more iBGP sessions.

The reason for that specificity is a failure I have seen: Data-plane drop stayed 0 percent. Control-plane CPU at 94 percent missed hellos; OSPF flapped for 20 minutes on otherwise clean links.

Data plane fine, hellos dying.

Plane	Drop or CPU	OSPF flaps	Minutes
forwarding	0 percent drop	—	20
control	94 percent CPU	yes	20

I would not consider it settled without evidence: show CoPP and process CPU during the flap and require interface error counters to stay flat.

Fast switching does not keep hellos alive.

The first thing I would establish about FIB/TCAM exhaustion is which forwarding entry the packet actually hits.

Hardware FIB/TCAM is finite. Prefixes that do not program punt or black-hole. Software RIB can still list them. Scale is a hardware number, not a protocol success.

Concretely, monitor RIB versus FIB counts, filter or summarize before the limit, and alarm before installation fails.

The reason for that specificity is a failure I have seen: 6,000 prefixes over a 512,000 TCAM limit were not programmed for 2 hours. Those destinations black-holed while BGP was Established with 518,000 in the RIB.

RIB larger than TCAM.

Table	Prefixes	Forwarded	Hours
RIB	518,000	—	2
TCAM limit	512,000	512,000	2
not programmed	6,000	0	2

I would not consider it settled without evidence: compare RIB and hardware FIB counts and require them equal for forwarded prefixes.

The TCAM size is the forwarding table.

I would start storm control versus a loop from the packet and the return path, not from the protocol adjacency.

Storm control rate-limits flood to protect uplinks. It does not break the loop. Frames still circulate; MAC tables still flap. STP or unplugging the loop is the cure.

Concretely, use storm control as a shock absorber, find the loop with MAC moves and disabled STP, and do not close the incident on a 1 percent drop rate.

The reason for that specificity is a failure I have seen: Storm control at 1 percent drop ran for 14 minutes on a loop with STP off. The VLAN stayed unhealthy; flood continued at the limiter.

Limited flood, loop intact.

Control	Drop	STP	Minutes still looping
storm control	1 percent	off	14
after STP enabled	—	blocking a port	0

I would not consider it settled without evidence: require STP blocking or a removed cable, not only storm-control drops, before closing.

A limiter is not a loop-free topology.

This is an area where a green session and a working path are different observations.

BPDU guard errdisables a port that receives a BPDU. It belongs on edge ports that should never see BPDUs. On an uplink it takes down the path the first time the upstream speaks STP.

Concretely, place BPDU guard only on PortFast/edge ports, use root guard toward untrusted switches, and test with a BPDU on an edge.

The reason for that specificity is a failure I have seen: BPDU guard on an uplink errdisabled the port for 9 minutes at the first hello from the core, isolating an IDF.

Guard on the wrong port.

Port	BPDU guard	Result	Minutes
uplink	on	errdisable	9
edge (correct)	on	errdisable on rogue	—

I would not consider it settled without evidence: send a BPDU to an edge port and require errdisable, and send one on an uplink and require normal STP processing without errdisable.

BPDU guard is an edge weapon.

My answer to PortFast on a trunk begins with which plane is making the decision: control, forwarding, or policy.

PortFast skips listening/learning on edges. On a switch-to-switch trunk it forwards immediately and can loop until STP blocks, which on a trunk is many VLANs of flood.

Concretely, enable PortFast only on true edges, keep trunks in normal STP, and use BPDU guard on those edges.

The reason for that specificity is a failure I have seen: PortFast on a trunk looped for 8 seconds across 2 VLANs before STP blocked; both VLANs stormed.

Trunk with PortFast.

Link	PortFast	Loop duration	VLANs stormed
switch trunk	yes	8 s	2

I would not consider it settled without evidence: require PortFast operational only on access edges, not on trunks to bridges.

PortFast assumes nothing behind the port bridges.

I would treat QoS classification versus marking as a claim about a specific five-tuple, VRF, and direction.

Classification selects a class. Marking writes the DSCP/CoS the next hop will see. Matching without marking leaves the original mark, often CS0 on the WAN.

Concretely, mark explicitly on ingress or at the WAN edge, and verify with a capture on the WAN, not with a class-map hit counter alone.

The reason for that specificity is a failure I have seen: Class-maps hit for 3 hours. WAN captures showed CS0 on 100 percent of those packets because no set-dscp was configured.

Matched, not marked.

Location	EF mark	Hours
class-map hits	counted	3
WAN DSCP	CS0 on 100 percent	3

I would not consider it settled without evidence: capture DSCP on the WAN for a known EF flow and require EF, not only a policy-map hit.

A class-map hit is not a DSCP on the wire.

The useful question for sampled NetFlow is what a hash-diverse probe would show on the other members.

Sampled NetFlow estimates. Short bursts smaller than the sampling chance can be invisible. It is not a packet-complete audit log.

Concretely, use packet capture or unsampled counters for the burst, and quote NetFlow as a sample with an error bar.

The reason for that specificity is a failure I have seen: A 3-second burst of 400 packets left 0 sampled flow records at random 1:1024 packet sampling, where only about 0.39 sampled packets were expected. The incident was closed as "no traffic" for 28 minutes.

Burst versus 1:1024.

Source	Packets in 3 s	Records	Minutes of "no traffic"
interface counters	400	—	28
random NetFlow 1:1024	expected ~0.39 sampled packets	0	28

I would not consider it settled without evidence: compare interface counters for the 3 seconds with NetFlow and require the counter, not the sample, as proof of absence.

A sample can miss a burst.

I would settle syslog versus packet truth by capturing both sides of the encapsulation, not by reading the neighbour table.

Syslog is a sampled, buffered, filtered management plane. ACL hit counters and captures are the forwarding record. Missing syslog is not a missing drop.

Concretely, read ACL counters and captures first, then syslog, and never close a deny with an empty log buffer.

The reason for that specificity is a failure I have seen: Logging was rate-limited to 0 visible denies. The TAP showed 12,000 ACL drops in 10 minutes; the change was thought to have no effect.

Silent syslog, busy TAP.

Source	Denies	Minutes
syslog	0	10
TAP / ACL counter	12,000	10

I would not consider it settled without evidence: compare ACL counters with syslog counts for the same rule.

The packet counter is the policy.

The judgement in change without rollback is which state the packet uses, not which state the operator intended.

A change without a known-good restore is a bet that the new ACL is perfect. Out-of-band or commit-rollback exists because the in-band path is what you just filtered.

Concretely, keep console or a confirmed commit, save the prior ACL, and test a session that would be denied before dropping the old permit.

The reason for that specificity is a failure I have seen: One ACL line blocked management. Restore from memory took 40 minutes because the only copy was on the now-unreachable SSH path.

Lockout without rollback.

Change	Rollback ready	Minutes to restore
one ACL line	no	40
same with confirmed commit	yes	auto

I would not consider it settled without evidence: require a rollback method that does not use the traffic you might deny.

The management path is in the packet filter.

Where candidates lose the interview on commit-confirmed is calling the tunnel or the BGP session the path.

Commit-confirmed applies the change and reverts unless a confirm arrives. It is the difference between a 10-minute automatic restore and a 2-hour drive to the console.

Concretely, use confirmed commit on remote boxes, set the timer longer than the test and shorter than the outage budget, and confirm only after forwarding checks.

The reason for that specificity is a failure I have seen: A bad static was committed without confirm. The site needed 2 hours to reach console. The same change with a 10-minute confirmed commit would have rolled back inside the timer.

Timer versus drive time.

Method	Restore	Hours or minutes
no confirm	console	2 hours
commit-confirmed	automatic	10 minutes

I would not consider it settled without evidence: fail to confirm in a lab and require the prior config to return at the timer.

Confirm is the rollback clock.

I would answer IPv4/IPv6 policy parity by separating reachability, policy, and observed delivery.

Address families are separate filters. Dual-stack hosts choose IPv6 under Happy Eyeballs. An IPv4-only ACL is not an IPv6 ACL. Parity is two policies, not a slogan.

Concretely, write matching IPv6 filters, tests, and logging, and probe with IPv6 as well as IPv4.

The reason for that specificity is a failure I have seen: IPv4 ACL blocked admin; IPv6 was open. 1,400 probes reached the service over IPv6 in 1 day.

IPv4 closed, IPv6 open.

Family	ACL	Probes in 1 day
IPv4	tight	0
IPv6	absent	1,400

I would not consider it settled without evidence: run the same test over AAAA and require the same deny or permit.

One family filtered is not the host filtered.

The engineering content of anycast DNS is the return path and the more-specific prefix, not the protocol name.

Anycast DNS steers by routing, not by a DNS health protocol. An unhealthy PoP that still announces the service address receives a share of clients who will SERVFAIL.

Concretely, withdraw the anycast prefix when local health fails, and monitor SERVFAIL per PoP, not only a global query success average.

The reason for that specificity is a failure I have seen: One of four PoPs stayed advertised while broken. 28 percent of clients hit SERVFAIL for 22 minutes; the global success average looked "mostly fine."

One sick PoP still announced.

PoPs	Unhealthy still advertised	Client SERVFAIL	Minutes
4	1	28 percent	22

I would not consider it settled without evidence: fail a PoP's nameserver and require its anycast prefix to be withdrawn from the routing domain.

Anycast advertisement is the health signal.

Before calling jumbo MTU mismatch done I would write down the ECMP member, VLAN, or VRF nobody hashed onto.

A jumbo sender toward a 1500 hop with DF set and no ICMP too-big black-holes large frames. NFS and other large UDP/TCP then fail while ping works.

Concretely, match MTU end to end, or clamp, and permit too-big; test with 9000-byte frames.

The reason for that specificity is a failure I have seen: NFS at jumbo met a 1500 hop. 33 percent of NFS ops failed for 4 hours; ICMP echo of 64 bytes succeeded.

9000 into 1500.

Frame	Forwarded	NFS ops failed	Hours
64-byte echo	yes	—	4
jumbo NFS	no	33 percent	4

I would not consider it settled without evidence: send 9000-byte DF frames and require either delivery or a too-big message.

Jumbo is a path property, not a NIC checkbox.

The first thing I would establish about SPAN oversubscription is which forwarding entry the packet actually hits.

SPAN is not lossless when the destination is slower than the source. Oversubscription drops span frames silently. The analyser then lies about loss on the production path.

Concretely, size the SPAN destination, use a TAP, or filter the session, and treat analyser drops as analyser drops.

The reason for that specificity is a failure I have seen: 10 Gbps offered to a 1 Gbps destination dropped at least 90 percent of span traffic. A 2-hour hunt chased production loss that was SPAN oversubscription.

10G source, 1G dest.

Port	Speed	Span frames dropped	Hours of wrong hunt
sources	10 Gbps	—	2
dest	1 Gbps	at least 90 percent	2

I would not consider it settled without evidence: compare production interface counters with analyser received frames.

A SPAN port has an MTU and a speed.

I would start DHCP pool exhaustion from the packet and the return path, not from the protocol adjacency.

A DHCP pool that is full offers nothing. New hosts fail DORA. This is capacity, not a relay bug, and reservations still consume pool space unless excluded.

Concretely, count used versus free, expand or reclaim, and alert before 0 free.

The reason for that specificity is a failure I have seen: The /24 pool hit 0 free. New hosts failed for 46 minutes; existing leases kept working, which looked like "DHCP is up."

254 used, 0 free.

Pool size	Free	New DORA	Minutes
254	0	no Offer	46
existing leases	—	still valid	46

I would not consider it settled without evidence: show free addresses and a Discover with no Offer.

A leased-up pool is a silent deny.

This is an area where a green session and a working path are different observations.

MSS clamping is per rewrite point. A clamp on the tunnel does not rewrite sessions that never enter it. Scope is the interfaces that see the SYN.

Concretely, clamp on every path that has reduced MTU, and test SYNs on VPN and on clear internet separately.

The reason for that specificity is a failure I have seen: VPN sessions were clamped; internet sessions were not. 18 percent of internet large transfers failed for 2 hours on a 1400-MTU middlebox.

Clamp on one path only.

Path	MSS clamped	Large-transfer fail	Hours
VPN	yes	0 percent	2
internet edge	no	18 percent	2

I would not consider it settled without evidence: read MSS on SYN for both paths and require the clamp only where the SYN actually passed.

MSS clamp is an interface action, not a campus spell.

My answer to end-to-end path validation begins with which plane is making the decision: control, forwarding, or policy.

End-to-end validation is both directions, every ECMP member, the reduced-MTU size, the application five-tuple, and the VRF the user is in. A single ping proves one hash, one size, one direction, one protocol.

Concretely, run a matrix of hashes, sizes, directions, and the real port, and record which member each probe used.

The reason for that specificity is a failure I have seen: A 12-hop ping succeeded. One of four hashes dropped large UDP on the return path. The application failed until a diverse probe found it 33 minutes later.

One ping, four hashes.

Probe	Hops	Large UDP return	Minutes until found
one ping	12	not tested	33
hash members 1–3	12	ok	—
hash member 4	12	drop	33

I would not consider it settled without evidence: require a recorded matrix covering members, directions, and sizes before signing the path.

The path is a matrix, not a ping.