cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
535
Views
0
Helpful
4
Replies

Auto QoS parameters on 2950

Kevin Dorrell
Level 10
Level 10

I have been looking at the way auto-qos behaves on a 2950 switch. Now, it used to be that the weightings given to the four WRR queues was 20 1 80 0. This made sense to me because it made a strict priority out of queue 4, which is the one that will get all my DSCP EF (i.e. voice) traffic.

I did this on a switch with version 12.1(22)EA4, and I see that the default weightings are now 10 20 70 1. This does not seem to make sense to me at all, and looks like the worst possible combination for voice. It is giving the least weighting to queue 4, which is the one carrying the voice traffic.

Is this a bug, or is there some reasoning behind it?

Kevin Dorrell

Luxembourg

1 Accepted Solution

Accepted Solutions

Prashanth Krishnappa
Cisco Employee
Cisco Employee

Kevin

This is a recent change in auto-qos on the 2950 from 20 1 80 0 to this 10 20 70 1. The reasoning is to get away from strict-priority queueing as it allows for starvation. In older code it still show 0 but new codes now show 1.

On the 2950 switches, This is done by design not to have a strict priority queue starve the other queues out. So this is expected behavior not to have a strict priority queue in newer versions of code when you use Auto QoS.

It is advisable not to give "strict" priority to any queue in order to prevent other queues from getting starved. On 2950, the wrr CLI allows weights of 1 - 255, and the weight of 0 is not configured (which would keep the queue in strict priority). One of the reason is that 2950 does not have features such as shaping. So, it is safer to keep the queues in round robin, and the number of buffers are controlled.

At this point it would probably be best to play with the weights to determine if the defaults work for your network. If the Auto QoS defaults do not work for your network you can always have the option to manually configure the CLI as you want.

Hope this helps.

View solution in original post

4 Replies 4

Kevin Dorrell
Level 10
Level 10

Bump! Anyone?

Kevin Dorrell
Level 10
Level 10

Bump²! Anyone?

I have been looking at the configuration guide, and that seems to confirm that it really does give just 1%, and no priority, to the EF voice queue. It seems like an extraordinary thing to do. Anyone any idea why they have done this?

http://www.cisco.com/en/US/products/hw/switches/ps628/products_configuration_guide_chapter09186a00802c31e8.html#wp1125449

Kevin Dorrell

Luxembourg

Prashanth Krishnappa
Cisco Employee
Cisco Employee

Kevin

This is a recent change in auto-qos on the 2950 from 20 1 80 0 to this 10 20 70 1. The reasoning is to get away from strict-priority queueing as it allows for starvation. In older code it still show 0 but new codes now show 1.

On the 2950 switches, This is done by design not to have a strict priority queue starve the other queues out. So this is expected behavior not to have a strict priority queue in newer versions of code when you use Auto QoS.

It is advisable not to give "strict" priority to any queue in order to prevent other queues from getting starved. On 2950, the wrr CLI allows weights of 1 - 255, and the weight of 0 is not configured (which would keep the queue in strict priority). One of the reason is that 2950 does not have features such as shaping. So, it is safer to keep the queues in round robin, and the number of buffers are controlled.

At this point it would probably be best to play with the weights to determine if the defaults work for your network. If the Auto QoS defaults do not work for your network you can always have the option to manually configure the CLI as you want.

Hope this helps.

Prashanth,

Thanks for the reply. I understand the point about not allowing any queue to have strict priority in order to prevent starvation (and/or DoS). I also see, now that you point it out, that the problem would not arise if the 2950 (hypothetically) supported shaping, in which case you could have a shaped priority queue like the traditional LLQ configuration. I was just surprised that the weighting was set as low as 1/101.

The question came up on the QoS course I attended last week, because the course notes still have the old 20 1 80 0 configuration.

Thanks for the response, anyway.

Kevin Dorrell

Luxembourg

Review Cisco Networking for a $25 gift card