Cisco 3550 and 3560 Switch Ingress Queueing
Cisco 3550 and 3560 switches perform both ingress and egress queuing. The 3550 uses a single
FIFO ingress queue as a place to hold frames waiting to be forwarded to the egress interface, so
the details are not terribly interesting. The 3560, on the other hand, has two ingress queues, one of
which can be configured as a priority queue. This section addresses the details of these features.
The 3560 packet scheduler uses a method called shared round-robin (SRR) to control the rates at
which packets are sent. On ingress queues, SRR performs sharing. In shared mode, SRR shares
the bandwidth among the queues according to the weights that you configure. The weights are
relative rather than absolute—only the ratios affect the frequency of dequeuing. SRR’s shared
operation is much like CBWFQ configured for percentages rather than bandwidth.
To configure ingress queuing, you first allocate the ratio by which to divide the ingress buffers to
the two queues using the mls qos srr-queue input buffers percentage1 percentage2 command.
Then, you configure the bandwidth percentage for each queue, which sets the frequency at which
the scheduler takes packets from the two buffers, using the mls qos srr-queue input bandwidth
weight1 weight2 command. (Although the command uses the bandwidth keyword, the
parameters are just relative weightings and do not represent any particular bit rate.) These two
commands, together, determine how much data the switch can buffer and send before it begins
dropping packets.
Either of the two ingress queues can be configured as a priority queue. You would usually use a
priority queue for voice traffic to ensure that it is forwarded ahead of other traffic to reduce latency
for the voice traffic. To enable ingress priority queuing, use the mls qos srr-queue input priorityqueue
queue-id bandwidth weight command. The weight parameter defines the percentage of the
link’s bandwidth that can be consumed by the priority queue when there is competing traffic in the
non-priority queue.
For example, consider a case with queue 2 as the priority queue, with a configured bandwidth of
40 percent. If frames have been coming in only queue 1 for a while and then some frames arrive
in queue 2, the scheduler would finish servicing the current frame from queue 1 but then
immediately start servicing queue 2, trying to empty queue 2. However, to prevent starvation, if
both queues contain frames over a period of time, the scheduler would limit the overall bandwidth
to the (configured) 40 percent for queue 2 to prevent queue starvation of queue 1.
The ingress queues in the 3560 use a method called weighted tail drop, or WTD, to set discard
thresholds for each queue. (WTD is discussed later, in the section “Cisco 3560 Congestion
Avoidance.”)