sFlow vs NetFlow vs IPFIX:
A Consultant's Guide to Flow Protocols

When a client hires you to deploy DDoS detection, one of the first questions you need to answer is: "What kind of flow data can their network equipment export?" The answer determines how you configure the detection platform, what visibility you will have, and whether any additional hardware or configuration is needed.

There are three flow protocols you will encounter in the field: sFlow, NetFlow, and IPFIX. They all do roughly the same thing (export summaries of network traffic from routers and switches to a collector), but they work differently and show up on different hardware. This guide covers what you actually need to know as a consultant deploying these in client environments.

sFlow: Packet Sampling at the Hardware Level

sFlow (sampled flow) works by capturing a copy of every Nth packet at the ASIC level and sending it to a collector. It does not track flows as continuous conversations between two endpoints. Instead, it takes statistical samples and lets the collector reconstruct traffic patterns from those samples.

How it works

The router or switch is configured with a sampling rate (for example, 1-in-1000 or 1-in-4096). For every N packets that cross an interface, one is copied and forwarded to the sFlow collector as a UDP datagram. The sample includes the full packet header (typically the first 128 bytes) plus metadata about the interface it crossed.

Which hardware supports it

sFlow has broad support across switching and routing platforms. You will find it on most modern hardware from vendors including Juniper, Arista, Dell, HP/Aruba, Mellanox, and many others. It is especially common on data center switches where ASIC-level sampling is efficient and adds no measurable performance overhead.

MikroTik RouterOS also supports sFlow, which matters because MikroTik is extremely common in hosting provider and ISP environments where you will be deploying DDoS detection.

Sampling rate considerations

The sampling rate is the single most important configuration decision for sFlow in a DDoS detection context. A rate of 1-in-1000 on a 10 Gbps link gives you good statistical accuracy for detecting volumetric attacks. On 100 Gbps links, 1-in-4096 or 1-in-8192 is common and still provides adequate visibility for flood detection.

The tradeoff is straightforward: lower sampling rates (sampling fewer packets) reduce the load on the collector but make it harder to detect smaller attacks. Higher sampling rates give better accuracy but generate more flow data. For DDoS detection specifically, the attacks you care about are large enough that even aggressive sampling rates will catch them clearly.

NetFlow: Cisco's Flow Record Protocol

NetFlow was developed by Cisco and works fundamentally differently from sFlow. Instead of sampling individual packets, NetFlow tracks complete flows. A flow is defined as a unidirectional sequence of packets sharing the same source IP, destination IP, source port, destination port, IP protocol, type of service, and input interface.

Versions you will encounter

There are two versions of NetFlow that still matter in practice:

• NetFlow v5. The legacy format. Fixed record structure with a specific set of fields. Still widely deployed because it is simple and every collector supports it. Limited to IPv4 and does not support variable-length fields or templates.
• NetFlow v9. Template-based format that supports IPv6, MPLS labels, BGP attributes, and other extended fields. Much more flexible than v5. This is what you want when deploying new configurations.

Which hardware supports it

NetFlow originated at Cisco, and Cisco routers and switches have the deepest NetFlow support. Most Cisco IOS, IOS-XE, IOS-XR, and NX-OS platforms support NetFlow v5 and v9. Many Cisco devices also support what Cisco calls "Flexible NetFlow," which is essentially NetFlow v9 with custom templates.

Non-Cisco vendors sometimes implement NetFlow v5 or v9 as well. Juniper calls their implementation "J-Flow" (which is NetFlow v5/v9 compatible). Some Huawei equipment supports NetFlow-compatible export. However, if the client's network is not Cisco-based, you are more likely to encounter sFlow or IPFIX as the native option.

Flow cache and export timing

One important difference from sFlow: NetFlow maintains a flow cache on the router itself. Flows are tracked in memory and only exported to the collector when they finish (FIN/RST), when they time out (active or inactive timeout), or when the cache is full. This means there is an inherent delay between when traffic occurs and when the collector sees it.

For DDoS detection, this delay matters. A default active timeout of 30 minutes means a long-lived flood could go unreported for up to 30 minutes. You should always configure active timeouts to 60 seconds (or less) on devices exporting NetFlow for DDoS detection purposes. Inactive timeouts of 15 seconds are standard.

IPFIX: The IETF Standard

IPFIX (IP Flow Information Export) is the IETF-standardized version of flow export. It was heavily based on NetFlow v9 and is sometimes described as "NetFlow v10," though it is technically a separate standard (RFC 7011). If you understand NetFlow v9, IPFIX will feel familiar.

How it differs from NetFlow v9

IPFIX uses the same template-based approach as NetFlow v9 but adds support for variable-length information elements, enterprise-specific fields, and SCTP transport (in addition to UDP and TCP). In practice, most IPFIX deployments use UDP transport, so the transport difference rarely matters in the field.

The bigger practical difference is vendor support. Many modern routers and switches that do not support Cisco's NetFlow natively will support IPFIX as the standards-based alternative.

Which hardware supports it

IPFIX support is broad and growing. Juniper (via inline flow monitoring on MX and QFX platforms), Nokia, Huawei, and most modern routing platforms support IPFIX natively. Many vendors that previously only supported sFlow have added IPFIX in recent firmware versions.

Which Protocol to Use in Practice

When you are sitting in front of a client's network and need to decide which flow protocol to configure, the decision tree is usually simple:

• If the client has Cisco gear: Use NetFlow v9 (or Flexible NetFlow). It is native, well-supported, and every collector handles it. Set active timeouts to 60 seconds.
• If the client has Juniper, Arista, or modern switching: sFlow is likely the easiest path. It is fast to configure, works at the ASIC level, and has zero performance impact. IPFIX is also an option on Juniper MX/QFX if the client prefers flow-based export over sampling.
• If the client has a mixed vendor environment: This is where IPFIX shines. As the IETF standard, it is the most universally supported option across different vendors. Configure all devices to export IPFIX and you get a consistent data format at the collector.
• If the client has MikroTik: sFlow is well-supported on RouterOS. Traffic Flow (MikroTik's NetFlow implementation) is also available but sFlow tends to be simpler to configure and lighter on the router's CPU.

How Flowtriq Handles All Three

The ftagent ingests sFlow, NetFlow v5, NetFlow v9, and IPFIX natively on a single listener. You do not need to choose one protocol for the entire deployment. If a client has Cisco routers exporting NetFlow and Arista switches exporting sFlow, both feed into the same agent and the same dashboard.

This matters in practice because most client environments are heterogeneous. The edge routers might be Juniper, the top-of-rack switches might be Arista, and there might be a legacy Cisco router in a closet somewhere. Having a collector that normalizes all three protocols into a unified view saves you from running separate detection stacks per flow type.

For more detail on how flow-based detection compares to other approaches, see our post on NetFlow vs sFlow vs packet inspection.

Practical Knowledge for the Field

Understanding flow protocols is table-stakes knowledge for anyone deploying DDoS detection. When a client asks "will this work with our switches?" you need to answer confidently. When the flow data looks wrong in the dashboard, you need to know whether the problem is a sampling rate issue, a timeout configuration, or a version mismatch.

This is exactly the kind of practical, deployment-focused knowledge that the Certified Flowtriq Consultant (CFC) exam covers. Flow protocol configuration, troubleshooting, and best practices are part of the exam because they are part of every real deployment.

Related