sFlow vs NetFlow vs IPFIX: Network Monitoring Protocols Compared

Every serious network needs traffic visibility, and the three protocols you will meet are sFlow, NetFlow and IPFIX. They are often used interchangeably, but they are architecturally different: sFlow is packet sampling performed on the switch ASIC with counters, while NetFlow/IPFIX are flow-export protocols that build flow records. Choosing the wrong one can leave you blind to DDoS attacks or drown your collector in data. This article compares the three, shows configuration examples on Cisco and Arista, and gives practical guidance for traffic analysis, capacity planning and security monitoring.

The distinction matters most at the two extremes of the network. In a large leaf-spine fabric with hundreds of ToR switches, asking every switch to maintain a full flow cache is expensive and fragile; statistical sampling scales almost for free. At a single internet edge router where you need to see every conversation for forensics, the opposite is true — sampling can miss the one flow that matters. Understanding where each mechanism fits is the whole game.

The Three Protocols in Brief

• NetFlow (Cisco, v5/v9): the switch/router builds flows (5-tuple sessions) and exports them to a collector over UDP 2055. v9 adds templates.
• IPFIX (RFC 7011): the IETF-standardized successor of NetFlow v9, widely supported (Cisco, Huawei, Juniper, Arista).
• sFlow (RFC 3176): statistical packet sampling (e.g., 1 in 8192) done in hardware, plus periodic interface counter polling - no flow state on the device.

How Flow Export Actually Works

NetFlow and IPFIX share a pipeline that runs entirely inside the device:

• Observation. Every packet is matched against a cache key — classically the 5-tuple of source IP, destination IP, source port, destination port and protocol, plus ingress interface and ToS.
• Aggregation. A new key creates a cache entry; a matching packet updates counters and timestamps rather than exporting again. This is why 10,000 packets on one connection produce one record, not 10,000.
• Expiry. A flow is exported when it goes idle (inactive timeout, typically 15–60 seconds), runs long (active timeout, typically 1–60 minutes), or when the cache fills and the oldest entry is flushed early.
• Transport. Records are bundled into UDP datagrams and sent to one or more collectors. UDP is lossy by design — there is no retransmission — so collectors are sized with headroom.

Because a flow cache is real state, it consumes memory and CPU. On a busy core router with millions of concurrent flows, the cache can fill, forcing early expiry that inflates export volume and blurs the picture. Vendors mitigate this with flexible keys (aggregating on fewer fields) and sampling, but the fundamental cost remains: flow export scales with flow count, not just with bandwidth.

How sFlow Sampling Works

sFlow inverts the model. There is no cache. Instead, the ASIC is configured with a sampling rate, and when a counter hits that threshold it copies up to the first 128–256 bytes of the packet into an sFlow datagram. Alongside the samples, an sFlow agent polls interface counters (bytes, packets, errors, discards) on a fixed interval and exports those too.

The two streams serve different purposes. The sampled packets tell you where traffic is going — top talkers, protocols, AS paths, source/destination prefixes. The counter samples tell you how much traffic there is and whether interfaces are dropping. Together they reproduce most of what a flow monitor shows, at a fraction of the device cost, which is why sFlow is the default choice for fabric-wide visibility.

Packet Sampling vs Flow Records: The Deeper Difference

The practical consequences of the two designs are worth spelling out, because they decide which tool answers which question.

• Accuracy. A flow monitor counts every packet, so its byte and packet totals are exact. sFlow extrapolates: a 1-in-8192 sample of a 100 Gbps link produces roughly 12,200 samples per second, and any estimate derived from them carries statistical error. For capacity planning that error is acceptable; for billing or strict accounting it is not.
• Latency for detection. Flow export waits for a timeout before the record appears, so a short attack can be over before the first record reaches the collector. sFlow datagrams carry timestamps and are pushed continuously, so pipeline detectors see anomalies within a second or two.
• Cardinality. Flow caches degrade under high cardinality — port scans and spoofed-source floods create millions of tiny flows and can flush the cache. sFlow has no cache to exhaust, only a sampling budget.
• Payload. Neither protocol exports payload, but sFlow's packet headers include the sampled IP header, so some detectors can act on TTLs, TCP flags and fragments directly in the exported data.

NetFlow v5 vs NetFlow v9 vs IPFIX

Three generations of the same idea are still in production, so it pays to know which one you are configuring.

• NetFlow v5 is fixed-format: IPv4 only, 20+ fields, no IPv6, no MPLS labels, no templates. It is simple and universally understood but has no room for anything modern.
• NetFlow v9 (RFC 3954) introduced templates: the exporter describes the record layout in a template packet, and the collector applies it to subsequent data packets. This supports IPv6, MPLS, BGP next-hop and vendor extensions, at the cost of complexity — a collector that misses a template cannot decode the data.
• IPFIX (RFC 7011) standardised the v9 template model under the IETF, added variable-length fields, structured data and better enterprise-extension handling. Multivendor shops should standardise on IPFIX where the hardware supports it.

Comparison Table

Configuring sFlow on Arista EOS

switch(config)# sflow sample 16384
switch(config)# sflow polling-interval 30
switch(config)# sflow destination 10.0.0.5 6343
switch(config)# sflow source-interface Management1
switch(config)# sflow run

sample 16384 = sample 1 packet in 16384; polling-interval 30 exports interface counters every 30 seconds.

Lower the sample rate when you need finer resolution. A 1-in-16384 rate on a 10 Gbps port yields only a few hundred samples per second, which is fine for trend analysis but coarse for short bursts; 1-in-1024 is a common compromise on access ports where the traffic volume is small. Verify the configuration with show sflow, which lists the agent address, destination, sample rate and a counter of exported datagrams, and confirm the collector is receiving with sflowtool -l 6343 on the collector host.

Configuring NetFlow on Cisco IOS

flow record FLOW-1
 match ipv4 source address
 match ipv4 destination address
 match transport source-port
 match transport destination-port
 collect transport tcp flags
 collect interface output
!
flow exporter EXPORTER-1
 destination 10.0.0.5
 source Loopback0
 transport udp 2055
!
flow monitor MONITOR-1
 record FLOW-1
 exporter EXPORTER-1
 cache timeout active 60
!
interface GigabitEthernet0/1
 ip flow monitor MONITOR-1 input

The flexible NetFlow configuration above is the modern, modular form: a record defines which fields to capture, an exporter defines the destination and transport, and a monitor binds the two and is applied to an interface. The cache timeout active 60 line caps long-lived flows at one minute, which keeps the collector's view fresh at the cost of more records. Verify with show flow monitor MONITOR-1 cache format table (the live cache) and show flow exporter statistics (whether datagrams are actually leaving).

Configuring IPFIX on Other Vendors

# Huawei VRP (netstream with IPFIX export)
netstream export ipfixtemplate 10.0.0.5 4739
netstream export ipfix 10.0.0.5 4739
interface GigabitEthernet0/0/1
 netstream inbound ipfix
# Juniper Junos (inline flow, IPFIX version)
set forwarding-options sampling instance SAMPLE-1
set forwarding-options sampling family inet output flow-server 10.0.0.5 port 4739 version-ipfix
set forwarding-options sampling family inet output flow-server 10.0.0.5 template-refresh-rate 60
set forwarding-options sampling family inet output interface ge-0/0/0.0
set forwarding-options sampling input rate 1024

Note the difference in Junos: sampling and flow export are combined — the device samples packets and feeds them to an inline flow engine rather than caching every packet, which is why Junos is a good middle ground between the sFlow and NetFlow extremes. Huawei calls the feature netstream and supports both NetFlow v9 and IPFIX export, selected by the command variant.

Sampling Rates and What They Cost You

Choosing a sampling rate is a trade-off between detection sensitivity and export volume. A rough rule: aim for a few hundred to a few thousand samples per second per monitored port. Below that, short flows disappear entirely and a top-talker ranking becomes noisy.

Those figures assume full-size frames; multiply by the packet rate rather than the bit rate for a truer picture, since a link carrying small packets produces far more samples at the same sampling rate. This is also the number to multiply by the average datagram size when sizing the collector's ingest bandwidth.

Sizing the Collector

Collectors fail for three reasons: CPU, disk and UDP socket buffers. Rough guidance for a headless software collector such as nfcapd or pmacct:

• sFlow at 10,000 samples/second rarely needs more than one or two cores; the work is parse-and-bucket, not stateful reassembly.
• Flow export is dominated by cache expiry storms. When active timeouts align across thousands of flows, the collector sees a burst; size for the burst, not the average.
• UDP buffers are the quiet killer. net.core.rmem_max and the collector's socket receive buffer must be raised well above the default, or the kernel silently drops datagrams and you discover it only from the exporter's "exported but not acknowledged" counters.
• Disk fills fast at full-fidelity flow capture. Plan for rolling retention (24–48 hours raw, longer if aggregated) rather than indefinite storage.

DDoS Detection Considerations

Both families of protocol feed DDoS pipelines, but they contribute differently. sFlow's continuous datagrams make it ideal for near-real-time thresholds: a detector such as FastNetMon watches incoming samples and raises an alarm when a destination prefix exceeds a packets-per-second or bits-per-second threshold, typically within seconds. Flow export contributes the precision afterwards — which ports, which TCP flags, which source countries — because it records every flow, not a sample of packets.

In practice the strongest deployments run both: sFlow enabled on every edge port of every switch for detection coverage, and IPFIX or NetFlow on the border routers for forensic detail. sFlow also has the advantage of being impossible to overload with a spoofed-source flood, since there is no cache with a finite size.

Verifying and Troubleshooting Export

Before trusting any dashboard, prove that datagrams arrive. Run sflowtool -l 6343 for sFlow or nfcapd -l 2055 -p 2055 -D for flow export on the collector, and confirm counters climb. On the device, check the exporter's statistics — if it reports datagrams sent but the collector sees nothing, the problem is a firewall rule, a routing loop for the collector's management address, or a mismatched destination port. A quick capture with our tcpdump BPF guide settles it in seconds: filter udp port 6343 or udp port 2055 or udp port 4739 and watch for outbound datagrams.

Choosing What to Run

• Fabric-wide visibility on many switches → sFlow: stateless, cheap, scales to every ToR.
• Detailed per-flow security analysis → NetFlow/IPFIX on the edge and core.
• DDoS detection at high speeds → sFlow sampling on all edge ports feeding a detection engine (FastNetMon etc.).
• Multi-vendor standardization → IPFIX (Huawei: netstream with IPFIX export; Juniper: flow-active-timeout under forwarding-options).
• Server-side or cloud traffic → neither protocol sees it; look at host-based flow accounting or a gNMI streaming telemetry path instead.

For metrics that complement flow data — interface counters, error rates, CPU — pair this with a poller. Our Zabbix SNMP monitoring guide covers scheduled OID polling and trap reception, and Prometheus with snmp_exporter is the equivalent for teams already running a Prometheus stack. For configuration and state telemetry pushed from the device rather than polled, see gNMI streaming telemetry, which is where modern NOSes such as SONiC are heading.

Practical Collector Tools

• nfdump/nfcapd - the classic NetFlow/IPFIX collector and CLI analyzer.
• sflowtool - converts sFlow to text/NetFlow for downstream tools.
• FastNetMon - open-source DDoS detector supporting sFlow, NetFlow and IPFIX.
• pmacct - a flexible accounting daemon that accepts both families and writes to SQL, Kafka or flat files.
• ElastiFlow / Akvorado - flow visualisation front ends built on Elasticsearch or ClickHouse when you need dashboards rather than CLI queries.

Frequently Asked Questions

Can I run sFlow and IPFIX on the same interface? Usually yes, and many designs do: sFlow for coarse coverage, flow export for detail on selected links. The cost is doubled exporter overhead, so keep an eye on CPU on software-forwarded platforms.

Why do my flow records show ports 0? That is normal for non-TCP/UDP traffic such as ICMP or GRE, where the transport-layer fields simply do not exist. It is not a decode error.

Why did sFlow estimated throughput differ from the interface counter? Because they measure different things — the counter sample is exact, the traffic breakdown is sampled. Use counters for totals and samples for composition.

Is either protocol encrypted? No. Both are plaintext UDP, and exported packet headers can reveal internal addressing, so restrict collector reachability and never expose ports 6343, 2055 or 4739 to the internet.

Related: Zabbix SNMP monitoring for network devices and tcpdump packet capture guide.

原文链接：https://sflow.org/