Skip to content
Explore the learning library ☟
SanchitGurukulTechnology · Education · Innovation Take a quiz

What Is NetFlow? How Flow Monitoring, Flexible NetFlow and IPFIX Work


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.

NetFlow Monitoring Architecture

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.

Flexible NetFlow Flow Lifecycle

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:

  1. Create an exporter.
  2. Define a flow record.
  3. Create a flow monitor.
  4. 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.

ConfigurationTEXT
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

Command
show flow exporter SG-NETFLOW-EXPORTER

Verify the Flow Monitor

Command
show flow monitor SG-NETFLOW-MONITOR

Inspect the Local Flow Cache

Command
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

Flexible NetFlow Troubleshooting Workflow

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

Command
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

Command
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:

Command
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

  1. NetFlow is a Cisco-developed network traffic telemetry technology.
  2. A NetFlow flow is normally a unidirectional set of packets sharing configured key values.
  3. Flow records describe communication metadata rather than storing complete packet payloads.
  4. Flexible NetFlow allows administrators to define key and non-key fields.
  5. A Flexible NetFlow deployment normally uses a flow record, monitor, cache, exporter, and collector.
  6. NetFlow v9 introduced template-based export.
  7. IPFIX is an IETF-standardized flow-export protocol derived from concepts used in NetFlow v9.
  8. Flexible NetFlow can export using NetFlow v5, NetFlow v9, or IPFIX on supported platforms.
  9. Flexible NetFlow supports packet sampling, so NetFlow is not always unsampled.
  10. NBAR/AVC can provide application information in supported Flexible NetFlow deployments.
  11. NetFlow is useful for bandwidth analysis, security monitoring, capacity planning, and historical traffic visibility.
  12. NetFlow does not replace packet capture when exact packet-level evidence is required.
  13. Flow telemetry should be correlated with other evidence before declaring traffic malicious.
  14. NetFlow v9 exports are not inherently encrypted or authenticated.
  15. 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.


SanchitGurukul Static Resources

Official External References

Your feedback matters

Was this post helpful?

0 reactions

SanchitGurukul — Technology • Education • Innovation

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.

This field is not used to determine whether a comment is safe.

Plain text only. File uploads, scripts, executable code, abuse and spam are not accepted.


Discover more from SanchitGurukul

Subscribe to get the latest posts sent to your email.

Keep exploring

Related guides

Namaste! I’m SG Saarthi 👋Need help learning or finding something?