NBAR is a more of an intelligent classification and has the ability to identify web based and client-server applications that uses dynamic ports as well as those using well known port numbers (like Bit Torrent). This helps the network administrator identify what really is going on in the network and then define QoS policies to ensure that the bandwidth is used for its original purpose – run business applications.
NBAR data, until now, has to be collected through SNMP polling of the NBAR MIB (CISCO-NBAR-PROTOCOL-DISCOVERY MIB) in the router. The NBAR reporting tool queried this MIB and gave outputs about the usage. Though NBAR gave users the ability to discover applications that used well know ports or visibility on applications that used dynamic ports, well visible was the limitation too. SNMP NBAR did not have the ability to report on the hosts involved with the identified application. So, NBAR allowed the network admin to define QoS policies which limited or blocked the application bandwidth, but he was unable to find out which user was involved with the traffic. Identifying the user will give more powers: identify hosts on which Peer to Peer applications are installed, ensure that the application was used by the intended user, warn the user if he was using a business critical application or define network management policies.
Flexible NetFlow – NBAR Integration (FNF – NBAR) :
With the introduction of Flexible NetFlow, things have changed. Flexible NetFlow, which requires NetFlow V9 exports, allows a user to define the key and non key fields in a flow record. This way, users define what they need to or need not see from NetFlow data and define what is classified as a single conversation. Flexible NetFlow configuration is different from the traditional NetFlow (called NetFlow v5) as this requires the creation of flow exporter, record and monitors. Read more on Flexible NetFlow configuration from our blogs here .
Match Application Name:
Flexible NetFlow allows defining the key and non key fields through match and collect statements, Our star match statement is the ‘match application name’ command which allows users to capture the NBAR application information to be included in NetFlow records. This helps identify, through a combination of NetFlow and NBAR reporting, the users involved with the ‘unwanted’ applications. Network admins who complained about not being able to see the users can leverage on the new reporting feature to see the hosts involved or the ‘culprits’ in case of undesired applications.
The support for this match statement is available with Cisco IOS 15.0 or above. So, any user running the latest IOS on their devices can use the new FNF – NBAR and get detailed visibility into their application usage.
The real 2 in 1:
Why limit your NBAR reporting to only the new devices or through IOS upgrades? Who will want to move the sturdy Cisco 2800 for a new device just for FNF NBAR report?
This is why NetFlow Analyzer has not dropped SNMP NBAR support even after the introduction of FNF – NBAR. There certainly are many users who have devices with the 12.x IOS trains which supports only SNMP NBAR and NetFlow Analyzer will not leave them in the lurch. So, users who have new devices with the mentioned IOS or have upgraded their IOS to the latest can opt for FNF – NBAR and users who have the earlier IOS versions can continue to use the SNMP NBAR. Now, that really is NBAR support.
Our next blog will walk you through the detailed configuration for Flexible NetFlow with NBAR support and show how NetFlow Analyzer does the reporting.
Download | Interactive Demo | Product overview video | Twitter | Customers
Regards,
Don Thomas Jacob
