The WFQ mechanism made sure that no traffic was starved out. However, WFQ did not make a specific amount of bandwidth available for defined traffic types.
You can, however, specify a minimum amount of bandwidth to make available for various traffic types using the CB-WFQ mechanism.
CB-WFQ is configured through the tree-step MQC process. Using MQC, you can create up to 63 class-maps and assign a minimum amount of bandwidth for each one.
Why not 64 ?
Because the default class-map is already configured.
Traffic for each class-map goes into a separate queue. Therefore, one queue can be overflowing , while other queues are still accepting packets.
Bandwidth for class-maps can be specified following 3 ways:
- Bandwidth
- Percentage of bandwidth
- Percentage of remaining bandwidth
By default , each queue that is used by CB-WFQ has a capacity of 64 packets. Also , only 75 percent of an interface’s bandwidth can be allocated by default.
The remaining 25 percent is reserved for nonclassified overhead traffic ( CDP,LMI,Routing,..)
But you can always overcome this limitation with the command max-reserved-bandwidth <<percentage>>.
CB-WFQ is therefore an attractive queuing mechanism thanks to MQC configuration and the ability to assign a minimum bandwidth allocation.
The only major drawback to CB_WFQ is its inability to give priority treatment to any class. To overcome this drawback, Low Latency Queuing (LLQ) was created tosupport traffic prioritization.