Netflow, as many of you may know, is a technology introduced by Cisco that gives the ability to collect IP network traffic as it enters or exits an interface. Something that you might not know is that Netflow was originally designed to be a packet switching technology. It was implemented to be an improvement over the Cisco Fast switching that was used at the time. The idea behind this was that the first packet of a flow would create a Netflow switching record and this record would then be used for all later packets of the same flow. Around 1995, Netflow as a switching technology, was replaced by CEF (Cisco Express Forwarding).
These days, Netflow is still popular but is mainly used to provide data to network administrators/engineers in order to troubleshoot problems or determine traffic patterns. Over the past years with the rise of Cisco Nexus and NX-OS, Cisco has been pushing for the and new type of Netflow called Flexible Netflow. The big advantage of Flexible Netflow over its standard version is that the administrator can define the flow it wants to export using NBAR. This allows you to provide application visibility rather than just flow visibility. Also, because only selected flows will be analyzed, Flexible Netflow offers better performance, scalability and aggregation of flow information.
Let’s take a look of the configuration of Standard Netflow vs Flexible Netflow. In this example I defined to just export flows with a set DSCP value:
On a side note, I have ran into problems where applications receiving Netflow would not be coded properly to receive Flexible Netflow formats. This would result into false positives in the logs of the exports received. I would highly suggest to make sure the application receiving Netflow does not have any compatibility problems with Flexible Netflow.