Downloads |
Table Of Contents
Class-Based Weighted Fair Queueing
Related Features and Technologies
Configuring Class Policy in the Policy Map
Configuring Class Policy Using Tail Drop
Configuring Class Policy Using WRED Packet Drop
Configuring the Class-Default Class Policy
Attaching the Service Policy and Enabling CBWFQ
Modifying the Bandwidth for an Existing Policy Map Class
Modifying the Queue Limit for an Existing Policy Map Class
Configuring the Bandwidth Limiting Factor
Verifying Configuration of Policy Maps and Their Classes
Class Map Configuration Example
Policy Attachment to Interfaces Example
CBWFQ Using WRED Packet Drop Example
Display Service Policy Map Content Examples
All Classes for a Specified Service Policy Map
All Classes for All Service Policy Maps
Specified Class for a Service Policy Map
All Classes for All Service Policy Maps on a Specified Interface
random-detect exponential-weighting-constant
Class-Based Weighted Fair Queueing
Feature Overview
Class-based weighted fair queueing (CBWFQ) extends the standard WFQ functionality to provide support for user-defined traffic classes. 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.
Once a class has been defined according to its match criteria, you can assign it characteristics. To characterize a class, you assign it bandwidth, weight, and maximum packet limit. The bandwidth assigned to a class is the guaranteed bandwidth delivered to the class during congestion.
To characterize a class, you also specify the queue limit for that class, which is the maximum number of packets allowed to accumulate in the queue for the class. Packets belonging to a class are subject to the bandwidth and queue limits that characterize the class.
After a queue has reached its configured queue limit, enqueuing of additional packets to the class causes tail drop or packet drop to take effect, depending on how class policy is configured.
Tail drop is used for CBWFQ classes unless you explicitly configure policy for a class to use Weighted Random Early Detection (WRED) to drop packets as a means of avoiding congestion. Note that if you use WRED packet drop instead of tail drop for one or more classes comprising a policy map, you must ensure that WRED is not configured for the interface to which you attach that service policy.
If a default class is configured with the bandwidth policy-map class configuration command, all unclassified traffic is put into a single queue and given treatment according to the configured bandwidth. If a default class is configured with the fair-queue command, all unclassified traffic is flow classified and given best-effort treatment. If no default class is configured, then by default the traffic that does not match any of the configured classes is flow classified and given best-effort treatment. Once a packet is classified, all of the standard mechanisms that can be used to differentiate service among the classes apply.
Flow classification is standard WFQ treatment. That is, packets with the same source IP address, destination IP address, source Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) port, or destination TCP or UDP port are classified as belonging to the same flow. WFQ allocates an equal share of bandwidth to each flow. Flow-based WFQ is also called fair queueing because all flows are equally weighted.
For CBWFQ, which extends the standard WFQ fair queueing, the weight specified for the class becomes the weight of each packet that meets the match criteria of the class. Packets that arrive at the output interface are classified according to the match criteria filters you define, then each one is assigned the appropriate weight. The weight for a packet belonging to a specific class is derived from the bandwidth you assigned to the class when you configured it; in this sense the weight for a class is user-configurable.
After the weight for a packet is assigned, the packet is enqueued in the appropriate class queue. CBWFQ uses the weights assigned to the queued packets to ensure that the class queue is serviced fairly.
Configuring a class policy—thus, configuring CBWFQ—entails these three processes:
•
Defining traffic classes to specify the classification policy (class maps).
This process determines how many types of packets are to be differentiated from one another.
•
This process entails configuration of policies to be applied to packets belonging to one of the classes previously defined through a class map. For this process, you configure a policy map that specifies the policy for each traffic class.
•
This process requires that you associate an existing policy map, or service policy, with an interface to apply the particular set of policies for the map to that interface.
Benefits
Bandwidth Allocation
CBWFQ allows you to specify the exact amount of 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 flow-based WFQ.
Flow-based WFQ applies weights to traffic to classify it into conversations and determine 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 the seven IP Precedence levels.
Coarser Granularity and Scalability
CBWFQ allows you to define what constitutes a class based on criteria that exceed the confines of flow. CBWFQ allows you to use access control lists and protocols or input interface names to define how traffic will be classified, thereby providing coarser granularity. You need not maintain traffic classification on a flow basis. Moreover, you can configure up to 64 discrete classes in a service policy.
Restrictions
•
•
•
•
•
Related Features and Technologies
Resource Reservation Protocol (RSVP) can be used in conjunction with CBWFQ. When both RSVP and CBWFQ are configured for an interface, RSVP and CBWFQ act independently, exhibiting the same behavior that they would if each were running alone. RSVP continues to work as it does when CBWFQ is not present, even in regard to bandwidth availability assessment and allocation.
Related Documents
For related information on this feature, refer to the following documents:
•
•
CBWFQ supports standard and extended numbered access lists only. For information on creating access lists, see the appropriate Cisco IOS Release 12.0 configuration guides and command references.
Supported Platforms
•
•
•
•
•
•
•
•
•
•
•
Prerequisites
Weighted Fair Queueing
Attaching a service policy to an interface disables WFQ on that interface if WFQ is configured for the interface. For this reason, you should ensure that WFQ is not enabled on such an interface.
For information on WFQ, see the "Configuring Weighted Fair Queueing" chapter of the Cisco IOS Release 12.0 Quality of Service Solutions Configuration Guide.
Weighted Random Early Detection
Attaching a service policy containing classes configured to use WRED to an interface disables WRED on that interface. If any of the classes that you configure in a policy map use WRED for packet drop instead of tail drop, you must ensure that WRED is not configured on the interface to which you intend to attach that service policy.
Access Control Lists
You can specify a numbered access list as the match criterion for any class that you create. For this reason, you should know how to configure access lists.
Supported MIBs and RFCs
MIBs
None
RFCs
None
Configuration Tasks
Perform the following tasks to configure CBWFQ:
•
•
•
•
•
•
Defining Class Maps
To create a class map containing match criteria against which a packet is checked to determine if it belongs to a class—and to effectively create the class whose policy can be specified in one or more policy maps—use the first command in global configuration mode to specify the class map name, then one of the following commands in class map configuration mode:
Configuring Class Policy in the Policy Map
To configure a policy map and create class policies that make up the service policy, use the policy-map command to specify the policy map name, then use one or more of the following commands to configure policy for a standard class or the default class:
•
•
•
•
For each class that you define, you can use one or more of the listed commands to configure class policy. For example, you might specify bandwidth for one class and both bandwidth and queue limit for another class.
The default class of the policy map (commonly known as the class-default class) is the class to which traffic is directed if that traffic does not satisfy the match criteria of other classes whose policy is defined in the policy map.
You can configure class policies for as many classes as are defined on the router, up to the maximum of 64. However, the total amount of bandwidth allocated for all classes included in a policy map must not exceed 75 percent of the available bandwidth on the interface. The other 25 percent is used for control and routing traffic. (To override the 75 percent limitation, use the max-reserved bandwidth command.) If not all of the bandwidth is allocated, the remaining bandwidth is proportionally allocated among the classes, based on their configured bandwidth.
To configure class policies in a policy map, perform the tasks in the following sections:
•
•
•
Configuring Class Policy Using Tail Drop
To configure a policy map and create class policies that make up the service policy, use the first command in global configuration mode to specify the policy map name, then use the following commands in policy-map class configuration mode to configure policy for a standard class. To configure policy for the default class, see the section "Configuring the Class-Default Class Policy."
To configure policy for more than one class in the same policy map, repeat Step 2 through Step 4. Note that because this set of commands uses the queue-limit command, the policy map uses tail drop, not Weighted Random Early Detection (WRED) packet drop.
Configuring Class Policy Using WRED Packet Drop
To configure a policy map and create class policies comprising the service policy, use the first global configuration command to specify the policy map name, then use the following policy-map class configuration commands to configure policy for a standard class. To configure policy for the default class, see the section "Configuring the Class-Default Class Policy."
To configure policy for more than one class in the same policy map, repeat Step 2 through Step 5. Note that this set of commands uses WRED packet drop, not tail drop.
Note
Configuring the Class-Default Class Policy
The class-default class is used to classify traffic that does not fall into one of the defined classes. Once a packet is classified, all of the standard mechanisms that can be used to differentiate service among the classes apply. The class-default class was predefined when you created the policy map, but you must configure it. If no default class is configured, then by default the traffic that does not match any of the configured classes is flow classified and given best-effort treatment.
By default, the class-default class is defined as flow-based WFQ. However, configuring the default class with the bandwidth policy-map class configuration command disqualifies the default class as flow-based WFQ.
To configure a policy map and configure the class-default class to use tail drop, use the first global configuration command to specify the policy map name, then use the following policy-map class configuration commands to configure policy for the default class:
To configure a policy map and configure the class-default class to use WRED packet drop, use the first global configuration command to specify the policy map name, then use the following policy-map class configuration commands to configure policy for the default class:
Attaching the Service Policy and Enabling CBWFQ
To attach a service policy to the output interface and enable CBWFQ on the interface, use the following interface configuration command. When CBWFQ is enabled, all classes configured as part of the service policy map are installed in the fair queueing system.
Enables CBWFQ and attaches the specified service policy map to the output interface.
Modifying the Bandwidth for an Existing Policy Map Class
To change the amount of bandwidth allocated for an existing class, use the following commands beginning in global configuration mode:
Modifying the Queue Limit for an Existing Policy Map Class
To change the maximum number of packets that can accrue in a queue reserved for an existing class, use the following commands beginning in global configuration mode:
Configuring the Bandwidth Limiting Factor
To change the maximum reserved bandwidth allocated for CBWFQ, LLQ, and the IP RTP Priority feature, use the following command in interface configuration mode:
Changes the maximum configurable bandwidth for CBWFQ, LLQ, and IP RTP Priority. The default is 75 percent.
Deleting Classes
To delete one or more class maps from a service policy map, use the following commands beginning in global configuration mode:
Deleting Policy Maps
To delete a policy map, use the following command in global configuration mode:
Specifies the name of the policy map to be deleted.
Verifying Configuration of Policy Maps and Their Classes
To display the contents of a specific policy map, a specific class from a specific policy map, or all policy maps configured on an interface, use one of the following global configuration commands:
The counters displayed after issuing the show policy-map interface command are updated only if congestion is present on the interface.
Configuration Examples
This section provides the following configuration examples:
•
•
•
•
Class Map Configuration Example
In the following example, ACLs 101 and 102 are created. Next, two class maps are created and their match criteria are defined. For the first map class, called class1, the numbered ACL 101 is used as the match criterion. For the second map class, called class2, the numbered ACL 102 is used as the match criterion. Packets are checked against the contents of these ACLs to determine if they belong to the class.
Router(config)# access-list 101 permit udp host 10.10.10.10 host 10.10.10.20 range 16384 20000Router(config)# access-list 102 permit udp host 10.10.10.10 host 10.10.10.20 range 53000 56000Router(config)# class-map class1Router(config-cmap)# match access-group 101Router(config-cmap)# exitRouter(config-cmap)# class-map class2Router(config-cmap)# match access-group 102Router(config-cmap)# exitPolicy Creation Example
In the following example, a policy map called policy1 is defined to contain policy specification for the two classes—class1 and class2. The match criteria for these classes were defined in the previous section "Class Map Configuration Example."
For class1, the policy specifies the bandwidth allocation request and the maximum number of packets that the queue for this class can accumulate. For class2, the policy specifies only the bandwidth allocation request, so the default queue limit of 64 packets is assumed.
Router(config)# policy-map policy1Router(config-pmap)# class class1Router(config-pmap-c)# bandwidth 3000Router(config-pmap-c)# queue-limit 30Router(config-pmap-c)# exitRouter(config-pmap)# class class2Router(config-pmap-c)# bandwidth 2000Router(config-pmap-c)# exitPolicy Attachment to Interfaces Example
The following example shows how to attach an existing policy map. After you define a policy map, you can attach it to one or more interfaces to specify the service policy for those interfaces. Although you can assign the same policy map to multiple interfaces, each interface can have only one policy map attached at the input and one policy map attached at the output.
The policy map in this example was defined in the previous section, "Policy Creation Example."
Router(config)# interface e1/1Router(config-if)# service output policy1Router(config-if)# exitRouter(config)# interface fa1/0/0Router(config-if)# service output policy1Router(config-if)# exitCBWFQ Using WRED Packet Drop Example
In the following example, the class map class1is created and defined to use the input interface FastEthernet0/1 as a match criterion to determine if packets belong to the class. Next, the policy map policy1 is defined to contain policy specification for class1, which is configured for WRED packet drop.
Router(config)# class-map class1Router(config-cmap)# match input-interface FastEthernet0/1!Router(config)# policy-map policy1Router(config-pmap)# class class1Router(config-pmap-c)# bandwidth 1000Router(config-pmap-c)# random-detect!Router(config)# interface serial0/0Router(config-if)# service-policy output policy1!Display Service Policy Map Content Examples
The following examples show how to display the contents of service policy maps. There are four methods to display the contents:
•
•
•
•
All Classes for a Specified Service Policy Map
The following example displays the contents of the po1 service policy map:
Router# show policy-map po1Policy Map po1 Weighted Fair Queueing Class class1Bandwidth 937 (kbps) Max thresh 64 (packets) Class class2 Bandwidth 937 (kbps) Max thresh 64 (packets)Class class3 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class4 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class5 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class6Bandwidth 937 (kbps) Max thresh 64 (packets) Class class7 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class8 Bandwidth 937 (kbps) Max thresh 64 (packets)All Classes for All Service Policy Maps
The following example displays the contents of all policy maps on the router:
Router# show policy-mapPolicy Map poH1 Weighted Fair Queueing Class class1 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class2 Bandwidth 937 (kbps) Max thresh 64 (packets)Class class3 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class4 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class5 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class6 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class7 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class8 Bandwidth 937 (kbps) Max thresh 64 (packets)Policy Map policy2Weighted Fair QueueingClass class1 Bandwidth 300 (kbps) Max thresh 64 (packets) Class class2 Bandwidth 300 (kbps) Max thresh 64 (packets)Class class3 Bandwidth 300 (kbps) Max thresh 64 (packets) Class class4 Bandwidth 300 (kbps) Max thresh 64 (packets) Class class5 Bandwidth 300 (kbps) Max thresh 64 (packets) Class class6 Bandwidth 300 (kbps) Max thresh 64 (packets)Specified Class for a Service Policy Map
The following example displays configurations for the class called class7 that belongs to the policy map po1:
Router# show policy-map po1 class class7 Class class7 Bandwidth 937 (kbps) Max Thresh 64 (packets)All Classes for All Service Policy Maps on a Specified Interface
The following example displays configurations for classes on the output interface e1/1:
Router# show policy-map interface e1/1 Ethernet1/1 output : po1Weighted Fair QueueingClass class1Output Queue: Conversation 264Bandwidth 937 (kbps) Max Threshold 64 (packets)(total/discards/tail drops) 11548/0/0Class class2Output Queue: Conversation 265Bandwidth 937 (kbps) Max Threshold 64 (packets)(total/discards/tail drops) 11546/0/0Class class3Output Queue: Conversation 266Bandwidth 937 (kbps) Max Threshold 64 (packets)(total/discards/tail drops) 11546/0/0Class class4Output Queue: Conversation 267Bandwidth 937 (kbps) Max Threshold 64 (packets)(total/discards/tail drops) 11702/0/0Class class5Output Queue: Conversation 268Bandwidth 937 (kbps) Max Threshold 64 (packets)(total/discards/tail drops) 11701/0/0Class class6Output Queue: Conversation 269Bandwidth 937 (kbps) Max Threshold 64 (packets)(total/discards/tail drops) 11702/0/0Class class7Output Queue: Conversation 270Bandwidth 937 (kbps) Max Threshold 64 (packets)(total/discards/tail drops) 11857/0/0Class class8Output Queue: Conversation 271Bandwidth 937 (kbps) Max Threshold 64 (packets)(total/discards/tail drops) 11858/1/0Command Reference
This section documents new commands that configure the CBWFQ feature. All other commands used with this feature are documented in the Cisco IOS Release 12.0 command references.
•
bandwidth (policy-map class)
To specify or modify the bandwidth allocated for a class belonging to a policy map, use the bandwidth policy map configuration command. To remove the bandwidth specified for a class, use the no form of this command.
bandwidth bandwidth-kbps
no bandwidth bandwidth-kbpsSyntax Description
Defaults
No default behavior.
Command Modes
Policy map configuration
Command History
Usage Guidelines
You use the bandwidth command when you configure a policy in a map for a class defined by the class-map command. The bandwidth command specifies the bandwidth for traffic in that class. Class-based weighted fair queueing (CBWFQ) derives the weight for packets belonging to the class from the bandwidth allocated to the class. CBWFQ then uses the weight to ensure that the queue for the class is serviced fairly.
Note that when the policy map containing class policy configurations is attached to the interface to stipulate the service policy for that interface, available bandwidth is assessed. If a policy map cannot be attached to a particular interface because of insufficient interface bandwidth, then the policy is removed from all interfaces to which it was successfully attached.
Examples
The following example modifies the bandwidth for a class called acl22. The default class belongs to a service policy map called polmap6. The previous bandwidth for this class was 3000.
policy-map polmap6 class acl22 bandwidth 2000 queue-limit 30Related Commands
class (policy-map)
To specify the name of the class whose policy you want to create or change or to specify the default class (commonly known as the class-default class) before you configure its policy, use the class policy-map configuration command. To remove a class from the policy map, use the no form of this command.
class [class-name | class-default]
no class [class-name | class-default]Syntax Description
class-name
The name of the class for which you want to configure or modify policy.
class-default
Specifies the default class so that you can configure or modify its policy.
Defaults
No default behavior.
Command Modes
Policy-map configuration
Command History
Usage Guidelines
Enter the policy-map command to identify the policy map and enter policy map configuration mode before you use the class command. After you specify a policy map, you can configure policy for new classes or modify policy for any existing classes in that policy map.
The class name that you specify in the policy map ties the characteristics for that class—that is, its policy—to the class map and its match criteria configured using the class-map command.
When you configure policy for a class and specify its bandwidth and attach the policy map to an interface, class-based weighted fair queueing (CBWFQ) determines if the bandwidth requirement of the class can be satisfied. If so, CBWFQ creates the necessary internal data structures to maintain state for the class and allocates a queue for it.
When a class is removed, available bandwidth for the interface is incremented by the amount previously allocated to the class.
The maximum number of classes you can configure for a router—and, therefore, within a policy map—is 64.
You can define a class policy to use either tail drop (by using the queue-limit command) or Weighted Random Early Detection (WRED) packet drop (by using the random-detect command). You cannot use the queue-limit and random-detect commands in the same class policy, but they can be used in two class policies in the same policy map.
You can configure the bandwidth command when either the queue-limit or the random-detect command is configured in a class policy. The bandwidth command specifies the amount of bandwidth allocated for the class.
For the default class, you can configure the fair-queue (class-default) command. The fair-queue command specifies the number of dynamic queues for the default class. The fair-queue command can be used in the same class policy as either the queue-limit or random-detect command. It cannot be used with the bandwidth command.
Examples
The following example configures policy for a class named acl136 included in the policy map called policy1. Class acl136 has these characteristics: a minimum of 2000 kilobits per second (kbps) of bandwidth are expected to be delivered to this class in the event of congestion, and the queue reserved for this class can enqueue 40 packets before tail drop is enacted. Note that when the policy map containing this class is attached to the interface to stipulate the service policy for that interface, available bandwidth is assessed, taking into account all class policies and RSVP, if configured.
policy-map policy1class acl136bandwidth 2000queue-limit 40The following example configures policy for a class named int101 included in the policy map called policy8. Class int101 has these characteristics: a minimum of 3000 kbps of bandwidth are expected to be delivered to this class in the event of congestion, and a weight factor of 10 is used to calculate the average queue size. For congestion avoidance, WRED packet drop is used, not tail drop. Note that when the policy map containing this class is attached to the interface to stipulate the service policy for that interface, available bandwidth is assessed.
policy-map policy8class int101bandwidth 3000random-detect exponential-weighting-constant 10The following example configures policy for the class-default default class included in the policy map called policy1. The class-default default class has these characteristics: 10 dynamic queues for traffic that does not meet the match criteria of other classes whose policy is defined by the policy map policy1, and a maximum of 20 packets per queue before tail drop is enacted to handle additional enqueued packets.
policy-map policy1class class-defaultfair-queue 10queue-limit 20The following example configures policy for the class-default default class included in the policy map called policy8. The class-default default class has these characteristics: 20 dynamic queues for traffic that doesn't meet the match criteria of other classes whose policy is defined by the policy map policy8 and a weight factor of 20 is used to calculate the average queue size. For congestion avoidance, WRED packet drop is used, not tail drop.
policy-map policy8class class-defaultfair-queue 20random-detect exponential-weighting-constant 14Related Commands
class-map
To create a class map to be used for matching packets to the class whose name you specify, use the class-map global configuration command. To remove an existing class map from the router, use the no form of this command.
class-map class-map-name
no class-map class-map-nameSyntax Description
class-map-name
Name of the class for the class map. The class name is used for both the class map and to configure policy for the class in the policy map.
Defaults
No default behavior.
Command Modes
Global configuration
Command History
Usage Guidelines
Use this command to specify the name of the class for which you want to create or modify class map match criteria. Use of the class-map command enables class-map configuration mode in which you can enter one of the match commands to configure the match criteria for this class. Packets arriving at the output interface are checked against the match criteria configured for a class map to determine if the packet belongs to that class.
You can use one of the following commands in a class map:
•
•
•
•
If you specify more than one command in a class map, only the last command entered applies. The last command overrides the previously entered commands.
Examples
The following example specifies access101 as the name of a class, and it defines a class map for this class. The match access-group command is entered following the class-map command to configure the numbered access control list (ACL) 101 whose contents are to be used as match criteria for the class.
class-map access101match access-group 101Related Commands
fair-queue (class-default)
To specify the number of dynamic queues to be reserved for use by the class-default class as part of the default class policy, use the fair-queue policy map configuration command. To delete the configured number of hash queues from the class-default policy, use the no form of this command.
fair-queue number-of-dynamic-queues
no fair-queue number-of-dynamic-queuesSyntax Description
number-of-dynamic-queues
(Optional) A power of 2 number in the range of 16 to 4096 specifying the number of dynamic queues.
Defaults
The number of dynamic queues is derived from the interface or ATM permanent virtual circuit (PVC) bandwidth. See for the default number of dynamic queues that weighted fair queueing (WFQ) and class-based WFQ (CBWFQ) use when they are enabled on an interface. See for the default number of dynamic queues used when WFQ or CBWFQ is enabled on an ATM PVC.
