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.

The reason this is worth doing properly is that NetFlow is invisible by design. When it works, nobody notices; when it breaks, the collector simply stops drawing graphs and by the time someone asks why, the historical data you needed is gone. Every section below therefore ends with something you can check, and the last two sections are a capacity estimate and a failure-mode table that between them cover almost every broken deployment I have seen.

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.

The distinction inside the record is the one people get wrong. Fields that appear under match form the flow key: two packets that differ in a matched field are two different flows. Fields that appear under collect are carried along with the flow but do not split it. If you match a field by mistake you multiply your flow count and your collector's load; if you forget to collect counters you get a perfectly good map of conversations with no volume information at all.

Before you configure: scope, time and sizing

Three decisions made before the first command save most of the pain later.

Scope. Pick the interfaces that show you the answer you need, and pick the direction with intent. Ingress monitoring on a WAN interface tells you what the branch tried to receive; egress monitoring tells you what the branch actually sent. Monitoring every interface with both directions is technically easy and operationally expensive: flow counts multiply and your collector's disk fills with conversations nobody ever queries.

Time. NetFlow timestamps are only as good as the router's clock. Point every exporter at NTP before you enable a monitor, because a router whose clock has drifted by four minutes produces flows that appear in the wrong five-minute bucket and graphs that look like a traffic shift that never happened.

Sizing. Estimate the export stream before you build it. A monitor exporting, say, 30 flow records per second in 1400-byte datagrams is roughly 340 kbit/s of steady overhead — trivial on a LAN, meaningful on a small WAN link. Sizing the export is a capacity-planning exercise, not a monitoring detail, and the calculation is worth writing into the design document.

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.

Read the two timeouts as a trade-off you are deliberately making. Active timeout sets your resolution: a 60-second ceiling means a long backup transfer is reported in one-minute slices, which is plenty for capacity graphs and roughly useless for watching a spike. Lowering it to 15 seconds sharpens the picture and multiplies the export volume fourfold. The inactive timeout is a memory optimisation with a correctness side effect: set it too high and short-lived flows pile up in the cache for no reason; set it too low and you chop legitimate idle connections into several flows, which inflates your connection counts. Fifteen to thirty seconds is the usual compromise.

The cache is a fixed-size table, and when it fills, new flows compete for space and the oldest entries are exported early. On a busy interface an undersized cache is why your graphs show suspiciously uniform flows. If show flow monitor statistics show very high allocation failures, raise cache entries or enable sampling.

Templates, options and why a collector goes blind

NetFlow v9 sends flow data with no field names attached: each export packet refers to a template that describes its layout, and the template is transmitted separately and periodically. That design saves bandwidth and creates a specific failure mode. If the collector restarts or is replaced and the template does not arrive again, every subsequent data packet is discarded as unparseable, usually with a single line in the collector log. A short template data timeout makes the router re-announce templates often, which bounds the outage to the timeout window instead of the life of the flow.

The interface option table exists for the same reason: it maps the interface indexes carried in flows back to names. Without it, a collector shows you flow data keyed by numbers and cannot label a single interface. If your graphs exist but every entry says "ifIndex 12", the option table is what you are missing.

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.

Sampling changes the meaning of your numbers, and it is worth saying so out loud: with 1:1000 sampling, a flow's byte counters are the counters of the sampled packets only. A collector that multiplies by the sample rate recovers the estimate; a collector that does not will happily report one thousandth of the real traffic with no warning at all. Record which interfaces are sampled and at what rate, and configure the multiplier on the collector, not in your head.

One more caveat that catches people out: not every platform implements every match and collect field in hardware. A field the platform cannot support in the fast path may be handled in software, or refused, or silently ignored depending on IOS XE version and platform. If a record behaves oddly, build a minimal record with just source and destination addresses, confirm it works, then add fields back one at a time rather than troubleshooting the whole record at once.

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.

Run the cache command twice, ten seconds apart, and compare. A static output looks exactly like a healthy one at a glance, and the difference between "the cache is stable because nothing is happening" and "the cache is frozen because the monitor was removed" is entirely in the delta. The same discipline applies to show flow exporter statistics: a non-zero packet counter that has not moved since the last check means exports stopped, not that they were never configured.

show flow interface is the fastest way to see what is actually attached, because it reports monitors per interface and direction in one screen. It answers the most common question of all — "did I apply that to the interface I think I did" — without needing to read the running configuration.

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.

Then work outward into the collector itself: check that the receiving process is bound to the right port and address family (a collector listening on IPv6 only will silently ignore your IPv4 exports), that the expected source address is the router's loopback and not an interface address that changed last week, and that the collector's own firewall profile allows the traffic that tcpdump already proved is on the wire. If flows land in the collector but a dashboard is empty, that is a parsing or a timezone problem, not an export problem — and treating the two as one is how a five-minute fix turns into an afternoon.

A failure-mode table worth keeping

• Cache is empty. The monitor is bound to the wrong interface or direction, the interface is layer-2 only, or the platform does not support the record's fields.
• Cache fills, exporter counters stay at zero. No route to the collector, an outbound ACL blocking UDP 2055, or the export source interface sitting in a VRF that cannot reach the management network.
• Exporter sends, collector sees nothing. A UDP filter on the collector host or an intermediate firewall, or the collector is bound to the wrong port.
• Collector receives data but cannot parse it. Missing or stale template — shorten template data timeout and restart the collector so it asks again.
• Byte counters are always zero. The collect statements are missing or unsupported on this platform.
• Timestamps look shifted. NTP is not configured, or the collector and router disagree about timezone versus UTC.
• Flow counts explode. A field that should be collected is being matched, or the same monitor is applied in both directions on both ends of a link.

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.

Two further habits separate a deployment that survives from one that quietly decays. First, treat NetFlow as a service with its own health checks: graph the exporter's packet rate alongside your traffic graphs, so that a silent exporter failure is visible as a flat line rather than as an absence. Second, keep the export topology simple and documented — one collector address, one loopback source, one management VRF — because the alternative is a firewall change somewhere you forgot about, followed by a month of missing data. When you need to correlate flows with the packets behind them, the on-box capture tools covered in Cisco IOS-XE embedded packet capture are the natural next step, and for on-device flow inspection with a different command set, see Junos monitor traffic examples. If your goal is steady-state telemetry rather than per-flow records, the streaming alternatives in gNMI dial-in versus dial-out and NETCONF vs RESTCONF vs gNMI are worth comparing on the same interface before you build a second pipeline. On routers where the collector has to live in a separate routing table, VRF Lite configuration covers the export-source plumbing.

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