Table Of Contents
Configuring QoS on the Optical Services Modules
Understanding QoS on the OSMs
Configuring QoS on the OSMs
Enabling QoS Globally
Configuring PFC2 QoS to Mark DSCP or IP Precedence Values
Configuring Class-Based Traffic Shaping
Configuring Class-Based Weighted Fair Queueing
Configuring Low Latency Queueing
Configuring Weighted Random Early Detection
Configuring Hierarchical Traffic Shaping
Configuring Queue Limit
Configuring QoS on the Optical Services Modules
This chapter describes how to configure Quality of Service (QoS) on the Optical Services Modules (OSMs).
This chapter consists of these sections:
•
Understanding QoS on the OSMs
•
Configuring QoS on the OSMs
Understanding QoS on the OSMs
Layer 3 QoS is supported on all Layer 3 WAN ports on the OSMs. QoS on the Gigabit Ethernet LAN ports on the OSMs is provided by Policy Feature Card 2 (PFC2).
In systems running Cisco IOS Release 12.1(11b)E and later, the supervisor engine and MSFC, PFC2 marking of received traffic is supported on both the LAN and WAN ports on the OSMs. In releases prior to Cisco IOS Release 12.1(11b)E, PFC2 marking of received traffic is supported only on the Gigabit Ethernet LAN ports on the OSMs, not on the WAN ports. PFC2 marking of received traffic is not supported on the OSM WAN ports in systems running Catalyst software on the supervisor engine and Cisco IOS software on the MSFC.
In systems running Cisco IOS software on both the supervisor engine and the MSFC, QoS is configured using the Modular QoS Command Line Interface (MQC). In systems with Catalyst software running on the supervisor engine and Cisco IOS software on the MSFC, QoS is configured using the existing MQC and supervisor engine CLI commands. Refer to the Cisco IOS QoS Solutions publications listed below and the Cisco 7600 series router and Catalyst 6000 publications listed in the "Related Documentation" section on page x for detailed QoS configuration and command information.
The OSM WAN ports support the following QoS implementations:
•
Class-based traffic shaping
•
Class-based weighted fair queueing (CBWFQ)
•
Low latency queueing (LLQ)
•
Weighted Random Early Detection (WRED)
•
Hierarchical Shaping
For QoS configuration information and examples for the WAN OSM ports, see the "Configuring QoS on the OSMs" section.
For MPLS QoS configuration information and examples for the WAN OSM ports, see the "Configuring MPLS QoS" section on page 11-4.
For QoS configuration information and examples for the PFC2, see
http://www.cisco.com/univercd/cc/td/doc/product/core/cis7600/software/121e/swcg/qos.htm.
For general information on how to configure Cisco IOS QoS, refer to these Cisco IOS publications:
•
Cisco IOS Quality of Service Solutions Configuration Guide at this URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_c/index.htm
•
Cisco IOS Quality of Service Solutions Command Reference at this URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_r/index.htm
Configuring QoS on the OSMs
These sections describe configuring Qos on the OSMs:
•
Enabling QoS Globally
•
Configuring PFC2 QoS to Mark DSCP or IP Precedence Values
•
Configuring Class-Based Traffic Shaping
•
Configuring Class-Based Weighted Fair Queueing
•
Configuring Low Latency Queueing
•
Configuring Weighted Random Early Detection
•
Configuring Hierarchical Traffic Shaping
•
Configuring Queue Limit
For information on shaping features supported with Destination Sensitive Services (DSS), see "Configuring Destination Sensitive Services on the Optical Services Modules"
For information on shaping features supported with MPLS, see Chapter 11, "Configuring Multiprotocol Label Switching on the Optical Services Modules."
The PFC2 provides the following QoS implementations for the OSM WAN and Gigabit Ethernet LAN ports:
•
Policing
•
Marking
To configure PFC2 QoS on the Cisco 7600 series router, refer to these publications:
–
Cisco 7600 Series Cisco IOS Software Configuration Guide, 12.1E at this URL:
http://www.cisco.com/univercd/cc/td/doc/product/core/cis7600/software/121e/swcg/index.htm
–
Cisco 7600 Series Cisco IOS Command Reference, 12.1E at this URL:
http://www.cisco.com/univercd/cc/td/doc/product/core/cis7600/software/121e/cmdref/index.htm
To configure PFC2 QoS on the Catalyst 6000 family switch running Cisco IOS software on the
supervisor engine and on the MSFC, refer to these publications:
–
Catalyst 6500 Series Cisco IOS Software Configuration Guide, 12.1E at this URL:
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/12_1e/swconfig/index.htm
–
Catalyst 6500 Series Cisco IOS Command Reference, 12.1E at this URL:
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/12_1e/comref/index.htm
Enabling QoS Globally
Before you can configure QoS on the OSMs, you must enable the QoS functionality globally. To enable QoS globally, perform this task:
| |
Command
|
Purpose
|
Step 1
|
Router(config)# mls qos
|
Enable QoS on the switch. Use the no mls qos command to globally disable QoS.
|
Step 2
|
Router(config)# end
|
Exit configuration mode.
|
Step 3
|
Router# show mls qos
|
Verify the configuration.
|
This example shows how to enable QoS globally:
Router(config)# mls qos
Router(config)# end
Router#
This example shows how to verify the configuration:
Router# show mls qos
QoS is enabled globally
Microflow QoS is enabled globally
QoS global counters:
Total packets: 544393
IP shortcut packets: 1410
Packets dropped by policing: 0
IP packets with TOS changed by policing: 467
IP packets with COS changed by policing: 59998
Non-IP packets with COS changed by policing: 0
Router#
Configuring PFC2 QoS to Mark DSCP or IP Precedence Values
PFC2 QoS is supported on both the LAN and WAN ports as follows:
•
12.1(11b)E supports PFC2 QoS for the OC-3c/STM-1 POS, OC-12c/STM-4 POS OSMs, and GE WAN OSMs.
•
12.1(11b)EX supports PFC2 QoS for the OC-48c/STM-16 POS OSM.
•
12.1(12c)E1 supports PFC2 QoS for the OC-12c/STM-4 ATM OSM.
Beginning with 12.1(13)E1, all other OSMs have PFC2 QoS support in the first release that supports the OSM. The only exception is the OC-48c/STM-12 POS/DPT OSM which PFC2 QoS does not support.
Note
PFC2 QoS on the WAN ports is supported only in systems running Cisco IOS software on the supervisor engine and MSFC. PFC2 QoS is not supported on the OSM WAN ports in systems running Catalyst software on the supervisor engine and Cisco IOS software on the MSFC.
Note
If the received traffic has valid DSCP or IP precedence values, you configure only traffic shaping (see the "Configuring Class-Based Traffic Shaping" section).
If the traffic received through the LAN or WAN ports does not have DSCP or IP precedence values that are valid for traffic shaping or if you want to modify the received values, you can configure PFC QoS to mark the traffic, as described in these publications:
•
To configure PFC2 QoS on the Cisco 7600 series router running Cisco IOS software on the supervisor engine and MSFC, refer to these publications:
–
Cisco 7600 Series Router Software Configuration Guide at this URL:
http://www.cisco.com/univercd/cc/td/doc/product/core/cis7600/121_8aex/swcg/index.htm
–
Cisco 7600 Series Router Family Command Reference at this URL:
http://www.cisco.com/univercd/cc/td/doc/product/core/cis7600/121_8aex/cmdref/index.htm
•
To configure PFC2 QoS on the Catalyst 6000 running Cisco IOS software on the supervisor engine and MSFC, refer to these publications:
–
Catalyst 6000 Family IOS Software Configuration Guide at this URL:
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/121_8aex/swconfig/index.htm
–
Catalyst 6000 Family IOS Command Reference at this URL:
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/121_8aex/comref/index.htm
•
To configure PFC2 QoS on the Cisco 7600 series router running Catalyst software on the supervisor engine and Cisco IOS software on the MSFC, refer to these publications:
–
Cisco 7600 Optical Services Router Software Configuration Guide at this URL:
http://www.cisco.com/univercd/cc/td/doc/product/core/cis7600/rel_6_2/swcg/index.htm
–
Cisco 7600 Optical Services Router Family Command Reference at this URL:
http://www.cisco.com/univercd/cc/td/doc/product/core/cis7600/rel_6_2/cmdref/index.htm
•
To configure PFC2 QoS on the Catalyst 6000 family switch running Catalyst software on the supervisor engine and Cisco IOS software on the MSFC, refer to these publications:
–
Catalyst 6000 Family Software Configuration Guide at this URL:
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_6_2/confg_gd/index.htm
–
Catalyst 6000 Family Command Reference at this URL:
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_6_2/cmd_ref/index.htm
Configuring Class-Based Traffic Shaping
This section contains information for configuring class-based traffic shaping.
QoS on the OSMs supports both inbound and outbound traffic shaping. Shaping can be based on a packet's IP precedence or DSCP value. In systems running Cisco IOS Release 12.1(11b)E and later on the supervisor engine and MSFC, inbound shaping can be based on IP precedence or DSCP values in received traffic, and outbound shaping can be based either on IP precedence or DSCP values in received traffic or on PFC2 marking of the received traffic.
In systems running a Cisco IOS release prior to 12.1(11b)E on the supervisor engine and MSFC, if the input interface and the output interface are both WAN ports, inbound and outbound shaping can be based on IP precedence or DSCP values in received traffic only. If the input interface is a LAN port and the output interface is a WAN port, PFC2 can mark traffic before it is forwarded to the output interface, and outbound shaping can be based on modified IP precedence or DSCP values.
Note
PFC2 QoS is not supported on the OSM WAN ports in systems running Catalyst software on the supervisor engine and Cisco IOS software on the MSFC.
To configure class-based shaping, use the class-map commands in global configuration mode to specify the name of the class map and define the class matching criteria. Use the policy-map commands in global configuration mode to specify the name of the policy map, and use the shape average command to set the maximum rate to which traffic will be shaped for each class. Apply the policy map to the appropriate interface.
To configure traffic-shaping, perform this task in global configuration mode on the MSFC:
| |
Command
|
Purpose
|
Step 1
|
Router(config)# class-map [match-all | match-any]
class-name
|
Creates a class map to be used for matching packets to a class.
|
Step 2
|
Router(config-cmap)# match ip [dscp ip-dscp-value
| precedence ip-precedence-value]
|
Specifies a specific DSCP or IP precedence value as a match criterion. Match criteria for classes can be based on IP DSCP or IP precedence.
|
Step 3
|
Router(config)# policy-map policy_name
|
Creates or modifies a policy map that can be attached to one or more interfaces to specify a service policy.
|
Step 4
|
Router(config-pmap)# class class-name
|
Defines the classes you want the service policy to contain.
|
Step 5
|
Router(config-pmap-c)# shape average cir1 2
|
Shapes traffic to the indicated bit rate for the specified class.
|
Step 6
|
Router(config)# interface interface-name
|
Specifies the interface to which the policy map will be applied.
|
Step 7
|
Router(config-if)# service-policy [input | output
policy-name]
|
Attaches the specified policy map to the interface.
|
To configure a low-shape-rate queue and a high-shape-rate queue, perform this task:
Step 1
Create traffic classes containing the match criteria for the two classes by defining the class-maps as follows:
Router(config)# class-map match-all gold-data
Router(config-cmap)# match ip dscp 40
Router(config-cmap)# exit
Router(config)# class-map match-all bronze-data
Router(config-cmap)# match ip dscp 8
Router(config-cmap)# exit
Step 2
Define a service policy to contain policy specifications for the two classes—gold-data and bronze-data. The match criteria for these classes are defined in Step 1.
Router(config)# policy-map policy1
Router(config-pmap)# class gold-data
Router(config-pmap-c)# shape average 2000000
Router(config-pmap-c)# exit
Router(config-pmap)# class bronze-data
Router(config-pmap-c)# shape average 1000000
Router(config-pmap-c)# exit
Router(config-pmap)# class class-default
Router(config-pmap-c)# shape average 3000000
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)#
Note
The class-default class is predefined when you create the policy map. It 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. The shaping rate of the class-default class is by default 99 percent of the line rate but can be reconfigured to a different value.
Step 3
Apply the policy map to the appropriate interface. The following example attaches the policy as an output policy:
Router(config)# interface pos2/0
Router(config-if)# service-policy output policy1
Router(config-if)# exit
Step 4
Display the policy information for the interface:
Note
The OSMs do not use the Bc and Be values in the output below. The CLI generates these values.
Router# show policy interface pos2/0
pos2/0
service-policy output:policy1
class-map:gold-data (match-all)
323743 packets, 322448028 bytes
5 minute offered rate 5796000 bps, drop rate 4819000 bps
match:ip dscp 40
queue size 0, queue limit 128
packets output 30390, packet drops 293353
tail/random drops 293353, no buffer drops 0, other drops 0
shape:cir 1000000, Bc 4000, Be 4000
output bytes 30268440, shape rate 575000 bps
class-map:bronze-data (match-all)
302715 packets, 301504140 bytes
5 minute offered rate 5443000 bps, drop rate 3448000 bps
match:ip dscp 8
queue size 0, queue limit 128
packets output 56936, packet drops 245779
tail/random drops 245779, no buffer drops 0, other drops 0
shape:cir 2000000, Bc 8000, Be 8000
output bytes 56708256, shape rate 1051000 bps
class-map:class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 67804000 bps, drop rate 0 bps
match:any
0 packets, 0 bytes
5 minute rate 0 bps
queue size 0, queue limit 128
packets output 0, packet drops 0
tail/random drops 0, no buffer drops 0, other drops 0
shape:cir 3000000, Bc 12000, Be 12000
output bytes 0, shape rate 0 bps
As shown in Table 9-1, the shape average andpriority commands (at OC-3c and above) have a minimum rate that is 1/255 of the physical interface speed or the hierarchical shaped rate. For T3 and lower interface speeds, the minimum rate is 256 Kbps.The bandwidth command has a minumum rate that is one percent of the physical interface speed or the hierarchical shaped rate.The granularity for the shape average, bandwidth and priority commands is 1/255 of the physical interface speed or the hierarchical shaped rate. All configured rates are rounded to an integer multiple of the granularity.
Table 9-1 Minimum QoS Rates
Physical Interface Speed
|
Minimum for Priority Command (Kbps)
|
Minimum for Shape Command (bps)
|
T3 & below
|
256
|
256,000
|
OC3 POS
|
607
|
607,843
|
OC12 POS
|
2439
|
2,439,215
|
OC48 POS
|
9756
|
9,756,862
|
OC12 ATM
|
2349
|
2,349,176
|
GE WAN
|
NA
|
1,000,000
|
Enhanced GE WAN
|
3921
|
3,921,568
|
Hierarchical shaping
|
NA
|
1,000,000
|
Note
For information on hierarchical shaping policies, see Configuring Hierarchical Traffic Shaping.
Configuring Class-Based Weighted Fair Queueing
Note
Class-based weighted fair queueing (CBWFQ) is not supported on OSM WAN ports in systems running Catalyst software on the supervisor engine and Cisco IOS software on the MSFC.
Note
CBWFQ is not supported on the OSM-4GE-WAN-GBIC and 2-port OC-48c/STM-16 POS/DPT OSMs.
CBWFQ provides support for user-defined traffic classes. Packets belonging to a traffic class are subject to the guaranteed bandwidth allocation that characterizes the traffic class.
After a queue reaches its queue limit, enqueuing additional packets to the traffic class causes a tail drop. Tail drop is a means of dealing with congestion by dropping packets for a traffic class until the packet input rate is lower than the packet output rate and the queue is no longer full.
These sections describe CBWFQ:
•
Restrictions and Usage Guidelines
•
Configuration Tasks
•
Configuration Examples
Restrictions and Usage Guidelines
The CBWFQ restrictions and usage guidelines are as follows:
•
Using the bandwidth command on the default traffic class
All traffic that does not match a user-defined traffic class is classified as part of the default traffic class. The implicit bandwidth allocated to the default traffic class is equal to the link bandwidth minus the bandwidth allocated to the user-defined traffic classes (with the bandwidth command). At least 1 percent of the link bandwidth is always reserved for the default traffic class. You can alter the bandwidth allocated to the default traffic by using the bandwidth command with the default traffic class.
•
Using the match protocol command
Access control lists are not supported as match criteria for traffic classes.
Only the match ip precedence command, the match ip dscp command, and the match mpls experimental command are supported.
•
Bandwidth allocation
CBWFQ allows you to specify the amount of guaranteed bandwidth to be allocated for a traffic class. Taking into account available bandwidth on the interface, you can configure up to 64 traffic classes and control bandwidth allocation among them. If excess bandwidth is available, the excess bandwidth is shared in proportion to the defined bandwidth specified with the priority and bandwidth commands.
•
You can configure up to 64 discrete traffic classes in a service policy.
Configuration Tasks
CBWFQ is configured using user-defined traffic classes and service policies. Traffic classes and service policies are configured in the Modular QoS CLI.
For information on configuring the Modular QoS CLI, refer to the Modular Quality of Service Command Line Interface document at this URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120xe/120xe5/mqc/mcli.htm
These sections describe the configuration tasks for CBWFQ:
•
Configuring a Service Policy in the Policy Map
•
Modifying the Bandwidth for an Existing Service Policy
•
Displaying the CBWFQ Configuration and Statistics
Configuring a Service Policy in the Policy Map
CBWFQ is configured using the Modular QoS CLI. In the Modular QoS CLI, you must create a traffic class before you can configure a service policy. The following task table assumes that a traffic class has already been created. For information on configuring the Modular QoS CLI, including information on configuring traffic classes, refer to the Modular Quality of Service Command-Line Interface document at this URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120xe/120xe5/mqc/mcli.htm
In the following table, a service policy (specified with the policy-map command) containing a bandwidth specification is created.
To configure QoS features in a service policy, perform this task:
| |
Command
|
Purpose
|
Step 1
|
Router(config)# policy-map policy-map
|
Specifies the name of the service policy to be created or modified.
|
Step 2
|
Router(config-pmap)# class class-name
|
Specifies the name of the traffic class to be associated with the service policy.
|
Step 3
|
Router(config-pmap-c)# bandwidth bandwidth-kbps |
percent % of available bandwidth1 2
|
Specifies the percentage of available bandwidth in kilobits per second to be assigned to packets that meet the match criteria of the associated traffic class.
|
Modifying the Bandwidth for an Existing Service Policy
To modify the amount of bandwidth allocated for an existing traffic class, perform this task:
| |
Command
|
Purpose
|
Step 1
|
Router(config)# policy-map policy-map
|
Specifies the name of the service policy to be created or modified.
|
Step 2
|
Router(config-pmap)# class class-name
|
Specifies the name of a traffic class whose bandwidth you want to modify.
|
Step 3
|
Router(config-pmap-c)# bandwidth bandwidth-kbps |
percent % of available bandwidth
|
Specifies the percentage of available bandwidth in kilobits per second to be assigned to packets that meet the match criteria of the associated traffic class.
|
Displaying the CBWFQ Configuration and Statistics
To display the configuration of a service policy and its associated traffic classes, perform this task:
Note
On the OSMs that support CBWFQ, the granularity of the QoS parameter is the greater of 1/255 of link rate or the hierarchical shape rate. The show policy-map interface command will display the rounded QoS parameter.
Versions of the show policy-map interface command are listed in the table below.
Command
|
Purpose
|
Router# show policy-map
|
Displays all configured service policies.
|
Router# show policy-map policy-map-name
|
Displays the user-specified service policy.
|
Router# show policy-map interface
|
Displays statistics and configurations of all input and output policies, which are attached to an interface.
|
Router# show policy-map interface interface-spec
|
Displays configuration and statistics of the input and output policies attached to a particular interface.
|
Router# show policy-map interface interface-spec input
|
Displays configuration and statistics of the input policy attached to an interface.
|
Router# show policy-map interface interface-spec output
|
Displays configuration statistics of the output policy attached to an interface.
|
Router# show policy-map [interface [interface-spec
[input | output] [ class class-name]]]]
|
Displays the configuration and statistics for the class name configured in the policy.
|
This example shows the information displayed when you enter the show policy-map interface command:
Router1-PE# show policy-map interface
POS6/2
service-policy output:s
queue stats for all priority classes:
queue size 0, queue limit 32655
packets output 0, packet drops 0
tail/random drops 0, no buffer drops 0, other drops 0
class-map:dscp0 (match-all)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
match:ip dscp 0
queue size 0, queue limit 610
packets output 0, packet drops 0
tail/random drops 0, no buffer drops 0, other drops 0
shape:cir 2440000, Bc 9760, Be 9760
(shape parameter is rounded to 2439000 due to granularity)
output bytes 0, shape rate 0 bps
class-map:dscp1 (match-any)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
match:ip dscp 1
0 packets, 0 bytes
30 second rate 0 bps
queue size 0, queue limit 100000
packets output 0, packet drops 0
tail/random drops 0, no buffer drops 0, other drops 0
bandwidth:kbps 400000, weight 64
(bandwidth parameter is rounded to 397592 kbps due to granularity)
class-map:dscp2 (match-all)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
match:ip dscp 2
Priority:21% (130620 kbps), burst bytes 3265500, b/w exceed drops:0
(Priority parameter is rounded to 129278 kbps due to granularity)
class-map:class-default (match-any)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
match:any
0 packets, 0 bytes
30 second rate 0 bps
queue size 0, queue limit 11422
packets output 0, packet drops 0
tail/random drops 0, no buffer drops 0, other drops 0
Vlan101
service-policy input:s2
class-map:class-default (match-any)
166999 packets, 169002065 bytes
5 minute offered rate 2084000 bps, drop rate 0 bps
match:any
0 packets, 0 bytes
5 minute rate 0 bps
queue size 0, queue limit 0
packets input 166999, packet drops 0
tail/random drops 0, no buffer drops 0, other drops 0
shape:cir 200000000, Bc 800000, Be 800000
(shape parameter is rounded to 197576000 due to granularity)
input bytes 169002065, shape rate 2084000 bps
Router1-PE#
Configuration Examples
To configure traffic classes, create a service policy, and attach it to an interface, perform this task:
Step 1
Two traffic classes are created and their match criteria are defined. For the first traffic class, called class1, DSCP 30 is used as the match criterion. For the second traffic class, called class2, DSCP 10 is used as the match criterion. Packets are checked against the contents of these criteria to determine if they belong to the traffic class.
Router(config)# class-map class1
Router(config-cmap)# match ip dscp 30
Router(config-cmap)# exit
Router(config)# class-map class2
Router(config-cmap)# match ip dscp 10
Router(config-cmap)# exit
Step 2
A service policy called policy1 is defined to associate QoS features with the two traffic classes—class1 and class2. The match criteria for these traffic classes were defined in Step 1.
Router(config)# policy-map policy1
Router(config-pmap)# class class1
Router(config-pmap-c)# bandwidth 30000
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# class class2
Router(config-pmap-c)# bandwidth 20000
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)#
Step 3
After you define a service policy, you can attach it to one or more interfaces to specify a service policy for those interfaces. Although you can assign the same service policy to multiple interfaces, each interface can have only one service policy attached at the input and one policy map attached at the output at one time.
Router(config)# interface pos 2/0
Router(config-if)# service-policy output policy1
Router(config-if)# exit
In the following example, CBWFQ is configured on an OC-3 link. Class foo and class bar are guaranteed minimum bandwidth of 20 percent and 30 percent of link rate, respectively. The remaining bandwidth is equally distributed between class-default and class baz, who each get 25 percent of link rate. However, because class baz is shaped to receive a maximum of 15 Mbps (or 10 percent of the link rate), the bandwidth allocated to class baz is capped by this specified shape value, and class baz is guaranteed a minimum bandwidth of 15 Mbps.
class-map foo
match ip dscp 10
class-map bar
match ip dscp 20
class-map baz
match ip dscp 30
policy-map foobar
class foo
bandwidth percent 20%
class bar
bandwidth percent 30%
class baz
shape average 15000000
int pos2/0
service-policy output foobar
The following example for CBWFQ shows the recommended hierarchical policymap to use when configuring below the minimum allowable shaping rate on the OSMs.
policy-map parent-policy
class class-default
shape average parent-shape-rate
service-policy child-policy
Note
It is not recommended to use values below 1000000 bps for the parent-shape-rate parameter or values below 256 Kbps for the child-policy map parameter.
Configuring Low Latency Queueing
Note
Low latency queueing (LLQ) is not supported on OSM WAN ports in systems running Catalyst software on the supervisor engine and Cisco IOS software on the MSFC.
Note
LLQ is not supported on the OSM-4GE-WAN-GBIC and 2-port OC-48c/STM-16 POS/DPT OSMs.
LLQ lets you specify low-latency behavior for a traffic class. LLQ allows delay-sensitive data to be given preferential treatment.
The priority command allows delay-sensitive data to be given preferential treatment. LLQ enables use of a single priority queue within which individual classes of traffic can be placed. To enqueue class traffic to the priority queue, you configure the priority command for the class after you specify the named class within a policy map. Within a policy map, you can give one or more classes priority status.
When you specify the priority command for a traffic class, you specify a bandwidth argument in kilobits per second (kbps) or in % followed by the percent keyword. The bandwidth parameter configures the guaranteed bandwidth to the priority class under worst-case congestion scenarios. In Cisco IOS Release 12.1(19)E, if the priority class is over subscribed, it impacts the guaranteed bandwidth allocations for non-priority traffic. Typically, you would use the priority command in conjunction with an admission control mechanism that controls the amount of load offered to the priority class to avoid starvation of other classes.
Note
Because bandwidth for the priority class is specified as a parameter to the priority command, you cannot also configure the bandwidth command for a priority class.
Restrictions and Usage Guidelines
The LLQ restrictions and usage guidelines are as follows:
•
The priority command can be configured in multiple classes. If the traffic is not constant bit rate traffic, you must configure a large enough bandwidth parameter to absorb the data bursts.
•
The bytes parameter in the priority command is not supported.
Configuration Tasks
To give priority to a class within a policy map, perform this task in configuration mode:
| |
Command
|
Purpose
|
Step 1
|
Router(config)# policy-map policy-name
|
Specifies the name of the policy map to configure.
|
Step 2
|
Router(config-pmap)# class class-map-name
|
Specifies the name of a predefined class included in the service policy.
|
Step 3
|
Router(config-pmap-c)# priority kpbs [bytes]1 2
|
Reserves a priority queue for CBWFQ traffic.
|
To configure a priority queue (with a guaranteed allowed bandwidth of 50 Mbps) reserved for traffic with an IP DSCP value of 8, perform this task:
Step 1
Create traffic classes and specify match criteria by defining class-maps.
Router(config)# class-map gold-data
Router(config-cmap)# match-any ip dscp 40
Router(config-cmap)# exit
Router(config)# class-map match bar
Router(config-cmap)# match-any ip dscp 8
Router(config-cmap)# exit
Router(config)#
Step 2
Create the policy map. In the example, a priority queue for the class gold-data is reserved with a guaranteed allowed bandwidth of 50 Mbps, and a bandwidth of 20 Mbps is configured for the class bar. The service-policy command attaches the policy map to interface pos 4/1.
Router(config)# policy-map policy1
Router(config-pmap)# class gold-data
Router(config-pmap-c)# priority 50000
Router(config-pmap)# class bar
Router(config-pmap-c)# bandwidth 20000
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# interface pos 4/1
Router(config-if)# service-policy output policy1
Router(config-if)# exit
Configuring Weighted Random Early Detection
Weighted Random Early Detection (WRED) is a congestion avoidance mechanism that takes advantage of the congestion control mechanism of TCP. By selectively dropping packets based on IP precedence prior to periods of high congestion, WRED tells the packet source to decrease its transmission rate. Edge routers assign IP Precedences to packets as they enter the network. WRED is useful on any output interface where you expect to have congestion. However, WRED is usually used in the core routers of a network rather than at the edge. WRED uses these precedences to determine how it treats different types of traffic.
When a packet arrives, the average queue size is calculated and one of the following events occurs:
•
If the average is less than the minimum queue threshold, the arriving packet is queued.
•
If the average is between the minimum queue threshold for that type of traffic and the maximum threshold for the interface, the packet is either dropped or queued, depending on the packet drop probability for that type of traffic.
•
If the average queue size is greater than the maximum threshold, the packet is dropped.
Note
WRED is not supported on the OSM-4OC3-POS, OSM-8OC3-POS, OSM-2OC12-POS, OSM-4OC12-POS, OSM-1OC48-POS, OSM-2OC12-ATM, and OSM-4GE-WAN-GBIC OSMs.
For more details on the queue calculations and how WRED works, refer to the section "About WRED" in the chapter "Congestion Avoidance Overview" in the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.1 at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_c/index.htm
To configure WRED on an interface, perform the tasks in the following sections.
Configuration Tasks
To configure WRED, perform the following task:
| |
Command
|
Purpose
|
Step 1
|
Router(config)# policy-map policy-name
|
Specifies the name of the policy map to configure.
|
Step 2
|
Router(config-pmap)# class class-name
|
Specifies the name of a predefined class included in the service policy.
|
Step 3
|
Router(config-pmap-c)# random-detect
|
Enables WRED.
|
Step 4
|
Router(config)# interface interface-name
|
Specifies the interface to which the policy map will be applied.
|
Step 5
|
Router(config-if)# service-policy [input | output
policy-name]
|
Attaches the specified policy map to the interface.
|
Router(config)# policy-map wred_test
Router(config-pmap)# class class-default
Router(config-pmap-c)# random-detect
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# interface pos3/2
Router(config-if)# service-policy output wred_test
Router(config-if)# end
Router# show policy-map interface pos3/2
POS3/2
service-policy output:wred_test
class-map:class-default (match-any)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
match:any
0 packets, 0 bytes
30 second rate 0 bps
queue size 0, queue limit 155500
packets output 0, packet drops 0
tail/random drops 0, no buffer drops 0, other drops 0
random-detect:
Exp-weight-constant:9 (1/512)
Mean queue depth:0
Class Random Tail Minimum Maximum Mark Output
drop drop threshold threshold probability packets
0 0 0 0 0 1/10 0
1 0 0 0 0 1/10 0
2 0 0 0 0 1/10 0
3 0 0 0 0 1/10 0
4 0 0 0 0 1/10 0
5 0 0 0 0 1/10 0
6 0 0 0 0 1/10 0
7 0 0 0 0 1/10 0
Configuring Hierarchical Traffic Shaping
Modular QoS CLI allows hierarchical traffic classes (nested traffic classes, which are also called nested class maps) to be configured as a single traffic class. A hierarchical traffic policy contains a child and a parent policy. The child policy is the previously defined traffic policy that is being associated with the new traffic policy through the use of the service-policy command. The new traffic policy using the preexisting traffic policy is the parent policy.
The current implementation of hierarchical traffic shaping on the Cisco 7600 series Interent Router supports only one traffic policy level within a single traffic policy.
Hierarchical traffic shaping is supported as follows:
•
For egress traffic on the WAN ports on the OSM-2+4GE-WAN+ OSMs
•
On the WAN ports on all other OSMs for the following types of traffic:
–
Egress traffic
–
Frame Relay encapsulation
Note
If a WAN interface on an OSM already has a hierarchical MQC policy map attached, do not attempt to convert it to a flat policy map. Conversely, do not attempt to convert a flat policy map to a hierarchical MQC policy map.
Configuring Task
To configure hiearchical traffic shaping, perform the following task:
| |
Command
|
Purpose
|
Step 1
|
Router(config-pmap)# class-map 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.
|
Step 2
|
Router(config-cmap)# match ip dscp ip-dscp-value
|
Specifies the exact value from 0 to 63 used to identify an IP DSCP value.
|
Step 3
|
Router(config)# policy-map policy-name
|
Specifies the name of the policy map to configure.
|
Step 4
|
Router(config-pmap)# class class-name
|
Specifies the name of a predefined class included in the service policy.
|
Step 5
|
Router(config-pmap-c)# priority percent percentage
|
Gives priority to a class of traffic belonging to the policy map.
|
Step 6
|
Router(config)# policy-map policy-name
|
Specifies the name of the policy map to configure.
|
Step 7
|
Router(config-pmap)# class class-name
|
Specifies the name of a predefined class included in the service policy.
|
Step 8
|
Router(config-pmap-c)# shape average mean-rate1 2
|
Shapes traffic to the indicated bit rate for the specified class.
|
Step 9
|
Router(config-pmap-c)# service-policy policy-name
|
Links the parent/child policy and class.
|
Step 10
|
Router(config)# interface interface-name
|
Specifies the interface to which the policy map will be applied.
|
Step 11
|
Router(config-if)# service-policy [input | output
policy-name]
|
Attaches the specified policy map to the interface.
|
This example shows a nested traffic policy configuration where traffic matching the class called "voice" will be guaranteed 3200 Kbps, or 10% of the parent_policy's shape average:
Router(config)# class-map match-all voice
Router(config-cmap)# match ip dscp 5
Router(config-cmap)# exit
Router(config)# policy-map child_policy
Router(config-pmap)# class voice
Router(config-pmap-c)# priority percent 10
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# policy-map parent_policy
Router(config-pmap)# class class-default
Router(config-pmap-c)# shape average 32000000 128000 128000
Router(config-pmap-c)# service-policy child_policy
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# interface Serial6/1:1.1 point-to-point
Router(config-subif)# service-policy parent_policy
Configuring Queue Limit
For the class-based traffic shaping and CBWFQ features, you can specify or modify the maximum number of packets the queue can hold for a class policy configured in a policy map using the queue-limit command from policy-map class configuration mode.
queue-limit number-of-packets
[no] queue-limit number-of-packets
Where number-of-packets is 18, 25, 42, 128, 256, 512, 1024, 2000, 4000, 8000, 16000, or 32000, and specifies the maximum number of packets that the queue for this class can accumulate.
Use the no form of the command to remove the queue packet limit from a class.
In the following example, a policy map called policy11 is configured to contain policy for a class called cls203, and the queue limit is set to 42 packets.
Router(config)# policy-map policy11
Router(config-pmap)# class cls203
Router(config-pmap)# queue-limit 42
Unsupported QoS Features
Adaptive traffic shaping using the MQC shape adaptive command is not supported by any OSM.
Unsupported Frame Relay-Specific QoS Features
The following Frame Relay specific QoS features are not supported:
•
Adaptive traffic shaping
•
Adaptive Policing
•
DLCI priority levels
•
DE bit support