We are into the final discussion about traffic prioritizing using Cisco NBAR. Before you start reading, I suggest going through this short blog on how to create custom application and protocols for Cisco NBAR. So, some things which we now know NBAR can do are:

 i. Identifying applications which uses dynamic ports for connectivity.
ii. Identifying rogue or unwanted applications traversing the network using well known port numbers.
iii. Doing Layer 7 analysis for application identification.
iv. Creating custom protocol identification with extensive custom options which includes string search into payloads

A large percentage of us would term the above as a “Good Enough” list. For the few who would ask if there is more, the answer is where we left off in the last blog – NBAR with QoS, traffic classes to match the packets marked by NBAR and associating the classes with QoS policies to manage bandwidth.

To recap, the command usage for creating the custom protocol is ‘ip nbar custom name [offset [format value]] [variable field-name field-length] [source | destination] [tcp | udp ] [range start end | port-number ]‘. Now, to associating these custom made NBAR protocols to a traffic class and attaching the traffic class to a traffic policy which in turn can be used for traffic management.

Traffic Classes and Traffic Policies :

Traffic classes are created to classify or organize the traffic into different groups based on user defined criterion. The criterion can be any known protocol or application name or one of the custom application created using NBAR.
Traffic policies are used to give QoS treatment to the created classes which results in the protocols or applications associated with the traffic class getting specific QoS treatment. The QoS treatment provided can be anything from prioritizing to complete drop of the selected protocol.

Creating Traffic Classes :

The first step is to create traffic classes for protocols or applications. For this, from the global configuration mode use the command ‘class-map [match-all | match-any] class-map-name‘  and then associate the protocols to this class using the ‘match protocol‘ statement. It is not just one, but any number of protocols can be associated with a traffic class. If you have multiple protocols using voice traffic in your network along with the custom NBAR application you created, you can associate them too to the same traffic class so that they all can be given priority in a single class. In the mentioned command, ‘match all’ works under the logical AND condition and ‘match any’ under the logical OR condition. If no statement is used, the default behavior is ‘match all’. An example of creating a traffic class is as below:

Router(config)# class-map voicetraffic
Router(config-cmap)# match protocol talk

Here, the protocol talk is a custom NBAR protocol that was created with user specific criteria. The custom protocol was created as below:
‘ip nbar custom talk tcp range 43000 43500’  where, the custom protocol talk will look for TCP packets that have a destination or source port within the range of 43000 to 43500. Click here for the last blog and for more examples on creating custom NBAR protocols.

Creating Traffic Policies :

The traffic class was created to organize or group together traffic. To assign QoS values to this traffic, you need to create policies, associate the classes to these policies and then provide the bandwidth. Let us see how this can be done:

Router(config)# policy-map Policy-Map-Name
Router(config-pmap)# class class-name
Router(config-pmap-c)# bandwidth {bandwidth-kbps | remaining percent percentage | percent percentage}

The last command specifies the amount of bandwidth in Kbps which the traffic class has to get or you can use the ‘remaining percent’ or the ‘percent’ option. The ‘relative percent’ specifies the guaranteed bandwidth based on a relative percent of available bandwidth and the ‘percent’ option sets the percentage of guaranteed bandwidth based on the absolute available. An example is as given below:

Router(config)# policy-map VoIP
Router(config-pmap)# class voicetraffic
Router(config-pmap-c)# bandwidth percent 60

Here, 60% of the absolute available bandwidth is to be provided for the traffic class voicetraffic which is a part of the policy VoIP. This allows the protocol talk created for custom NBAR to always use 60% of the link bandwidth thus ensuring voice application delivery across the network. Now, there is one last step that has to be done before the bandwidth prioritizing can take effect. Lets move to that.

Attaching Traffic Policy to an Interface :

The traffic classes have been created, they have been associated to a traffic policy and the bandwidth has been assigned. Now, how would the QoS take effect unless it gets to handle the traffic to prioritize. This is why the policy has to be attached to an interface through which the traffic flows. The command for attaching a policy to an interface is ‘service-policy {input | output} policy-map-name‘. The last command allows a policy to be attached to an interface’s IN or OUT traffic. Let us look at an example:

Router(config-if)# service-policy output VoIP

The above example attaches the traffic policy VoIP which contains the traffic class voicetraffic to the OUT traffic for an interface. The policy will allow the protocol talk to use 60% of the available bandwidth on the link which we had specified under the traffic class. It is mostly preferred to associate the policy to the OUT traffic of the WAN interface so that the QoS priority is available for traffic when it exits your network and moves into the cloud.

Now that the policy has been created and associated, you will see your VoIP calls going smoothly with no drops and disturbance. You dont have to limit this to your voice calls alone. Armed with these polices, when it comes to fighting unwanted traffic like peer to peer, your business critical applications will be a definite winner.

If you are not sure whether this really will work, do all that is mentioned and then install NetFlow Analyzer. NetFlow Analyzer can verify your network traffic using NetFlow data and also verify the effect of the CBQoS policies created. You will be able to see the QoS policies and classes attached to an interface, the match statements used, the original volume of traffic and the volume of traffic dropped or queued per class.

Download NetFlow Analyzer to see this and more.
Don Thomas Jacob

Download | Interactive Demo | Product overview video | Twitter | Customers

This site uses Akismet to reduce spam. Learn how your comment data is processed.