NetFlow vs sFlow vs IPFIX: Differences & When To Use

NetFlow, sFlow, and IPFIX are three network traffic export protocols that give visibility into traffic flows without requiring full packet capture. NetFlow and IPFIX aggregate packets into flow records on the device before exporting them, providing exact (if unsampled) accounting. sFlow takes a fundamentally different approach: it exports every Nth packet header plus interface counters, making it stateless and scalable but statistical rather than exact. IPFIX is the IETF-standardized evolution of NetFlow v9, adding vendor-neutral extensibility through template-based information elements.

What is NetFlow?

NetFlow is a flow-based traffic export protocol originally developed by Cisco. A network device (router, switch, or firewall) inspects passing packets and groups them into flows based on a common set of attributes - typically the 5-tuple of source IP, destination IP, source port, destination port, and protocol. The device maintains state for each active flow, accumulating byte and packet counts, and exports a flow record when the flow expires or a timer triggers.

Key NetFlow versions:

NetFlow can operate in unsampled mode (every packet is counted, giving exact accounting) or sampled mode (only a subset of packets is processed, reducing device load at the cost of statistical accuracy).

For a deeper overview, see What is NetFlow?.

What is IPFIX?

IPFIX (IP Flow Information Export), defined in RFC 7011, is the IETF standard that generalizes NetFlow v9. It takes the template-based, extensible design of NetFlow v9 and makes it vendor-neutral. Think of it as “standardized NetFlow v9.”

Key properties of IPFIX:

• Template-based: The exporter and collector negotiate which fields are included, so the format is not hardcoded.
• Extensible: Vendors and organizations can define enterprise-specific Information Elements (IEs) for custom fields.
• Vendor-neutral: Any vendor can implement it, making it suitable for multi-vendor environments.
• Transport: Typically runs over UDP, SCTP, or TCP, with SCTP offering built-in reliability.

Because IPFIX is a superset of NetFlow v9’s concepts in a standardized form, many modern network devices support both, and collectors often treat NetFlow v9 and IPFIX similarly.

What is sFlow?

sFlow (sampled flow), created by InMon, takes a fundamentally different approach from NetFlow and IPFIX. Instead of aggregating packets into flows on the device, sFlow performs statistical packet sampling: every Nth packet has its header copied and exported as a datagram, along with periodic interface counter samples.

This design has important implications:

• Stateless on the device: The device does not maintain flow tables or track active flows. It simply samples and forwards.
• Low overhead: Because there is no flow-state maintenance, sFlow scales to very high link speeds (100Gbps and beyond) with minimal CPU and memory impact.
• Statistical, not exact: Totals must be scaled by the sampling rate. If 1 in 1,000 packets is sampled, estimated totals are multiplied by 1,000, which introduces statistical variance.

sFlow also exports interface counters (similar to SNMP polling) alongside packet samples, giving a blend of flow-level estimates and counter data.

How Each Protocol Works

The architectural difference between these protocols is best understood by looking at where the work happens.

NetFlow / IPFIX: Device-side aggregation

1. The device inspects every (or sampled) packet passing through.
2. Packets sharing the same key fields (5-tuple or extended tuple) are grouped into a flow.
3. The device maintains state for each active flow in a flow cache.
4. When a flow expires (timeout, TCP FIN, or cache full), the device exports the aggregated record.
5. The collector receives complete or near-complete flow records with byte and packet totals.

This model provides accurate flow-level data but requires the device to maintain flow state, which consumes CPU and memory.

sFlow: Device-side sampling

1. The device samples every Nth packet (configurable rate).
2. The sampled packet header is exported immediately as a datagram.
3. No flow state is maintained on the device.
4. Interface counter samples are exported periodically alongside packet samples.
5. The collector reconstructs traffic estimates by scaling sampled data.

This model is lightweight on the device but shifts the analysis burden to the collector, which must infer flows from sampled headers.

Comparison Table

When to Use Each

Choose NetFlow or IPFIX when:

• You need flow-level accuracy for billing, capacity planning, or compliance.
• You want rich metadata per flow (AS paths, MPLS labels, VLAN tags, application IDs).
• You operate in a multi-vendor environment and need standardization (IPFIX).
• You are doing security analysis where every connection matters (e.g., detecting lateral movement, data exfiltration).

IPFIX is generally the better choice over NetFlow v5 in new deployments because of its extensibility and vendor neutrality.

Choose sFlow when:

• You operate at very high link speeds where maintaining flow state is impractical.
• Low device overhead is a priority (you cannot spare CPU on your switches or routers).
• You can accept statistical estimates rather than exact flow records.
• You need near-real-time visibility for DDoS detection or traffic anomaly alerts, where directional trends matter more than exact byte counts.

Practical reality: many networks use both

Large networks often deploy sFlow on high-speed core switches (where overhead matters most) and NetFlow or IPFIX on edge routers and firewalls (where flow accuracy and rich fields are more valuable). A capable collector that ingests all three protocols lets you correlate both perspectives.

Common Pitfalls and Misconceptions

1. Treating sFlow totals as exact

sFlow exports sampled headers. If your sampling rate is 1:1,000, multiplying totals by 1,000 gives an estimate - not an exact count. Short-lived flows or low-volume conversations may be entirely missed. Always interpret sFlow data as a statistical sample, and be cautious when using it for billing or exact accounting.

2. Assuming NetFlow v5 and v9 are interchangeable

NetFlow v5 has a fixed field structure with a defined set of columns. NetFlow v9 (and IPFIX) use templates, meaning the collector must first receive and parse the template before it can decode data records. A collector that only understands v5 will not parse v9 or IPFIX correctly.

3. Ignoring sampling in NetFlow

Sampled NetFlow (e.g., 1:100 sampling on a Cisco router) is still NetFlow, but it is not exact. The flow records represent sampled data. If accuracy matters, confirm that the device is configured for unsampled NetFlow.

4. Forgetting that IPFIX is not just “NetFlow v10”

While IPFIX is based on NetFlow v9, it is a distinct IETF protocol with its own specification, transport options, and extensibility model. Treating IPFIX as identical to NetFlow v9 can lead to parsing errors when enterprise-specific IEs are present.

Flow Analysis with Netdata

Netdata’s built-in flow analyzer ingests all three protocols - NetFlow v5/v7/v9, IPFIX, and sFlow v5 - on a single UDP listener. It normalizes sampling rates across protocols, so you can mix NetFlow and sFlow exporters in the same deployment and still get coherent visualizations.

Key capabilities:

• Top talkers by source and destination IP, with GeoIP and ASN enrichment.
• Sankey diagrams for traffic flow visualization between endpoints.

• Geographic maps mapping traffic to physical locations.
• Time-series metrics for traffic volume, flow counts, and bandwidth over time.

This means you do not need separate collectors for NetFlow, IPFIX, and sFlow. Netdata network monitoring normalizes all three into a unified view, which is particularly useful in heterogeneous environments where different device vendors use different export protocols.

FAQ

Is IPFIX better than NetFlow?

IPFIX is more extensible and vendor-neutral than NetFlow, making it the preferred choice for new multi-vendor deployments. However, NetFlow v5 remains the most widely supported legacy format. If your devices support IPFIX, use it. If they only support NetFlow v5 or v9, that is still perfectly useful for traffic analysis.

Can sFlow replace NetFlow?

Not in all scenarios. sFlow is excellent for high-speed traffic estimation with low device overhead, but it is statistical, not exact. If you need precise flow records for billing, compliance, or security forensics, NetFlow or IPFIX in unsampled mode is the right choice. For capacity planning and anomaly detection on high-speed links, sFlow is often sufficient and more scalable.

What sampling rate should I use for sFlow?

The ideal sampling rate depends on link speed and traffic volume. Common guidelines range from 1:1,000 for 1Gbps links to 1:10,000 or higher for 10Gbps+ links. Lower sampling rates improve accuracy but increase device overhead. Test with your specific traffic patterns to find the right balance.

Do NetFlow and sFlow use the same port?

Not necessarily. The default and most common port for NetFlow and IPFIX is UDP 2055, but this is configurable. sFlow typically uses UDP 6343. Both are configurable on both the exporter and collector. Netdata’s flow analyzer listens on a single UDP port and can accept all three protocols on that port.

Can I use NetFlow and sFlow on the same network?

Yes, and many large networks do. A common pattern is sFlow on high-speed core switches and NetFlow or IPFIX on edge routers and firewalls. As long as your collector supports all three - as Netdata does - you can correlate data from both perspectives in a single view.