mls qos srr-queue input bandwidth weight1 weight2

[Federico Olivieri]

Hi All,

I got a question about input queue for Cisco 3750: Cisco documentaton talks about "mls qos srr-queue input bandwidth weight1 weight2" where "The ratio of the weights is the ratio of the frequency in which the SRR scheduler sends packets from each queue." I'm struggling to understand its meaning. It is a kind of policer for not starving the other queue? (i.e. if I have 10 Megabits in Q2 with a ratio of 45 % - weight 4 4 - the SRR will serve 4.5 Megabits of those 10 and it will serve Q1 for its 45% and then it will come back to serve again Q2 for its 45%) 

Thank You

Federico

[Joseph W. Doherty · Accepted solution]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

No, it's not a policer, because a policer would limit bandwidth usage even if there was available bandwidth.

What the input QoS does, if there's congestion, it will drain packets from two different queues in the proportions you specify.

As the scheduler uses SRR, either ingress queue shouldn't be totally starved of bandwidth, but it's possible one or both queues still might not obtain enough bandwidth to preclude packet drops in a queue or queues.

The normal purpose of these two queues is to try to insure sufficient bandwidth for some of your critical traffic, like VoIP.

[Federico Olivieri]

Hi,

I signed the answer as right but it was a mistake.

What I want try to understand what the command "mls qos srr-queue input bandwidth weight1 weight2" does. I got how Input queues work but I would like to know in specific the command.

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Sorry, it's not clear, to me, what you're still looking to understand.

Do you understand, that ingress queues are (I recall) for interface ingress traffic egress to the fabric?  I.e. multiple ports ingress capacity can overrun the fabric bandwidth, these queues allow you to (somewhat) manage that congestion.

[Federico Olivieri]

Sorry to have been not clear.

Yes, I have clear the meaning of the input queueon Catalyst.

However, I  think I found the answer

SRR services the priority queue for its configured weight as specified by the bandwidth keyword in the mls qos srr-queue input priority-queue queue-id bandwidth weight global configuration command. Then, SRR shares the remaining bandwidth with both ingress queues and services them as specified by the weights configured with the mls qos srr-queue input bandwidth weight1 weight2 global configuration command.

As far as I have understood, ls qos srr-queue input priority-queue queue-id bandwidth weight sets the bandwidth for the priority queue and mls qos srr-queue input bandwidth weight1 weight2 sets the percent of bandwidht remaining between the 2 queues.

The problem is that some documents explain the things in a way, and someone else in another way. It is just matter to find the one that gives a better explanation