Recently I’ve had many requests from customers who upgraded to the Catalyst 9500 series and are looking for a NetFlow configuration document. So I’ve put together this guide for configuring FNF (Flexible NetFlow).
This guide is built for the Catalyst 9500 series running on IOS XE Everest 16.6.x and will contain examples for both Layer 3 and Layer 2 flow collection.
If you’re familiar with FNF configurations, there won’t be much new to you in this guide. The configuration consists of three main components;
- Creating a flow record
- This will contain match (key fields) and collect (non-key fields) statements
- Creating a flow exporter
- This contains your export information such as source interface, transport port, and destination address
- Creating a flow monitor
- This will reference your custom flow record, custom flow exporter, and cache modifications such as timeout values
In order to capture both ingress and egress traffic statistics, we’ll need to create separate flow records and separate flow monitors for each direction. This configuration will allow you to monitor both ingress and egress traffic statements per interface.
A few restrictions to point out prior to the actual configuration:
- FNF is not supported on the L2 port-channel interface, but is supported on the L2 port-channel member ports
- FNF is not supported on the L3 port-channel interface, but is supported on the L3 port-channel member ports
- FNF version 9 and 10 (IPFIX) are supported formats. However, if you have not specified the export protocol, V9 will be the default
Let’s dive into the actual configuration!
We’ll start with a FNF record to capture our L3 ingress traffic:
Device# configure terminal Device (config) # flow record record-ingress Device (configure-flow-record) # description IPv4 ingress Device (configure-flow-record) # match ipv4 source address Device (configure-flow-record) # match ipv4 destination address Device (configure-flow-record) # match ipv4 protocol Device (configure-flow-record) # match transport source-port Device (configure-flow-record) # match transport destination-port Device (configure-flow-record) # match ipv4 tos Device (configure-flow-record) # match interface input Device (configure-flow-record) # match flow direction Device (configure-flow-record) # collect interface output Device (configure-flow-record) # collect counter bytes long Device (configure-flow-record) # collect counter packets long Device (configure-flow-record) #collect tcp flags Device (configure-flow-record) # collect timestamp absolute first Device (configure-flow-record) # collect timestamp absolute last Device (configure-flow-record) # exit
Flow record for capturing egress traffic:
Device# configure terminal Device (config) # flow record record-egress Device (configure-flow-record) # description IPv4 egress Device (configure-flow-record) # match ipv4 source address Device (configure-flow-record) # match ipv4 destination address Device (configure-flow-record) # match ipv4 protocol Device (configure-flow-record) # match transport source-port Device (configure-flow-record) # match transport destination-port Device (configure-flow-record) # match ipv4 tos Device (configure-flow-record) # match interface output Device (configure-flow-record) # match flow direction Device (configure-flow-record) # collect interface input Device (configure-flow-record) # collect counter bytes long Device (configure-flow-record) # collect counter packets long Device (configure-flow-record) #collect tcp flags Device (configure-flow-record) # collect timestamp absolute first Device (configure-flow-record) # collect timestamp absolute last Device (configure-flow-record) # exit
Next we’ll create our flow exporter:
Device# configure terminal Device (config) # flow exporter export-ipfix Device (configure-flow-exporter) # description Export to Scrutinizer Device (configure-flow-exporter) # destination [IP of collector] Device (configure-flow-exporter) # transport udp 2055 Device (configure-flow-exporter) # export-protocol ipfix Device (configure-flow-exporter) # template data timeout 60 Device (configure-flow-exporter) # exit
Then both of our flow monitors (one for ingress and one for egress):
Ingress:
Device# configure terminal Device (config) # flow monitor fm-input Device (configure-flow-monitor) # description IPv4 ingress exports Device (configure-flow-monitor) # exporter exporter-ipfix Device (configure-flow-monitor) # record record-ingress Device (configure-flow-monitor) # cache timeout active 60 Device (configure-flow-monitor) # exit
Egress:
Device# configure terminal Device (config) # flow monitor fm-output Device (configure-flow-monitor) # description IPv4 egress exports Device (configure-flow-monitor) # exporter exporter-ipfix Device (configure-flow-monitor) # record record-egress Device (configure-flow-monitor) # cache timeout active 60 Device (configure-flow-monitor) # exit
Finally, applying your monitor to the interface:
Device# configure terminal Device (config) # interface GigabitEthernet 1/0/1 Device (config-if) # ip flow monitor fm-input Device (config-if) # ip flow monitor fm-output Device (config-of) # end
Configure flows for a L2 interface:
We shouldn’t expect much of a change here other than how we’re configuring the custom flow record. Below is an example of a flow record for monitoring L2 traffic:
Device# configure terminal Device (config) # flow record record-l2 Device (configure-flow-record) # description layer 2 flows Device (configure-flow-record) # match datalink ethertype Device (configure-flow-record) # match datalink mac source address input Device (configure-flow-record) # match datalink mac destination address input Device (configure-flow-record) # match datalink vlan input Device (configure-flow-record) # collect counter bytes long Device (configure-flow-record) # collect counter packets long Device (configure-flow-record) # exit
Similar to capturing L3 statistics, you’ll also need separate monitors for both ingress and egress collection that will reference the custom L2 records and the exporter.
When creating custom FNF records users have a lot of flexibility in the elements they would like to monitor. For a full list of key and non-key fields, you can reference Cisco’s documentation here. When collecting a variety of unique data elements for network monitoring or security purposes, you’ll also need a robust collection and reporting platform such as Scrutinizer, which can always be evaluated free for 14 days.