An optical tap yields two simplex feeds — what must you spend so one IDS engine sees both halves of an intruder's session?
answer
- a tap does not combine anything
- both directions, one worker
- the default hash is not symmetric
- half a conversation still logs a flow
- verify with a known bidirectional session
basics
~20 sYou must re-aggregate the two directions and keep them together all the way to one engine instance: enough aggregation capacity for both directions at peak, and flow-aware or symmetric load balancing so a session's two halves land on the same receive queue and worker.
solid answer
~50 sA passive tap splits each fibre, so a full-duplex link becomes two simplex outputs. Three things then have to be bought or configured. First, capacity: both directions of a saturated link need up to twice the link rate on whatever port carries them, so re-aggregating two 10G feeds into one 10G sensor port guarantees loss at peak. Second, both feeds must actually be patched — connect one and the sensor sees requests with no responses, yet still logs a plausible-looking connection. Third, and most easily missed, the standard receive-side-scaling hash is not symmetric: swap source and destination and it produces a different queue, so the two directions land on different queues and different worker threads. Each thread holds half a conversation, reassembly never completes, and detection that depends on a command *and* its response silently never fires. You pay in broker ports, NIC queues and cores — and in re-verifying the hash after every driver change.
go deeper
Know that a passive tap produces one output per direction and that a sensor needs both to understand a conversation at all.
Explain the capacity doubling and the asymmetric receive-side hash: two directions of one connection can reach different queues and different workers, so no worker can reassemble the stream.
Demonstrate how you would prove it in production — a known bidirectional replay, one engine instance, one connection record with both byte counts — and schedule the re-check because the setting regresses silently.
Argue the budget in terms of detection classes rather than throughput: without both halves converging on one engine, no rule investment can reach detections that depend on a response.
## Why a tap gives you two of everything A passive optical tap splits the light on each strand of a fibre pair. A pair carries one direction per strand, so the tap's outputs are **simplex**: one output carries client-to-server, the other server-to-client. Nothing in the tap combines them — that is the point of a passive device, and it is also the whole problem, because detection is a property of the *conversation*, not of either direction alone. ## Cost one: the capacity doubles A 10 Gb/s full-duplex link can carry 10 Gb/s in each direction simultaneously. Re-aggregating both simplex outputs into a single 10 Gb/s sensor interface therefore offers up to 20 Gb/s to a 10 Gb/s port. At average load nothing is wrong; at the busy hour the aggregation point discards, and it discards silently, the same way an oversubscribed mirror destination does. The fix is a faster sensor interface, a broker that fans the aggregated stream across several sensor ports, or fewer tapped links per sensor. All three are line items. ## Cost two: both feeds have to be patched, and half-patching looks healthy If only one simplex output is connected — a common outcome of a rushed patching job or a broken fibre nobody noticed — the engine sees one direction. It will typically still create a connection record from the handshake it saw, so the sensor's own logs look ordinary. What is gone is everything that depended on the other half: the server's response, the data returned to the client, the bulk direction of a transfer. An intruder pulling data out of a database tier is invisible in precisely the direction that matters, and no counter anywhere says so. ## Cost three: the hash, and this is the one senior candidates miss Modern NICs spread incoming packets across multiple receive queues so that several CPU cores can process traffic in parallel. The spreading is done by hashing header fields — typically source address, destination address, source port, destination port. The default hash is **not symmetric**: exchanging source and destination changes the result. So the client-to-server packets of one TCP connection hash to queue 3, and the server-to-client packets of the *same* connection hash to queue 11. A stateful engine reassembles per worker. Worker A now holds one half of the conversation and worker B the other. Neither can reassemble the stream. Detection that depends on seeing a request and the response to it — an issued command and the output returned, a request and the payload sent back — cannot fire, because no single instance ever holds both. Depending on the engine you get two one-sided flows, or one flow with wildly wrong byte accounting, and in both cases the sensor reports itself healthy with zero drops. The same split happens at a packet broker that load balances to several sensors without being flow aware: direction A goes to sensor 1, direction B to sensor 2, and you have bought two sensors that each see half of everything. ## Getting it right - Configure a **symmetric hash** on the NIC so that the two directions of a flow collide onto the same queue, or hash on a direction-agnostic key. - Where a broker distributes to several sensors, require **flow-aware** load balancing that pins both directions of a session to the same egress port. - Verify empirically rather than by configuration review: run a known bidirectional session and confirm that **one** engine instance logged **one** connection with sensible byte counts in both directions, not two half-connections. - Re-verify after firmware, driver and NIC replacements. This setting regresses quietly and a regression produces no error — only a slow decline in the class of detections that need both halves. ## What the whole thing costs Broker ports (and per-port licensing), sensor NICs with enough queues, one core per queue you actually intend to use, the optics and patching for two fibres instead of one, and recurring engineering time to re-prove the symmetry. The argument that wins this budget is not that the sensor would be faster; it is that without it, an entire *class* of detection — anything requiring a response — is unreachable no matter how good the rules are. ## Adjacent, and worth stating clearly Re-aggregation can also introduce duplicates when the same traffic is both tapped and mirrored somewhere else in the path. Duplicates burn capacity that you are already short of and can confuse retransmission accounting. Deduplication at the aggregation stage is another feature you pay for.
- How would you detect that a NIC firmware update quietly reverted the symmetric hash?By replaying a known bidirectional session and inspecting the sensor's own connection records: one connection with byte counts in both directions means the halves converged, two one-sided records mean they did not. Make that replay a scheduled check rather than a post-change memory task, because the regression produces no error and only shows up as a slow decline in detections that need a response.
- A broker load balances the aggregated feed across four sensors. What must the balancing be based on?A flow-aware key that maps both directions of a session to the same egress port — effectively a direction-agnostic hash of the address and port pair. Round-robin or plain per-packet distribution splits conversations across sensors, so every sensor holds fragments and none can reassemble. Four sensors each seeing half of everything detect less than one sensor seeing all of one quarter.
- Why can a half-patched tap be worse than an obviously dead feed?Because it looks alive. A dead feed shows zero packets and gets fixed the same day; a single simplex feed still produces connection records, still shows throughput, and still raises occasional alerts, so it passes every health check while an entire direction of traffic is unexamined. Silent partial coverage survives far longer than obvious total failure.
saying these in an interview costs you the question
- Assumes a tap delivers one combined bidirectional stream
- Sizes the sensor port for the link rate, not twice it
- Believes any load balancing across queues is safe
- Treats connection records as proof both directions arrived
- Never re-verifies hash symmetry after driver changes