LAN switching: Congestion avoidance and management

The text discusses 3560 switch queues, specifically how this model has ingress and egress queues. There are two ingress queues, but only one of them can be configured as a priority queue, and these queues use a method called Weighted Tail Drop during periods of congestion.


Shared Round Robin (SRR) is used in the 3560 to schedule packets from the ingress queues to the backplane fabric. You can specify the guaranteed amount of traffic each queue will have (weighting), but neither queue is limited to only that amount. This way, if one queue is empty the second ingress queue can utilize all the bandwidth available for sending traffic.Finally, you should know that SRR weighting functions more like a percentage specification than as a bandwidth amount (e.g.- it is relative and not absolute).

Behaviors you'll want to keep in mind when you configure ingress queuing include:

1) COS mappings are used by default; COS 5 traffic gets its own queue. DSCP mapping is available.
2) You'll need to specify if the second ingress queue is a priority queue
3) Ensure the default WTD thresholds are appropriate for your traffic; at 100% full traffic is dropped by default
4) WTD can have up to three different thresholds where traffic is dropped in increasing increments

Priority Ingress Queuing
The relevant command is mls qos srr-queue input priority-queue QUEUE-ID bandwidth WEIGHT. In this syntax, the weight value is a percentage of link bandwidth. The next command used is mls qos srr-queue input buffers PERCENTAGE1 PERCENTAGE2. The default for the latter command has 90% of buffers allocated to queue 1 and 10% to queue 2, so you'll want to watch out for this if your priority queued traffic needs more buffers.

Unfortunately, when I tried to Google search the 3560 or 3750 buffer sizes I had no luck determining either how large the buffers are, or how best to check for buffer size problems! The best info available was to run a show interface command and check the input section for buffer overflow packets being reported. That's far from an exact science.

You'll also need to configure the SRR scheduler for both queues-  mls qos srr-queue input bandwidth WEIGHT1 WEIGHT2. Although the word bandwidth appears in this command, it's not an actual BW value but a weight number being specified. Confusing eh? Default values are 4 and 4 for weight1 and weight2, which divides scheduling evenly between queues. Although I've been Googling, I cannot locate solid info on what happens to the second queue once you configure a priority queue and its weight value. I'll test this in my lab tomorrow and update the blog.

EDIT: So the results are in! Configuring the bandwidth weight with mls qos srr-queue input priority-queue changes a weighting value, which is multiplied by the bandwidth value (set using the command mls qos srr-queue input bandwidth). To see these command options being changed, you'd check the output of the command sh mls qos input-queue. Sample output is below-

Rack1SW1(config)#mls qos srr-queue input priority-queue 2 bandwidth 30

Rack1SW1#sh mls qos input-queue
Queue     :       1       2
----------------------------------------------
buffers   :      90      10
bandwidth :       4       4
priority  :       0      30
threshold1:     100     100
threshold2:     100     100

Rack1SW1(config)#mls qos srr inp ban 2 6

Rack1SW1#sh mls qos input-queue
Queue     :       1       2
----------------------------------------------
buffers   :      90      10
bandwidth :       2       6
priority  :       0      30
threshold1:     100     100
threshold2:     100     100