NetFlow is a flow-export protocol, originally developed by Cisco, in which routers, switches and firewalls summarize the traffic passing through them into flow records and send those records to a collector for analysis. In network monitoring, it answers the questions of who talked to whom, over which ports, how much and for how long, without storing packet contents.
A flow is a set of packets that share the same key fields, traditionally the source and destination IP addresses, ports, protocol, type of service and input interface. NetFlow version 9 became the basis for the IETF standard IPFIX, and the term NetFlow is now commonly used for the whole family of flow technologies, including sFlow and J-Flow.
How NetFlow builds and exports flow records
The device that observes traffic is called the exporter. It keeps a flow cache in memory: when a packet arrives, the exporter computes the flow key, updates the matching entry with byte and packet counters and timestamps, or creates a new entry if none exists.
Entries leave the cache when a timer expires or the flow ends. The exporter packs expired entries into UDP datagrams and sends them to a collector, which stores them and feeds analysis tools. Common collector ports are UDP 2055, 9995 or 4739 for IPFIX, although any port can be configured.
The parameters below control how accurate and how timely the exported data is.
| Parameter | Typical value | Effect |
|---|---|---|
| Active timeout | 60 seconds to 30 minutes, often 1 minute | Splits long flows into periodic records |
| Inactive timeout | 15 seconds | Exports flows that have gone quiet |
| Cache size | Thousands to millions of entries | Too small causes early exports and lost detail |
| Sampling rate | 1:1 to 1:10000 | Reduces load at the cost of precision |
| Export version | v5, v9 or IPFIX | Determines available fields and IPv6 support |
A one-minute active timeout is a common choice for monitoring, because long downloads or backups otherwise appear in reports only after they finish, hiding their impact on link utilization.
NetFlow versions and related protocols
Several versions and competing protocols exist, and they differ mainly in flexibility and sampling behavior. Collectors usually accept all of them.
| Format | Record structure | Notes |
|---|---|---|
| NetFlow v5 | Fixed format | IPv4 only, still widely supported |
| NetFlow v9 | Template-based | Adds IPv6, MPLS and custom fields |
| IPFIX | Template-based, IETF standard | Supports variable-length fields and vendor elements |
| sFlow | Sampled packet headers plus counters | Always sampled, common on switches |
| J-Flow, NetStream | Vendor variants of NetFlow | Largely compatible with v5, v9 or IPFIX |
Templates in v9 and IPFIX let the exporter describe its own record layout, so new fields such as application identifiers or NAT translations can be added without changing the protocol. The collector must receive the template before it can decode data records, which is why template refresh intervals matter after a collector restart.
NetFlow compared with other monitoring methods
NetFlow sits between interface counters and full packet capture in the level of detail it provides. Each method answers a different question in network monitoring.
| Method | What it shows | Storage need | Typical question |
|---|---|---|---|
| SNMP counters | Total bytes and errors per interface | Very low | Is the link full |
| NetFlow or IPFIX | Conversations with volumes and timing | Moderate | Who is filling the link |
| Packet capture | Every packet with payload | Very high | Why does this session fail |
| Wireshark analysis | Decoded protocols from a capture | Depends on capture | What exactly happened in the exchange |
A practical workflow uses all three: SNMP raises an alert about utilization, NetFlow identifies the hosts and applications responsible, and a targeted packet capture explains the protocol behavior. NetFlow does not measure latency, jitter or packet loss directly, although some IPFIX extensions add timing data.
Practical uses of NetFlow
Flow data supports both capacity planning and security. Because it records every conversation crossing an exporter, it creates an audit trail that remains useful long after traffic has passed.
- Top talkers and applications: identifying which hosts, ports or autonomous systems consume bandwidth.
- Capacity planning: trending traffic per site or per service over months.
- Anomaly and DDoS detection: spotting sudden floods of flows toward one address or from many sources.
- Incident investigation: reconstructing which internal hosts contacted a malicious address and when.
- Segmentation design: mapping real dependencies before writing firewall rules.
- Billing and peering: measuring traffic exchanged with customers or upstream networks.
For security use, exporters should run unsampled at internal boundaries where possible, because a sampled feed can miss short scans or a single beacon connection.
Limitations and common mistakes
NetFlow data is only as reliable as the exporter configuration and time synchronization. The issues below cause most misleading reports.
| Symptom | Likely cause | Fix |
|---|---|---|
| Traffic appears in spikes | Long active timeout | Set the active timeout to about 60 seconds |
| Traffic counted twice | Ingress and egress export on the same path | Export in one direction per interface |
| Wrong timestamps | Exporter clock not synchronized | Configure NTP on all exporters |
| Undecodable records | Collector missed v9 or IPFIX templates | Shorten template refresh interval |
| Volumes too low | Sampling not corrected | Multiply by the sampling rate in the collector |
Encrypted traffic is another limit: NetFlow shows that a host talks to an address on TCP 443, but not which URL or content was involved.
Put simply
NetFlow is like the itemized phone bill of a network. A phone bill does not record what people said, but it lists every call: who called whom, when, and for how long.
Routers produce the same kind of list for network traffic and send it to a separate system for analysis. The main advantage is visibility without recording content: administrators can see which devices use the network and spot unusual conversations quickly.
In practice
A university network team receives complaints that the internet link becomes slow every weekday around noon. SNMP graphs confirm that the 10 Gbit/s uplink reaches over 90 percent utilization at that time, but they cannot show why.
The team enables IPFIX export with a 60-second active timeout on the border router and sends it to a flow collector. Within a day, the reports show that a research server is synchronizing a large dataset to a cloud storage service at midday, using a substantial share of the link.
The researchers move the job to a nightly window and apply a bandwidth limit. Midday utilization returns to normal levels, and the team keeps the flow data for future capacity planning and security investigations.