QoS on 3560 Question

All,

I'm learning (struggling with!) our QoS policy at work and in particular on the 3560G.

What I'm trying to understand is the "srr-queue bandwidth" statement as applied to an interface (see below). Could anyone explain this please? It's not documented in the CCO Command Lookup tool.

From searching this newsgroup's archives and talking to colleagues, I understand that any bandwidth limitations put in place are only applicable during periods of congestion. In which case, what measures does a Cisco switch use to realise there is congestion?

If it's better that I go and RTFM, please let me know where it is ;-)

Many thanks,

James.

mls qos map policed-dscp 24 to 8 mls qos map cos-dscp 0 10 18 24 34 46 48 56 mls qos map ip-prec-dscp 0 10 18 24 34 46 48 56 [... CoS/DSCP Map ...] mls qos queue-set output 1 threshold 1 100 100 100 400 mls qos queue-set output 1 threshold 2 100 100 100 400 mls qos queue-set output 1 threshold 3 100 100 100 400 mls qos queue-set output 1 threshold 4 100 100 100 400 mls qos

[... Policy and Class Map ...]

inter fa0/x service-policy input MYPOLICY ! Not sure what this does: srr-queue bandwidth share 30 40 25 5 priority-queue out

Reply to
James.Brown
Loading thread data ...

formatting link

Reply to
Trendkill

these 4 lines play with the thresholds on each Q and the buffer alloc.

very easy to get stupid results like dropping packets for small traffic surges, and doesnt seem to affect the results much when i tested it.

it sets the bandwidth ratios for the 4 Qs on this port - how the port capacity will get %age of bandwidth shares if the queue backs up. They dotn have to add up to 100 (although it makes it much easier for people)

and this one sets the 1st Q in priority mode, so it ignores the "share" command (and no outbound policing, so can be a problem)

the other one in the set is the "shape" command that lets you have a rate limit on a queue

eg srr-queue bandwidth shape 0 0 4 0

would leave queues 1,2 4 alone, but rate limit Q3 to 1/4 of the link bandwidth - ie 25%. AFAICT you can use any integer.

Any more than the limit and a few packets get queued, and then you start dropping stuff.

Note 1 of your queues will get routing control, OSPF, spanning tree etc - the Qs can be aggressive and it is easy to set it up so the routing is unstable on overload if you arent careful.

sh mls qos and sh platform port-asic

commands can give you some idea of where the flows are going, what is in which queue and when drops start.

i recommend a traffic generator, an isolated network and some serious overload to check......

Reply to
stephen

i am using 3560s for L3 and it is the same QoS model irrespective of L2 or L3 switching.

Q control is about buffering, limiting and contention - doesnt matter how the traffic gets to the output port....

Reply to
stephen

Seriously, at L2 I find that the auto qos settings are quite sufficient.

Given the bandwidth throughput of switches, the only real concern is real time traffic (i.e. Voice!!!) which is admirably handled by auto qos (it sticks COS 5 traffic into the priority queue and marks it as EF DSCP which is pretty much standard practice anyway even if you choose to tweak the queues manually).

WAN links are a different story altogether but you'd be classifying at L3 or higher for that sort of stuff - the commands you are talking about are the L2 switching queues.

James.Brown wrote:

Reply to
Johann Lo

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.