NetFlow is a network traffic-monitoring technology originally developed by Cisco to provide visibility into IP traffic passing through network devices.
Instead of storing complete packet payloads like a packet-capture system, NetFlow summarizes traffic into flow records.
A flow record can help answer questions such as:
- Who communicated with whom?
- Which source and destination addresses were involved?
- Which ports and protocols were used?
- How many packets and bytes were transferred?
- Which network interface carried the traffic?
- When did the flow start and end?
- Which applications consumed bandwidth when application recognition is available?
NetFlow is widely used for:
- Network monitoring
- Bandwidth analysis
- Capacity planning
- Traffic engineering
- Security analytics
- DDoS detection
- Troubleshooting
- Application visibility
- Historical traffic analysis
- Network accounting
Modern Cisco environments primarily use Flexible NetFlow, which allows administrators to choose the fields that define and describe a flow rather than relying only on a fixed record structure.

What Is a NetFlow Flow and How Does It Work?
A flow is generally a unidirectional sequence of packets sharing a defined set of key values.
With Flexible NetFlow, the administrator determines which fields are used as keys.
A traditional IP flow often uses values such as:
- Source IP address
- Destination IP address
- Source port
- Destination port
- IP protocol
- Type of Service / DSCP
- Input interface
A simple TCP conversation between two devices normally creates separate records for each direction because NetFlow flows are fundamentally directional.
Example Flow
Consider a client opening an HTTPS connection.
Key Fields and Non-Key Fields
Flexible NetFlow divides record fields conceptually into:
Key fields
These identify separate flows.
Examples:
- Source IP
- Destination IP
- Protocol
- Source port
- Destination port
Cisco configuration uses:
match
for key fields.
Non-key fields
These provide additional information about a flow without defining a new flow.
Examples:
- Packet count
- Byte count
- Input interface
- Output interface
- Timestamps
- Application name on supported configurations
Cisco configuration commonly uses:
collect
for these fields.
Major Components
Modern Flexible NetFlow contains several logical components.
Flow Record
Defines what information is measured.
Flow Monitor
Combines a flow record with a flow cache and optional exporter.
Flow Cache
Maintains active flow information while traffic is being observed.
Flow Exporter
Defines how completed or periodically aged flow records are sent to a collector.
NetFlow Collector
Receives, decodes, stores, and analyzes exported records.
Flow Aging
NetFlow does not necessarily wait for a TCP session to formally close before exporting information.
Flow-cache entries can be exported because of conditions including:
- Inactivity
- Active timeout
- Cache behavior
- Flow termination
- Platform-specific events
Cisco Flexible NetFlow commonly uses both:
- Active timeout
- Inactive timeout
An active timeout ensures long-lived conversations can periodically generate records.
An inactive timeout removes flows that have stopped seeing traffic.

NetFlow Versions, Flexible NetFlow and IPFIX
NetFlow has evolved significantly since its original implementation.
NetFlow Version 5
NetFlow v5 uses a predefined record format containing fields such as:
- IPv4 source address
- IPv4 destination address
- Next hop
- Input and output interfaces
- Packet count
- Byte count
- Start and end times
- Source and destination ports
- TCP flags
- IP protocol
- ToS
- Autonomous system information
Version 5 remains recognizable in older environments but is much less flexible than modern template-based formats.
NetFlow Version 9
NetFlow v9 introduced a template-based export format.
Instead of forcing every exported record to contain one fixed set of fields, the exporter first describes the structure using a template.
The collector then uses that template to decode subsequent records.
This makes v9 significantly more extensible.
Flexible NetFlow
Flexible NetFlow improves the collection model further by allowing administrators to define:
- Which fields identify a flow
- Which additional information is collected
- Where the monitor is applied
- Which exporter receives the data
- Whether sampling is used
Cisco describes Flexible NetFlow using reusable components such as:
- Flow records
- Flow monitors
- Flow exporters
- Flow samplers
IPFIX
IP Flow Information Export, or IPFIX, is an IETF-standardized flow-export protocol.
It is defined by:
RFC 7011
IPFIX evolved from concepts used by NetFlow v9.
One obvious protocol indicator is the version number:
- NetFlow v9 — version 9
- IPFIX — version 10
Flexible NetFlow on supported Cisco platforms can export using formats including:
- NetFlow v5
- NetFlow v9
- IPFIX
NetFlow vs IPFIX
| Area | NetFlow v9 | IPFIX |
|---|---|---|
| Origin | Cisco | IETF standard |
| Record model | Template based | Template based |
| Version | 9 | 10 |
| Extensible | Yes | Yes |
| Information-element registry | NetFlow model | Standardized IPFIX Information Elements |
| Multi-vendor interoperability | Widely implemented | Designed as an Internet standard |
| Flexible NetFlow export | Supported | Supported on compatible platforms |
NetFlow Can Use Sampling
Another common misconception is:
NetFlow always analyzes every packet.
Flexible NetFlow can use a flow sampler.
Sampling reduces the number of packets presented to the flow monitor, reducing monitoring overhead at the cost of some statistical accuracy.
Therefore:
Sampling is not exclusive to sFlow.
How NetFlow Helps with Monitoring, Security and Capacity Planning
NetFlow is especially valuable because it provides network-wide communication metadata without requiring full packet capture everywhere.
Bandwidth and Top-Talker Analysis
A collector can identify:
- Highest-volume source hosts
- Highest-volume destinations
- Busy applications
- Traffic by protocol
- Busy interfaces
- Traffic between subnets
- Internet traffic trends
For example, an administrator investigating a saturated WAN link may discover that a backup server is transferring several terabytes during business hours.
Network Security Monitoring
Flow data can help identify suspicious traffic patterns such as:
- Sudden connection spikes
- Port scans
- DDoS activity
- Unexpected outbound traffic
- Unusual east-west communication
- Large data transfers
- Communication with suspicious destinations
- Compromised systems contacting many hosts
DDoS Detection
Flow analytics can identify:
- Large packet-rate increases
- Sudden changes in source diversity
- Concentrated traffic toward one destination
- UDP floods
- TCP SYN patterns
- Unexpected protocol changes
A monitoring or DDoS platform can then trigger operational responses.
NetFlow itself does not automatically mitigate the attack.
Capacity Planning
Historical flow data helps answer:
- Which links are growing fastest?
- What are peak utilization periods?
- Which applications consume capacity?
- Which locations generate the most traffic?
- When will WAN upgrades be required?
Troubleshooting
NetFlow is particularly useful for determining:
what traffic was present during a problem.
For example, it can reveal that a WAN circuit experienced unexpectedly high traffic from a large replication operation at the same time users reported poor performance.
However, NetFlow does not inherently prove:
- Packet loss
- Application response time
- TCP retransmissions in every implementation
- Device queueing
- Physical-layer errors
Use interface counters, packet capture, telemetry, application monitoring, and device statistics when those measurements are required.
Application Visibility
Traditional NetFlow records mostly describe Layer 3 and Layer 4 communication.
Modern Cisco platforms can integrate NBAR / Application Visibility and Control with Flexible NetFlow.
On supported configurations, flow records can contain fields such as:
application name
This means it is no longer accurate to say that NetFlow can never provide Layer-7 application information.
Application recognition depends on:
- Platform
- Cisco software release
- NBAR/AVC capabilities
- Flow-record configuration
NetFlow vs sFlow and Packet Capture
NetFlow, sFlow, and packet capture provide different types of visibility.
NetFlow vs sFlow
| Characteristic | Flexible NetFlow | sFlow |
|---|---|---|
| Primary model | Flow records | Statistical packet + counter sampling |
| Flow cache | Common | Not inherently required |
| Sampling | Optional/supported | Fundamental design |
| Traffic counters | Per-flow records | Statistical traffic plus counter samples |
| Packet headers | Not the primary model | Sampled packet headers |
| Custom fields | Extensive | Extensible sFlow structures |
| High-speed monitoring | Yes | Yes |
| Full packet payload | No | No |
| Exact packet history | No | No |
The choice should not be reduced to:
NetFlow = complete traffic
and:
sFlow = sampled traffic
because Flexible NetFlow can also operate with sampling.
NetFlow vs Packet Capture
| NetFlow | Packet Capture |
|---|---|
| Communication metadata | Complete captured packet data |
| Lower storage requirements | Potentially huge storage requirements |
| Excellent historical traffic trends | Excellent packet-level troubleshooting |
| Good top-talker analysis | Good protocol debugging |
| No full payload by default | Payload available when captured and not encrypted |
| Network-wide monitoring | Usually targeted collection |
| Long retention practical | Long retention more expensive |
Use NetFlow for questions such as:
Who communicated with whom and how much traffic was transferred?
Use packet capture for questions such as:
What exactly happened inside this TCP/TLS/DNS exchange?
Use Multiple Telemetry Sources
A mature monitoring system may combine:
- Flexible NetFlow
- IPFIX
- sFlow
- SNMP
- Streaming telemetry
- Syslog
- Firewall logs
- DNS logs
- Packet capture
- Application monitoring
These tools complement rather than replace one another.
Deploying and Troubleshooting Flexible NetFlow
A typical Flexible NetFlow configuration follows four stages:
- Create an exporter.
- Define a flow record.
- Create a flow monitor.
- Apply the monitor to an interface.
The exact commands and supported fields depend on the Cisco platform and IOS/IOS XE release.
Example Flexible NetFlow Configuration
The following example exports NetFlow v9 records to a collector at:
192.0.2.50
using UDP port:
2055
The port is an example—the collector must be configured to listen on the same port.
flow exporter SG-NETFLOW-EXPORTER
destination 192.0.2.50
source Loopback0
export-protocol netflow-v9
transport udp 2055
!
flow record SG-IPV4-RECORD
match ipv4 source address
match ipv4 destination address
match ip protocol
match transport source-port
match transport destination-port
collect counter bytes long
collect counter packets long
collect interface input
collect interface output
collect timestamp sys-uptime first
collect timestamp sys-uptime last
!
flow monitor SG-NETFLOW-MONITOR
record SG-IPV4-RECORD
exporter SG-NETFLOW-EXPORTER
!
interface GigabitEthernet1/0/1
ip flow monitor SG-NETFLOW-MONITOR input
Verify the Exporter
show flow exporter SG-NETFLOW-EXPORTER
Verify the Flow Monitor
show flow monitor SG-NETFLOW-MONITOR
Inspect the Local Flow Cache
show flow monitor SG-NETFLOW-MONITOR cache
This helps answer an important troubleshooting question:
Is the router actually creating flows before we investigate the collector?
Troubleshooting Missing NetFlow Data

Step 1 — Confirm Traffic Exists
Make sure packets are actually traversing the monitored interface and direction.
Step 2 — Check the Interface Configuration
Confirm that the expected flow monitor is attached.
Step 3 — Inspect the Flow Cache
show flow monitor SG-NETFLOW-MONITOR cache
If the cache contains no flows, investigate the local monitor configuration before blaming the collector.
Step 4 — Check Exporter Statistics
show flow exporter SG-NETFLOW-EXPORTER
Verify:
- Destination
- Source interface
- Export protocol
- Export counters
- Transport port
Step 5 — Verify Routing
The exporter must be able to reach the collector.
Use the configured exporter source address when validating routing and ACLs.
Step 6 — Verify Collector Traffic
On an authorized Linux collector, for example:
sudo tcpdump -ni any udp port 2055
If UDP packets arrive but no flows appear in the monitoring application, investigate:
- Template decoding
- Export format
- Collector compatibility
- Observation source
- Collector configuration
NetFlow v9 Templates Matter
NetFlow v9 is template based.
A collector needs the appropriate template before it can correctly interpret the associated data records.
This is one reason a packet arriving at the collector does not automatically mean the collector can decode it.
Sampling Best Practices
Use sampling only when justified by:
- Platform capacity
- Traffic volume
- Monitoring requirements
- Collector scale
Sampling lowers processing demands but reduces measurement precision.
Monitor Both IPv4 and IPv6
Do not assume an IPv4 flow record automatically provides equivalent IPv6 visibility.
Create and apply appropriate records for both address families where required.
Protect Flow Telemetry
NetFlow data can reveal:
- Internal IP addresses
- Server relationships
- Traffic volumes
- Application usage
- Communication patterns
- Network topology
NetFlow v9 does not inherently provide confidentiality, integrity, or authentication for exported records.
RFC 3954 explicitly warns about interception, modification, injection, and attacks against collectors.
Key Takeaways and Summary
Key Takeaways
- NetFlow is a Cisco-developed network traffic telemetry technology.
- A NetFlow flow is normally a unidirectional set of packets sharing configured key values.
- Flow records describe communication metadata rather than storing complete packet payloads.
- Flexible NetFlow allows administrators to define key and non-key fields.
- A Flexible NetFlow deployment normally uses a flow record, monitor, cache, exporter, and collector.
- NetFlow v9 introduced template-based export.
- IPFIX is an IETF-standardized flow-export protocol derived from concepts used in NetFlow v9.
- Flexible NetFlow can export using NetFlow v5, NetFlow v9, or IPFIX on supported platforms.
- Flexible NetFlow supports packet sampling, so NetFlow is not always unsampled.
- NBAR/AVC can provide application information in supported Flexible NetFlow deployments.
- NetFlow is useful for bandwidth analysis, security monitoring, capacity planning, and historical traffic visibility.
- NetFlow does not replace packet capture when exact packet-level evidence is required.
- Flow telemetry should be correlated with other evidence before declaring traffic malicious.
- NetFlow v9 exports are not inherently encrypted or authenticated.
- Troubleshooting should verify local flow creation before investigating the collector.
Summary
NetFlow provides a scalable way to understand network communication without storing every packet.
Its core concept is simple:
Observe packets → group them into flows → collect metadata and counters → export records → analyze them centrally.
Modern Flexible NetFlow significantly expands this model by allowing administrators to choose what defines a flow and what additional information should be collected.
This makes NetFlow useful for:
- Traffic visibility
- Top-talker analysis
- Security analytics
- DDoS monitoring
- Capacity planning
- Troubleshooting
- Application analysis
- Historical reporting
NetFlow is most powerful when used as part of a broader monitoring architecture.
Use:
NetFlow/IPFIX for flow behavior, sFlow for scalable statistical sampling, packet capture for packet-level evidence, and telemetry/logging systems for device and application health.
The goal is not to collect the maximum possible amount of data.
The goal is to collect the right telemetry to answer operational and security questions quickly and accurately.
Useful Links and References
SanchitGurukul Static Resources
Official External References
Your feedback matters
Was this post helpful?
Discussion
0 approved comments
No approved comments yet. You can start the discussion below.
Leave a Comment
No login is required. Name and email are used for moderation/security. Your email is never displayed publicly. All comments require administrator approval.
Discover more from SanchitGurukul
Subscribe to get the latest posts sent to your email.
