Customized Application and Protocol Analytics using Cisco NBAR

The last blog discussed in brief about NBAR, PDLM and about adding new PDLMs for Cisco NBAR. The process of adding new PDLMs for new application recognition has now been made almost obsolete with no new PDLMs being available and the introduction of custom application identification for NBAR. Let me show you how a custom application or protocol identification can be added to Cisco’s NBAR engine and later on we will go through how traffic privatization can be done for these applications.

Cisco by default provides PDLMs to recognize around 100 bandwidth hogging and business critical applications including BitTorrent, Kazaa, Skype, RealAudio, HTTP(S), Exchange and many more. These applications can be those which uses a fixed port number or the ones which uses random ports to even those applications which hide behind well known port numbers. You can see the complete list of NBAR supported protocols from the below link:
http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/clsfy_traffic_nbar.html#wp1056828

Back to custom feature. Cisco stopped the custom.pdlm file for NBAR and somewhere around 12.3 IOS version, moved to this new option called ‘custom feature’. A single command now allowed a user to add a new protocol recognition to the NBAR engine. So how is this done? To define a custom protocol/application, apply the below command from the global config mode:

ip nbar custom name [offset [format value]] [variable field-name field-length] [source | destination] [tcp | udp ] [range start end | port-number ]

In the above command, offset defines the byte in the payload to be inspected for the format which can be ascii, hex, or decimal. The value field can contain either a term (used with ascii), a hexadecimal (used with hex) or a decimal value (used with decimal.)
Even further customization can be done using the optional variable keyword. The variable keyword lets a specific portion of the custom protocol to be treated as another NBAR-supported protocol. For example, a specific portion of the custom protocol can be tracked using class-map statistics and can be matched using the class-map commands of QoS.
The rest of the commands specifies the flow direction to be searched (source flow or destination flows), the transport protocol to be analyzed and the port numbers or range to search in.

Let us discuss some examples to get a better understanding on the feature:

Eg 1: ip nbar custom xmail 10 ascii xmail source udp 1202

In the above example, custom protocol xmail will look for the term xmail in the 10th byte of the payload that have their source port as 1202 UDP.

Eg 2: ip nbar custom virus_home 7 hex 00AF destination udp 3000

In the above example (taken from the Cisco guide), the custom protocol virus_home will identify UDP packets that have a destination port of 3000 and that contains the hex character “00AF” in the seventh byte of the payload.

Eg 3: ip nbar custom talk tcp range 43000 43500

In the above example, the custom protocol talk will look for TCP packets that have a destination or source port within the range of 43000 to 43500

NBAR engine also has a list of well known ports to identify an application along with the rule based payload inspection approach. If you would like to have NBAR search for a protocol using custom ports other than the well know port numbers, use the ‘ip nbar port-map’ command. Quite useful when you have a common applications using a non-well known port number. Adding a port to a NBAR protocol does not limit it to search only for the added port numbers. Those protocols which are identified based on payloads will continued to be identified as before in addition to the new port number based search. The command usage for adding ports to a protocol is as below:

ip nbar port-map protocol-name [tcp | udp] port-number

Here, replace protocol-name with the name of the NBAR protocol and specify the transport protocol and port number to be added. An example is ‘ip nbar port-map telnet tcp 24’ where NBAR engine is designed to identify telnet traffic on TCP 24 in addition to TCP 23.

That really is custom analytics. You can specify more than 30 custom protocols but the total number of protocols that can be defined for NBAR is 128. There are other limitations too. One is that the custom protocol defined can inspect the protocol payload into only 255 bytes. Another one is the port length. It is only a maximum of 16 ports that can be given or when using port range, a range of maximum 1000 ports only is allowed. I would term these limitations minor when considering the advantages you get on the whole with custom defining.

There is more to come. NBAR working with QoS. Creating traffic classes to match the packets marked by custom protocol. Associating the classes with QoS policies to manage bandwidth. Maybe, the topic should be titled ‘Hidden Powers of Cisco NBAR’. We will see how to create QoS classes using NBAR classified protocols in our next blog.

By the way, ManageEngine NetFlow Analyzer can report on NBAR data as well as on QoS policies which are created with NBAR protocol matching. Two complimentary technologies and a single tool to monitor. The end expression is awesome !