NetFlow, IPFIX, and sFlow: A Practical Guide

If you're deploying network flow monitoring in an enterprise environment, you'll encounter three major flow export protocols: NetFlow, IPFIX, and sFlow. They all serve the same high-level purpose — exporting data about network conversations to a collector — but they differ in important ways that affect deployment decisions, data fidelity, and analytical capabilities.

NetFlow

NetFlow was developed by Cisco and released in 1996. It remains the most widely supported flow protocol in enterprise networking equipment, and its version 9 variant became the de facto standard before IPFIX displaced it as the official IETF standard.

How NetFlow Works

NetFlow operates on the concept of a flow: a sequence of packets that share the same 5-tuple (source IP, destination IP, source port, destination port, protocol). The router or switch maintains a flow cache, and when a flow ends (via TCP FIN/RST, or a cache timeout), it exports a flow record to the configured collector.

The key fields in a standard NetFlow v9 record include:

Flow source/destination IP
Source/destination port
IP protocol
Byte count
Packet count
Flow start/end timestamps
Input/output interface index
TCP flags
DSCP/ToS marking
Next-hop IP

NetFlow Versions

• NetFlow v5: Fixed 7-tuple format. Wide hardware support but no IPv6, no MPLS, no custom fields. Legacy use only.
• NetFlow v9: Template-based format. Extensible to new field types, supports IPv6 and MPLS. The standard for modern deployments.
• Flexible NetFlow (FNF): Cisco's extension of v9 that allows fully custom flow definitions with operator-selected fields.

Basic Cisco IOS Configuration

! Define a flow record
flow record FLOWSIGHT-RECORD
 match ipv4 protocol
 match ipv4 source address
 match ipv4 destination address
 match transport source-port
 match transport destination-port
 collect counter bytes
 collect counter packets
 collect timestamp sys-uptime first
 collect timestamp sys-uptime last
 
! Define a flow exporter
flow exporter FLOWSIGHT-EXPORTER
 destination 10.0.1.50
 transport udp 2055
 source GigabitEthernet0/0
 
! Define a flow monitor
flow monitor FLOWSIGHT-MONITOR
 record FLOWSIGHT-RECORD
 exporter FLOWSIGHT-EXPORTER
 cache timeout active 60
 
! Apply to interface
interface GigabitEthernet0/1
 ip flow monitor FLOWSIGHT-MONITOR input
 ip flow monitor FLOWSIGHT-MONITOR output

IPFIX

IPFIX (IP Flow Information Export) is the IETF standardization of NetFlow v9, defined in RFC 7011. It's structurally very similar to NetFlow v9 — template-based, extensible, with a rich field vocabulary — but it carries the authority of an open standard rather than a vendor specification.

IPFIX vs. NetFlow v9

For most practical purposes, IPFIX and NetFlow v9 are interchangeable. The key differences:

• IPFIX has a broader standard field registry, including enterprise-defined private fields that vendors can include without conflicting with the standard namespace.
• IPFIX is vendor-neutral. Non-Cisco vendors (Juniper, Palo Alto, VMware, etc.) are more likely to implement IPFIX than NetFlow v9, though many support both.
• IPFIX has stronger options template support, enabling richer metadata export (sampling configuration, device information).

Modern collectors that support NetFlow v9 almost universally support IPFIX as well. If you're deploying new infrastructure, IPFIX is the forward-looking choice.

Juniper IPFIX Configuration

# Junos IPFIX configuration
set forwarding-options flow-export-profile FLOWSIGHT-PROFILE flow-active-timeout 60
set forwarding-options flow-export-profile FLOWSIGHT-PROFILE flow-inactive-timeout 15
set forwarding-options flow-export-profile FLOWSIGHT-PROFILE template-refresh-rate 20
set forwarding-options flow-export-profile FLOWSIGHT-PROFILE version ipfix
 
set forwarding-options flow-export-profile FLOWSIGHT-PROFILE destination 10.0.1.50 port 4739
set forwarding-options flow-export-profile FLOWSIGHT-PROFILE source-address 10.0.1.1
 
set class-of-service interfaces ge-0/0/1 unit 0 forwarding-class FLOWSIGHT-PROFILE

sFlow

sFlow (Sampled Flow) takes a fundamentally different approach. Rather than tracking flows in a cache, sFlow samples individual packets at a defined rate — for example, one in every 1,000 packets — and exports both packet header data and interface counter statistics.

sFlow's Core Difference: Sampling

The sampling model has important implications:

Pros of sFlow:

• Linear scalability. CPU and memory requirements scale with sampling rate, not with the number of active flows. At high traffic volumes, this is a significant advantage.
• No flow cache state. Devices don't need to maintain per-flow state, making sFlow more suitable for hardware-limited devices.
• Packet-level detail. Sample records include raw packet header data, which can include fields that flow-cache-based protocols don't expose.
• Wide vendor support. sFlow is supported by many switching vendors (Arista, Brocade, HP/Aruba) that don't support NetFlow.

Cons of sFlow:

• Statistical, not exact. Flow volumes are estimates derived from the sampling ratio. For fine-grained anomaly detection, the statistical uncertainty can affect model accuracy.
• Short flows may be missed. A conversation that completes in fewer packets than the sampling interval may never be sampled at all.

When to Use sFlow

sFlow is the right choice when:

• Your switching hardware doesn't support NetFlow or IPFIX
• Traffic volumes are high enough that per-flow state is a performance concern
• You need vendor-neutral support across a heterogeneous switching environment

For core routing infrastructure where precision matters, NetFlow v9 or IPFIX is generally preferred.

Choosing the Right Protocol

| Factor | NetFlow v9 | IPFIX | sFlow | |---|---|---|---| | Cisco hardware | Native | Supported | Limited | | Non-Cisco hardware | Variable | Better | Best | | Data accuracy | Exact | Exact | Statistical | | High traffic volumes | Cache pressure | Cache pressure | Scales well | | IPv6 support | Yes | Yes | Yes | | Cloud collectors | Supported | Supported | Supported |

Collector Considerations

All three protocols export data over UDP by default — which means records can be lost if the collector is unavailable or overwhelmed. For production deployments:

• Deploy collectors with sufficient buffer capacity to handle peak rates
• Consider redundant collector configurations (dual export)
• Monitor collector drop rates as part of operational health

FlowSight accepts NetFlow v9, IPFIX, and sFlow v5/v10 from any exporting device. Records are normalized on ingestion into a unified schema, so mixed environments — Cisco core routers exporting NetFlow, Arista ToR switches exporting sFlow — flow into a single analysis engine without configuration gymnastics.