skip to content

In NetFlow and IPFIX flow export, what is a flow key, and how does an exporter turn packets into flow records?

level: juniorimportance: must knowfreq 35%

answer

  1. fields every packet in it shares
  2. one cache entry per key
  3. the five-tuple, one direction only
  4. key fields versus accumulated fields
  5. expire the entry, then export it

basics

~20 s

A flow key is the set of fields, classically the five-tuple, that packets must share to count as one flow. The exporter keeps a cache entry per key, adds each matching packet to it, and exports it as a record on expiry.

solid answer

~50 s

RFC 7011 calls a **flow key** each field used to define a flow: a header field such as the destination address, a property of the packet such as its length, or a value derived from treatment such as an AS number. The traditional key is the five-tuple (source and destination address, source and destination port, protocol), which groups one *direction* of one conversation, so a TCP connection normally becomes two flows. The metering process looks each packet's key up in a flow cache: a hit adds to that entry's packet and byte counters and moves its end time; a miss creates an entry. Fields outside the key are accumulated, such as NetFlow v9's `TCP_FLAGS`, the union of all flags seen. When the entry expires (idle, long-lived, TCP end, or cache pressure) the exporting process sends it to a collector as one record.

go deeper

for a junior

Recall the five-tuple, that a flow is one direction, and that a record carries counters and timestamps rather than packet contents.

for a middle

Walk through the cache lookup: key fields select the entry, counters accumulate, non-key fields such as TCP flags are folded in, and expiry triggers export.

for a senior

Show that the key is a design choice: every added field multiplies cache entries and export volume, and a coarse key loses the detail later questions need.

for a principal

Frame key choice as a cost decision across the estate: what the analysts must be able to answer versus what cache memory and collector capacity can carry.

## What a flow is **Flow export** is how a router or switch summarises the traffic it forwards without copying the packets. Three specifications describe the record formats a candidate meets: **NetFlow v5**, a fixed-format vendor export with no RFC at all; **NetFlow v9**, published as Informational RFC 3954; and **IPFIX**, the IETF standard in RFC 7011 (STD 77) with its information model in RFC 7012. All three share the same idea. RFC 7011 defines a **flow** as a set of packets passing an observation point during a time interval that share a set of common properties. Those common properties are the **flow keys**. Each flow key is a field that is: - part of the packet header, such as the destination IP address; - a property of the packet itself, such as its length; or - derived from how the device treated it, such as an Autonomous System number. The textbook example in RFC 7011 is the **five-tuple**: source and destination address, source and destination transport port, and transport protocol. It groups the packets of a single *direction* of communication on a single socket. Because a reply swaps source and destination, it carries a different key, so one TCP connection normally produces **two** flows. ## The key decides the granularity The key is a configuration choice, and it trades detail against cache size and export volume. | Key | One record covers | Effect | |---|---|---| | five-tuple | one direction of one socket pair | the common default, detailed | | five-tuple + DSCP or ingress interface | the same, split by marking or port | more entries, more records | | destination prefix only | everything sent to one prefix | far fewer entries, no per-host detail | Adding a field to the key can only split flows further: two packets that differ in that field now land in different entries. ## The flow cache, step by step The part of the exporter that builds flows is the **metering process**, and its working store is the **flow cache**. 1. A packet arrives (or is selected, if the exporter samples). 2. The metering process extracts the key fields and looks them up. 3. On a **hit**, it adds one to the entry's packet counter, adds the packet's length to its byte counter, updates the last-seen time and folds in non-key fields such as TCP flags. 4. On a **miss**, it creates an entry with the first-seen time. 5. When the entry **expires**, the exporting process encodes it as a **flow record** and sends it to a collector. RFC 3954 and RFC 5470 list the expiry reasons: the exporter detects the end of a flow (a TCP FIN or RST), the flow has been idle for the inactive timeout, a long-lived flow reaches the active timeout, or the device runs short of resources, such as cache memory. ## What a record carries A typical record holds: - the **key fields**, such as `sourceIPv4Address` and `destinationIPv4Address`; - **counters**, which IPFIX calls `packetDeltaCount` and `octetDeltaCount`; - **timestamps** for the first and last packet; - **accumulated non-key fields**, such as NetFlow v9's `TCP_FLAGS`, the cumulative flags seen in the flow, plus the input and output interfaces. A typical flow record carries no payload: it summarises header fields and counts rather than copying the packets. ## Formats and transport around the record | Format | Status | Record layout | |---|---|---| | NetFlow v5 | vendor documentation, no RFC | fixed fields, IPv4 only | | NetFlow v9 | RFC 3954, Informational | described by templates | | IPFIX | RFC 7011, Standards Track | described by templates, version number 10 | Records usually travel to the collector over **UDP**, which is cheap for the exporter but unreliable. IPFIX also defines SCTP and TCP and assigns port **4739** (4740 for secure transport). Because templates in v9 and IPFIX describe each record's fields, the key and the carried fields can change without a new protocol version. RFC 3954 notes that adding a field to the older fixed formats meant a new export version. ## Traps to avoid - Calling a flow a *connection*: with the five-tuple, a flow is one direction. - Treating every field as a key: counters and timestamps describe the flow and never split it. - Assuming one record per conversation. Timeouts split long flows into several records, which the next question in an interview usually probes.

  • In NetFlow or IPFIX, what happens to the record count if you add DSCP to a five-tuple flow key?
    It can only rise. Packets of the same socket pair that carry different DSCP values now land in separate cache entries, so a conversation whose marking changes mid-stream becomes several flows. The cache needs more entries and the collector receives more records. In return, a record can now report traffic by marking, which a five-tuple key would have merged.
  • Why is NetFlow v9's TCP_FLAGS field accumulated rather than used as part of the flow key?
    Flags change packet by packet within one connection: SYN, then ACK, then FIN. Keying on them would split one conversation into many flows. As a non-key field, RFC 3954 records the cumulative flags seen in the flow. A record that saw SYN but never ACK then tells you the handshake never completed, without splitting the flow.

saying these in an interview costs you the question

  • A flow record is a copy of the packets in the conversation.
  • One TCP connection always produces exactly one flow record.
  • The flow key must be the five-tuple; no other fields can be keys.
  • Every field in a flow record is part of the flow key.
  • The exporter normally sends a record for every packet it forwards.