How do a NetFlow or IPFIX exporter's active and inactive timeouts decide when flow records are sent, and what do they do to per-minute graphs?
answer
- two clocks per cache entry
- idle versus long-lived flows
- a long flow reported in slices
- delta counters reset on export
- bytes land in the export minute
basics
~20 sThe inactive timeout expires a flow that has gone quiet; the active timeout exports a long-lived flow in slices. Collectors see traffic only when records arrive, so a long active timeout piles a long transfer into one graph spike.
solid answer
~50 sRFC 3954 and RFC 5470 describe two expiry clocks and say both should be configurable at the exporter. The **inactive** (idle) timeout expires a flow once no packet has matched it for that long; RFC 5470 notes that zero turns every packet into a single-packet flow. The **active** timeout exports a still-running flow at regular intervals, so a long transfer becomes a series of records. In IPFIX each record's `octetDeltaCount` restarts at zero after export, so the slices add up. Neither RFC fixes a value; the numbers in use are implementations' defaults. The graph effect: a collector that bins records by end time puts each slice's bytes into one minute. With an 1800-second active timeout, a 30-minute 400 Mb/s transfer shows nothing for 29 minutes and then a 12 Gb/s spike. A 60-second active timeout keeps the line near 400 Mb/s.
go deeper
Remember there are two timers: one for idle flows and one for long-running flows, and records only reach the collector when one fires.
Explain how each timeout expires an entry, that IPFIX delta counters restart after each export, and compute the spike a long active timeout creates.
Diagnose graph artefacts from timeout settings, separate implementation defaults from what the RFCs require, and watch for cache pressure overriding both.
Set timeouts as a fleet-wide policy that trades dashboard freshness against record volume, collector capacity and cache memory at the busiest edge.
## Why a flow needs an expiry rule A flow cache entry is only useful once it reaches a collector, and the exporter cannot know in advance when a conversation will end. NetFlow v9 (RFC 3954, Informational) and the IPFIX architecture (RFC 5470, Informational) therefore list the conditions that end a cache entry and trigger export: 1. The exporter detects the end of the flow, such as a TCP **FIN** or **RST**. 2. No packet has matched the entry for the **inactive timeout** (also called the idle timeout). 3. A long-lived flow reaches the **active timeout** and is exported "on a regular basis". 4. The device hits a resource limit, such as a full cache or a counter about to wrap, and expires entries early. Both RFCs say only that the two timeouts should be **configurable**. RFC 3954 and RFC 5470 both allow an inactive timeout of zero. Any specific default an operator quotes, such as 15 seconds idle or 30 minutes active, is an implementation's choice, not a protocol rule. RFC 3954 even defines field types for the configured values, `FLOW_ACTIVE_TIMEOUT` (36) and `FLOW_INACTIVE_TIMEOUT` (37), so an exporter can report them. ## The two timeouts compared | | Inactive timeout | Active timeout | |---|---|---| | Fires when | no packet for N seconds | the flow has run N seconds since its last export | | Targets | finished or paused flows | flows still running | | Too short | bursty conversations split into many records | more records and more collector load | | Too long | dead entries occupy the cache | long flows invisible until late, then a spike | A zero inactive timeout is the extreme case. RFC 5470 notes that it "would report a Flow as a sequence of single-packet Flows". ## What the slices contain When the active timeout fires, the exporter sends what it has counted so far and keeps tracking the flow. RFC 5470 lets the metering process keep the cache entry so it need not rebuild it. In IPFIX, the counters `packetDeltaCount` and `octetDeltaCount` have **deltaCounter** semantics. RFC 7012 §3.2.3 says a delta counter "is reset to 0 each time it is exported", so consecutive records of one flow are **additive**: the collector sums them and never subtracts one from another. ## The arithmetic of a graph spike Take a 100 Gb/s internet edge where a backup job sends at 400 Mb/s for 30 minutes, and a collector that puts each record's bytes into the minute in which the record ends. - Total sent: 400 Mb/s x 1800 s = 720,000 Mb = 720 Gb = **90 GB**. - **Active timeout 1800 s:** one record arrives at the end. That minute shows 720 Gb / 60 s = **12 Gb/s**; the 29 minutes before it show nothing for this flow. - **Active timeout 60 s:** thirty records of 400 x 60 = 24,000 Mb (**3 GB**) each. Every minute shows about **400 Mb/s**, as it should. Two lessons follow: - The graph **lags** reality by up to one active timeout. A flow-based dashboard cannot show the current minute of a long transfer. - A long active timeout makes bursts **appear** where none happened. Some collectors spread each record's bytes evenly between its start and end timestamps. That smooths the shape but cannot fix the lag. ## A sketch of the expiry loop The pseudocode below is the generic logic, not any one implementation's code. ```pseudocode on packet p with no matching entry: create e; e.slice_start = now; then update e as below on packet p matching entry e: e.packets += 1; e.octets += length(p); e.last_seen = now if p is TCP with FIN or RST: export(e); remove(e) # end of flow detected every second, for each entry e: if now - e.last_seen >= inactive_timeout: export(e); remove(e) # idle: the flow is over else if now - e.slice_start >= active_timeout: export(e) # long flow: send a slice e.packets = 0; e.octets = 0 # delta counters restart e.slice_start = now ``` ## Choosing values - Match the **active timeout** to the graph resolution you need. A one-minute active timeout suits one-minute graphs, at the cost of more records per long flow. - Keep the **inactive timeout** short enough to free cache entries promptly but longer than the normal pauses inside a conversation, or chatty sessions fragment. - Remember the **cache**: a longer inactive timeout means more simultaneous entries. When the cache fills, the device expires flows early and the records stop reflecting the timeouts you set.
- In IPFIX, why must a collector add consecutive octetDeltaCount values for one long flow rather than take the last one?RFC 7012 defines deltaCounter semantics: the counter is reset to 0 each time it is exported. Each record therefore carries only the bytes since the previous record of that flow. Keeping only the last one would report just the final slice, and subtracting would produce nonsense.
- Why does a too-short inactive timeout inflate a NetFlow or IPFIX collector's record count without improving its graphs?A conversation that pauses longer than the inactive timeout, such as an interactive session between keystrokes, is expired and restarted as a new flow. Its bytes are the same, but split across more records, so the collector stores more rows. The per-minute totals barely change, because the timing problem with long flows is governed by the active timeout.
saying these in an interview costs you the question
- The IETF specifications fix the active timeout at 30 minutes.
- A long flow is reported only once, when it finally ends.
- Each IPFIX record of a long flow carries the running total since it began.
- Lowering the inactive timeout makes long transfers report more often.
- Flow-based graphs show the current minute of a long transfer in real time.