I found it important to make a small post in reply to the following question:

Hi Petr
i’m still confused between
mls qos min-reserve and wrr-queue bandwidth
what is the difference between the two


The 3550 WRR (weighted round robin) scheduler algorithm utilizes four configurable queues at each interface of the switch. Let’s consider just FastEthernet ports for simplicity in this post. For each queue, the following important parameters could be configured:

1) WRR scheduling weight. Defines how much attention the queue is given in case of congestion. The weight essentially defines the number of packets taken from queue each time WRR scheduler runs through queues in sequence. WRR weights are defined per-interface using the command wrr-queue bandwidth w1 w2 w3 w4. Theoretically, if each queue holds packets of approximately the same size, the proportion of bandwidth guaranteed to queue number “k” (k=1..4) is: wk=wk/(w1+w2+w3+w4) [this formula does not hold strict if packet sizes are much different]. If queue 4 is turned into priority by using priority-queue out, than it’s weight is ignored in computations (w4 is set to 0 in the above formula). The currently assigned weights could be verified as follows:

interface FastEthernet 0/1
 wrr-queue bandwidth 10 20 30 40

Rack1SW4#show mls qos interface queueing
Egress expedite queue: dis
wrr bandwidth weights:
 1 - 10
 2 - 20
 3 - 30
 4 - 40

2) Queue size. Number of buffers allocated to hold packets when the queue is congested. When a queue grow up to this limit, further packets are dropped. The queue size value is not explicitly configurable per FastEthernet interface. Rather, each queue is mapped to one of eight globally configurable “levels”. Each level, in turn, is assigned the number of buffers available to queues mapped to this level. Therefore, the mapping is as following: queue-id -> global-level -> number-of-buffers. By default, each of eight levels is assigned the value of “100″. This means that every queue mapped to this level will have 100 buffers allocated. The interface-level command to assign a level to a queue is wrr-queue min-reserve Queue-id Global-level. By default, queues 1 through 4 are mapped to levels 1 through 4. Look at the following example and verification:

mls qos min-reserve 1 10
mls qos min-reserve 2 20
mls qos min-reserve 3 30
mls qos min-reserve 4 40
! Assign 40 buffers to queue 1
! Assign 30 buffers to queue 2
! Assign 20 buffers to queue 3
! Assign 10 buffers to queue 4
interface FastEthernet0/1
 wrr-queue min-reserve 1 4
 wrr-queue min-reserve 2 3
 wrr-queue min-reserve 3 2
 wrr-queue min-reserve 4 1

Rack1SW4#show mls qos interface fastEthernet 0/1 buffers
Minimum reserve buffer size:
 10 20 30 40 100 100 100 100
Minimum reserve buffer level select:
 4 3 2 1

3) CoS values to Queue-ID (1,2,3,4) mapping table (per-port). Defines (per-interface) which outgoing packets are mapped to this queue based on the calculated CoS value. The interface-level command to define the mappings is wrr-queue cos-map Queue-ID Cos1 [Cos2] [Cos3] … [Cos8]. For example:

interface FastEthernet0/1
 wrr-queue cos-map 1 0 1 2
 wrr-queue cos-map 2 3 4
 wrr-queue cos-map 3 6 7
 wrr-queue cos-map 4 5

Rack1SW4#show mls qos interface fastEthernet 0/1 queueing
Egress expedite queue: dis
wrr bandwidth weights:
 1 - 10
 2 - 20
 3 - 30
 4 - 40
Cos-queue map:
 0 - 1
 1 - 1
 2 - 1
 3 - 2
 4 - 2
 5 - 4
 6 - 3
 7 - 3

Note that the CoS value is either based on the original CoS field from the incoming frame (if CoS was trusted) or is calculated using the global DSCP to CoS mapping table (for IP packets).

Note that for GigabitEthernet ports on the 3550 platform, the configuration options are more flexible – you can specify queue-depths per-interface, configure drop thresholds, map DSCP value to thresholds and define the drop strategy. However, this topic is for separate post :) .

About Petr Lapukhov, 4xCCIE/CCDE:

Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, and progressed into networking with his first exposure to Novell NetWare in 1991. Initially involved with Kazan State University's campus network support and UNIX system administration, he went through the path of becoming a networking consultant, taking part in many network deployment projects. Petr currently has over 12 years of experience working in the Cisco networking field, and is the only person in the world to have obtained four CCIEs in under two years, passing each on his first attempt. Petr is an exceptional case in that he has been working with all of the technologies covered in his four CCIE tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching classes, developing self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied Mathematics.

Find all posts by Petr Lapukhov, 4xCCIE/CCDE | Visit Website

You can leave a response, or trackback from your own site.

9 Responses to “Understanding WRR Queue Parameters”

  1. Maarten says:

    I’ve got a question regarding this post.
    If you configure a priority queue out, que 4 its weight value is ignored. Which weight is then given to the priority que? it wil have strict prior to all other ques does this mean it will have a weight of 100 or default 30?

  2. The priority queue has an infinite weight, since it is always serviced first before any other queue.

  3. PQ does not have any WRR weight per itself. Rather, the PQ is always services ahead of any WRR queues, having absolute priority. This means, you can consider its weight as being zero for WRR computations.

  4. Maarten says:

    Ok thats clear.

    Just to clearify it. If for some reason(misconfiguration) all traffic thats in the priority queue consumes 100% of the link all other traffic will be dropped?

  5. Yes, that’s the problem with PQ in the 3550/3560. It is not policed (unlike LLQ), so you have to be careful with traffic admission on the edge of your network.

  6. Dharmesh Shah says:

    Can you pls point me to the link (or navigation steps) on the doc cd for this topic ?

    Thanks in advance

  7. [...] specifically: http://blog.internetworkexpert.com/2008/07/20/undestanding-wrr-queue-parameters/ Categories: CISCO Tags: qos Comments (0) Trackbacks (0) Leave a comment [...]

  8. Tibia says:


    Thanks, I always aprisiate a good read. Dont stop posting!…

  9. luis palma says:

    very clear thank you, greetings from mexico


Leave a Reply


CCIE Bloggers