CBWFQ not supported on Sub-Interfaces

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!

Laz