Switching (MPLS) experimental (EXP) bits has no effect if MPLS is not enabled.

Matching on Inter-Switch Link (ISL) priority bits has no effect if ISL is not used.

It is important to note that CBWFQ is configured using Cisco Modular QoS CLI (MQC). The classifications that can be configured depend on the Cisco IOS version and the type of interface that is configured. Scheduling Mechanisms
The CBWFQ mechanism calculates weights based on the available bandwidth. These weights are then used by the CBWFQ scheduling mechanism to dispatch the packets. You can configure bandwidth guarantees by using one of the following commands:

• The bandwidth command allocates a fixed amount of bandwidth by specifying the amount in kilobits per second. The reserved bandwidth is subtracted from the available bandwidth of the interface where the service policy is used. The allocated bandwidth must also be within the configured reservable limit (75 percent of interface bandwidth by default).
• The bandwidth percent command can be used to allocate a percentage of the total available bandwidth of an interface. The total interface bandwidth is defined by using the bandwidth interface command. It is recommended that the bandwidth command reflect the real speed of the link. The allocated bandwidth is subtracted from the available bandwidth of the interface where the service policy is used.
• The bandwidth remaining percent command is used to allocate the amount of guaranteed bandwidth based on a relative percentage of available bandwidth. When the bandwidth remaining percent command is configured, hard bandwidth guarantees may not be provided, and only relative per-class bandwidths are assured. That is, class bandwidths are always proportionate to the specified percentages of the interface bandwidth. When the link bandwidth is fixed, class bandwidth guarantees are in proportion to the configured percentages. If the link bandwidth is unknown or variable, class bandwidth guarantees in kilobits per second cannot be computed

A single service policy cannot mix the bandwidth (fixed, in kilobits per second) and bandwidth percent commands (except with strict-priority queues). The weights needed for scheduling are calculated by the CBWFQ process based on the configured bandwidth or its percentage. Calculating Available Bandwidth
The available bandwidth displayed by the show interface command is calculated by subtracting all fixed bandwidth reservations from the default 75 percent of the configured bandwidth of an interface. The available bandwidth is calculated with the following formula as shown in : Bandwidthavail = Bandwidth * MaxReservable – SUM (all fixed guarantees) Properly provisioning the network bandwidth is a major component of successful network design. You can calculate the required bandwidth by adding the bandwidth requirements for each major application (for example, voice, video, and data). The resulting sum represents the minimum bandwidth requirement for any given link, and it should not exceed 75 percent of the total available bandwidth for the link. The remaining 25 percent is used for other overhead, including Layer 2 overhead, routing traffic, and best-effort traffic. However, under aggressive circumstances in which you want to configure more than 75 percent of the interface bandwidth to classes, you can override the 75 percent maximum sum allocated to all classes or flows using the max-reserved-bandwidth command. If you want to override the default 75 percent, exercise caution and ensure that you allow enough remaining bandwidth to support best-effort and control traffic and Layer 2 overhead such as Layer 2 keepalive messages, as well as the class default traffic. If all of the bandwidth is not allocated, the remaining bandwidth is proportionately allocated among the classes based on the configured bandwidth of the classes. CBWFQ Benefits and Drawbacks
CBWFQ allows you to define traffic classes based on custom-defined match criteria such as ACLs, input interfaces, and protocol type. Figure shows the benefits and drawback of CBWFQ described as follows:

• Classification: CBWFQ allows custom-defined classifications based on many parameters, such as ACLs, input interfaces, byte count, and so on.
• Bandwidth allocation: CBWFQ allows you to specify the exact minimum bandwidth to be allocated for a specific class of traffic. Taking into account available bandwidth on the interface, you can configure up to 64 classes and control distribution among them, which is not the case with the flow-based WFQ. Flow-based WFQ applies weights to traffic to classify it into conversations and determines how much bandwidth each conversation is allowed, relative to other conversations. For flow-based WFQ, these weights, and traffic classification, are dependent on and limited to IP precedence levels.
• Finer granularity and scalability: CBWFQ allows you to define what constitutes a class based on criteria that exceed the confines of flow. You do not need to maintain traffic classification on a per-flow basis. Moreover, you can configure up to 64 discrete classes in a service policy.

The drawback is that voice traffic can still suffer from unacceptable delays if you use CBWFQ as the only queuing mechanism.

---

Content 4.5 Configuring CBWFQ and LLQ 4.5.4 Configuring and Monitoring CBWFQ The bandwidth command within the policy-map class configuration command is used to specify or modify the bandwidth allocated for a class belonging to a policy map. Figures and show the command syntax to use. All classes belonging to one policy map should use the same type of bandwidth guarantee, in kilobits per second, percentage of interface bandwidth, or percentage of available bandwidth. Configuring bandwidth in percentages is most useful when the underlying link bandwidth is unknown or the relative class bandwidth distributions are known. bandwidth {bandwidth | percent percent | remaining percent percent} bandwidth Parameters
Parameter Description bandwidth Amount of bandwidth, in kilobits per second, to be assigned to the class. percent percent Amount of guaranteed bandwidth, based on an absolute percentage of available bandwidth. The percentage can be a number from 1 to 100. (By default, only 75 percent can be reserved.) remaining percent percent Amount of guaranteed bandwidth, based on a relative percentage of available bandwidth. The percentage can be a number from 1 to 100. These restrictions apply to the bandwidth command:

• If the percent keyword is used, the sum of the class bandwidth percentages cannot exceed 100 percent.
• The amount of bandwidth configured should be large enough to accommodate Layer 2 overhead.
• A policy map can have all the class bandwidths specified in kilobits per second or in percentages but not a mix of both. However, the unit for the priority command in the priority class can be different from the bandwidth unit of the low-priority class.

The default queue limit of 64 packets can be changed using the queue-limit command. It is recommended that you not change the default value. The default class can be selected by specifying the class-default name of the class. The default class supports two types of queuing: a FIFO queue (default) or a flow-based WFQ system. Both types can be combined with WRED. A FIFO queue can also get a minimum bandwidth guarantee. Example: Configuration of FIFO Queuing for the Class-Default
This example shows the configuration of FIFO queuing within the default class. The default class is also guaranteed 1 Mbps of bandwidth, and the maximum queue size is limited to 40 packets. policy-map A
class A
bandwidth 1000
class class-default
bandwidth 1000
queue-limit 40 Example: Configuration of