How to Configure NetFlow on Cisco Routers for Network Traffic Monitoring and Analysis

There’s a specific moment every network engineer eventually hits: something is eating bandwidth, a link is saturated, or security wants to know “what talked to what” during an incident window — and packet captures alone won’t answer it at scale. That’s the exact problem NetFlow was built to solve. Rather than capturing every packet, NetFlow summarizes traffic into flow records: who talked to whom, over what protocol, for how long, and how much data moved. This guide covers NetFlow from first principles through full Cisco IOS/IOS-XE configuration, verification, and real troubleshooting.

What NetFlow Actually Is

A flow is defined by a unique combination of seven key fields (the “seven-tuple”):

1. Source IP address
2. Destination IP address
3. Source port
4. Destination port
5. Layer 3 protocol (TCP, UDP, ICMP, etc.)
6. Type of Service (ToS) byte
7. Input interface

Every packet matching the same seven-tuple within an active flow window is counted into that single flow record instead of being logged individually. The router (or switch) builds these records in a local flow cache, then periodically exports them — via UDP, typically — to a flow collector, a server running analysis software like Cisco Stealthwatch, SolarWinds NTA, ntopng, or an open-source tool like nfdump.

This is fundamentally different from SPAN/port mirroring (which copies full packets) or SNMP (which gives interface-level counters only). NetFlow sits in between: far more detail than SNMP, far less overhead than full packet capture.

NetFlow Versions

• NetFlow v5 — fixed fields, IPv4 only, still widely used for its simplicity and broad tool support.
• NetFlow v9 — template-based, supports IPv6, MPLS, and custom fields.
• Flexible NetFlow (FNF) — Cisco’s modern implementation, built on v9 templates, letting you define exactly which fields to match and collect per flow monitor. This is the standard for any IOS-XE deployment today and is what this guide focuses on.
• IPFIX — the IETF-standardized evolution of NetFlow v9, supported alongside FNF on newer platforms.

Core Building Blocks of Flexible NetFlow

1. Flow Record — defines which fields are used to key a flow (match) and which are just collected (collect).
2. Flow Exporter — defines where and how flow data is sent (destination IP, port, transport, version).
3. Flow Monitor — ties a record and exporter together into a single monitoring policy, plus cache behavior (timers, size).
4. Flow Sampler (optional) — for very high-traffic interfaces, samples 1-in-N packets instead of processing every packet, reducing CPU load.

Lab Topology

• Cisco ISR 4331 router running IOS-XE 17.6, hostname R1
• WAN interface: GigabitEthernet0/0/0, IP 203.0.113.1
• LAN interface: GigabitEthernet0/0/1, IP 10.10.10.1
• Flow collector at 10.10.10.50, listening on UDP 2055

Step 1: Define the Flow Record

R1(config)# flow record CORP-RECORD
R1(config-flow-record)# description IPv4 traffic flow record
R1(config-flow-record)# match ipv4 tos
R1(config-flow-record)# match ipv4 protocol
R1(config-flow-record)# match ipv4 source address
R1(config-flow-record)# match ipv4 destination address
R1(config-flow-record)# match transport source-port
R1(config-flow-record)# match transport destination-port
R1(config-flow-record)# match interface input
R1(config-flow-record)# match flow direction
R1(config-flow-record)# collect routing next-hop address ipv4
R1(config-flow-record)# collect interface output
R1(config-flow-record)# collect counter bytes
R1(config-flow-record)# collect counter packets
R1(config-flow-record)# collect timestamp sys-uptime first
R1(config-flow-record)# collect timestamp sys-uptime last

match fields define the flow key (what makes two packets part of the same flow); collect fields are additional data gathered but not used to distinguish flows.

Step 2: Define the Flow Exporter

R1(config)# flow exporter CORP-EXPORTER
R1(config-flow-exporter)# destination 10.10.10.50
R1(config-flow-exporter)# transport udp 2055
R1(config-flow-exporter)# source GigabitEthernet0/0/1
R1(config-flow-exporter)# export-protocol netflow-v9
R1(config-flow-exporter)# template data timeout 60

Using the physical interface’s IP as the export source ensures the collector always sees flow data coming from a consistent, predictable address, which matters for collector-side filtering and firewall rules.

Step 3: Define the Flow Monitor

R1(config)# flow monitor CORP-MONITOR
R1(config-flow-monitor)# description Main traffic monitor
R1(config-flow-monitor)# record CORP-RECORD
R1(config-flow-monitor)# exporter CORP-EXPORTER
R1(config-flow-monitor)# cache timeout active 60
R1(config-flow-monitor)# cache timeout inactive 15

• Active timeout — how long a still-ongoing flow is allowed to run before it’s exported anyway (prevents long-lived flows like a large file transfer from never being reported).
• Inactive timeout — how long the cache waits after the last packet of a flow before considering it finished and exporting it.

Step 4: Apply the Flow Monitor to Interfaces

Apply on the WAN interface, capturing both directions of traffic:

R1(config)# interface GigabitEthernet0/0/0
R1(config-if)# ip flow monitor CORP-MONITOR input
R1(config-if)# ip flow monitor CORP-MONITOR output
R1(config-if)# exit

For IPv6 traffic, a separate flow record/monitor referencing match ipv6 fields is needed and applied with ipv6 flow monitor.

Step 5: Verify NetFlow Is Capturing Data

R1# show flow monitor CORP-MONITOR statistics

Expected output (trimmed):

Cache type:                             Normal (Platform cache)
Cache size:                            10000
Current entries:                          124
High Watermark:                          201

Flows added:                            8452
Flows aged:                             8328
   - Active timeout       (  60 secs)     212
   - Inactive timeout     (  15 secs)    8116

Check the live cache contents directly:

R1# show flow monitor CORP-MONITOR cache format table

Expected output (trimmed):

IPV4 SRC ADDR    IPV4 DST ADDR    TRNS SRC PORT  TRNS DST PORT  IP PROT  bytes  pkts
10.10.10.15      93.184.216.34    54221          443            6        45812  38
10.10.10.22      203.0.113.55     51422          80             6        2044   6

Confirm the exporter is actually sending packets out:

R1# show flow exporter CORP-EXPORTER statistics

Expected output (trimmed):

Client send statistics
  Client: Flow Monitor
    Records added:                                       8452
      - sent:                                             8452
    Bytes added:                                         608544
      - sent:                                            608544

If “sent” stays at zero while “added” climbs, the router is generating flows but failing to export them — almost always a routing or ACL problem between the router and collector.

Sampling for High-Throughput Interfaces

On a busy core or edge interface (multi-gigabit), full NetFlow can add meaningful CPU load. Use a flow sampler to process only a fraction of packets:

R1(config)# sampler CORP-SAMPLER
R1(config-sampler)# mode random 1 out-of 100
R1(config)# interface GigabitEthernet0/0/0
R1(config-if)# ip flow monitor CORP-MONITOR sampler CORP-SAMPLER input

This samples 1 in every 100 packets and extrapolates flow statistics — acceptable for trend and top-talker analysis, not for exact byte-accurate billing.

Real-World Enterprise Scenario: Identifying a Bandwidth Hog

A branch office WAN circuit is consistently near capacity during business hours. With NetFlow already exporting to a collector:

1. Pull top talkers by bytes over the last hour from the collector UI or via nfdump-style query.
2. Cross-reference the top source IP against DHCP leases to identify the device.
3. Check destination ports — a flow to TCP 443 sustained for hours at high byte counts often indicates cloud backup or video streaming rather than malicious activity, while unusual destination ports or a fan-out pattern (one host talking to hundreds of external IPs) suggests something worth investigating further, such as a compromised host doing reconnaissance or exfiltration.
4. Apply a QoS policy or ACL to that host/application once identified, rather than blindly throttling the whole circuit.

This is the core value proposition of NetFlow: it turns “the link is full” into “here is exactly which host and application is responsible,” without ever needing a packet capture.

Performance Tuning

• Increase cache size on routers with high flow counts to avoid premature cache eviction: flow monitor CORP-MONITOR → cache size 65536.
• Reduce active timeout (e.g., to 30 seconds) if you need near-real-time visibility for security use cases, at the cost of more export traffic.
• Use hardware-accelerated NetFlow where available (e.g., on ASR or Catalyst platforms with dedicated flow ASICs) rather than software (CPU-based) flow export on high-throughput links.
• Limit collected fields to what you actually analyze — every additional collect field increases per-flow cache memory usage across potentially tens of thousands of concurrent flows.

Common Configuration Mistakes

• Applying the flow monitor only in the input direction, missing outbound traffic entirely (most designs need both directions applied, one per interface, to see full bidirectional flow data on a routed interface).
• Forgetting that Flexible NetFlow record/monitor/exporter objects must all be created before they can reference each other — the CLI will reject a monitor referencing a record that doesn’t exist yet.
• Not accounting for asymmetric routing — if inbound and outbound traffic take different paths through different routers, no single device sees the complete flow, skewing analysis.
• Overloading a low-end router’s CPU by running full (unsampled) NetFlow on a very high-bandwidth interface.
• Forgetting to permit UDP 2055 (or whatever export port is chosen) through any firewall sitting between the router and the collector.

Troubleshooting Checklist

• No flows appearing on collector: verify routing to the collector (ping 10.10.10.50 from the router), confirm the exporter source interface has a valid route, and check show flow exporter … statistics for “sent” vs. “added” mismatches.
• Flows show but fields are all zero: check the flow record’s match/collect statements — a typo or unsupported field combination on certain platforms silently produces incomplete templates.
• High CPU after enabling NetFlow: check show processes cpu sorted for the NetFlow-related process and consider enabling a sampler.
• Collector shows old/stale templates only: template refresh intervals (template data timeout) may be too long relative to how often the collector expects fresh templates — lower the timeout.

FAQs

Does NetFlow capture packet payloads? No — NetFlow only records metadata about flows (addresses, ports, byte/packet counts, timing). It never captures the actual packet contents, which is one reason it’s lighter-weight and generally has fewer privacy implications than full packet capture.

What’s the difference between NetFlow and sFlow? sFlow (used mostly on switches from vendors like Arista and older Cisco Nexus platforms) samples packets at the interface level and is protocol-agnostic; NetFlow builds full flow records in a cache and exports summarized data, giving more precise per-flow statistics at the cost of more router resources.

Can NetFlow run on a switch instead of a router? Yes — many Catalyst switches (9300, 9400, 9500 series) support Flexible NetFlow in hardware; the same record/exporter/monitor model applies, though field support varies by platform ASIC.

How much bandwidth does NetFlow export traffic itself use? Typically well under 1% of monitored traffic, since only summarized records are sent, not full packets — though this scales with the number of unique flows, not the byte volume, so a network with many short-lived flows can generate more export overhead than one with a few large flows.

Summary

NetFlow configuration on modern Cisco IOS-XE routers boils down to four objects: a flow record defining what to match and collect, an exporter defining where to send it, a monitor tying the two together with cache timers, and interface-level application in both traffic directions. Once running, show flow monitor … statistics and show flow exporter … statistics are the two commands that confirm the pipeline is healthy end to end. From there, NetFlow becomes the primary tool for answering “who is using the bandwidth and why” without resorting to full packet captures.

References

• Cisco: Flexible NetFlow Configuration Guide — https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/fnetflow/configuration/xe-16/fnf-xe-16-book.html
• Cisco: NetFlow Overview — https://www.cisco.com/c/en/us/products/ios-nx-os-software/ios-netflow/index.html
• Cisco: IPFIX and NetFlow Version 9 — https://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_paper09186a00800a3db9.html