sFlow vs NetFlow vs IPFIX for DDoS Detection: Which to Use

For DDoS detection, sFlow, NetFlow and IPFIX all work. Use whichever your router supports natively, and tune sampling and export timers instead of switching protocols. sFlow is usually the fastest and most robust under spoofed floods. IPFIX is the best-standardized flow format. NetFlow v9 is the common denominator on older gear.

The protocol matters less than three settings: the sampling rate, the flow export timeouts, and whether the exporter can survive the attack it is reporting. This article covers each of them, then which platforms support what, and working configs.

How the three protocols differ

sFlow does not track flows. The agent picks 1 in N packets at random, copies the first bytes of the header, and sends it in a datagram. It also exports interface counters on a polling interval. There is no cache to fill and no timer to wait for.

NetFlow v5 is IPv4-only with a fixed record layout. Avoid it on any network that carries IPv6 traffic, because v5 cannot represent it.

NetFlow v9 and IPFIX are template-based. IPFIX is the IETF standardization of v9 and adds variable-length fields and enterprise-specific elements. For detection purposes the two are close to equivalent. Collectors treat them the same way.

Sampling: what it does to detection

All of these protocols are normally used with packet sampling on backbone interfaces. Unsampled flow export at 10G+ is rarely practical on a router.

The collector multiplies sampled counters by the sampling rate to estimate real traffic. This is a statistical estimate, and its error shrinks as the number of samples grows.

A rough way to check whether your rate is adequate:

samples per second = (attack pps toward one IP) / sampling rate

At 1:1000, a 50,000 pps attack on one address gives about 50 samples per second. That is plenty to detect it. A 5,000 pps attack gives about 5 samples per second, which is noisy over a one-second window but fine over 5–10 seconds. If you need to catch small attacks on individual hosts, such as low-rate floods against a game server, use a lower sampling rate (1:512 or 1:256) on edge interfaces where you can afford it.

Practical guidance:

• Sample on ingress of transit, peering and customer-facing interfaces. Do not sample the same traffic on both ingress and egress, or you will double count.
• Use the same rate on all interfaces of one router where possible. Mixed rates are supported by collectors, but they make debugging harder.
• Set thresholds in terms of estimated pps and bps per destination IP or prefix, not per interface. See our earlier article on NetFlow DDoS detection thresholds and baselines for baseline methods.
• Do not expect sampled data to produce exact byte counts for forensics. It is for detection and classification.

Latency: where the delay comes from

Detection latency has three parts: exporter delay, network transit to the collector, and collector analysis window.

sFlow exporter delay is close to zero. Samples are sent as they are taken, batched into datagrams that are typically flushed in well under a second on busy links. On quiet links, an agent may wait to fill a datagram, so a low-traffic interface can be slower to report.

NetFlow/IPFIX exporter delay is controlled by the active timeout and inactive timeout. An attack flow that never ends is not exported until the active timeout fires. Some vendors ship long defaults (tens of minutes in some implementations). If you leave a long default in place, your detection is delayed by that much. Set the active timeout to somewhere between 10 and 60 seconds, and the inactive timeout to 10–15 seconds.

Shorter timeouts raise export volume, so size your collector accordingly.

Accuracy and robustness under attack

This is the part many comparisons skip. Flow-cache protocols have a failure mode that sFlow does not.

A randomly spoofed flood creates a new 5-tuple for almost every packet. A cache-based exporter then has to create a huge number of flow entries. Depending on the platform, this can exhaust the flow table, drop records, or load the CPU or line card. The attack then degrades the very telemetry you rely on to detect it. Sampling reduces this problem, since only sampled packets create entries. It does not remove it. A stateless sampler like sFlow has no such cache.

On the other side:

• sFlow gives you actual packet header bytes. You can see exact TCP flags, source ports, packet sizes and sometimes payload prefixes. That is helpful for building FlowSpec rules.
• NetFlow/IPFIX records usually carry cumulative TCP flags (OR of all flags in the flow), which is less precise. They do give you exporter-side data such as AS numbers, next hop and BGP communities, if you configure those fields in the template.

Neither is better for every case. If you plan to automate BGP FlowSpec rules from detections, packet-level detail from sFlow is convenient, but IPFIX with the right fields works too.

Which routers support which

Support varies by model and software release, so treat this as a starting point and check release notes.

The rule of thumb: Cisco and MikroTik routers are in the NetFlow/IPFIX world. Arista and many white-box switches are in the sFlow world. Juniper can do either.

Configuration examples

All examples send to a collector at 192.0.2.10. Use the real collector address of your deployment.

Juniper MX: inline IPFIX

set services flow-monitoring version-ipfix template ipv4 flow-active-timeout 15
set services flow-monitoring version-ipfix template ipv4 flow-inactive-timeout 10
set services flow-monitoring version-ipfix template ipv4 template-refresh-rate seconds 30
set services flow-monitoring version-ipfix template ipv4 ipv4-template

set chassis fpc 0 sampling-instance SAMPLE-1

set forwarding-options sampling instance SAMPLE-1 input rate 1000
set forwarding-options sampling instance SAMPLE-1 family inet output flow-server 192.0.2.10 port 2055
set forwarding-options sampling instance SAMPLE-1 family inet output flow-server 192.0.2.10 version-ipfix template ipv4
set forwarding-options sampling instance SAMPLE-1 family inet output inline-jflow source-address 192.0.2.1

set interfaces xe-0/0/0 unit 0 family inet sampling input

Juniper: sFlow (on platforms that support it)

set protocols sflow agent-id 192.0.2.1
set protocols sflow collector 192.0.2.10 udp-port 6343
set protocols sflow polling-interval 20
set protocols sflow sample-rate ingress 1000
set protocols sflow interfaces xe-0/0/0.0

Cisco IOS-XE: Flexible NetFlow with sampling

flow exporter NIXMON
 destination 192.0.2.10
 source Loopback0
 transport udp 2055
 export-protocol ipfix
!
flow record DDOS-REC
 match ipv4 source address
 match ipv4 destination address
 match ipv4 protocol
 match transport source-port
 match transport destination-port
 match interface input
 collect transport tcp flags
 collect counter bytes long
 collect counter packets long
!
flow monitor DDOS-MON
 exporter NIXMON
 record DDOS-REC
 cache timeout active 15
 cache timeout inactive 10
!
sampler SMP-1000
 mode random 1 out-of 1000
!
interface TenGigabitEthernet0/0/0
 ip flow monitor DDOS-MON sampler SMP-1000 input

If your release does not support export-protocol ipfix, use netflow-v9.

MikroTik RouterOS: Traffic Flow

/ip traffic-flow set enabled=yes interfaces=ether1 \
    active-flow-timeout=30s inactive-flow-timeout=10s
/ip traffic-flow target add dst-address=192.0.2.10 port=2055 version=9

Use version=ipfix if your collector prefers it. Note that RouterOS Traffic Flow does not sample by default, so on high-pps links watch CPU load closely. Do not forget the connection-tracking cost.

Linux: sFlow with hsflowd

sflow {
  collector { ip=192.0.2.10 udpport=6343 }
  pcap { dev=eth1 }
  sampling=1000
  polling=20
}

For NetFlow from a mirror port, softflowd works:

softflowd -i eth1 -v 9 -n 192.0.2.10:2055 -t maxlife=60

Common mistakes

1. Leaving the default active timeout. This is the most common reason NetFlow detection feels slow.
2. Sampling both directions. Estimated traffic gets doubled, and thresholds fire too early.
3. Using NetFlow v5 with IPv6 traffic. Attacks on IPv6 space are invisible.
4. Forgetting the exporter's source address. If the collector sees the sender as an unexpected IP, the sampling rate lookup and router identification will break.
5. Thresholds per interface rather than per destination. A 2 Gbps flood against one /32 can be a small part of an interface's total traffic.
6. Dropped UDP exports. Check ACLs, control-plane policing and collector socket buffers. Flow export is UDP, and loss is silent.
7. Not testing. Generate controlled traffic toward a test IP and verify that the estimated pps matches what you sent.

Choosing in practice

• You have Cisco or MikroTik edge routers: use NetFlow v9 or IPFIX with short timeouts.
• You have Arista or similar switches: use sFlow.
• You have Juniper MX: inline IPFIX is a solid default, and sFlow is an option on some platforms.
• You have mixed vendors: use a collector that accepts all formats, so each device exports what it does best.

NixMon accepts NetFlow v5/v9, IPFIX and sFlow, with sub-second traffic analytics and per-IP or per-prefix bps/pps thresholds. Detections can trigger BGP blackhole (RTBH), BGP FlowSpec, the on-prem NixGuard firewall, or NixGuard Edge. Mixed-vendor networks can send everything to one place. You can test it with your own routers through the 15-day free trial, with no credit card.