Sounds simple enough. What are the different IOS tools that you can use accomplish this?

Method 1: MQC

ip access-list extended PRECEDENCE53
 permit ip any any precedence 5
 permit ip any any precedence 3

class-map match-any PRECEDENCE53
  match access-group name PRECEDENCE53
!
!
policy-map CAR
  class PRECEDENCE53
     police 1000000 35000 35000 conform-action transmit exceed-action drop
!
interface FastEthernet0/0
 service-policy input CAR

Pretty simple really. We have used an extended access-list that matches IP Precedence values 5 and 3 on class “PRECEDENCE53″. All traffic in that class will be policed to 1Mbs (the normal and burst sizes have been set to 35,000).

Let’s verify this:

Verification:

R2#sh policy-map int f0/0
 FastEthernet0/0 

  Service-policy input: CAR

    Class-map: PRECEDENCE53 (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group name PRECEDENCE53
        0 packets, 0 bytes
        5 minute rate 0 bps
      police:
        1000000 bps, 35000 limit
        conformed 0 packets, 0 bytes; action: transmit
        exceeded 0 packets, 0 bytes; action: drop
        conformed 0 bps, exceed 0 bps

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

Looks good. How about we do the same thing, but this time using the traditional rate-limit command?

Method 2: Rate-Limit with extended access-list

access-list 101 permit ip any any precedence 5
access-list 101 permit ip any any precedence 3
!
interface FastEthernet0/0
 rate-limit input access-group 101 1000000 35000 35000 conform-action transmit exceed-action drop

Not much different really (just less typing!). Let’s verify this:

Verification:

R2#sh int f0/0 rate-limit 

FastEthernet0/0
  Input
    matches: access-group 101
      params:  1000000 bps, 35000 limit, 35000 extended limit
      conformed 0 packets, 0 bytes; action: transmit
      exceeded 0 packets, 0 bytes; action: drop
      last packet: 97872632ms ago, current burst: 0 bytes
      last cleared 00:00:07 ago, conformed 0 bps, exceeded 0 bps

Looks great.

Method 3: Access-list rate-limit command

Now, for the twist! I’m going to add one more condition. We are only allowed to have a 1 line ACL for this. What the?! How are we going to do that. The extended access-lists (whether named or not) only allow you to match one precedence per line! Enter the access-list rate-limit command!

There is always more than one way to skin a cat (poor cat!…whoever came up with that expression is one sick puppy). The CCIE exam often forces us to perform a task in multiple ways. Each methos acts like a little tool in your toolkit that you can whip out at a moments notice. This is no exception.

Let’s take a look at that rate-limit command closely:

R2(config)#int f0/0
R2(config-if)#rate-limit input access-group ?
  <1-2699>    Access list index
  rate-limit  Match rate-limit access list

R2(config-if)#rate-limit input access-group rate-limit ?
  <0-99>     Rate-limit prec access list index
  <100-199>  Rate-limit mac access list index
  <200-299>  Rate-limit exp access list index

Looks like when you define an access-list on the rate-limit command, you have the option of specifying a special type of access list.

R2(config)#access-list ?
  <1-99>            IP standard access list
  <100-199>         IP extended access list
  <1000-1099>       IPX SAP access list
  <1100-1199>       Extended 48-bit MAC address access list
  <1200-1299>       IPX summary address access list
  <1300-1999>       IP standard access list (expanded range)
  <200-299>         Protocol type-code access list
  <2000-2699>       IP extended access list (expanded range)
  <300-399>         DECnet access list
  <400-499>         XNS standard access list
  <500-599>         XNS extended access list
  <600-699>         Appletalk access list
  <700-799>         48-bit MAC address access list
  <800-899>         IPX standard access list
  <900-999>         IPX extended access list
  dynamic-extended  Extend the dynamic ACL abolute timer
  rate-limit        Simple rate-limit specific access list

See that right at the end there (I never really noticed it before today either!). What the hell is that thing?

R2(config)#access-list rate-limit ?
  <0-99>     Precedence ACL index
  <100-199>  MAC address ACL index
  <200-299>  mpls exp ACL index

Well looks like we can match Precedence, MAC, or MPLS experimental bits. We want Precedence…

R2(config)#access-list rate-limit 1 ?
  <0-7>  Precedence
  mask   Use precedence bitmask

Looks promising, I wander if you can specify more than one Precedence? That would solve our problem!

R2(config)#access-list rate-limit 1 7 ?
  <cr>

Doh! Damn, but what about that mask option? Well turns out, according to the access-list rate-limit documentation, we can specify more than one precedence value using a mask! Cool!

R2(config)#access-list rate-limit 1 mask ?
  <0-FF>  Precedence bit mask

There area 8 IP precedence values <0-7>. To calculate the rate-limit mask, each bit corresponds to one IP Precedence value so:

So If I want to match IP Precedence 5 and 3 thats:

00100000 + 00001000 = 00101000

Converting 00101000 to hex gives us 0×28.

So the corresponding rate-limit mask to match IP precedence 5 and 3 is:

R2(config)#access-list rate-limit 1 mask 28

Our final configuration then (using a 1 line access-list) is:

access-list rate-limit 1 mask 28
!
interface FastEthernet0/0
 rate-limit input access-group rate-limit 1 1000000 35000 35000 conform-action transmit exceed-action drop

Verification:

R2#sh int f0/0 rate-limit 

FastEthernet0/0
  Input
    matches: access-group rate-limit 1
      params:  1000000 bps, 25000 limit, 25000 extended limit
      conformed 0 packets, 0 bytes; action: transmit
      exceeded 0 packets, 0 bytes; action: drop
      last packet: 100597644ms ago, current burst: 0 bytes
      last cleared 00:33:18 ago, conformed 0 bps, exceeded 0 bps

R2#sh access-lists
Rate-limit access list 1
    mask 28

So we have managed to solve the scenario in two lines! Bring on those “use the minimum configuration possible” questions! Hope this helps! Now back to labs.

Read this article and more like it on ardenpackeer.com
Follow me on twitter: http://twitter.com/ardenpackeer

Lets take a look at the basic CBWFQ configuration:

class-map match-any TELNET
  match protocol telnet
class-map match-any FTP
  match protocol ftp
class-map match-any WWW
  match protocol http
!
!
policy-map QOS
  class WWW
   bandwidth percent 60
   queue-limit 30
  class FTP
   bandwidth percent 35
  class TELNET
   bandwidth percent 5

Pretty straight forward. We are giving 60 percent of the bandwidth to http traffic, 35% of the bandwidth to ftp, and 5% of the bandwidth to telnet traffic in times of congestoin. I tried applying it to a sub-interface:

R5(config)#int f0/0.52
R5(config-subif)#service-policy out QOS
 CBWFQ : Not supported on sub-interfaces

Uh Oh! CBWFQ is not supported on sub-interfaces. Lets try something to get around this:

policy-map PARENT
  class class-default
   service-policy QOS

We’ve used hierarchical policy-map, with a PARENT policy-map calling the QOS policy map (it’s child). The QOS policy map will apply to all traffic on the PARENT policy map. This way i’m not directly applying CBWFQ to the sub-interface as the parent policy map doesn’t technically have CBWFQ enabled on it (the child policy map, QOS, does!) Let’s try apply it to the sub-interface and see if it works:

R5(config)#int f0/0.52
R5(config-subif)#service-policy out PARENT
 CBWFQ : Hierarchy supported only if shaping is configured in this class

Still no good, but it says that it should work as long as shaping is applied! Let’s try it:

policy-map PARENT
  class class-default
   shape average percent 100
   service-policy QOS

R5(config)#int f0/0.52
R5(config-subif)#service-policy out PARENT

Woohoo no errors! Lets check it:

R5#sh policy-map int f0/0.52
 FastEthernet0/0.52 

  Service-policy output: PARENT

    Class-map: class-default (match-any)
      596 packets, 49791 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
      Traffic Shaping
           Target/Average   Byte   Sustain   Excess    Interval  Increment
             Rate           Limit  bits/int  bits/int  (ms)      (bytes)
        100000000/100000000 625000 2500000   2500000   25        312500   

        Adapt  Queue     Packets   Bytes     Packets   Bytes     Shaping
        Active Depth                         Delayed   Delayed   Active
        -      0         596       49791     0         0         no

      Service-policy : QOS

        Class-map: WWW (match-any)
          0 packets, 0 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: protocol http
            0 packets, 0 bytes
            5 minute rate 0 bps
          Queueing
            Output Queue: Conversation 265
            Bandwidth 60 (%) Max Threshold 30 (packets)
            (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0

        Class-map: FTP (match-any)
          0 packets, 0 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: protocol ftp
            0 packets, 0 bytes
            5 minute rate 0 bps
          Queueing
            Output Queue: Conversation 266
            Bandwidth 35 (%) Max Threshold 64 (packets)
            (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0

        Class-map: TELNET (match-any)
          0 packets, 0 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: protocol telnet
            0 packets, 0 bytes
            5 minute rate 0 bps
          Queueing
            Output Queue: Conversation 267
            Bandwidth 5 (%) Max Threshold 64 (packets)
            (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0

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

Looks good.

Summary:

You can’t apply CBFWQ to a sub-interface directly. You have to create a parent policy-map and apply shaping before it can be applied to a sub-interface. Cool huh? I’m going to have to write a proper tutorial on this one when I have some time, right now i’m trying to fit in 12 hours of labs a day for the next 30 days.

Read this article and more like it on ardenpackeer.com
Follow me on twitter: http://twitter.com/ardenpackeer

We will be using the following topology for this tutorial:

You can download the dynagen .net configuration file here.

The Scenario:
“The users on the 1.1.1.0/24 subnet have been complaining of slow network response times recently when connecting to services on the 2.2.2.0/24. Users on the 1.1.1.0/24 subnet use voice and web applications. During times of congestion we want the web applications to be guaranteed bandwidth. Also, delay sensitive Voice traffic needs to be given priority over all other traffic.”

The scenario above is typical of something you might see in your environment. We have congestion happening on an interface on the ethernet link between R1 and R2. We need to implement a congestion management strategy during times of congestion so that voice and web traffic are given traffic guarantees. Lets say that we want to reserve at least 20% of the bandwidth during times of congestion for web traffic. Lets implement that first and we’ll get back to voice traffic later.

First lets just do a quick check of bandwidth of R1:

R1(config)#int f1/0
R1(config-if)#fair-queue 

R1#sh queueing int f1/0
Interface FastEthernet1/0 queueing strategy: fair
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: weighted fair
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations  0/1/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 75000 kilobits/sec

You can see above the available bandwidth when you implement a fair-queueing on an interface is 75,000 kbs. Wait a second, this is a fast ethernet interface! Shouldn’t the available bandwidth be 100,000 kbs (100 Mbs). Why are we operating at only 75%? What happened to the other 25%?

We’ve implemented fair queueing on the interface between R1 and R2. Now, fair queing is a congestion management strategy but probably not the congestion management strategy we want to use for this particular scenario. For the moment, we just want to see the affect of any congestion management strategy on an interface and set a baseline for this tutorial.

By default, when a congestion management strategy like Fair Queueing or CBWFQ is implemented on an interface 25% is reserved for things like routing protocol updates and important layer 2 traffic. 25% of 100 mbs is quite a lot for routing updates! Let’s change this:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int f1/0
R1(config-if)#max-reserved-bandwidth 100
R1(config-if)#end

R1#sh queueing int f1/0
Interface FastEthernet1/0 queueing strategy: fair
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: weighted fair
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations  0/1/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 100000 kilobits/sec

You can see above that we used the max-reserved-bandwidth command so that we can use 100% of the interface bandwidth (ie. none of the bandwidth is reserved).

Now that we’ve set up the bandwidth lets set up CBWFQ. We’ll reserve 20% of the bandwidth for web traffic during times of congestion:

class-map match-any WEB
 match protocol http
!
policy-map QOS
 class WEB
  bandwidth percent 20
!
interface FastEthernet1/0
 no fair-queue
 max-reserved-bandwidth 100
 service-policy output QOS

You can see above we are using NBAR to match the http protocol, and reserving 20% of the link bandwidth when congestion occurs using the bandwidth percent command.

Let’s verify this:

R1#sh queueing int f1/0
Interface FastEthernet1/0 queueing strategy: fair
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: Class-based queueing
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations  0/1/256 (active/max active/max total)
     Reserved Conversations 1/1 (allocated/max allocated)
     Available Bandwidth 80000 kilobits/sec

You can see above that 80,000 kbs is now available. This doesn’t mean that http traffic can ONLY use 20% of the link (the bandwidth command does not have a built in policer). The bandwidth command only comes into play when there is congestion on the interface. This configuration is telling IOS that when congestion occurs, keep a minimum of 20% (20,000 kbs) of the bandwidth for http traffic.

The show queueing interface command shows that when congestion occurs 80% of the bandwidth is available for use for everything else.

Lets add a reservation for voice:

class-map match-any WEB
 match protocol http
class-map match-any VOICE
 match protocol rtp audio
 match protocol rtcp
!
policy-map QOS
 class WEB
  bandwidth percent 20
 class VOICE
  priority percent 10

What we’ve done here is add a LLQ (low latency queue) for voice traffic. We are using NBAR to match the voice rtp stream and control protocol. The priority command sets up a low latency queue for the voice class. What this means is that voice traffic will be served before all other traffic. The priority command implements a built-in policer. This means that voice traffic will be served first, with a bandwidth gaurantee upto a maximum of 10% of the interface when there is congestion. This is to stop the LLQ starving all the other queues of traffic.

R1#sh queueing int f1/0
Interface FastEthernet1/0 queueing strategy: fair
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: Class-based queueing
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations  0/1/256 (active/max active/max total)
     Reserved Conversations 1/1 (allocated/max allocated)
     Available Bandwidth 70000 kilobits/sec

You can see here the available bandwidth has been changed to 70% available bandwidth (70,000 kbs). This makes sense, we are using 10% for voice and 20% for web traffic.

Bandwidth Remaining Percent
So what does the bandwidth remaining percent do then? We will change the bandwidth reservation of the web class so it uses the bandwidth remaining percent command and see the effect on the show queueing interface command.

class-map match-any WEB
 match protocol http
class-map match-any VOICE
 match protocol rtp audio
 match protocol rtcp
!
policy-map QOS
 class WEB
  bandwidth remaining percent 20
 class VOICE
  priority percent 10

R1#sh queueing int f1/0
Interface FastEthernet1/0 queueing strategy: fair
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: Class-based queueing
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations  0/1/256 (active/max active/max total)
     Reserved Conversations 1/1 (allocated/max allocated)
     Available Bandwidth 90000 kilobits/sec

You can see above we have changed the bandwidth percent command to a bandwidth remaining percent. Take a look at that available bandwith. 90% is available?! Didn’t we just make a reservation for web traffic of 20%?

The bandwidth remaining percent command makes a reservation from the available bandwidth not the total reservable bandwidth. What we have done here is reserved 10% of the total reservable bandwidth for voice traffic. This leaves us 90,000 kbs left when congestion occurs, this is the available bandwidth. Using the bandwidth remaining percent command we have made a 20% reservation of this remainder (available bandwidth) for http (20% of 90,000 kbs is 18,000 kbs for http).

The bandwidth remaining percent command takes a percentage of the available bandwidth not from the total reservable bandwidth (100% of the interface). The bandwidth percent command takes a percentage of the total reserveable bandwidth.

Lets change the max-reserved-bandwidth and see the effect this has on available bandwidth.

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int f1/0
R1(config-if)#max-reserved-bandwidth 90
Reservable bandwidth is being reduced.
Some existing reservations may be terminated.  

You can see above we have changed the bandwidth available command using the max-reserved bandwidth command to 90%. This means that 10% of the total reservable bandwidth has been reserved for routing protocols etc.

R1#sh queueing int f1/0
Interface FastEthernet1/0 queueing strategy: fair
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: Class-based queueing
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations  0/1/256 (active/max active/max total)
     Reserved Conversations 1/1 (allocated/max allocated)
     Available Bandwidth 80000 kilobits/sec

So we have both the VOICE traffic and MAX-RESERVABLE-TRAFFIC (routing, layer 2 traffic) using 10% of the total reservable bandwidth each. This leaves us with 80,000 kbs (80%) as available bandwidth. WEB traffic then takes 20% of this 80,000 kbs (16,000 kbs).

In summary, we have the total reservable bandwidth of 100%. The bandwidth percent, priority percent, and max-reservable-bandwidth command makes reservations from the total reservable bandwidth. The bandwidth remaining percent command makes reservations from the available bandwidth (whats left over of the total reservable bandwidth after the other reservations is treated as 100%).

HTH. Now back to labs.

Summary:

• By default, 25% of the total reservable interface bandwidth is reserved for routing protocols and important layer 2 traffic. The max-reservable-bandwidth command is used to change the amount of bandwidth reserved for this traffic.
• The bandwidth percent and priority percent commands makes reservations from the total reservable interface bandwidth
• The bandwidth remaining percent command makes reservations from the available bandwidth (whats left over of the total reservable bandwidth after the other reservations are made).

Resources:

• Dynamips/Dynagen .net configuration file

Read this article and more like it on ardenpackeer.com
Follow me on twitter: http://twitter.com/ardenpackeer

One solution to this problem is the use of Cisco’s Network Based Application Recognition (NBAR). NBAR is a deep packet inspection and classification engine. It was first introduced in experimental versions of IOS v12.1 and can be used with Cisco’s Modular Quality Of Service Command Line (MQC).

In this article we will look at using MQC to filter websites. I will demonstrate using the match protocol http command to match a URL, a host or MIME type. We will use the following topology for demonstration:

R3 will act as a webserver and R1 as a client. The filtering will be applied on R2. You can download the dynamips .net file the following topology here.
R1 Base Configuration:

hostname R1
!
int s1/0
 ip add 10.0.12.1 255.255.255.0
 no shut
!
router ospf 1
 network 10.0.12.1 0.0.0.0 area 0

R2 Base Configuration:

hostname R2
!
int s1/0
 ip add 10.0.12.2 255.255.255.0
 no shut
!
int s1/1
 ip add 10.0.23.2 255.255.255.0
 no shut
!
router ospf 1
 network 10.0.12.2 0.0.0.0 area 0
 network 10.0.23.2 0.0.0.0 area 0

R3 Base Configuration:

hostname R3
!
int s1/0
 ip add 10.0.23.3 255.255.255.0
 no shut
!
int f0/0
 ip add 192.168.1.100 255.255.255.0
 no shut
!
router ospf 1
 network 10.0.23.3 0.0.0.0 area 0
!
ip http server
ip http path flash:

We have set up R3 as a webserver. Details on how to setup R3 as a webserver using IOS can be found here.

R3#sh run | in ip http
ip http server
no ip http secure-server
ip http path flash:

R3#dir
Directory of flash:/

    1  -rw-          90                    <no>  picture.gif
    2  -rw-         329                    <no>  picture.jpg
    3  -rw-         174                    <no>  index.html

8388604 bytes total (8387812 bytes free)
</no></no></no>

Basic HTTP Filtering using NBAR

Lets set up basic http filtering with MQC on R2.

R2(config)#class-map match-all MATCH-HTTP
R2(config-cmap)#match protocol http
R2(config-cmap)#exit
R2(config)#policy-map HTTP-POLICY
R2(config-pmap)#class MATCH-HTTP
R2(config-pmap-c)#set dscp af13
R2(config-pmap-c)#exit
R2(config-pmap)#int s1/0
R2(config-if)#service-policy input HTTP-POLICY

In the code above we have a class map called MATCH-HTTP. The match protocol http command tells NBAR to match the http protocol. This will match all http traffic. The MATCH-HTTP class is then utilized in the HTTP-POLICY policy map. This policy map is used to set a DSCP marking on all traffic that matches the MATCH-HTTP class (ie all http traffic). The policy is then implemented on R2’s s1/0. Traffic is inspected and marked as it comes into that interface.

We can check how many packets have been marked using the show policy-map command.

R2#sh policy-map int s1/0
 Serial1/0 

  Service-policy input: HTTP-POLICY

    Class-map: MATCH-HTTP (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol http
      QoS Set
        dscp af13
          Packets marked 0

    Class-map: class-default (match-any)
      2 packets, 168 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
R2#

Lets generate some http traffic, and see if our policy marks some packets.

R1#copy http://10.0.23.3/index.html null:
Loading http://10.0.23.3/index.html
174 bytes copied in 0.544 secs (320 bytes/sec)

R2#sh policy-map int s1/0
 Serial1/0 

  Service-policy input: HTTP-POLICY

    Class-map: MATCH-HTTP (match-all)
      5 packets, 344 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol http
      QoS Set
        dscp af13
          Packets marked 5

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

We used the copy http://10.0.23.3/index.html null: command to generate some http traffic. We can see above that 5 packets were generated and were marked as af13. All other traffic will fall into the class-default class. With the packets marked, we could forward them or drop them.

Instead of matching all of the http protocol we can use NBAR to look further into the packet and classify or drop packets based on the host requested.

Match protocol HTTP host

The match protocol HTTP url command is used to match a url. It takes a regular expression as an argument. For example:

match protocol http host *youtube.com*
! This would match anything in youtube.com like http://www.youtube.com or http://video.youtube.com
!
match protocol http host *google*
! This would match anything with google in the host like http://mail.google.com or
http://www.google.com.au
!
match protocol http host google*
! This would match http://google.com but not http://video.google.com

Lets set up R2 to filter based on a host.

R2(config)#class-map MATCH-HTTP
R2(config-cmap)#no match protocol http
R2(config-cmap)#match protocol http host 10.0.23.3

R2#clear counters s1/0
Clear "show interface" counters on this interface [confirm]
*Mar  1 00:04:42.071: %CLEAR-5-COUNTERS: Clear counter on interface Serial1/0 by console
R2#
R2#sh policy-map int s1/0
 Serial1/0 

  Service-policy input: HTTP-POLICY

    Class-map: MATCH-HTTP (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol http host "10.0.23.3"
      QoS Set
        dscp af13
          Packets marked 0

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

We’ve cleared the counters on R2, so lets generate some traffic on R1 again.

R1#copy http://10.0.23.3/index.html null:
Loading http://10.0.23.3/index.html
174 bytes copied in 0.596 secs (292 bytes/sec)

R2#sh policy-map int s1/0
 Serial1/0 

  Service-policy input: HTTP-POLICY

    Class-map: MATCH-HTTP (match-all)
      5 packets, 344 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol http host "10.0.23.3"
      QoS Set
        dscp af13
          Packets marked 5

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

We can see here it matched 5 packets based on the host. We can use this to match whole sites like youtube.com or video.google.com.

Match protocol HTTP url

We can match strings AFTER the host portion of a URL using the match protocol http url command. It also takes a regular expression as an argument. For example:

match protocol http url *video*
! This would match http://www.cisco.com/video/index.php or
http://www.google.com/stuff/video.html
!
match protocol http url video*
! This would match http://www.cisco.com/video but not http://www.cisco.com/stuff/video.html
! because stuff precedes the video portion of the url and in the expression above we have said
! it has to start with the string video
!
match protocol http url *.jpeg|*.jpg|*.gif
! This would match any .jpeg or .jpg or .gif extention in the url

Lets set up R2 to match based on a URL.

R2(config)#class-map MATCH-HTTP
R2(config-cmap)#no match protocol http host 10.0.23.3
R2(config-cmap)#match protocol http url *.jpg

As you can see above we have used the match protocol http url function of NBAR to match any url that ends in a .jpg. This effectively blocks jpeg images (unless they have a different extension).

Let test it, before we send some traffic we’ll reset the counters on the interface.

R2#clear counters s1/0
Clear "show interface" counters on this interface [confirm]
*Mar  1 00:43:39.135: %CLEAR-5-COUNTERS: Clear counter on interface Serial1/0 by console
R2#
R2#sh policy-map int s1/0
 Serial1/0 

  Service-policy input: HTTP-POLICY

    Class-map: MATCH-HTTP (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol http url "*.jpg"
      QoS Set
        dscp af13
          Packets marked 0

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

If we request a gif file we shouldn’t match the class MATCH-HTTP. Lets test that first.

R1#copy http://10.0.23.3/picture.gif null:
Loading http://10.0.23.3/picture.gif
90 bytes copied in 0.644 secs (140 bytes/sec)

R2#sh policy-map int s1/0
 Serial1/0 

  Service-policy input: HTTP-POLICY

    Class-map: MATCH-HTTP (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol http url "*.jpg"
      QoS Set
        dscp af13
          Packets marked 0

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

Great Success! Looks pretty good. Now lets try a .jpg extension. We should match this.

R1#copy http://10.0.23.3/picture.jpg null:
Loading http://10.0.23.3/picture.jpg
329 bytes copied in 0.820 secs (401 bytes/sec)

R2#sh policy-map int s1/0
 Serial1/0 

  Service-policy input: HTTP-POLICY

    Class-map: MATCH-HTTP (match-all)
      7 packets, 433 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol http url "*.jpg"
      QoS Set
        dscp af13
          Packets marked 7

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

Awesome! You can see above we matched based on a URL.

match protocol http mime

We can also use the match protocol http mime to match internet mime types. The mime type has to be the same mime type that the web server responds with. For a list of valid mime types check out: http://www.sfsu.edu/training/mimetype.htm. Lets look at an example:

match protocol http mime image/jpeg
! This would match jpeg,jpg,jpe,jfif,pjpeg, and pjp types
!
match protocol http mime image/jpg
! This would not match anything as it is not a proper mime type. Get a list of the mime types
! here: http://www.sfsu.edu/training/mimetype.htm
!
match protocol http mime image*
! This would match all image mime types
!
match protocol http mime application/x-shockwave-flash
! This would not only match swf flash movies, but all of flash.

Lets set up R2 to filter the image/jpeg mime type:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#class-map MATCH-HTTP
R2(config-cmap)#no match protocol http url *.jpg
R2(config-cmap)#match protocol http mime ?
  WORD  Enter a string as the sub-protocol parameter

R2(config-cmap)#match protocol http mime image/jpeg
R2(config-cmap)#exit
R2(config)#exit

Once again, we’ll clear the counters so we can verify that this works correctly.

R2#clear counters s1/0
Clear "show interface" counters on this interface [confirm]
*Mar  1 01:12:10.759: %CLEAR-5-COUNTERS: Clear counter on interface Serial1/0 

R2#sh policy-map int s1/0
 Serial1/0 

  Service-policy input: HTTP-POLICY

    Class-map: MATCH-HTTP (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol http mime "image/jpeg"
      QoS Set
        dscp af13
          Packets marked 0

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

On R1 lets generate some traffic. A gif file will be requested first. This should not match our policy.

R1#copy http://10.0.23.3/picture.gif null:
Loading http://10.0.23.3/picture.gif
90 bytes copied in 0.808 secs (111 bytes/sec)

R2#sh policy-map int s1/0
 Serial1/0 

  Service-policy input: HTTP-POLICY

    Class-map: MATCH-HTTP (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol http mime "image/jpeg"
      QoS Set
        dscp af13
          Packets marked 0

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

All good! Ok lets do the final test and actually request a jpeg image and see if it matches our policy.

R1#copy http://10.0.23.3/picture.jpg null:
Loading http://10.0.23.3/picture.jpg
329 bytes copied in 1.216 secs (271 bytes/sec)

R2#sh policy-map int s1/0
 Serial1/0 

  Service-policy input: HTTP-POLICY

    Class-map: MATCH-HTTP (match-all)
      5 packets, 220 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol http mime "image/jpeg"
      QoS Set
        dscp af13
          Packets marked 5

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

You can see above that the jpeg image was matched. It works!

Putting it all together

So lets put it all together. We can use all three match protocol http commands in a match-any class map. For example:

class-map match-any INTERNET-SCUM
 match protocol http host *youtube.com*|*video.google.com*
 match protocol http mime video/flv|video/x-flv|video/mp4|video/x-m4v|audio/mp4a-latm
 match protocol http mime video/3gpp|video/quicktime
 match protocol http url *.flv|*.mp4|*.m4v|*.m4a|*.3gp|*.mov
! uncomment below if you don't want ANY flash.
! match protocol http mime application/x-shockwave-flash
! match protocol http url *.swf
!
policy-map NOINTERNETVIDEO
 class INTERNET-SCUM
  drop
!
int s1/0
 service-policy input NOINTERNETVIDEO
!

This would match any traffic going to youtube or video.google.com, or any flash applications, or common video mime types, and any swf (flash or flash movie) files! Be aware that NBAR does make your router take a hit in CPU processor usage, I’d suggest evaluating your processor usage before using this in production.

HTH! Now back to labs!

Summary:

• Use the match http protocol command to match the http protocol.
• match protocol http host matches the host portion
• match protocol http url matches the url after the hostname
• match protocol http mime matches mime types

Resources
Webserver - Dynamips .net configuration file
QOS HTTP Filtering - R1 Final Configuration
QOS HTTP Filtering - R2 Final Configuration
QOS HTTP Filtering - R3 Final Configuration

Read this article and more like it on ardenpackeer.com
Follow me on twitter: http://twitter.com/ardenpackeer

I was playing around with Mindomo (which is an awesome online mind map creator) and I whipped up a QoS mind map. The interface for Mindomo takes a bit of getting used to, but its a fantastic study tool. Mind maps are a great way to organise your thoughts and ideas about a topic in a very structured way. I am a very visual person, so by creating mind maps it allows me to organize my thoughts for easy recall.

I’ve placed a link to my mind map below. I’ll add notes and links back to this website from it with articles (thats the plan anyway!). I’ve also placed a copy of my CCIE QoS extended Blueprint for study.

QoS Mind Map:

CCIE QoS Extended Blueprint

A. Quality of service solutions
B. Classification and Marking
I. Using MQC
I. Using NBAR
II. Using PBR
III. Using CAR
IV. QoS Policy Propagation via BGP
V. DE
I. DE List
II. MQC
VI. 3550 - Classifying Traffic on a Per-Port Per-VLAN Basis by Using
Class Maps
C. Congestion management, congestion avoidance
I. Legacy Congestion Management (WFQ, CQ, PQ)
II. LLQ
III. CBWFQ
IV. WRED
V. 3550 - Expedite Queue
D. Policing and shaping
I. 3550 Policing
II. Policing with MQC
I. Two-Rate Policer
II. Percentage-based Policing and Shaping
III. Unconditional Packet Discard
IV. Control Plane Policing
V. Shaping with MQC
VI. CAR
VII. Generic Traffic Shaping
VIII. FRTS
E. Signaling
I. RSVP
F. Link efficiency mechanisms
I. MultiLink PPP (MLP)
I. MPL Interleaving and Queuing
II. Multiclass Multilink PPP
II. FRF.12
III. FTF.16
IV. Compressed Real-Time Protocol
V. Compression - STAC versus PREDICTOR

Now back to labs.

HTH

Read this article and more like it on ardenpackeer.com
Follow me on twitter: http://twitter.com/ardenpackeer

In my previous article on WFQ, we really only talked about flow based WFQ. Flow based WFQ automatically sorts out traffic flows or conversations into separate queues. Smaller flower get precedence over larger flow. But what about frames that are classified with a QoS marking. If we have a larger frame with a high precedence or high valued ToS it should probably get to be served before a smaller frame with a very low precedence or ToS.

With the fair-queue qos-group command we can use a qos-group, which is an internal classification used by QoS features like Committed Access Rate (CAR).

interface serial0/0
 ip address 150.1.13.1 255.255.255.0
 rate-limit output 80000 10000 20000 conform-action set-qos-transmit 6 exceed-action drop
 fair-queue qos-group
 fair-queue qos-group 6 weight 40
 fair-queue qos-group 6 limit 37 

This is quite a long example with references we haven’t talked about yet like rate-limit command. But essentially what that rate-limit command says is this “Set up a Committed Access Rate on serial 0/0, where the speed is limited to 80 kbps with a 10kps burst normal and 20kps burst max set. If it conforms place all traffic in qos-group 6 and transmit otherwise drop”.

The fair-queue qos-group commands above then set up the traffic in qos-group 6 to have a higher weight hence more priority in the queues. In this case a weight of 30 was applied to all traffic in qos-group 6. The net affect of this is that traffic in qos-group 6 will get 40% of the bandwidth. We have also limited the size of the queues to 37.

That example is pretty simple. We aren’t really doing much more than putting all traffic into qos-group 6 and then giving it 40% of the rate-limited bandwidth (40% of 80kbps).

Lets look at a more complex example. We might want to just put traffic that has an ip precedence of 1 into qos-group 1, everything with an ip precedence of 2 into qos-group 2, and everything with an ip precedence of 3 also goes into qos-group 2.

interface serial0/0
 ip address 150.1.13.1 255.255.255.0
 rate-limit output access-group rate-limit 1 80000 10000 20000 conform-action set-qos-transmit 1 exceed-action drop
 rate-limit output access-group rate-limit 2 80000 10000 20000 conform-action set-qos-transmit 2 exceed-action drop
 rate-limit output access-group rate-limit 3 80000 10000 20000 conform-action set-qos-transmit 2 exceed-action drop
 fair-queue qos-group
 fair-queue qos-group 1 weight 5
 fair-queue qos-group 1 limit 20
 fair-queue qos-group 2 weight 10
 fair-queue qos-group 2 limit 30
!
access-list rate-limit 1 1
access-list rate-limit 2 2
access-list rate-limit 3 3

In the example above, we modify the rate-limit command to utilise a access-list rate-limit command. The rate-limit command says anything that matches this access-list rate-limit list 1, should be put into qos-group 1. access-list rate-limt 1 says anything with an ip precedence of 1 goes into it. We have done that for ip precedence 2 and 3 as well, they go into qos-group 2.

This changes the rate-limit command to say “Set up a Committed Access Rate on serial0/0. Everything with ip precedence 1, goes into QoS-Group 1 and gets limited to 8kbps, 1kpbs burst normal and burst max. Qos-Group 1 has 5% of the bandwidth, and each queue has a size limit of 20. Everything with ip precedence 2 and 3, goes into QoS-Group 2. Qos-Group 2 has 10% of the bandwidth and a queue size limit of 30.

ToS Based Weighted Fair Queue

We can also use Weighted Fair Queue taking into account the Type Of Service (ToS) field in the ip header. The higher the ToS field the more likely the packet train is to get served by the WFQ scheduling algorithm.

Lets have a look at some examples. To set up ToS based WFQ we use the fair-queue tos command:

int serial 0/0
 ip address 150.1.13.1 255.255.255.0
 fair-queue tos
 fair-queue tos 1 weight 10
 fair-queue tos 1 limit 20
 fair-queue tos 2 weight 20
 fair-queue tos 2 limit 30

In the example above, WFQ is implemented. Packet flows with an IP precedence of 1 will get 10% of the bandwidth and each queue will have a size limit of 20 members. Packet flows with an IP precedence of 2 will get 20% of the bandwidth and each queue will have a size limit of 30.

Summary:

• QoS-group based WFQ places packet flows into QoS-groups. Bandwidth and queue limits can then be placed on those queues.
• QoS-group based WFQ uses the fair-queue qos-group command
• ToS based WFQ packets takes into account the ToS field in the IP header and schedules packet flows accordingly (higher ToS, higher chance of serviced by the WFQ scheduler).
• ToS based WFQ uses the fair-queue tos command

HTH

Read this article and more like it on ardenpackeer.com
Follow me on twitter: http://twitter.com/ardenpackeer

Weighted Fair Queue (WFQ) is another congestion management strategy. It is very different from the other two congestion management strategies we have looked at (PQ and CQ), in that it does not need classification options configured. Traffic is automatically sorted and put into different queues without any kind of access-list or protocol matching configured by the user. It all happens automagically.

How does that work? WFQ classifies packets based on flows. What is a flow? Well a flow could be based on a number of things (source and destination address, protocol, source and destination port) but it identifies a train of packets. For example if you are surfing the web, you might have one train of packets coming in for the HTTP request, then another for the response, then another for the graphics and so on. WFQ calls these train of packets separate flows or conversations and puts each one automatically into a separate queue. Thats a whole bunch of queues, and the number of queues is changing dynamically all the time.

So instead of the user manually specifying criteria to manually create queues like CQ and PQ, WFQ uses the concept of flows to create queues on the fly. So that takes care of the classification difference, but what about the actual scheduling algorithm? Well as each flow arrives, the time of the very last bit to arrive is used to calculate a sequence number. The lower the sequence number the higher the chance that that queue will be emptied first. The end result of this is that lower volume traffic gets precedence over higher volume traffic.

The Magic Toll Booth.

Lets try come up with an analogy to explain this. Imagine a traffic toll booth. Okay its a magic traffic toll booth. We have cars of different sizes approaching to traffic toll booth. Cars, trucks, motorbikes, all vehicles of different sizes. As the vehicle approaches this magic toll booth creates a new lane for each of the vehicles. When each of the vehicles enter their own queue, the toll booth record the exact time the last wheel on your vehicle entered the new lane and stamps this time on the vehicle. Motor-cycles because they are smaller, will have their last wheel enter their new lane before a multi trailer truck enters its new lane for example. Who ever has the earliest entry time will get to go through the toll booth first. See how smaller vehicles get priority.

This is the basis of Weighted Fair Queue. It gives the little packets a chance. Without it, you might have lots of ftp traffic going on which would create fairly large packet trains. In a fifo queue a small telnet packet coming along would have to wait till the large ftp packet train is finished before it could go through. With Weighted Fair Queue, the smaller telnet packet would get right of way.

Implementing Weighted Fair Queuing

Weighted Fair Queuing is the default on links that are of E1 speed (2.048 Mbps) or slower. So if you have any of those speed links you don’t have to do anything! On all other links, or if you want more control, you can use the fair-queue command.

fair-queue [congestive-discard-threshold [dynamic-queues  [reservable-queues]]]

Let turn on WFQ on an interface.

int serial0/0
 fair-queue

This will turn on WFQ on the serial 0/0 interface. In its basic form, that’s it! The WFQ algorithm will automatically distinguish between flows and put them into their own queues, giving precedence to the smaller IP traffic.

We can specify the amount of messages in each queue by setting the congestive-discard-threshold (CDT). Think of this as the maximum size of each individual queue. Why didn’t they just call it a maximum individual queue size then? Well what actually happens is when the congestive-discard-threshold is reached, new arriving packets for the queue might not be dropped. If there is another message in another queue with a worse serial number (think entry time), it might get dropped instead.

int s0/0
 fair-queue 2048 1024 0

This changes the CDT to 2048 instead of the default 64. The command above also changes the maximum number of dynamic queues to 1024 (think maximum number of flows at one time). The 0 at the end says that there is no queues being used with RSVP (Resource Reservation Protocol).

We can not only specify the default size of each queue with the CDT but we can specify the overall queue size or all the queue’s with the hold-queue command.

int s0/0
 fair-queue 2048 1024 0
 hold-queue 4096 out

This will set the maximum limit of one queue to 2048 (CDT), but the overall queue limt on the interface to 4096 (hold-queue). This means that even though one of the queues can have a maximum of 2048 messages, the combined total of all the queues cannot have more than 4096 messages.

Summary

• Weighted Fair Queuing is a congestion management strategy
• Queues are dynamically assigned based on flows
• A flow is a train of packets with the same properties (source and destination ip address, protocol, source and destination ports etc).
• There can be a maximum of 4096 queues.
• We use the fair-queue command to define WFQ on an interface
• It takes three parameters, the first is CDT (length of each queue), Maximum number of dynamic queues and RSVP queues
• We can define an overall queue size with the hold-queue command.

Thats it for part I of WFQ. Yes there is more, which we will look at including QoS-group and ToS based Weighted Fair Queue.

HTH.

Read this article and more like it on ardenpackeer.com
Follow me on twitter: http://twitter.com/ardenpackeer

When we are talking about Committed Information Rate we are usually talking about Traffic Shaping. This is especially true of Frame Relay Traffic Shaping (FRTS). In FRTS we might configure a CIR with the frame-relay cir command:

For example:

interface serial0
 encapsulation frame-relay
 frame-relay traffic-shaping
 frame-relay interface-dlci 200
 class adjust_vc_class_rate
!
map-class frame-relay adjust_vc_class_rate
 frame-relay cir 64000
 frame-relay mincir 32000
 frame-relay adaptive-shaping becn

Here we have a committed information rate of 32k for the virtual circuit represented by DLCI 200 (we’ll have a look at Frame Relay traffic shaping in more detail later). In this case a shaper is set. From your perspective, the CIR is the rate of the virtual circuit according to a business contract. From the service providers perspective it might involve setting up SLA’s and discarding anything above (discard eligible on Frame Relay).

Committed Access Rate is an example of policing. It is rate limiting to the committed access rate. It is implemented with the rate-limit command. For example:

int fa0/0
 rate-limit output 8000 1000 2000 conform-action transmit exceed-action drop

The example of above sets a committed access rate of 8kbps with 1kbps burst and 2kbps max burst.

Read this article and more like it on ardenpackeer.com
Follow me on twitter: http://twitter.com/ardenpackeer

Custom Queuing is another congestion management strategy and is what we will be looking at in detail in this post. Custom queuing is a round robin like queuing mechanism where frames in each queue are serviced until a byte-counter limit threshold is met. Once this byte-count limit threshold is met, the frames in the next queue are serviced. Because it queues are serviced in a round robin fashion, Custom Queuing does not suffer from queue starvation.

There are 17 custom queues, with 16 user definable queues. The first queue, queue 0 is a system queue, and is serviced first. Critical system traffic like keepalives, and other important interface traffic etc are placed in this queue and are always serviced first. Queues 1 to 16 are then serviced in a round robin fashion. Each of those 16 queues can be configured with a byte-count limit threshold.

The Cisconator

To explain how this works lets use a theme park analogy. Lets say you are the manager of a theme park that has just opened at new ride: The Cisconator. The ride is really popular from the beginning but people are complaining about the line for the ride. Some people are waiting for quite a while before they can ride.

You decide to arrange 4 queues. All VIP customers will go into queue 1, all adults will go into queue 2, all kids go into queue 3 and all ninjas go into queue 4. VIPs and kids are your most important customers, so management decides the queuing mechanism will work like this: for every 5 VIPS, you will let through 4 kids, 2 adults, and 1 ninja (never know when one will come in handy). So the guy at the front of the line has a little counter, he moves to queue 1 and counts five people through, as soon as those have gone through he moves to the adult queue and lets through 2, he then moves through to the kids queue and lets through 5, and then goes to the ninja queue lets 1 through before repeating the procedure.

This is the basis of custom queuing. We go around to each queue and let through packets until a byte count is reached before letting through packets in the next queue. The concept of a byte count is important. If we are in the middle of a packet and we hit that byte-count limit we can’t just stop at half a packet so we sometimes go over that byte-count limit. Custom Queuing takes this into account by penalizing the queue (lowering the limit) next time around. So it might not match the byte count each time perfectly but over time it averages out to the byte-count limit.

Custom Queuing Configuration.

To configure custom queuing we need to figure out which traffic to put into the different queues. After we do this we define which interface to apply this congestion strategy to. Remember this is a congestion management strategy, so it will apply to outbound traffic. To configure custom queuing we use the queue-list command. The syntax for the queue-list command is:

queue-list list-number protocol protocol-name queue-number queue-keyword queue-keyword value

Let have a look at a few examples of configuring custom queuing.

access-list 101 permit ip any 150.1.1.0 0.0.0.127
queue-list 1 protocol ip 1 list 101
queue-list 1 protocol ip 2 tcp 80
queue-list 1 protocol cdp 3
queue-list 1 protocol ip 4 lt 800
queue-list 1 default 6

In the above example we have all traffic that matches access-list 101 (ie all ip traffic heading towards 150.1.1.0/25) will be put in queue 1. All tcp traffic going to port 80 will be put in queue 2, all cdp traffic will be placed in queue 3, all ip traffic less than 800 bytes in size will be placed in queue 4. We used the queue-list default command to specify that all traffic not matched will go into queue 6.

We can also match traffic based on the interface it came in from using the queue-list interface command.

queue-list 1 interface fa0/0 5

This places all traffic originating from fa0/0 into queue 5. Like access-lists and priority-list, queue-lists are read sequentially until a match is found. So if you mix and match queue-list interface commands with queue-list protocol commands, the ones you put in first will be evaluated first. The system will go through each one sequentially till a match is found and then put it in the queue defined.

So we have our six queues set up. We can specify the size of each of those queues (how many packets each queue can have) using the queue-list queue limit command.

access-list 101 permit ip any 150.1.1.0 0.0.0.127
queue-list 1 protocol ip 1 list 101
queue-list 1 protocol ip 2 tcp 80
queue-list 1 protocol cdp 3
queue-list 1 protocol ip 4 lt 800
queue-list 1 interface fa0/0 5
queue-list 1 default 6
queue-list 1 queue 1 limit 40
queue-list 1 queue 6 limit 100

You can see above we have changed the size of queues 1 and 6 to 40 and 100 respectively. The default queue size is 20, so this makes our queues sizes 40, 20, 20, 20, 20 and 100 for queues 1,2,3,4,5 and 6 respectively. This is the amount of packets each can hold before things start being dropped.

Now that we have defined our queues we need to set up the byte-count limits for each of the queues. This is how many bytes will be served up before moving to the next queue. We do this with the queue-list queue byte-count command.

queue-list 1 queue 6 byte-count 2000

This changes the queue byte-count from the default 1500 to 2000. What is the effect of this? Well, if queues 1 through 5 have a byte-count limit of 1500 each and queue 6 has a limit of 2000 we have a total byte-count of 9500 ((1500 x 5) + 2000) to go through all the queues. This means that queue 6 will have about 21% (2000/9500) of the bandwidth that the queue-list is applied to.

There is a great how-to guide for working out percentages of a link using custom queuing here. I think i will do another post regarding this when i write up a few labs. Stay tuned!

Speaking of applying a custom queue to an interface, how do we do that? With the custom-queue-list command.

int fa0/0
 custom-queue-list  1

The commands above applies the queue-list 1 define above to interface fa0/0.

Recall that custom queuing has 17 queues, with only 1 to 16 being user definable. You can also have 16 different custom queues each capable of having 16 queues. You can only apply one custom queue to an interface however. Queue 0 is always used for priority traffic and that queue is always served first (kind of like a priority queue). You can make your own queues act like this also using the queue-list lowest-custom command.

queue-list 1 lowest-custom 3

This defines queues 0 to 3 as having high priority traffic and using a priority queue.

What was in that queue again?

To verify the custom queue we can use the show queuing custom command.

Router#sh queuing custom
Current custom queue configuration:

List   Queue  Args
1      6      default
1      1      protocol ip          list 101
1      2      protocol ip          tcp port www
1      3      protocol cdp
1      4      protocol ip          lt 800
1      5      interface FastEthernet0/0
1      1      limit 40
1      6      byte-count 2000 limit 100

Summary:

• Custom Queuing is a congestion management strategy
• There are 17 queue, 0 to 16
• Queue 0 is a priority like queue, 1 to 16 are user definable
• You specify what traffic goes into a queue using the queue-list protocol command
• Queues are served in a round robin like fashion. Each queue is served until a byte-count limit threshold is reached, before going on to the next queue
• You can have up to 16 queue-lists but only one can be applied to an interface.

Read this article and more like it on ardenpackeer.com
Follow me on twitter: http://twitter.com/ardenpackeer

Priority Queuing is a QoS congestion management mechanism. What the hell is a congestion management mechanism I hear you ask? Congestion management is how a router deals with what happens when its output queue is full. A router can’t really do much to control traffic, all it does is collect frames, figure out what to do with them, and pass them down the correct interface (hopefully!). If the frames are coming too thick and fast for the router to handle, this output queue gets full and there is not enough room for the new frames that arrive. This is known as congestion.

Congestion Management is a strategy that the router uses to handle congestion. What happens if a really important frame arrives and finds that the output queue is full? Without Congestion Management the router might just decide to drop that frame (”Aaarraaggh” I’m too busy leave me alone). Or it could say, “alright Mr VIP frame you wait in this line here and as soon as there is a free spot your the first one in”. It could have a whole bunch of different “queues” and have different criteria on who gets to go in first etc. It could even accept reservations ahead of time. These are all examples of congestion management strategies.

There are a couple of different styles of congestion management, Priority Queuing (PQ), Custom Queuing (CQ), Weighted Fair Queue (WFQ) each with different strengths and weaknesses. This article focuses on Priority Queuing.

“OK, you get to go first”

The priority queuing congestion management strategy consists of four queues. These queues are creatively called the high, medium, normal and low queues. The way it works is this, whatever the router places in the high queue always gets served before the medium, normal, and low queues. Whatever the router places in the medium queue, always gets served before the normal and low queues but only if there is no stuff in the high queue. Whatever the router places in the normal queue always gets served before the low queue but only if there is no stuff in the medium and high queues. The Low queue gets served last as long as there is nothing in the other queues.

So frames in the high queue are given preferential treatment over other frames, which for VIP frames like voice is great. The problem with this method is that the other queues can suffer from starvation. Imagine a case where the high queue always has something in it (maybe a busy site with lots of voice traffic). If the high queue always has something in it, then the other queues will never get served!

So priority queuing is really great for high priority traffic, but all other traffic suffers in some scenarios because of traffic starvation. It is usually seen on very low bandwidth links. For the CCIE, the things that i would look for is the key word prioritise, or such and such protocol must take priority over another.

Priority Queue Configuration.

Lets have a look at how to configure it:

To configure priority queuing we need to figure out which traffic to put into the different queues. After we do this we define which interface to apply this congestion strategy to. Remember this is a congestion management strategy, so it will apply to outbound traffic.

The syntax for establishing a priority-list is:

priority-list list-number protocol protocol-name {high | medium | normal | low } queue-keyword keyword-value

Lets have a look at a few examples:

access-lists 101 permit ip any 150.1.1.0 0.0.0.127
priority-list 1 protocol ip high list 101
priority-list 1 protocol ip medium gt 120
priority-list 1 protocol cdp low

The configuration above has all traffic that matches access-list 101 (any ip traffic heading to the 150.1.1.0/25 subnet) put in the high queue. All ip traffic greater than 120 bytes is placed in the medium queue. All cdp traffic is placed in the low queue.

What about traffic that doesn’t match that stuff? We might want all other traffic to be placed in the normal queue. To do that we use the priority-list default command. The syntax for this command is:

priority-list list-number default { high | medium | normal | low}

Lets expand that example above and make all other traffic go into the normal queue:

access-lists 101 permit ip any 150.1.1.0 0.0.0.127
priority-list 1 protocol ip high list 101
priority-list 1 protocol ip medium gt 120
priority-list 1 protocol cdp low
priority-list 1 default normal

By default anything that doesn’t match a priority list is sent to the normal queue. The last line above is not really required, as that is the default.

The priority-list command not only allows deciding which protocols get to go in each of the queues, you can also decide which frames get to go into queues based on the interface it arrived on. This is done with the priority-list interface command:

priority-list list-number interface interface-type interface number { high | medium | normal | low }

Lets have a look at an example:

priority-list 1 int fa 0/0 medium

The above places all frames arriving on the fastethernet0/0 interface to the medium queue. Cool huh?

What about precedence? If you have both a priority-list interface command and a priority-list protocol command in a single priority queue. Like access-lists, priority-lists are read one line at a time until a match is found.

Example 1:
access-list 101 permit any 150.1.1.0 0.0.0.127
priority-list 1 protocol ip high list 101
priority-list 1 interface fa0/0 medium

Example 2:
access-list 101 permit any 150.1.1.0 0.0.0.127
priority-list 1 interface fa0/0 medium
priority-list 1 protocol ip high list 101

Let’s say you have this scenario: A frame arrives on fa0/0 and is destined for the 150.1.1.0/128 subnet. With the first example, it would be placed in the high queue. Using the second example it would be placed in the medium queue.

The priority-list queue-limit command is used to place limits on the number of packets that can be waiting in each of the priority queues (ie. the queue size).

priority-list list-number queue-limit high-limit medium-limit normal-limit low-limit

For example:

priority-list 1 queue-limit 20 40 60 80

This sets the maximum packets in the priority queues to 20 for the high queue, 40 for the medium queue, 60 for the normal queue, and 80 for the low queue. These are the defaults queue sizes for each of the queues.

Now that we’ve had a look at configuring the priority queue how do we apply it to an interface. To do this we use the priority-group command.

priority-group list-number

For example:

int fa0/0
priority-group 1

This applies the priority-list 1 defined above, to interface fa0/0. Don’t forget this is congestion management so it only applies in an outbound direction. You can create up to 16 different priority-lists each with a different set of the four queues, but only one of the lists can be applied to the interface.

Show me the PQ!

Now that we have gone through setting up priority queuing how do we verify that it has actually been set up the way we want? Show commands! The show queuing priority command is used to verify the priority queues.

show queuing priority

For example:

Router(config)#priority-list 1 protocol ip high list 101
Router(config)#priority-list 1 interface FastEthernet0/0 medium
Router(config)#priority-list 1 protocol ip low gt 1024

Router#sh queuing priority
Current DLCI priority queue configuration:
Current priority queue configuration:
List Queue Args
1 normal protocol ip list 101
1 medium interface FastEthernet0/0
1 low protocol ip gt 1024

Summary:

• Priority Queues are a congestion management strategy
• There are 4 queues: high, medium, normal, low
• It can suffer from queue starvation, as if the higher queues are always full the lower queues might never get served.
• You define the priority queues using the priority-list command
• You attach a priority queue to an interface using the priority-group command
• You can define up to 16 priority-list but only one can be assigned to an interface
• The priority list is evaluated in the order in which it was inserted.

Read this article and more like it on ardenpackeer.com
Follow me on twitter: http://twitter.com/ardenpackeer