This article is great. You mention that the 3560 loses the internal DSCP method that the 3550 used. However, the DOCcd is still cluttered with references to it in various sections of the 3560 configuration guide. Is this an error on their part (copy and paste?)

I’m referring to:
http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_44_se/configuration/guide/swqos.html

Just search for ‘internal dscp’, as they mention it several times.

Is this just the usual doc cd errors?

The trick with SRR shape is that it “guarantees” and “limits” the bandwidth at the same time. That is, if you set shape weight to 20 on a 100Mbps interface, you will restrict the queue to 1/20*100=5Mbps but this will also be the guaranteed rate (i.e. if interface is congested, you wont get less than 5Mbps). The “share” weight is not taken in account when “shape” is specified.

Thanks for the clarification.

What about Question 1?
do shaping(upper bound) and sharing(minimum guarantee) work at the same time for a single queue? or would applying non-zero “shape” value invalidate “share” ratio for that queue?

Honestly, I was first confused by the DocCD But the latter statement is actually correct: PQ on 3560 is not subject to policing by SRR shaped mode. So i just fixed my older article with respect to that matter. Thanks for pointing this out!

Thanks for the great articles!
I’ve got a couple of questions which follow, it would be very kind of you to help me out with this.

Question1:
The really fun part is that an interface could be configured for SRR shared and shaped mode at the same time. This way, each queue is guaranteed a bandwidth share, and additionally has some upper bound on transmission rate set.”
Does this imply that the shape and share statements work at the same time on the same queue? or would shaping override and cancel out sharing configuration for a particular single queue?
Question2:

interface gigabitethernet0/1
srr-queue bandwidth shape 10 0 0 0
srr-queue bandwidth share 10 10 60 20
!
! As expedite queue (queue-id 1) is enabled, it’s weight is no longer honored by the shared mode scheduler
! Still, this queue is subject to shaped mode policing, in order to prevent over queues starvation
!
priority-queue out

The following quote is from another article:

5) When you enable “priority-queue out” on an interface, it turns queue 1 into priority queue, and scheduler effectively does not account for the queue’s weight in calculations. Note that PQ will also ignore shaped mode settings as well, and this may make other queues starve.
Is it me or do the starvation parts contradict each other?
Which one is valid?

Thanks for your time.
All the best!

Which begs a question; as quoted by yourself in this article “The biggest obstacle is absence of any good information source on the 3750/3560 switches QoS, besides the Cisco Documentation site, which has really poor documents regarding both models.”

The question I have is, how do you go about finding the true facts of these things? I can spend days reading through Cisco docs, all contradicting themselves and at the end, be none the wiser - what’s the trick?

Big thanks again, look forward to the next article.

Regards,
Steve