I wanted to take some time today to talk a little bit about some differences between user-defined and predefined Flexible NetFlow records.
A big advantage of the Flexible NetFlow concept opposed to traditional NetFlow is that the user can define the flow.
The user-defined flow records and the component structure of Flexible NetFlow make it easy to create various configurations for traffic analysis and data export on a networking device with a minimum number of configuration commands.
I work with customers all the time who are a little intimidated by the thought of defining their own records when moving to new device platforms that support Flexible NetFlow. They tend to under-configure the records and don’t include some needed fields for the best reporting. In many cases, they aren’t aware that vendors like Cisco include several predefined Flexible NetFlow records that will help when migrating to Flexible NetFlow.
These predefined records are available to help you quickly deploy Flexible NetFlow. They help ensure backward compatibility with your existing NetFlow collectors.
The predefined records are based on the original NetFlow ingress and egress caches and the aggregation caches. Each has a unique combination of key and non-key fields that offer you the built-in ability to monitor various types of traffic in your network without customizing Flexible NetFlow on your router.
Many users will find that the pre-existing Flexible NetFlow records are suitable for the majority of their traffic analysis requirements.
With all of these predefined records, why have user-defined records?
User-defined Flexible NetFlow is a powerful option for network administrators because vendors like Cisco now use NetFlow to export unique vendor metadata that includes things like performance metrics, NBAR (application names), and URL information.
Another key benefit has to do with flow volume and overhead on the network device. We can change how we aggregate NetFlow data by modifying the key fields to cut down on flow volume and maybe eliminate need for sampling.
By changing the key fields in the flow record, the flow aggregation method on the NetFlow cache table changes. In many cases, you can cut down flow volume and resource overhead and still get 100% traffic accountability.
Here is an example:
Say there are two SSL connections to the same web server in the same minute. We monitor one with a flow record that includes a key field that collects the NBAR application name, and the other with a record that includes the source and destination ports as key fields. The NBAR template will generate one flow record because both flows will match the same application-name key field. The record that includes source and destination ports as key fields will create two flow records as long as the connections have different ephemeral ports to make the connection.
You could see as much as a 50 percent drop in flow volume from the exact same traffic streams simply by using a different aggregation method.
What if you don’t have Cisco devices?
When we talk about Flexible NetFlow, the focus usually turns toward Cisco devices. These days, however, with IPFIX being the industry flow standard, many other vendors also give administrators options regarding the metadata seen in the flows. These vendor-specific exports can deviate drastically from the traditional NetFlow v5 or v9 standard.
Moving from traditional to Flexible NetFlow gives you a ton of different user configuration options. Contact our support team if you want to learn more or need help with configurations.