Cisco Catalyst 6509 NetFlow configuration has been a very popular topic in the support room lately. We have been bombarded with questions on how to enable NetFlow on Supervisor Engines 720, 2T, and of course, 6T.

Since the reporting accuracy of your NetFlow analyzer depends on the quality of the exported data, discussing some of the major dos and don’ts in configuring the 6500 series will help us better understand how exactly reporting on these switches works.

Supervisor Engine 720

With the Catalyst 6509 Supervisor Engine 720, there are technically three sets of commands to enable NetFlow support.

To configure NetFlow on the router, we will need the following:

ip flow-export source (insert interface name here)
ip flow-export version 9
ip flow-export destination (netflow collector ip address) (port to export flows to)
ip flow ingress layer2-switched vlan (insert vlans X,Y,X)

ip flow-cache timeout active 1

Once those are in place, we need to configure NetFlow for the switched traffic:

mls nde sender version 9
mls flow ip interface-full
mls nde interface
mls aging long 64
mls aging normal 64

Our next step is to configure each of the interfaces:

ip route-cache flow 

or

ip flow ingress

Supervisor Engine 2T

The Supervisor Engine 2T introduces support for Flexible NetFlow to the Cisco Catalyst 6500 Series switch. A big advantage of the Flexible NetFlow concept—as opposed to traditional NetFlow—is that a user can define the flow themselves. For example, you can create separate flow monitors for security analysis and traffic analysis. Previous generations of Supervisors for the Cisco Catalyst 6500 Series switch don’t provide this level of flexibility.

Many users will find that the pre-existing Flexible NetFlow records are suitable for the majority of their traffic analysis requirements. These predefined records are available to help you quickly deploy Flexible NetFlow. With that said, user-defined Flexible NetFlow is a powerful option for network administrators. Vendors like Cisco now use NetFlow to export unique vendor metadata that includes things like performance metrics, NBAR (application names), and URL information.

When choosing between a predefined and custom record, the first step is to determine what you want to report on.  A good NetFlow reporting solution will be able to provide reporting tailored to the flow elements exported.  A couple weeks ago, my colleague Jeff worked with a customer who wanted QoS and subnet reporting. The elements required for this reporting were not available in the platform-original record, so by following the Cisco Flexible NetFlow guidelines, we found the supported elements for this device.

Here is the custom flow record Jeff ended up with:

flow record NetFlow

match ipv4 source address
match ipv4 destination address
match transport source-port
match transport destination-port
match ipv4 protocol
match interface input
match interface output
match ipv4 tos
match flow direction

collect counter bytes
collect counter packets
collect routing source as
collect routing destination as
collect routing next-hop address ipv4
collect transport tcp flags
collect ipv4 source prefix
collect ipv4 destination prefix
collect timestamp sys-uptime first
collect timestamp sys-uptime last

The key fields are defined in the ‘match’ statements and define how each flow is aggregated in the flow cache table. All packets with the same ‘matching’ attributes are grouped into a flow, and then the ‘collect’ statements define what additional information is added to those flow records.

In this example, our key fields include source and destination addresses, source and destination transport ports, protocol, input and output interfaces, type of service, and flow direction. Then we added counters for both bytes and packets so that we can track network bandwidth utilization. In addition to Type of Service, which was one of the critical elements for this customer, our collect statements also included the source and destination prefixes, which allow for subnet reporting. To go beyond, we added Autonomous System elements and Next Hop addresses.

As a side note, on Sup2T platforms, we also need to configure platform specific CLI to influence the NetFlow cache timeouts.

!
flow platform cache timeout inactive 60
flow platform cache timeout active 60
!

The first command configures the aging time for NetFlow table entries that have been inactive longer than the configured time value. The second command defines the aging time for NetFlow table entries regardless of packet activity, which can prevent counter wraparound and inaccurate statistics. We recommend setting both to 60 seconds.

The result is a QoS report between two locations showing source/destination IP Address pairs with Type of Service per flow.

Cisco Catalyst 6509 NetFlow Support

Supervisor Engine 6T

The Cisco Catalyst Supervisor Engine 6T is the latest addition to Cisco Catalyst 6500 and 6800 family. Supervisor 6T is a next-generation supervisor that offers increased scalability for a few supported features, much higher per-slot throughput, and forwarding performance similar to the previous supervisor. Just like its predecessor, 2T, 6T supports Flexible and Sampled NetFlow.

If you would like to learn more or need help with configurations, please don’t hesitate to reach out to our support team.

Anna McElhany

Anna McElhany

Anna is a Technical Support Engineer at Plixer. She is dedicated to resolving any product-related issues, assisting with device configurations, and making sure customers are getting the most out of Scrutinizer. Anna holds a degree in Computer Technology, the AWS Certified SysOps Administrator - Associate, CCNA R&S, CCNA Security, and CompTIA Network + and Security + certifications, as well as NSTISSI Security INFOSEC Professional recognition. In her free time, Anna enjoys spending time with friends and family, flying drones, and hiking.

Related