Configuring QoS on the OSMs

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.

1 Only supportrd parameters are shown.

2 See Table 9-1.

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.

1 Only the parameters shown are supported.

2 See Table 9-1.

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.

1 Only the parameters shown are supported.

2 See Table 9-1.

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.

1 The Bc and Be command arguments and the shape peak command are not supported.

2 Starting in Cisco IOS Release 12.1(11b)E, the minimum accepted value for the mean rate is 1 MB.

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