Cisco infrastructure generates the telemetry that Cisco network bandwidth monitoring depends on natively. Every Cisco router and switch running IOS or IOS XE is capable of exporting flow records that describe the source, destination, protocol, and byte volume of traffic crossing its interfaces. That telemetry is what network teams rely on to monitor Cisco network traffic, troubleshoot bandwidth contention, plan capacity upgrades before links saturate, and investigate security incidents by reconstructing which hosts talked to which. The operational question is not whether Cisco devices can produce that data, but how to monitor bandwidth on Cisco devices correctly, which export format to use, and how to extend basic flow visibility to Layer 7 application identification through NBAR2 and AVC.
That question doesn't have one answer across a Cisco estate. Which export mechanism is even available, and how it's configured, depends on the platform: traditional NetFlow and Flexible NetFlow aren't interchangeable, IOS XE devices drop support for the older method entirely, and NBAR2 application visibility can't simply be layered on top of an existing flow configuration without a specific AVC setup. The rest of this guide works through those platform-specific decisions in order, covering the export mechanism to use, how to add Layer 7 visibility to it, and what changes when the device in question is a router, a Nexus switch, an ASA firewall, or a wireless controller instead.
How Cisco devices export bandwidth data
Traditional NetFlow applies to older Cisco IOS devices and is the earliest form of Cisco NetFlow monitoring available on the platform. It is configured directly on the interface using ip flow ingress and ip flow egress commands and exports records in NetFlow v5 or v9 format. The record format is fixed, and the fields captured cannot be customized. This is the starting point for how to monitor Cisco network traffic with NetFlow on any IOS or IOS XE device: pick the export mechanism the platform supports, then decide how much of the flow record you need to customize.
Flexible NetFlow is the current standard on Cisco IOS XE devices, including the Catalyst 9000 series, ISR 4000 series, and ASR platforms. Traditional NetFlow accounting is not supported on IOS XE. Instead, Flexible NetFlow uses a three-component configuration: a flow record that defines which fields to capture, a flow exporter that defines the collector destination, and a flow monitor that combines both and is applied to the interface.
Flexible NetFlow and NBAR2: why they can't run together
Flexible NetFlow and NBAR cannot be configured together on the same interface simultaneously. When Layer 7 application identification through NBAR2 is required alongside flow export, the correct approach is AVC Flexible NetFlow, which integrates Cisco application visibility with Cisco flow monitoring through a separate AVC configuration path (refer below).
Choosing the right configuration path
| If you need | Use | Gives you |
|---|---|---|
| Basic flow export on IOS XE | Flexible NetFlow | Five-tuple flow data (source/destination IP, port, protocol, byte/packet counts) |
| Layer 7 application ID only | NBAR2 (standalone) | Application classification, but not exported as flow records |
| Both flow export and application ID | AVC Flexible NetFlow | Flow records tagged with the NBAR2-identified application name |
Layer 7 application identification with NBAR2 and AVC
Cisco application visibility starts with NBAR2, which classifies traffic by application behavior and payload characteristics rather than port assignment, identifying applications that use dynamic ports, tunnel inside HTTPS, or otherwise avoid port-based detection. NBAR2 ships with signatures for over 1,000 applications by default, and Cisco extends that library through protocol pack updates released roughly every one to four months (see the FAQ below).
On Cisco IOS XE devices, enabling NBAR2-based application visibility alongside flow export requires configuring AVC Flexible NetFlow. In practice, this means building a flow record with the usual key fields (source/destination IP, ports, and protocol) and adding collect application name alongside the standard byte and packet counters. That one command is what causes the device to tag each exported flow record with its NBAR2-identified application, on top of a flow monitor (combining the record and an exporter) applied to the interface as input and output.
The collect application name command is what enables NBAR2 application tagging on exported flow records. Without it, the flow record carries five-tuple data only, and application identification must be performed by the collector using port-based classification rather than NBAR2 data from the device.
Cisco bandwidth monitoring across device types
Not all Cisco devices export bandwidth data the same way, and Cisco bandwidth utilization monitoring shifts depending on the platform. The device determines the export mechanism, the configuration syntax, and the level of application visibility available, which means a monitoring strategy that works on a Catalyst 9000 series switch may not apply directly to a Nexus data center switch or an ASA firewall. Whether the question is how to monitor bandwidth on Cisco routers like the ISR 4000 and ASR series, or how to monitor bandwidth on Cisco switches like the Catalyst 9000 or Nexus line, the flow export mechanism below is what changes.
| Platform | Export mechanism | Config syntax | App visibility | Key restriction |
|---|---|---|---|---|
| Cisco IOS XE routers/switches (Catalyst 9000, ISR 4000) | Flexible NetFlow, AVC | Standard Flexible NetFlow (flow record, exporter, monitor) | Native, via AVC + NBAR2 | Flexible NetFlow and NBAR2 can't run on the same interface without AVC |
| Cisco Nexus switches (data center) | NetFlow via NX-OS | NX-OS syntax, distinct from IOS XE | Export format and downstream analysis equivalent to IOS XE | N/A |
| Cisco ASA / Firepower firewalls | NetFlow Secure Event Logging (NSEL) | ASA/Firepower-specific NSEL configuration | Security-event flows only (connection create, teardown, denied), not application-level | N/A |
| Cisco wireless infrastructure (Catalyst Center-managed APs, WLCs) | Flow export from the wireless controller | WLC-specific configuration | Per-SSID and per-client traffic visibility | N/A |
Cisco bandwidth monitoring with NetFlow Analyzer
Configuring and maintaining Flexible NetFlow, AVC, and NBAR2 protocol packs by hand across dozens or hundreds of devices is a significant ongoing operational burden, one that only grows as protocol packs are updated every one to four months and new device types (IOS XE routers, Nexus switches, ASA/Firepower firewalls, wireless controllers) get added to the network. NetFlow Analyzer is one of the Cisco bandwidth monitoring tools built to read Cisco's flow export formats directly, correlating all of it into one console instead of requiring a separate parsing setup per platform. That's the practical difference between manually maintaining Cisco NetFlow bandwidth monitoring device-by-device and consolidating it into one place.
With NetFlow Analyzer, you get:
- Native NBAR2 application visibility: reads the NBAR2 application name directly from Flexible NetFlow records exported with NBAR information included, and surfaces it per flow, with no separate port-based classification step on the collector side
- Cross-platform correlation: combines Flexible NetFlow from IOS XE, NX-OS flow data from Nexus switches, NSEL security events from ASA/Firepower, and WLC-exported wireless flows in one dashboard
- Per-application, per-interface, and per-host breakdowns: pinpoints exactly which application, host, or conversation is consuming bandwidth on any monitored interface
- Application names sourced straight from the device: displays whatever NBAR2 application name the router or switch already assigned, so accuracy depends on keeping the device's own Cisco protocol pack current rather than on anything NetFlow Analyzer does independently
- No probes or agents: works entirely from flow telemetry your Cisco devices are already capable of exporting
Get NetFlow Analyzer now for a hands-on experience with your own Cisco infrastructure.
Frequently asked questions
Can Flexible NetFlow and NBAR2 be configured on the same interface?
Not simultaneously using standard Flexible NetFlow; see the configuration path table above. Cisco's Network Management Configuration Guides for the Catalyst 9000 series state this restriction directly: Flexible NetFlow and NBAR cannot be configured together at the same time on the same interface. When Layer 7 application identification is required alongside flow export, AVC Flexible NetFlow is the correct approach, integrating NBAR2 application tagging into the flow record through the collect application name command.
What is the difference between NetFlow v5, v9, and IPFIX on Cisco devices?
How do I get started if I just want to monitor Cisco bandwidth usage on a single router or switch?
What is the NBAR2 protocol pack and why does it matter?
Does NetFlow affect router CPU?
How much bandwidth does the export itself consume?
What happens on my older ISR G2s?
Why is application data missing in my collector after configuring AVC?
By Gladius,
ManageEngine Team