skip to content

Your zone firewall exports no flow for a busy subnet pair - how do you tell a bypass an intruder can use from missing collection before booking a window?

level: middleimportance: should knowfreq 46%

answer

  1. absence is a statement about the instrument
  2. check the exporter before the topology
  3. sampling hides low-volume pairs
  4. corroborate with a positive record elsewhere
  5. the conclusion costs a change night

basics

~20 s

Absence of flow records is ambiguous: it means the device never saw the traffic, or that export was never configured, sampled it away, or dropped it. Confirm the forwarding path itself before you claim a bypass, because the claim buys an outage window somebody has to authorise.

solid answer

~50 s

Treat the missing records as a hypothesis, not a finding. First establish that the exporter is healthy and complete for that device: is export enabled on the relevant interfaces, is it sampled, are records for other pairs arriving in the same interval? A sampled exporter can genuinely miss a low-volume pair, and an interface added later often has no export configured. Then answer the path question directly from forwarding state: which next hop does each side's device choose for the other's prefix, does an overlay or interconnect provide a shorter route, are there records for the same pair on some *other* exporter, and do the device's interface and rule counters move at all. A flow record proves bytes moved past the exporter and carries no payload; the absence of one proves only that the exporter did not report it. When both halves line up - the exporter is healthy and the path genuinely resolves elsewhere - you have evidence that justifies asking for a change night.

code

text · 10 lines
text
# aggregation switch, exporter 10.10.0.2  (IPFIX)
src=10.20.7.14:51344 dst=10.60.3.9:1433 proto=TCP pkts=118 bytes=94220 in=Eth1/12 out=Eth1/48 start=09:14:02 end=09:14:31
src=10.20.7.31:49810 dst=10.60.3.9:1433 proto=TCP pkts=96  bytes=71880 in=Eth1/12 out=Eth1/48 start=09:15:07 end=09:15:44
...

# zone firewall, exporter 10.10.0.9  (NetFlow v9)
# export verified enabled on all forwarding interfaces, unsampled
(no records matching 10.20.7.0/24 <-> 10.60.3.0/24 in the last 30 days)

# note: records carry the five-tuple, counters, timestamps and interfaces - no payload

go deeper

for a junior

Know what a flow record contains - the five-tuple, counters, timestamps, interfaces - and that it never contains payload, so it can show that bytes moved but not what they were.

for a middle

Explain why absent records are ambiguous and name the checks that separate a collection gap from a real bypass: export coverage, sampling rate, records for other pairs, device counters, next-hop resolution.

for a senior

Demonstrate that you build the case from a positive observation plus a verified-healthy absence, and that you know the finding cashes out as a change request somebody must authorise.

for a principal

Be ready to argue what telemetry coverage the estate should fund at all, given that a boundary you cannot observe is a boundary you can only assert.

## Why this is the tree's signature reconciliation problem The documented zone boundary is a claim. The cheapest evidence that the claim has quietly stopped being true is negative evidence: the device that is supposed to be between two zones reports no traffic between them, while the traffic obviously exists. Negative evidence is also the easiest evidence to misread, and misreading it here is expensive, because the conclusion buys a maintenance window and a change owner's night. ## What a flow record does and does not prove A NetFlow or IPFIX record carries the five-tuple (source and destination address, source and destination port, protocol), packet and byte counters, timestamps, and usually ingress and egress interface. It carries **no payload**. So: - A record at an exporter proves bytes moved past that exporter, at that time, between those endpoints. It does not tell you what they were. - The absence of a record proves the exporter did not report it. That is a statement about the exporter, not about the network. That asymmetry is the whole question. Three different worlds produce the same empty query result. ## The three worlds, and how to separate them **1. Collection is incomplete.** Export was configured on the interfaces that existed when the device was built, and the uplink added two years ago was never added. Or export is sampled - one in a few hundred packets - and a low-rate pair falls below the sampling floor for the interval you queried. Or the collector dropped records under load, or the device's export destination changed. Test it: are records from that same exporter arriving in the same window for other pairs? Are all its forwarding interfaces represented? Is sampling configured, and at what rate? Does the device's own interface and policy counters move for that pair? **2. The traffic genuinely does not transit the device.** The path resolves somewhere else - a newer fabric path, a stretched overlay segment reaching the same destination without crossing the routed aggregation boundary the diagram names, or an interconnect built to make two merged estates talk. Test it from forwarding state on both sides: what next hop is chosen for the other zone's prefix, and does the chain of hops include the enforcement device at all? Corroborate with a *positive* observation elsewhere - another exporter that does show the pair, with interface fields that name a link the diagram never had. **3. The traffic genuinely does not exist.** Rare, but check it before the other two: the pair may have moved, been decommissioned, or been re-addressed. ## Reading the two exporters The strongest artefact is a pair of observations rather than one absence: a healthy exporter that *does* see the pair, and the boundary device that does not, over the same interval. That is a positive statement about where the traffic goes, and it survives the obvious rebuttal ("your collection is broken"). Be careful about one adjacent claim you have not made. Showing that the device is not on the path is a different question from showing that the device, when it *is* on the path, actually denies what it says it denies. Do not let the two be conflated in an interview - a bypass finding says the policy is not consulted, not that the policy is wrong. ## The price, and why it is part of the answer Evidence here is not free and neither is the conclusion: - Closing the collection gap means enabling export on every path device and accepting the collector volume, or paying for sampling and accepting what sampling hides. - The conclusion cashes out as a change request. Moving enforcement onto the real path means a routing change or a policy relocation, and every one of those is a maintenance night with a named owner, an application owner who has to agree to the risk, and a rollback. An engineer who brings "the firewall shows nothing" to a change board will be sent away. An engineer who brings "here is the pair observed on the interconnect, here is the boundary device with export verified healthy and no records for thirty days, here is the next hop each side chooses" gets the window. ## The interview trap The weak answer is to read empty as proof of a bypass, or - the mirror image and just as common - to shrug and assume telemetry is always broken. Both skip the step that matters: establishing what your instrument can and cannot see before you interpret what it did not show you.

  • The boundary device is sampled at 1 in 1000. How does that change what you can conclude?
    It weakens the absence badly for low-rate pairs. A flow of a few packets an hour may never be sampled, so 'no records' is expected even when the traffic transits the device. Fall back on evidence that is not sampled: interface and rule-hit counters on the device, and the forwarding decision each side makes for the other's prefix. Or temporarily raise the sampling rate on the relevant interfaces and re-query.
  • You find records for the pair on a second exporter. Does that prove the boundary is bypassed?
    It proves the traffic transited that second device. Whether the boundary device is also in the chain depends on the topology - both can be on the path in sequence. Confirm with the interface fields and the hop-by-hop forwarding decision, not with the mere existence of a record elsewhere.
  • What would you bring to a change board to get the maintenance window?
    The pair observed on a device the zone model does not include, the boundary device with export health verified and no records over a stated interval, the next-hop resolution on both sides, and a scoped statement of which flows the move would newly be filtered - so the application owners can see what they are being asked to risk on the night.

saying these in an interview costs you the question

  • Reads an empty query as proof of a bypass
  • Never checks whether export is enabled on all interfaces
  • Forgets that sampled export hides low-volume flows
  • Claims flow records show what was sent, not just that bytes moved
  • Brings the finding to a change board without the corroborating positive observation

context