NetFlow v9 Configuration on Cisco IOS: Flexible NetFlow Guide

NetFlow answers the question syslog cannot: who is talking to whom, on which ports, and how much traffic is really flowing. Modern IOS XE uses Flexible NetFlow, where you assemble a flow record, point it at an exporter, and bind both with a monitor that you apply to an interface. This guide builds that stack from scratch, explains the timer values that decide export granularity, adds sampling for high-rate interfaces, and finishes with the verification chain that proves flows are cached and leaving the router.

Know the four building blocks

NetFlow identifies a flow by a seven-tuple: source IP, destination IP, source port, destination port, IP protocol, ToS byte and input interface. Flexible NetFlow separates that into a record (which fields key the flow, and which are merely collected), an exporter (destination, port, protocol version), a monitor (which ties record and exporter together with cache timers) and an optional sampler. Thinking in those four objects makes the configuration self-documenting and makes troubleshooting much faster.

Step 1: flow record, exporter and monitor

Router(config)# flow record CORE-RECORD
Router(config-flow-record)# match ipv4 source address
Router(config-flow-record)# match ipv4 destination address
Router(config-flow-record)# match ipv4 protocol
Router(config-flow-record)# match ipv4 tos
Router(config-flow-record)# match transport source-port
Router(config-flow-record)# match transport destination-port
Router(config-flow-record)# match interface input
Router(config-flow-record)# collect counter bytes long
Router(config-flow-record)# collect counter packets long
Router(config-flow-record)# collect timestamp absolute first
Router(config-flow-record)# collect timestamp absolute last

Router(config)# flow exporter CORE-EXPORTER
Router(config-flow-exporter)# destination 10.10.50.20
Router(config-flow-exporter)# source Loopback0
Router(config-flow-exporter)# transport udp 2055
Router(config-flow-exporter)# export-protocol netflow-v9
Router(config-flow-exporter)# template data timeout 60
Router(config-flow-exporter)# option interface-table timeout 300

Router(config)# flow monitor CORE-MONITOR
Router(config-flow-monitor)# record CORE-RECORD
Router(config-flow-monitor)# exporter CORE-EXPORTER
Router(config-flow-monitor)# cache timeout active 60
Router(config-flow-monitor)# cache timeout inactive 15
Router(config-flow-monitor)# cache entries 65536

Export from a loopback that never goes down - collectors build rules around the source address. The active timeout is the ceiling on how long a long-lived flow stays invisible to your collector (60 seconds is a good default); the inactive timeout ends flows that stop sending. Set template data timeout explicitly: NetFlow v9 is template-based, and a collector that restarts without a fresh template sees nothing at all.

Step 2: apply, and sample if the interface is hot

Router(config)# sampler CORP-SAMPLER mode random 1 out-of 1000
Router(config-flow-monitor)# sampler CORP-SAMPLER

Router(config)# interface GigabitEthernet0/0/1
Router(config-if)# description Uplink to core
Router(config-if)# ip flow monitor CORE-MONITOR input
Router(config-if)# ip flow monitor CORE-MONITOR output
Router(config-if)# ip flow ingress
Router(config-if)# ip flow egress

Apply the monitor in the direction you care about. For uplink capacity planning use output on the customer-facing interface, which gives an accurate picture of what you actually deliver. Sampling at 1:1000 with the bytes counters lets you multiply back up to a very good estimate, at a fraction of the CPU cost.

Step 3: verify cache and exports separately

Router# show flow monitor CORE-MONITOR cache format table
Router# show flow monitor CORE-MONITOR statistics
Router# show flow exporter CORE-EXPORTER statistics
Router# show flow record CORE-RECORD
Router# show flow interface
Router# show running-config | section flow exporter
Router# debug ip flow export
Router# show platform software fed switch active punt cause summary

Two independent facts have to be true. First, the cache must be filling: show flow monitor ... cache format table should list flows, with increments between two runs. Second, the exporter must be sending: show flow exporter statistics should show increasing "packets sent" and, critically, zero "socket errors" and zero "transmission failures". If flows fill the cache but nothing leaves, the problem is routing or ACLs - the classic case is an outbound ACL blocking UDP 2055 on egress. If flows never appear in the cache, the monitor is attached to the wrong interface or in the wrong direction.

Collector-side sanity checks

tcpdump -i eth0 -nn udp port 2055 -c 20
tcpdump -i eth0 -nn -A 'udp port 2055' | grep -i template

Confirm packets arrive before you blame the collector, and confirm the template arrived before you blame the parsing. Most "NetFlow is broken" tickets end here with a firewall rule or a stale template.

Design habits worth keeping

Document the collector IP and the source interface in your monitoring runbook; alert on exporter statistics rather than having a human notice missing graphs; and keep one record definition per purpose (traffic accounting, security, QoS) instead of an everything-record. Related guides: sFlow vs NetFlow vs IPFIX, Prometheus snmp_exporter for network devices, and Wireshark filters when you need packet-level proof.

原文链接：https://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/netflow/226065-troubleshoot-netflow-on-ios-xe.html