// you’re reading...

QoS & VoIP

Configuring Custom Queuing

Thanks for visiting! If you're new here, you may want to subscribe to my RSS feed. This blog posts regular tutorials, news, and study tips about networking, especially about Cisco CCIE related topics. Go ahead, subscribe to the rss feed! You can also receive updates from this blog via email. Thanks for visiting!

In my previous post, I talked a little bit about congestion management focusing on priority queuing. Priority queuing is great in making sure that VIP traffic gets to looked first dibs on that output queue when congestion occurs. The problem with priority queuing was starvation. If there was frames always waiting in the high queue the lower queues might never get served.

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.

Related posts

Discussion

No comments for “Configuring Custom Queuing”

Post a comment


Twitter Feed...

Follow me...

View Arden Packeer's profile on LinkedIn Arden Packeer ClaimID Add to Technorati Favorites TwitterCounter for @ardenpackeer