Mark Custom Applications for QoS with Cisco NBAR
The modern day network handles a high volume of data and more applications than ever before. Many of these applications are sensitive to delay and latency. Under such situations, network engineers need QoS to prioritize delay-sensitive business apps over others or to drop non-business traffic.
A QoS implementation method used to classify and mark applications or protocols in the network is Modular Quality of Service (MQC) QoS. With MQC QoS, the traffic you need to prioritize or drop is grouped into a class-map. The class-map is then assigned to a policy-map to perform QoS actions. If you are not familiar with QoS, check out this blog for getting started with MQC QoS.
An option available under MQC QoS to group traffic into a class-map is the “match protocol” statement. This statement allows users to match a desired application or protocol, such as FTP or HTTP, into a class-map and then perform QoS actions on it. Here, the ‘protocol’ key word can refer either to regular protocols like bgp, citirix, dhcp, etc., or Network Based Application Recognition (NBAR) recognized protocols.
What is NBAR?
NBAR is a classification technology from Cisco that can identify and classify applications and protocols, including those that use dynamic port numbers. NBAR goes beyond TCP/UDP port numbers and can inspect the payload to identify a protocol. NBAR classifies applications using the default Packet Description Language Modules (PDLM) available in the IOS.
Cisco also has NBAR2, which is the next generation version of NBAR that enhances the existing NBAR functionality to classify even more applications. It also provides additional classification capabilities, such as field extraction and attributes-based categorization. Cisco routinely releases updated protocol packs for NBAR2, which can be accessed from the NBAR protocol library for new signatures, signature updates, and bug fixes.
Conveniently, Cisco NBAR is supported on most Cisco IOS devices and NBAR2 is supported on devices such as ISR-G2, ASR1K, ASA-CX, and Wireless LAN controllers. And to make it easy, NBAR2 configuration is exactly the same as NBAR.
Why NBAR
Many network engineers use Access Control Lists (ACL) for application classification when defining their QoS policies. But sometimes, NBAR is a better choice than ACLs because of NBAR’s ability to automatically recognize applications and protocols which otherwise would have to be defined manually.
NBAR is also easier to configure compared to ACLs and provides collection statistics (if you need them) via an NBAR protocol discovery MIB for each application identified by NBAR.
Finally, the biggest advantage of NBAR is that it can be used for custom protocol identification.
Custom Protocols with NBAR
There are many applications that are designed to use dynamic port numbers. Such a dynamic change in port numbers can make it difficult to identify applications when using regular monitoring tools and sometimes even with NBAR. While NBAR2 does have signatures for various applications, there are chances you might be using an internally built application not defined in NBAR2 which gives a good reason to define your own custom protocol for NBAR.
NBAR custom protocol is quite extensive too. You can define custom protocols to be identified by the NBAR engine based on IP address, port, transport protocol, and even after inspecting into specific bytes of the payload for keywords.
Another is the HTTP advantage. Every network allows ingress and egress HTTP protocol which also makes it the protocol used by many non-business applications, rouge applications, and even malware to gain access into the enterprise. With custom protocol matching, NBAR can classify HTTP traffic based on URL, host, MIME, or even the HTTP header fields. So imagine the advantages: allow HTTP traffic from specific sources and block everything else, stop unwanted HTTP traffic and allow all business applications, block only Youtube, but not Salesforce, or allow only Salesforce, but block everything else and many more permutations.
So, here it is. You do not have to enable NBAR on your device to group with QoS policies unless you need either NBAR protocol discovery or the NBAR custom protocol identification. There are two options that Cisco reference sites mention for enabling custom NBAR, depending on your IOS version. There is ip nbar custom and also ip nbar custom_name transport command. Provided below is the syntax for both:
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 refers to the byte location in the payload for inspection. The format and its value can be a term (when used with ascii format), a hexadecimal value (used with hex format), or a decimal value (used with decimal format). For complete information on what each option refers to, check this link:
http://www.cisco.com/c/en/us/td/docs/ios/qos/command/reference/qos_book/qos_i1.html#wp1022849
Another command, mostly referred to with NBAR2 or newer IOS is:
ip nbar custom name transport {tcp | udp} {id id } ip address ip-address | subnet subnet-ip subnet-mask}| ipv6 address {ipv6-address | subnet subnet-ipv6 ipv6-prefix} | port {port-number | range start-range end-range} | direction {any | destination | source}
Check the link below for a reference on the above command:
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos/command/qos-cr-book/qos-i1.html#wp1207545360
Once you have your custom protocol captured with NBAR, create a class-map and use the match protocol statement with your custom protocol name to classify the traffic that matches the custom-protocol into a class-map. You can then prioritize, drop or police the traffic based on your requirements.
Well, I hope this information eases your implementation of NBAR. More importantly, I hope you enjoy the many benefits of NBAR and a trouble-free network!
