CBWFQ not supported on Sub-Interfaces

Hi Lazarus,

I’m wondering about how is selected the queue for a certain traffic. If I understood it correctly from your quoted text, its from the number of classes in the policy map. Does this mean that for each “class” entry in a “policy-map” a new queue is created? Or only for some “class” entries depending on the commands nested inside it?

You also mention that 4, 8 or 12 are considered best practice. However, if I only need 2 o 3 classes in my policy map, what do I do? I wouldn’t be following the best practice, what effect will it have? Will I get worse performance than if I used 4?


Hello José

According to this Cisco documentation:

For CBWFQ, you define traffic classes based on match criteria including protocols, access control lists (ACLs), and input interfaces. Packets satisfying the match criteria for a class constitute the traffic for that class. A queue is reserved for each class, and traffic belonging to a class is directed to the queue for that class.

So yes, each class created corresponds to a queue for that class.

As for the best practice of the number of queues, I was trying to find the documentation where this is stated, but I have been unable to. But I do know that this is indeed a recommended best practice from Cisco. On some platforms, you can create up to 64 queues, but the recommendation is indeed 4, 8, or 12. The reason for this is that the algorithms used to achieve queueing are more efficient for these values. That doesn’t mean you can’t implement 3 or 5 classes, but it will simply be less efficient. How much less efficient it may be will also depend on traffic patterns and congestion experienced.

I hope this has been helpful!


1 Like