SNMP & Telemetry

NetFlow vs sFlow vs IPFIX vs Streaming Telemetry: Which Should You Use?

A clear comparison of NetFlow, IPFIX, sFlow, SNMP polling and model-driven streaming telemetry, covering what each one measures, their trade-offs and how to combine them in a modern monitoring design.

On this page
  1. The two big questions: "how much?" and "who?"
  2. SNMP polling
  3. NetFlow and IPFIX
  4. sFlow
  5. Model-driven streaming telemetry
  6. Side-by-side comparison
  7. A practical combined design

"Should we use NetFlow or sFlow?" is one of the most common questions in network monitoring projects, and the honest answer is that it's often the wrong question. These technologies measure different things. A mature monitoring design usually combines several of them.

This article explains what each one does, where it shines and how they fit together.

The two big questions: "how much?" and "who?"

Network telemetry answers two different kinds of questions:

  1. How much, and how healthy? Interface utilization, errors, CPU, memory, optical levels. These are counters and gauges on the device.
  2. Who is talking to whom? Which applications, hosts and conversations make up the traffic. This is flow data.

SNMP polling and streaming telemetry mostly answer the first question. NetFlow, IPFIX and sFlow answer the second.

SNMP polling

The long-standing workhorse. A poller asks each device for counter values every few minutes and calculates rates from the differences.

Strengths - Supported by almost every device ever made - Mature tooling and MIBs for interfaces, CPU, memory, environment - Simple to reason about

Limitations - Polling intervals are typically 1–5 minutes, so short bursts get averaged away - Polling many objects on large devices can load the control plane - Pull-based: the collector must reach every device

Use it for: baseline health and utilization across the whole estate, especially older or lower-end devices.

NetFlow and IPFIX

NetFlow, originally developed by Cisco, groups packets into flows defined by shared attributes, classically the 5-tuple: source IP, destination IP, source port, destination port and protocol. The device keeps a flow cache and exports flow records when flows end or time out.

NetFlow v5 has a fixed format (IPv4 only). NetFlow v9 introduced templates, so exporters can define which fields they send. IPFIX (defined in RFC 7011) is the IETF standard based on NetFlow v9. It is template-based, extensible and vendor-neutral.

Strengths - Rich per-conversation detail: who, what application, how much - Great for top talkers, application mix, security investigations and capacity planning - IPFIX supports many fields, including IPv6, MPLS labels and application IDs on some platforms

Limitations - Flow caches consume device memory and CPU. Many high-speed platforms rely on sampling - Timing depends on active and inactive timeouts, so flow data is not real-time to the second - Flow volume can be large and needs a capable collector

Use it for: traffic analysis, internet edge and WAN visibility, security forensics and chargeback.

sFlow

sFlow takes a different approach: packet sampling. The device forwards a sample of packet headers, say 1 in every 2,048 packets, along with periodic interface counters, straight to the collector. There is no flow cache on the device. The collector reconstructs traffic statistically.

Strengths - Very light on the device, which makes it well suited to high-speed data-center switches - Includes interface counters, so it provides some "how much" data too - Sees Layer 2 information, including non-IP traffic

Limitations - Statistical: very small flows may not be sampled at all - Accuracy depends on the sampling rate and traffic volume

Use it for: high-speed data-center fabrics where you need traffic visibility without loading switches.

Sampled NetFlow vs sFlow: many routers also support sampled NetFlow/IPFIX. The difference is where aggregation happens. Sampled NetFlow still builds flows on the device, while sFlow ships raw samples and lets the collector do the work.

Model-driven streaming telemetry

Modern platforms can push data to collectors continuously instead of waiting to be polled. Data is defined by YANG models (vendor-native or OpenConfig) and typically transported over gRPC/gNMI, with encodings such as protobuf or JSON.

Two subscription styles matter: - Periodic (sample): send the value every N seconds, often 10–30 seconds or faster. - On-change: send only when the value changes, ideal for state like interface status or BGP sessions.

Strengths - Much higher resolution than SNMP polling, so microbursts and short events become visible - More efficient at scale: structured data, push-based, less control-plane overhead than heavy SNMP walks - Consistent structure through OpenConfig models across vendors

Limitations - Requires newer platforms and software versions - More complex collector stack (for example gNMI collectors feeding a time-series database) - Vendor model coverage varies

Use it for: core and data-center devices where fine-grained visibility matters, and as the long-term successor to SNMP polling on modern gear.

Side-by-side comparison

SNMP polling NetFlow/IPFIX sFlow Streaming telemetry
Answers How much / health Who / what Who / what + counters How much / health / state
Model Pull Push (flow records) Push (samples) Push (subscriptions)
Typical resolution 1–5 min Flow timeouts (sec–min) Near real time, sampled Seconds or on-change
Device impact Moderate at scale Moderate (flow cache) Low Low–moderate
Device support Universal Routers, firewalls, many switches Many DC switches Modern platforms

A practical combined design

For a typical enterprise data center with a WAN and internet edge:

  1. SNMP polling everywhere as the baseline for health and utilization, using SNMPv3.
  2. Streaming telemetry on core and spine/leaf devices that support it, for high-resolution interface and state data.
  3. sFlow on data-center switches for east-west traffic visibility.
  4. NetFlow/IPFIX on WAN routers, internet edge and firewalls, where conversation detail matters for troubleshooting and security.
  5. SNMP traps and syslog for events, correlated in your fault-management platform.

Performance platforms such as IBM SevOne can ingest several of these sources side by side. That lets you view SNMP metrics, flow data and telemetry for the same interface in one place, which is what engineers need during an incident.

Key takeaways

  • Counters and flows answer different questions. You usually need both.
  • NetFlow/IPFIX give rich conversation detail. sFlow gives lightweight sampled visibility at high speed.
  • Streaming telemetry is the modern replacement for SNMP polling on newer devices, with far better resolution.
  • Design for the questions your team asks, then choose the telemetry that answers them at the right cost.