Looking for feedback/advice on proposed Cat3560 QoS config

[d-fillmore]

Hi, I'm trying to set up a QoS policy on a Cat3560 so that incoming voice and video traffic matched by an ACL on one interface, is guaranteed 35% of the outbound bandwidth on another.
I've spent the last few hours trying to work out how to do this and I think I have it but if anyone has any experience of this I'd appreciate any comments.

The incoming traffic is voice and video on a 1Gb link but any dscp or cos marking will have been stripped so I'm classifying based on IP
The outbound traffic is going out through a 100Mb site to site link

!! Enable Qos
mls qos

!! classify traffic
access-list 1 permit 10.1.1.0 0.0.0.255

class-map voicevideo
 match access-group 1
 
!! Create inbound policy-map in order to match the IP traffic and set a DSCP value so the traffic goes into a a specific qos-group and output queue
!! I'm going to put the voice and video traffic into queue 3. My understanding is that all incoming traffic will be marked as dscp 0 by default and will therefore end up in queue 2 by default
!! Setting the dscp to between 16-31 should mean my voice and video traffic will get mapped to queue 3 (http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3560/software/release/15-0_1_se/configuration/guide/scg3560/swqos.html#pgfId-1202482)

policy-map inbound-classification
 class voicevideo
  set dscp 16
 class class-default
  set dscp 0
  
interface G0/X
 service-policy input inbound-classification

!! based on the above, I'd expect all my voice and video traffic to be in queue 3 (35%) and all my other traffic to be in queue 2 (25%) The number for queue 1 and queue 2 are unimportant I guess so have chosen 15 & 25 respectively
!! For clarity I'll set the shaping figures to be zero to be clear that I'm not using shaping

Interface G0/Y
srr-queue bandwidth shape 0 0 0 0
srr-queue bandwidth share 15 25 35 25

Any feedback would be appreciated!

Cheers, Dom

[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 whatsoever (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

If you're going to use only two queues, and if you want to guarantee the one queue 35% of your egress bandwidth, you need to assign your two queues the ratio of 65:35; you'll need to adjust the four queue percentages to provide those two queues the same ratio.  Ideally you'll want something like share 0 65 35 0, but if you cannot assign zero, something like 40 13 7 40, 20 39 21 20, 10 52 28 10 should do.

[d-fillmore]

Thanks for your feedback Joseph.

I was initially going to do that but was concerned that some other traffic that I'd not classified would end up in a starved queue - eg routing protocol control or STP traffic or something else that I hadn't thought of.

[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 whatsoever (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

If you do your egress mapping correctly, you shouldn't be seeing traffic to those other queues (don't forget device generated traffic).  But to preclude total starvation, you can use something like 10 52 29 10.  However any unexpected traffic, will disrupt your 35% guarantee.  So, if seen, cause should be determined and it should be redirected to your intended queue.

[d-fillmore]

Yeah good idea, start off with 10 in each of the spare queues just in case and then tune to 0 65 35 0 based on results.

Thanks for the advice, appreciate it!

[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 whatsoever (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

Or if you cannot set zeros for share percentage, or you want the bare minimum for other "spare" queues, you might try something like 1 64 34 1.  Your 65:35 ratio isn't maintained, even without "spare" queue traffic, but the ratio is still close.

PS:

BTW, when you adjust bandwidth ratios, you might also want adjust buffers allocations ratios too.