QoS Classification on Cisco IOS Router

On most networks you will see a wide range of applications, each application is unique and has its own requirements when it comes to bandwidth, delay, jitter, etc. For example, an FTP application used for backups of large files might require a lot of bandwidth but delay and jitter won’t matter since it’s not an interactive application.

Voice over IP on the other hand doesn’t require much bandwidth but delay and jitter are very important. When your delay is too high your calls will become walkie-talkie conversations and jitter screws up the sound quality.

To make sure each application gets the treatment that it requires we have to implement QoS (Quality of Service).

The first step when implementing QoS is classification, that’s what this tutorial is all about.

By default your router doesn’t care what kind of IP packets it is forwarding…the only important thing is looking at the destination IP address, doing a routing table lookup and whoosh…the IP packet has been forwarded.

Before we can configure any QoS methods like queuing, policing or shaping we have to look at the traffic that is running through our router and identify (classify) it so we know to which application it belongs. That’s what classification is about.

Once the traffic has been classified, we will mark it and apply a QoS policy to it. Marking and configuring QoS policies are a whole different story so in this tutorial we’ll just stick to classification.

On IOS routers there are a couple of methods we can use for classification:

  • Header inspection
  • Payload inspection

There are quite some fields in our headers that we can use to classify applications. For example, telnet uses TCP port 23 and HTTP uses TCP port 80. Using header inspection you can look for:

  • Layer 2: MAC addresses
  • Layer 3: source and destination IP addresses
  • Layer 4: source and destination port numbers and protocol

This is a really simple method of classification that works well but has some downsides. For example, you can configure your router that everything that uses TCP and destination port number 80 is “HTTP” but it’s possible that some other applications (instant messaging for example) are also using TCP port 80. Your router will perform the same action for IM and HTTP traffic.

Payload inspection is more reliable as it will do deep packet inspection. Instead of just looking at layer 2/3/4 information the router will look at the contents of the payload and will recognize the application. On Cisco IOS routers this is done with NBAR (Network-Based Application Recognition).

When you enable NBAR on an interface, the router will inspect all incoming IP packets and tries to match them with signatures and attributes in the PDLM (Packet Description Language Module). For example, NBAR can detect HTTP traffic no matter what ports you are using and it can also match on things like:

  • URL
  • MIME type (zip file, image, etc)
  • User-agent (Mozilla, Opera, etc)

Since NBAR can see the URL, it is also commonly used to block websites and a popular choice for classification.

You should now have an idea what classification is about, let’s look at some routers and configure classification.

Configuration

We’ll start with a simple example where I use an access-list to classify some telnet traffic. Here’s the topology that I will use:

R1 R2 Gigabit Links

R1 will be our telnet client and R2 the telnet server. We will classify the packets when they arrive at R2. Let’s look at the configuration!

Classification with access-list

First I have to create an access-list that matches on telnet traffic:

R2(config)#ip access-list extended TELNET
R2(config-ext-nacl)#permit tcp any any eq 23

This will match on all IP packets that use TCP as the transport protocol and destination port 23. Normally when you configure an access-list for filtering, we apply it to the interface. When configuring QoS we have to use the MQC (Modular Quality of Service Command-Line Interface). The name is pretty spectacular but it’s a really simple method to configure QoS.

We use something called a policy-map where we configure the QoS actions we want to perform…marking, queueing, policing, shaping, etc. These actions are performed on a class-map, and that’s where we specify the traffic. Let me show you how this is done:

R2(config)class-map TELNET
R2(config-cmap)#match ?
  access-group         Access group
  any                  Any packets
  class-map            Class map
  cos                  IEEE 802.1Q/ISL class of service/user priority values
  destination-address  Destination address
  discard-class        Discard behavior identifier
  dscp                 Match DSCP in IP(v4) and IPv6 packets
  flow                 Flow based QoS parameters
  fr-de                Match on Frame-relay DE bit
  fr-dlci              Match on fr-dlci
  input-interface      Select an input interface to match
  ip                   IP specific values
  mpls                 Multi Protocol Label Switching specific values
  not                  Negate this match result
  packet               Layer 3 Packet length
  precedence           Match Precedence in IP(v4) and IPv6 packets
  protocol             Protocol
  qos-group            Qos-group
  source-address       Source address
  vlan                 VLANs to match

I created a class-map called “TELNET” and when you create a class-map you have a lot of options. On top you see access-group which uses an access-list to classify the traffic, that’s what I will use. Some other nice methods are the input-interface, frame-relay DLCI values, packet length, etc. The most simple option is probably the access-list:

R2(config-cmap)#match access-group name TELNET

My class-map called “TELNET” now matches traffic that is specified in the access-list called “TELNET”.

Now we can create a policy-map and refer to our class-map:

R2(config)#policy-map CLASSIFY
R2(config-pmap)#class TELNET

The policy-map is called “CLASSIFY” and the class-map called “TELNET” belongs to it. Normally this is where I also specify the QoS action like marking, queueing, etc. I’m not configuring any action right since this tutorial is only about classification.

Before the policy-map does anything, we have to attach it to an interface:

R2(config)#interface GigabitEthernet 0/1
R2(config-if)#service-policy input CLASSIFY

That’s it, our router can now classify telnet traffic. Let’s try it by telnetting from R1 to R2:

R1#telnet 192.168.12.2
Trying 192.168.12.2 ... Open

Let’s see what R2 thinks of this:

R2#show policy-map interface GigabitEthernet 0/1
 GigabitEthernet0/1

  Service-policy input: CLASSIFY

    Class-map: TELNET (match-all)
      11 packets, 669 bytes
      5 minute offered rate 0 bps
      Match: access-group name TELNET

    Class-map: class-default (match-any)
      3 packets, 206 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

Great! Our router sees the telnet traffic that arrives on the GigabitEthernet 0/1 interface. You can see the name of the policy-map, the class-map and the access-list that we used. Something that you should remember is that all traffic that is not specified in a class-map will hit the class-default class-map. Not too bad right? Let’s see if we can also make this work with NBAR…

Classification with NBAR

The configuration of NBAR is quite easy. First let me show you a simple example of NBAR where it shows us all traffic that is flowing through an interface:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 651 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

504 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Forum Replies

  1. Hello Rene

    Thanks for your feedback, and then, what’s the best way to get the port numbers of some particular applications?

     

    Thanks

    Dong

  2. Hi Dong,

    If you have “well known” applications like HTTP, FTP, telnet, SSH, etc. then it’s easy to look them up. You can google for the RFCs to find the official documentation. Here’s an example for HTTP:

    https://tools.ietf.org/html/rfc2616

    If it’s an application from some vendor, contact them…most of them offer an overview with addresses / protocols / port numbers that should be allowed. Here’s a good example from Airwatch:

    https://www.air-watch.com/downloads/resources/AirWatch-Install-Requirements-SaaS.pdf

    Hope this helps.

    Rene

  3. Hi, Rene,
    my question is, how can I classify the encrypted traffic of a certain traffic category? If I want to classify all streaming video traffic and I don’t know the ports or IP addresses of the video streaming sources. And we know that great deal of traffic is encrypted (https) nowadays.
    Is there a possibility?

    Thanks.

    Primoz

  4. Hi Rene,

    Can you give me an example of using match not classification ?? and in situation we used it ??

  5. Hello Hussein.

    The match not criterion for a class map matching statement essentially says “anything that doesn’t match what follows”. It is similar to “not equal to” in programming or logic. If we use the example in the lesson, and the command entered was:

    R2(config-cmap)#match not access-group name TELNET

    then the result would be that the policy map would match everything EXCEPT what is found in the access-list named TELNET.
    In other words, the policy would match everything and would not match anything using port 23.

    It is just another tool to be able to ex

    ... Continue reading in our forum

5 more replies! Ask a question or join the discussion by visiting our Community Forum