QoS: srr-queue bandwidth share / shape query

[tonymurphy30]

I know the principles behind the following standard Auto-Qos output

srr-queue bandwidth share 10 10 60 20
srr-queue bandwidth shape  10  0  0  0

However if priority-queue out is NOT applied how does the switch process the queues?

The shape statement will give 10% bandwidth to Q1 and limit/shape it to this, and q2,q3 and q4 will share the remaing bandwidth as per the ratio's in the share statement.

Will the switch still use the full 10 10 60 20 ratio's for actually processing the queues?

I always use PRIORIY-QUEUE OUT but I have come across a configuration which does not have it set and suspect this may cause issues with VoIP quality if voice is put into Q1?

Regards

Tony

[Shashank Singh]

Hi Tony,

With the following commands configured under an interface:

srr-queue bandwidth share 10 10 60 20

srr-queue bandwidth shape  10  0  0  0

• 100/10 = 10% of bandwidth is reserved for queue 1 and other queues cannot share this bandwidth even if queue 1 is empty.
• 10/(10+10+60+20) = 10% of bandwidth is set for queue 2 and this bandwidth can be shared by queue 3 and queue 4 if they are congested.
• 60/(10+10+60+20) = 60% of bandwidth is set for queue 3 and this bandwidth can be shared by queue 2 and queue 4 if they are congested.
• 20/(10+10+60+20) = 20% of bandwidth is set for queue 4 and this bandwidth can be shared by queue 2 and queue 3 if they are congested.

If you use 'priority-queue out' command under an interface, as long as there is any traffic in the priority queue (queue 1 by default), 100% of the bandwidth is used by queue 1. Also, weight1 in the shape and share commands is not used in bandwidth calculation for other queues.

Without 'priority-queue out' , and above share and shape commands in place, queue1 can use at most 10% of the interface bandwidth beyond which packets will be dropped.

Hope this helps.

Shashank

Please rate this answer if you found the content useful

[michael-luo]

I'm seeing conflicting information between Shashank's post above and "srr-queue bandwidth shape" command reference (http://www.cisco.com/en/US/partner/docs/switches/lan/catalyst3750/software/release/12.2_55_se/commmand/reference/cli3.html#wp1947494).

This is what I saw from the command reference:

==============

Examples

This example shows how to configure the queues for the same port for  both shaping and sharing. Because the weight ratios for queues 2, 3, and  4 are set to 0, these queues operate in shared mode. The bandwidth  weight for queue 1 is 1/8, which is 12.5 percent. Queue 1 is guaranteed  this bandwidth and limited to it; it does not extend its slot to the  other queues even if the other queues have no traffic and are idle.  Queues 2, 3, and 4 are in shared mode, and the setting for queue 1 is  ignored. The bandwidth ratio allocated for the queues in shared mode is 4/(4+4+4), which is 33 percent:

Switch(config)# interface gigabitethernet2/0/1

Switch(config-if)# srr-queue bandwidth shape 8 0 0 0

Switch(config-if)# srr-queue bandwidth share 4 4 4 4

==============

Which means, I could substitue the above with the following and achive the same result:

Switch(config)# interface gigabitethernet2/0/1

Switch(config-if)# srr-queue bandwidth shape 8 0 0 0

Switch(config-if)# srr-queue bandwidth share 255 4 4 4

Since the settings for queue 1 is ignored, it doesn't matter what value I put in there (in my case it's 255)

Can somebody confirm my thought?

Thanks!

Mcihael

[aananda]

Any update on this?

[paul_jerome]

I will have to lab it up to be sure, which I'm not able to do right now. But I would expect that is correct as queue 1 could have a different share value to it's shaped value. If the shaped value doesn't apply it should not have an effect on the other shared queues. Though my preference to be on the safe side would be to give it a shared weight of 1.

In your example if queue 1 is guaranteed 12.5% then the other 3 queues would get 33% of the remaining bandwidth. So on 100Mbit they would receive an equal share of the 87.5Mbit remaining, but would never encroach on the 12.5Mbit reserved for queue 1.

At least that is my understanding.