skip to content

How does sFlow's packet and counter sampling differ from a NetFlow or IPFIX exporter's flow cache, and what does each design cost?

level: middleimportance: should knowfreq 20%

answer

  1. state on the device or not
  2. headers out versus records out
  3. no timeouts on the sFlow agent
  4. interface counters on a timer
  5. XDR datagrams on UDP 6343

basics

~20 s

An sFlow agent keeps no flow state: it sends a copy of the header of about 1 in N packets, plus periodic interface counters. A NetFlow or IPFIX exporter keeps a flow cache and exports aggregated records when entries expire.

solid answer

~40 s

sFlow v5, an sflow.org specification rather than an RFC (RFC 3176, Informational, describes version 4), does two things per data source. **Packet flow sampling** randomly picks about 1 in N packets and copies its header, by default up to 128 bytes in the sFlow MIB, with forwarding details. **Counter sampling** sends the interface's own counters at a polling interval. Both go out at once as XDR-encoded datagrams on UDP 6343, and the collector builds flows. A NetFlow v9 or IPFIX exporter instead keeps a **flow cache** keyed on flow fields and exports one record per flow on expiry. That costs memory that grows with concurrent flows and adds timeout delay, but it can count every packet. sFlow is cheap and immediate but statistical; its counter samples supply the exact totals.

go deeper

for a junior

Recall that sFlow samples packets and polls counters without tracking flows, while NetFlow and IPFIX build flow records in a cache.

for a middle

Explain packet flow sampling, counter sampling and the flow cache side by side, including what each sends and when it leaves the device.

for a senior

Choose between them for a given fault or edge: cache memory and timeout delay against statistical error, and counter samples as the cross-check.

for a principal

Weigh a mixed estate where some platforms export flows and others sFlow, and decide how analysis normalises both into one trustworthy traffic picture.

## Two answers to the same problem Both designs get traffic data off a switch or router without copying every packet. They put the work in different places. - A **flow-cache exporter** (NetFlow v9 under RFC 3954, Informational; IPFIX under RFC 7011, Standards Track) aggregates on the device. Packets update entries in a cache keyed by flow fields, and each entry is exported as a record when it expires. - An **sFlow agent** samples on the device and aggregates at the collector. sFlow version 5 is defined by an sflow.org text dated July 2004, **not by an RFC**. It replaces version 4, which was published as Informational RFC 3176. ## What an sFlow agent does The sFlow v5 text defines two kinds of sampling per **data source**, typically an interface. 1. **Packet flow sampling.** After the forwarding decision, a counter of packets to skip is decremented. When it reaches zero the agent takes a sample, then resets the counter to a random value so that Total_Packets / Total_Samples equals the sampling rate. The text requires that every packet have "an equal chance of being sampled". The sample is usually a `sampled_header`, the first bytes of the frame (the sFlow MIB's `sFlowFsMaximumHeaderSize` defaults to 128). It travels with forwarding details such as input and output interface and next hop. 2. **Counter sampling.** At a configurable polling interval (`sFlowCpInterval` in the sFlow MIB; the text calls 20-120 seconds typical), the agent exports the data source's counters, such as the `if_counters` block with 64-bit octet counters. The agent may piggyback them on flow-sample datagrams to save packets. Each `flow_sample` carries `sampling_rate`, `sample_pool` (packets that could have been sampled) and `drops` (samples the agent could not process). Datagrams are **XDR-encoded** and sent over **UDP**, to port **6343** by default. A collector configures the agent through the sFlow MIB over SNMP. ## What a flow-cache exporter does 1. Each packet, or each sampled packet if sampling is on, is looked up by its **flow key**, classically the five-tuple. 2. Counters and timestamps accumulate in the entry. 3. The entry expires on TCP FIN or RST, the **inactive** timeout, the **active** timeout, or resource pressure. 4. The record is encoded with a **template** (v9, IPFIX) and exported, usually over UDP. IPFIX uses port 4739. ## What each design costs | | sFlow v5 agent | NetFlow v9 / IPFIX flow cache | |---|---|---| | State on the device | none per flow | one entry per active flow key | | Export delay | a sample leaves at once | up to the active timeout | | What is exported | raw header bytes plus counters | parsed fields named by a template | | Accuracy | statistical: about 1/sqrt(samples) | exact per flow if unsampled | | Exact link totals | counter samples | interface counters polled separately | | Decoding | fixed XDR structures | needs templates first | The trade-offs, in practice: - **Memory and scale.** A cache must hold every concurrent flow. At a busy 100 Gb/s edge that can mean millions of entries, and when the cache fills the exporter expires flows early. An sFlow agent's cost grows with sample rate, not with flow count. - **Freshness.** sFlow samples arrive within seconds, while cache records wait for a timeout. That matters for spotting a sudden traffic shift. - **Visibility.** A copied header shows whatever the frame carried, including Layer 2 fields and protocols the cache does not key on. A flow record shows only the fields its template names. - **Completeness.** Unsampled flow export accounts for every packet, while sFlow at 1-in-N gives good estimates for large aggregates and little about small flows. ## Why counter samples matter Counter samples are not estimates: they are the device's own interface counters. They let a collector check sampled sums against exact totals, catching a wrong sampling rate or heavy sample loss. The sFlow text explains why UDP loss does little harm. A lost counter sample is replaced at the next interval, and with 64-bit counters an undetected wrap is negligible. A lost flow sample only slightly lowers the effective sampling rate. ## Common confusions - Calling sFlow "sampled NetFlow": sampled NetFlow still runs a cache and timeouts; sFlow does not. - Citing RFC 3176 as the sFlow standard: it is Informational and describes version 4. - Assuming counter samples are themselves sampled: they report exact counters at an interval.

  • How does sampled NetFlow differ from sFlow if both pick about 1 packet in N?
    Sampled NetFlow feeds the selected packets into a flow cache. It still keys, accumulates and expires entries on active and inactive timeouts, and exports records whose counters must be multiplied by N. sFlow sends each sampled header straight to the collector with no per-flow state on the device. The collector does the aggregation, and samples arrive without timeout delay.
  • What does a rising drops value in sFlow v5 flow samples tell an operator, and what is the usual remedy?
    The agent detected packets marked for sampling that it could not process for lack of resources, so hardware is selecting samples faster than the agent can handle. The attained rate falls below the configured one. The sFlow v5 text says increasing the sampling rate, meaning sampling less often, reduces the drop rate.

saying these in an interview costs you the question

  • sFlow is an IETF standard defined in RFC 3176.
  • An sFlow agent keeps a flow cache and exports on timeouts like NetFlow.
  • sFlow counter samples are themselves estimates scaled from sampled packets.
  • A NetFlow v9 record contains a copy of each packet's header.
  • A lost sFlow datagram corrupts interface counters until the agent restarts.