NetFlow vs sFlow vs IPFIX: what they measure and how each one fails

Flow telemetry protocols are often lumped together as “flow data,” but they measure fundamentally different things. NetFlow and IPFIX build stateful flow records by tracking conversations in device memory. sFlow captures random packet samples without maintaining any flow state. This architectural split determines not only what you can see but how the data breaks when something goes wrong.

Operators who conflate the three protocols tend to misdiagnose the dominant failure they all share (silent UDP loss) and miss the protocol-specific failures that produce the most misleading data: template desync in NetFlow v9 and IPFIX, sampling blindness in sFlow, and exporter-side drops that neither NetFlow nor IPFIX reports in-band.

What each protocol measures

The three protocols divide into two architectural families: stateful flow aggregation (NetFlow v5, NetFlow v9, IPFIX) and stateless packet sampling (sFlow).

NetFlow v5 is effectively legacy. It exports a fixed 7-field record layout with no templates, no IPv6 support, no MPLS or VXLAN awareness, and ingress-only tracking. It still appears on older Cisco IOS deployments but should be treated as deprecated for any new build. NetFlow v5 also lacks an exporter-side timestamp, which means you cannot compute export-to-ingest latency from its records alone.

NetFlow v9 is the de facto current NetFlow standard. It exports stateful flow records aggregated in device memory (RAM or TCAM). Each record tracks L3/L4 attributes: source and destination IP, ports, protocol, ToS, byte and packet counts, and start and end timestamps. NetFlow v9 is template-based: the exporter sends a template record describing the field layout, followed by data records that conform to that template. Collectors must receive and cache the template before they can decode any data records.

IPFIX (RFC 7011/7012) is a direct derivative of NetFlow v9. Its template-based architecture is identical in concept, but it uses an IETF-maintained, vendor-neutral Information Element registry instead of Cisco-specific field definitions. IPFIX supports enterprise-specific custom fields and variable-length field encoding for arbitrary data such as URL fragments or usernames. It is the forward-looking standard, with active IETF governance and formal interoperability testing.

sFlow (RFC 3176, maintained by sflow.org) takes a fundamentally different approach. It performs stateless random packet sampling: on average, 1 in N packets is captured. The sampling is pseudorandom to avoid synchronizing with periodic traffic patterns. sFlow exports the full packet header (Ethernet through L4) plus the first 64 or 128 bytes of payload, and it also exports time-based interface counter samples. There is no unsampled mode. There are no flow timestamps in the NetFlow sense. sFlow is sample-datagram oriented, not template-flow oriented.

flowchart LR
    subgraph Stateful["NetFlow v9 / IPFIX (stateful)"]
        A1[Packet stream] --> A2[Device flow cache]
        A2 --> A3[Aggregated flow records]
        A3 --> A4[Template + data records]
        A4 --> A5[UDP export]
    end
    subgraph Stateless["sFlow (stateless)"]
        B1[Packet stream] --> B2[1-in-N random sampling]
        B2 --> B3[Sample datagrams]
        B2 --> B4[Counter samples]
        B3 --> B5[UDP export]
        B4 --> B5
    end

How they fail differently

All three protocols share one dominant failure mode: UDP transport with no retransmission, no acknowledgment, and no sender-side notification of loss. When a UDP datagram carrying flow data is dropped, every record inside it is permanently lost. The kernel counter Udp_RcvbufErrors (in /proc/net/snmp) is often the only signal that this happened.

Beyond the shared UDP weakness, each protocol fails in architecturally distinct ways.

NetFlow v9 and IPFIX: template desync

NetFlow v9 and IPFIX require collectors to receive and cache template records before data records can be decoded. Templates are sent over UDP on a configurable interval, typically 5 to 30 minutes. After a device reboot, software upgrade, or flow-exporter configuration change, the template may change. Until the collector receives the new template and rebuilds its cache, all data records from that exporter are silently discarded.

This window can be 5 to 30 minutes per exporter. If the restart coincides with a security event, the forensic traffic evidence is gone. Neither protocol provides an in-band signal that data is being discarded for this reason. The collector may log “template not found” or “cache miss” internally, but these messages rarely surface on operational dashboards.

NetFlow v9 and IPFIX: exporter-side silent drops

Most operators monitor collector-side packet loss (kernel buffer drops, NIC drops) but the exporter itself can silently discard flow records. Full internal buffers, FIB lookup failures, and VRF mismatches all cause the device to drop flow records before they are exported. Neither NetFlow nor IPFIX provides an in-band signal for these drops.

On Cisco devices, the CISCO-NETFLOW-MIB exposes counters for this purpose:

<!-- TODO: verify these OIDs map to the claimed objects in CISCO-NETFLOW-MIB;
     these may require table index suffixes; use snmpwalk first to discover the correct instance OIDs -->
# Verify the OIDs exist on your device first:
snmpwalk -v2c -c <community> <device> .1.3.6.1.4.1.9.9.387.1.4

# Then query specific counters:
snmpget -v2c -c <community> <device> .1.3.6.1.4.1.9.9.387.1.4.6   # cnfESPktsDropped
snmpget -v2c -c <community> <device> .1.3.6.1.4.1.9.9.387.1.4.4   # cnfESPktsExported

If the device-exported rate exceeds the collector inbound rate, loss is happening in transit or at the collector. If the device drop counter is rising, loss is happening on the device itself. Comparing these two numbers gives you end-to-end loss visibility that Udp_RcvbufErrors alone cannot provide.

sFlow: sampling accuracy degrades at low volumes

sFlow accuracy depends on absolute sample count, not total packet volume. At 0.25% sampling (1-in-400), hourly estimates for rare flows can swing plus or minus 65%. Monthly aggregation at the same rate yields plus or minus 2.4%. Cloudflare recommends not exceeding a 1-in-5000 sampling rate before noticeable accuracy loss on typical network volumes.

This means sFlow systematically underrepresents bursty or low-volume traffic. A flow generating 100 packets per second may yield zero samples in a given interval, or three, purely due to Poisson variance. This makes sFlow unsuitable for forensic investigation of short-duration events or detection of low-volume exfiltration. Operators relying on sFlow for security alerting should understand this architectural blind spot.

sFlow: sampling rate not normalized

sFlow reports raw sampled counts. If the analytics layer does not multiply by the sampling rate to recover true byte and packet counts, bandwidth charts are wrong by the sampling factor. At a 1-in-1000 sampling rate, charts report one-thousandth of actual traffic. The error is consistent across all conversations, so relative comparisons look right while absolute numbers are off by orders of magnitude.

On high-speed links with low aggregate traffic, static sampling rates produce extremely sparse samples. A 10 Gbps interface carrying less than 500 Mbps with a static 1-in-10000 rate may yield so few samples that the data is unusable for meaningful analysis. Misconfigured sFlow on 40G inter-switch links routinely produces data that operators mistake for a traffic drop when the real problem is sampling sparsity.

sFlow vs NetFlow: different collector load profiles

sFlow and NetFlow have very different packet-rate characteristics at equal bandwidth. sFlow generates samples proportional to packet rate, not bandwidth. NetFlow v9 exports are bursty: they concentrate on flow creation and teardown events. Buffer sizing and collector capacity planning must be protocol-specific. A collector sized for NetFlow v9 may be overwhelmed by sFlow at the same link speed, because sFlow export volume scales with packet count rather than flow count.

Where these failures show up in production

The table below maps each protocol to its dominant failure mode, what it looks like on a dashboard, and the first signal to check.

The shared UDP failure is the most common and the most damaging. The Linux default net.core.rmem_max of 4,194,304 bytes (4 MB) is inadequate for high-pps sFlow collectors. Production deployments should target 16 MB or higher, with 33 MB for very high-volume collectors. The socket buffer must also be explicitly set on the listener socket via SO_RCVBUF.

A collector that looks healthy (process running, port listening, disk not full) can still be losing a significant fraction of incoming flow datagrams if the socket buffer is undersized. The “packets received” counter at the application layer increments normally for packets that make it through, while dropped packets increment a separate kernel counter that most teams never monitor.

Signals to watch in production

For deeper coverage of specific failure modes, see the related guides on UDP flow loss, template desync, sFlow sampling rate, and export-to-ingest latency.

How Netdata helps

Netdata correlates flow telemetry signals across the collection stack, which is where most silent failures live.

• UDP socket buffer drops are monitored at the kernel level (Udp_RcvbufErrors), with per-collector visibility so you can see which collector is losing data.
• NIC RX drops are tracked per interface, catching hardware-level loss before it reaches the socket layer.
• Collector CPU utilization is monitored per core, which catches RSS misconfiguration where one core saturates at 100% while others sit idle. This is a common cause of flow data loss that aggregate CPU metrics hide.
• TSDB write queue depth and disk space are tracked, catching the slow-consumer bottleneck that backs up the socket buffer and causes silent drops.
• Cross-signal correlation lets you compare SNMP interface counters (which reflect real traffic) against flow-derived analytics (which may be missing data). When SNMP shows rising traffic but flow charts show decline, the gap points directly to collector-side loss.
• Exporter-side counters for Cisco devices (cnfESPktsDropped, cnfESPktsExported) can be polled alongside collector-side metrics, giving you end-to-end loss visibility without relying on a single signal.

Related guides

• Flow export-to-ingest latency: why your NetFlow data is minutes behind
• Network monitoring checklist: the signals every production network needs
• NetFlow v9/IPFIX template desync: flows decoded wrong or dropped after a reboot
• Silent UDP flow data loss: why your NetFlow collector is dropping records
• sFlow sampling rate: why your traffic totals are off by 1000x