NetFlow is a network protocol, originally developed by Cisco, for collecting metadata about IP traffic flows as they pass through a router, switch, or firewall. A flow is a unidirectional sequence of packets that share the same key fields - classically the 5-tuple of source IP, destination IP, source port, destination port, and protocol. NetFlow does not capture packet payloads; it exports compact metadata records that a collector stores and analyzes, giving you visibility into who is talking to whom, how much bandwidth they are using, and when.
What Is NetFlow?
At its core, NetFlow answers a simple question: what traffic is on my network? Instead of inspecting every packet’s contents, a NetFlow-enabled device groups packets into flows based on shared attributes and then sends summary records to a collector for analysis.
The concept was introduced by Cisco in the 1990s and became one of the most widely deployed network monitoring technologies. The term “NetFlow” is often used generically to describe flow-based monitoring, but it specifically refers to Cisco’s original protocol family, which has evolved through several versions and was eventually standardized by the IETF as IPFIX.
A single flow record answers questions like:
- Which source IP sent the most data?
- Which destination port received the most packets?
- What protocol dominated traffic during a given window?
- Which internal host communicated with an external service?
Because NetFlow records are metadata only - no payload, no deep packet inspection - they are lightweight enough to export at high speed and compact enough to store for long periods. This makes flow data ideal for capacity planning, security forensics, anomaly detection, and billing.
How NetFlow Works
NetFlow monitoring follows a three-component architecture:
Exporter - A network device (router, switch, firewall, or dedicated probe) that observes traffic, groups packets into flows, and exports flow records. The exporter maintains a flow cache where active flows are aggregated. When a flow ends or times out, the record is exported.
Collector - A server or application that receives exported flow records (typically over UDP) and stores them for querying, visualization, and alerting.
Analysis layer - The tools and dashboards that turn stored flow records into actionable insight: top-talkers lists, traffic maps, anomaly alerts, and trend reports.
Here is how a packet becomes a flow record:
- A packet arrives on an interface on the exporter.
- The exporter extracts the key fields (the 5-tuple, plus ingress interface and Type of Service in NetFlow v5).
- It checks the flow cache for an existing flow matching those fields. If found, it updates the byte and packet counters. If not, it creates a new flow entry.
- When the flow expires (idle timeout, active timeout, or TCP FIN/RST), the exporter generates a flow record and sends it to the collector over UDP.
NetFlow v5 uses a fixed record format with a fixed set of fields. NetFlow v9 introduced template-based records, meaning the exporter tells the collector which fields to expect and in what order. This made the protocol extensible and allowed support for IPv6, MPLS labels, multicast, and more. IPFIX (RFC 7011) took NetFlow v9’s template model and standardized it as an IETF protocol.
Key Fields in a NetFlow Record
The following table summarizes the fields that define a classic NetFlow v5 flow record:
| Field | Description |
|---|---|
| Source IP address | IP of the sending host |
| Destination IP address | IP of the receiving host |
| Source port | TCP/UDP port of the sender |
| Destination port | TCP/UDP port of the receiver |
| Protocol | IP protocol number (TCP = 6, UDP = 17, etc.) |
| Ingress interface (SNMP ifIndex) | Interface on which the flow was received |
| Type of Service (ToS) | IP ToS / DSCP byte for QoS |
| Number of packets | Total packets in the flow |
| Number of bytes | Total bytes in the flow |
| Flow timestamps | Start and end time of the flow |
In NetFlow v9 and IPFIX, the template mechanism allows the exporter to include additional fields such as IPv6 addresses, TCP flags, BGP next-hop AS, VLAN ID, MAC addresses, and many others.
NetFlow Versions at a Glance
| Version | Key Characteristics | Notes |
|---|---|---|
| NetFlow v5 | Fixed format, widely supported | No IPv6; most common legacy version |
| NetFlow v9 | Template-based, extensible | Supports IPv6, MPLS, multicast |
| IPFIX (RFC 7011) | IETF standard based on NetFlow v9 | Vendor-neutral; the recommended modern choice |
| sFlow | Statistical sampling, L2-L7 | Different technology; not a NetFlow version |
For a deeper comparison of these technologies, see our NetFlow vs sFlow vs IPFIX guide.
Sampling and Why It Matters
On high-speed links (10 Gbps and above), processing every packet into a flow is often impractical. Many exporters apply sampling - for example, inspecting every 1,000th packet (a 1:1000 sampling rate) and extrapolating from there.
This has a critical implication for analysis: if your collector or analytics tool does not account for the sampling rate, your bandwidth totals and traffic reports will be wrong by orders of magnitude. A sampled flow of 1,000 bytes at 1:1000 represents approximately 1,000,000 bytes of actual traffic.
Always verify whether your exporter is configured for sampled or full NetFlow, and make sure your analytics platform multiplies accordingly.
Real-World Use Cases
NetFlow data drives some of the most common network operations tasks:
Top talkers and bandwidth analysis. Identify which hosts, applications, or subnets are consuming the most bandwidth. This is the bread and butter of flow analysis and directly informs capacity planning and troubleshooting.
Anomaly and DDoS detection. Sudden spikes in traffic to or from specific IPs, unusual protocol distributions, or unexpected international traffic patterns can indicate attacks or misconfigurations.
Capacity planning. Long-term flow data reveals growth trends, peak usage windows, and underutilized links, helping you size circuits and peering connections.
Billing and peering. ISPs and data centers use flow records to bill customers by usage and to settle peering agreements with other networks.
Security forensics. After an incident, stored flow records provide a detailed history of which systems communicated, when, and how much data was transferred - without requiring full packet captures.
Common Pitfalls and Misconceptions
“NetFlow captures packet contents.” No. NetFlow is metadata only. It records the 5-tuple, byte/packet counts, and timestamps. It does not see payloads, URLs, or file contents.
“All flow protocols are the same.” NetFlow v5, NetFlow v9, IPFIX, and sFlow are distinct. NetFlow v5 is fixed-format; v9 and IPFIX are template-based and extensible; sFlow uses statistical sampling at the packet level and is not a flow aggregation protocol. See our NetFlow vs sFlow vs IPFIX comparison for details.
“Sampling is transparent.” As noted above, sampled NetFlow must be scaled by the sampling rate during analysis. Failing to do so produces totals that are far too low.
“NetFlow replaces SNMP.” NetFlow and SNMP are complementary. SNMP tells you interface-level metrics (utilization, errors, discards). NetFlow tells you who is generating the traffic behind those interface counters. For a broader view, see our SNMP monitoring guide.
NetFlow with Netdata
Netdata includes a built-in flow analyzer that ingests NetFlow v5, v7, and v9, IPFIX, and sFlow v5 directly in the agent - no packet capture and no separate appliance required. Point your exporters at the Netdata agent and it handles collection, enrichment, and visualization.
Key capabilities include:
- Top talkers with sortable, filterable flow tables.
- Sankey conversation diagrams that visualize traffic between source and destination, with reorderable columns including TCP flags.
- Geographic traffic maps with automatic GeoIP and ASN enrichment, showing traffic distribution down to street level.
The Sankey view makes it easy to spot dominant conversations at a glance - for example, a single internal host generating disproportionate outbound traffic, or an unexpected external destination receiving large transfers.
Geographic mapping helps identify traffic from unexpected regions, which can signal misconfigured services, CDN behavior, or potential security concerns.
To explore the feature in detail, see the Netdata NetFlow Traffic Analyzer page, or browse our broader network monitoring solutions.
FAQ
What is NetFlow used for?
NetFlow is used for network traffic analysis. Common use cases include identifying top talkers, bandwidth monitoring, capacity planning, anomaly and DDoS detection, security forensics, and usage-based billing. It provides metadata about traffic flows without capturing packet payloads.
Does NetFlow capture packet contents?
No. NetFlow exports metadata only - the 5-tuple (source IP, destination IP, source port, destination port, protocol), byte and packet counts, timestamps, and related fields. It does not inspect or store packet payloads.
What is the difference between NetFlow and IPFIX?
NetFlow v9 introduced template-based, extensible flow records. IPFIX (RFC 7011) is the IETF standardization of that template model. IPFIX is essentially the standards-based evolution of NetFlow v9, adding vendor-neutral interoperability. NetFlow v5 is an older, fixed-format version that does not support IPv6.
What is the difference between NetFlow and sFlow?
NetFlow aggregates packets into flows based on shared key fields and exports summary records. sFlow uses statistical sampling - it periodically samples packets (e.g., 1 in N) and exports those samples. They are fundamentally different technologies. See our NetFlow vs sFlow vs IPFIX guide for a detailed comparison.
Do I need a separate NetFlow collector?
Not necessarily. While many organizations deploy dedicated collector appliances, Netdata ingests NetFlow v5/v7/v9, IPFIX, and sFlow v5 directly in the agent without requiring packet capture or a separate device. This simplifies deployment for environments that already run the Netdata agent.
What is NetFlow sampling and why does it matter?
On high-speed links, exporters may sample traffic (e.g., 1 in every 1,000 packets) rather than processing every packet. Analytics tools must multiply flow totals by the sampling rate to produce accurate bandwidth numbers. If the sampling rate is ignored, reported traffic volumes will be far lower than actual.