As a company reporting on just about all unique flow exports found in the world, we run into nearly every issue probably thought possible. From problems with active timeout to long lived flows, we work with different companies to try and make sure all the data can work together. To this end, we like to think that we promote the best practices that our team has collected over the years from being in this business.
Today’s post is about the importance of IDs when working NBAR and option templates. NBAR or Network Based Application Recognition is used by Cisco hardware to intelligently identify and classify applications in order to optimize the end user experience over the network. Typically it is used to mark the traffic as best effort, policed or blocked as required. NBAR has gone through some revisions over the years and today it is sometimes referenced as NBAR2.
When NBAR is enabled, typically at least two templates are exported when using NetFlow v9 or IPFIX.
- Flows: these are the typical flows with an additional element ‘Application ID’ which our interface auto converts to the application name by looking in the 2nd
- Option Template: this is a list of all the Application IDs with the text description.
After reviewing the two templates shown above, you can see that it is the ID (Type: 3 ID: 53) that allows the reporting system to link the two together. These values are exported in different templates in order to allow the flow export process to scale for high flow volume environments.
When configuring custom NBAR2 protocols, it is always a good idea to try and maintain consistency across all your protocol definitions on each router in order to avoid collisions in the central reporting system. Since custom definitions do not contain device specific information, there comes the potential for collectors to incorrectly lookup a protocol in a centralized collection system. These collisions could happen for a variety of reasons.
Custom protocols are arbitrarily assigned a “selector ID” when configured without the optional “id” option. The selector ID can be anything from 1-65535. We suggest maintaining a master protocol list to stay consistent across your network.
Examples without id option:
roto-router(config)#ip nbar custom NETFLOW udp 2055 roto-router(config)#sh ip nbar protocol-id | i NETFLOW NETFLOW 252 Custom
Example with id option:
roto-router(config)#ip nbar custom http ssl unique-name *plixer* id 42 roto-router(config)#do sh ip nbar protocol-id | i plixer plixer 42 Custom
How these are assembled are defined here in the Cisco wiki.
The intention is that an enterprise keep consistent identifiers across the entire enterprise. This is outlined in RFC 6759.
PANA-L3 2 Proprietary layer 3 definition. : An enterprise can export its own layer 3 protocol numbers. The Selector ID has a global significance for all devices from the same enterprise.
Not every custom protocol needs to be applied to every device. They just need to have a unique ID.
If it is possible for you to maintain a master custom protocol list, it would match the design goals of the RFC and provide a consistent set of protocol definitions for all vendors including non-Cisco devices exporting applicationid using this IPFIX information element. If you want to learn more about this topic, check out this post on NBAR2 AVC.