CBWFQ not supported on Sub-Interfaces

This topic is to discuss the following lesson:

CBWFQ stands for Class-Based Weighted Fair Queuing

Class-Based Weighted Fair Queuing. It’s meant to give a certain bandwidth to traffic classes when an interface is congested.

Brilliant as ever Rene. Good post i was looking for it

Hi Rene,

I’ve been following your tutorials for quite a while now and they have helped my a lot. Thanks for them.

Two things I want to ask:

  1. Using Class-map, is it possible to block something like Facebook. I am able to block http://www.facebook.com but https is a headache. Can’t seem to block only one https site. I don’t want to block all https category.

  2. Do you have tutorials on different Switching stuffs like STP, RSTP, MST, VLAN etc?

Please share if ya have. Will be grateful.


Hi BJ,

You can use NBAR to block HTTP but not HTTPS, here’s why:

I have quite some switching tutorials but I’m going to add more, take a look here:


Hello Rene,

Nice article. Does this work around also works on SVI (interface vlan)?


Tried adding policies on a SVI ina 4900/4500 Switch. Said its not allowed. Does the same work around works for this? i haven’t tried it yet but will do and find out result.

Hi Olaniyi,

QoS on the switches works a bit different. The configuration is different. Here’s an example:


I think the 4900/4500 QoS is similar but I’d have to check.


Hello Rene,

I don’t see a CBWFQ topic, so I’ll ask a question here.

I understand that CBWFQ guarantees a minimum bandwidth in times of congestion for certain traffic. If one queue doesn’t need it’s bandwitdh, other user-defined classes of traffic can use that bandwidth in proportion to their configured bandwidth.

But what happens with class-default class? Can it also use unused bandwidth of user-defined classes, and in which proportion? I suppose that class-default can use that bandwidth only if we manually define bandwidth for that class. Am I right?

Hi Filip,

That’s right and the same thing applies to the class-default class. The only difference is that the class-default class will have a much higher weight that any of the user defined classes so it will only get a small portion of the bandwidth, even if you don’t configure a bandwidth for it. I’d have to check how much exactly, on IOS 12.4 you could use the “show queueing” command to see the weights. Not sure you can still see them on IOS 15 since these commands have been deprecated but I could do a simple bandwidth test :slight_smile:


Hi Rene,

I need you shed some light on ‘when congested’. Am I right in saying the QoS policies that we apply are insignificant during the period of non-congestion? can request you demo this.

Also I believe tx ring limit and hold-queue commands on an interface lets us play with the interface buffers and hence the congestion. Can you please shed some light on them too?


Hello Ayyappan

QoS mechanisms will only engage when there is congestion. They play absolutely no role when there is no congestion on a particular interface. QoS will look at DSCP values and compare them between packets that are waiting in line (in the queue) to see which to send first based on the QoS configuration. There is a comparison involved and then a decision as to which will be sent first. If a packet arrives at an interface and the interface’s queues are empty, there is no comparison, there is no question as to which packet will be sent, it is the one that has arrived and will be sent immediately.

This is why one way to deal with congestion is to over-provision links. If you vastly over-provision links, there is no need to employ QoS. (Although this thought is logical, it is a simplistic view and should not be considered best practice). So if there is no congestion, there is no delay, packets are sent immediately and QoS is not engaged.

The tx-ring-limit command is used on ATM router interfaces that support per virtual circuit queuing. This is something that you would find on ISP or telecom carrier equipment and not on a simple Ethernet interface. You can find more information about that, and when it should be used, here:

As for the hold-queue command,

the system counts input queue drops if the number of packet buffers allocated to the interface is exhausted or reaches its maximum threshold. You can increase the maximum queue value with the hold-queue <value> command for each interface (the queue length value can be between 0 and 4096. The default value is 75).

You can find out more about that command here:

I hope this has been helpful!



I have router 3925 I configured subinterfaces on the Ethernet LAN for Assigning DSCP values for the input traffic, the configuration is made without nested policy map, do you think this configuration it’s different from router to router? or it’s because the policy only assigning DCSP?

Hello Samer

If you are only changing the markings on the packets going through each subinterface, then you will have no problem in applying a policy map and setting DSCP values. The restriction of the CBWFQ on subinterfaces will appear when you attempt to assign a percentage of bandwidth to a particular class of traffic.

I hope this has been helpful!


Hi Rene,

Great explanation! I have a question about the queues. Are there 4 queue by default? I have watched a video on YouTube where another instructor states that Cisco recommends not to create more than 11 classes (12 in total if you include the default-class). My question is how do you create the queues? Are the queues created as you create the class-maps? How do you check how many queues have been created? Cisco has recommendations for 4, 8 and 12 classes? I’m abit confused and would really appreciate if you can shed some light?



Hello Akhas

First of all it’s important to note that there is a difference between physical or hardware queues on an interface, and logical queues. Most lower end devices (2900 and 3900 series) will have a single hardware queue while some of the higher end devices such as the 9000 series may have multiple hardware queues. However, these queues fundamentally function in FIFO mode, and are simply used as buffers for oversubscribed traffic.

The queues created using QoS mechanisms such as CBWFQ for example, are logical queues, and they are essentially defined using the number of classes that you define in your policy map. Typically, the Cisco recommendation for 4, 8, or 12 classes is considered best practice, because this number of classes that will create the most efficient set of queues.

Now keep in mind that you can create very complex multi-level queueing structures where some platforms will support up to 64 queues in total (this is platform and IOS dependant), but it is generally not efficient to use so many queues. You can find out more about multi-level queuing at the following Cisco documentation:

I hope this has been helpful!


Hi Laz,

That’s clarified it!

Many thanks!

1 Like

I have multiple sub-interfaces configured under one parent interface and using CBWFQ with bandwidth guarantees for different classes of traffic in the child policy and a shaper for all traffic in the parent policy. How does the policy under one of the sub-interfaces know how to calculate the bandwidth guarantee since it needs to guarantee based on the CIR it has with the provider and not the full line rate?

Hello Victor

It would be helpful if you shared the configuration of your particular configuration on the physical interface, on the sub interfaces, as well as in the policy and class maps. You can “sanitize” the configuration and share it here, and we’ll be able to respond to it in more detail.