What Is NetFlow? Flow Monitoring for Bandwidth and Security

The link graph says 40% utilization and the office still says the internet is slow. An interface counter can tell you how much traffic crossed a port, but not who sent it, where it went or which application it belonged to. NetFlow answers those three questions from the router itself, with no probe and no packet capture, and this post covers what it records, how the versions differ and where flow data fits next to SNMP and logs.

What NetFlow Is

NetFlow is a Cisco protocol that turns traffic passing through a router or switch into summary records. The device watches packets, groups them into flows and ships the summaries to a collector. The collector stores them, and an analyzer turns them into charts, top-talker lists and alerts.

A flow is a one-way stream of packets that share the same key fields. Cisco's IOS documentation defines the original seven: source IP address, destination IP address, source port, destination port, Layer 3 protocol, type of service and the input interface. Every packet that matches on all seven lands in the same flow record.

The record carries what those packets added up to: byte and packet counts, start and end timestamps, TCP flags and the output interface. What it never carries is payload. NetFlow doesn't see the body of an email or the contents of a file transfer, which keeps the data small and keeps it out of privacy arguments.

The Cisco v9 specification, RFC 3954, puts it in one sentence: a flow is "a unidirectional sequence of packets with some common properties that pass through a network device." Unidirectional matters: one web request is two flows, and the analyzer stitches them back together.

If you've read our guide on checking bandwidth usage, flow data is the layer that turns "the link is busy" into "the link is busy because of this host and this port."

How a Flow Gets Made and Shipped

The router keeps active flows in a flow cache. A flow leaves the cache when it goes quiet for 15 seconds, or when it has been running for 30 minutes, which are Cisco's default inactive and active timeouts. Long downloads therefore arrive as a chain of 30-minute records, and the analyzer adds the pieces back up.

When a flow expires, the router packs it into an export datagram with other expired flows and sends it over UDP to the collector. In NetFlow v5 that datagram is a 24-byte header plus up to 30 records of 48 bytes each, per Cisco's collector documentation. UDP means no retransmission: if the collector is down or the packet drops, that record is gone.

Three things follow from this that trip up new deployments:

• A collector that can't keep up silently loses data, and the graphs look fine. Watch the collector's own drop counters.
• Timestamps come from the exporter, so a router with a wrong clock produces flows that appear to happen in the past or the future. NTP on every exporter is part of the setup, not an afterthought.
• Exporting from both ends of the same link counts every conversation twice. Pick one side, usually the one closer to the internet edge.

NetFlow Versions, IPFIX and sFlow

You'll meet three formats in the wild. Their names cause more confusion than the protocols do.

v5 is still everywhere because every collector understands it. Its limit is the fixed layout: no IPv6, no MPLS labels, no way to add a field.

v9 fixed that with templates. The exporter sends a template that says "my records contain these fields in this order," then sends data records that follow it. The collector needs the template before it can read anything, so v9 collectors show a blank first minute until the template arrives, and they show nothing at all if the template packet was the one that got dropped.

IPFIX took the v9 template idea to the IETF. RFC 7011 sets the version field to 10, "incrementing by one the version used in the NetFlow services export version 9," and adds transports beyond UDP. If a vendor's data sheet says "NetFlow v10," it means IPFIX.

sFlow is the odd one out. Instead of tracking every flow, an sFlow agent samples one packet in N, sends that packet's header, and separately polls interface counters. That scales to switches that could never keep a full flow cache, at the cost of precision: sFlow estimates a transfer's size, NetFlow counts it. For billing or forensics you want counted bytes; for spotting a top talker on a 100 Gbps core, sampling is fine.

The video below walks through the same three formats with packet examples:

What Flow Data Shows You

The first thing anyone does with a collector is sort by bytes. Top talkers, top destinations, top ports. That alone answers the slow-internet ticket most days: a backup job that drifted into business hours, a workstation syncing a personal cloud drive, a Windows update wave at 9 a.m.

Over weeks, the same data becomes capacity planning: which links grow, which applications drive it, and whether a circuit upgrade or a QoS policy is the cheaper fix.

The second use is security, and it's where flow data earns its keep on a small team. Because every conversation leaves a record, you can ask questions a firewall log can't answer:

• Which internal hosts talk to each other on ports they never used before? That's the shape of lateral movement.
• Which workstation sent 40 GB outbound to one address overnight? That's the shape of exfiltration.
• Which host connects to the same external IP every 60 seconds with a tiny payload? That's the shape of a beacon.

None of that needs the packet contents. It needs a baseline of who normally talks to whom, and flow records are the cheapest way to build one. Pair them with the logs you already keep; our log management guide covers that side.

What flow data can't do is name the file, read the email or tell you whether the 40 GB was malicious or a legitimate archive upload. It points; something else confirms.

NetFlow vs SNMP vs Packet Capture

These three get compared as if they competed. They answer different questions at different prices.

SNMP polls counters. It tells you an interface moved 3.2 GB in the last five minutes and that the switch's CPU is at 60%. It has no idea who moved the bytes. It's cheap, it runs everywhere, and it's the right tool for "is the link up and how full is it." Our SNMP OID guide covers how to read those counters.

NetFlow summarizes conversations. It tells you the 3.2 GB was 2.9 GB from one file server to one laptop over SMB. It costs a little router CPU and a collector with disk. It's the right tool for "who and what."

Packet capture records everything. It tells you what was in the SMB session. It costs a span port or a tap, a box with fast disks and a person who reads Wireshark. It's the right tool for "prove it," on one link, for a short window.

On a real ticket the sequence is SNMP first (which link), flow second (which host and application), capture last and only if a question is still open. Teams that run all three spend most of their time in the middle one.

Setting Up a Collector Without Drowning It

A working flow setup on a small network is four decisions.

Where to export from. The internet edge router sees everything that leaves and enters, which covers the slow-internet and exfiltration questions. Add the core switch for east-west visibility, and remember the double-counting rule.

Which format. Use IPFIX or v9 if the exporter and collector both speak it, because you get IPv6 and extra fields for free. Use v5 when an old router is all you have. Use sFlow when the exporter is a high-throughput switch that only offers sampling.

On the collector side there's more open-source choice than the vendor pages suggest, and this r/networking thread from November 2024 is a good starting list of what people run:

Whether to sample. Full export from a busy 10 Gbps edge can produce thousands of records per second. Sampled NetFlow, where the router inspects one packet in N, cuts collector load at the cost of missing small flows: fine for capacity graphs, less fine for beacon hunting. Start unsampled on the edge, sample on the core.

How long to keep it. Raw records are small individually and enormous in aggregate. Common practice is full-resolution records for days to a few weeks and rolled-up summaries for a year. Set retention before the disk fills, because a collector that runs out of space stops recording exactly when you'll need it.

The store-everything-or-aggregate question comes up on r/networking too. In this October 2025 thread a collector developer argues for aggregating on the way in, and the security-minded replies push back: you don't know which fields you'll need until the investigation starts.

Then verify. Copy 1 GB between two hosts you control and check that the collector shows roughly 1 GB between those addresses. If it shows 30 MB, the exporter is sampling and the analyzer isn't scaling up. If it shows nothing, check the UDP port, the collector's listener and any firewall in between.

On a fleet, the check that catches most misconfigured exporters is a script that reads each device's flow export config and compares the destination against the collector's address. OpenFrame can run that script across a client's devices and collect the output in one place.

FAQ

Is NetFlow only for Cisco devices?

The name is Cisco's, and v5 and v9 are Cisco formats, but many other vendors export v9-compatible records or IPFIX. Juniper calls its version J-Flow, and firewalls from several vendors export IPFIX directly. Any collector that reads v9 or IPFIX will take them.

Does NetFlow slow down a router?

Building flow records uses router CPU and memory, and the cost grows with the number of concurrent flows. On modern hardware with flow export in silicon the cost is small. On an older or busy device, enable sampled export first and watch CPU before going to full export.

How is NetFlow different from a firewall log?

A firewall log records decisions at one chokepoint: this connection was allowed or denied by this rule. Flow records cover every interface you export from, including traffic between internal hosts that never touches the firewall, and they carry byte counts over the life of the conversation rather than one line at connection time.

How much storage does flow data take?

It depends on flow count, not bandwidth. A quiet office produces a few million records a day; a busy campus, far more. Plan retention in tiers and check the disk after the first week rather than trusting an estimate.

Where to Start

NetFlow gives you the who and the what behind every busy link, from the router you already own, without reading a single payload. Start with IPFIX or v9 from the internet edge, point it at a collector with tiered retention, and verify with a known transfer. Then read the infrastructure monitoring guide for where flow data sits next to the rest of your monitoring, and the bandwidth usage guide above for the day-to-day questions it answers first.