Cisco 7600-ES20 Ethernet Line Card Configuration Guide

Configuring QoS on the Cisco 7600 Series Ethernet Services 20G Line Card

This chapter provides information about configuring Quality of Service (QoS) on the Cisco 7600 Series Ethernet Services 20G (ES20) line card on the Cisco 7600 series router.

Before referring to any other QoS documentation for the platform or in the Cisco IOS software, use this chapter to determine ES20 line card-specific QoS feature support and configuration guidelines.

For additional details about QoS concepts and features in Cisco IOS Release 12.2, you can refer to the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2SR, at:

http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/12_2sr/qos_12_2sr_book.html

This chapter includes the following sections:

•QoS Functions in the Cisco 7600 Series Ethernet Services 20G Line Card

•Configuring QoS Features Using MQC

•Dual Rate Three Color (2R3C) Ingress Policer on Service Instances

•EVCS QoS Support

•Configuring Qos Over an EVC Group

•Configuring Policing

•Configuring Marking

•Configuring Shaping

•Configuring Shaping on the ES20 Main Interface

•Configuring PFC QoS on a Cisco 7600 Series Ethernet Services 20G Line Card

•Configuring Hierarchical QoS

•Configuring Bandwidth Remaining Ratio (BRR) - Utilizing Unused Bandwidth Support

•EVC Configuration Examples

•Troubleshooting QoS Features in a ES20 Line Card

QoS Functions in the Cisco 7600 Series Ethernet Services 20G Line Card

Note Main interface refers to the maininterface and switchport unless specified otherwise.
If the supported feature is not mentioned, then the feature is not supported in the particular interface.

The following sections describe ingress and egress QoS functions.

Ingress QoS Functions in a Cisco 7600 Series Ethernet Services 20G Line Card

The following paragraphs describe ingress QoS support on the ES20 line card.

Ingress Trust

Trust is a port assignment instructing the port to trust (leave) existing priorities as they are on incoming frames or to rewrite the priorities back to zero.

A packet can arrive at an interface with a priority value already present in the packets header. The router needs to determine if the priority setting was set by a valid application or network device according to pre defined rules or if it was set by a user hoping to get better service.

The router has to decide whether to honor the priority value or change it to another value. How the router makes this determination is by using the port "trust" setting.

The ES20 line card always trusts Differentiated Services Code Point (DSCP) by default. Maininterfaces and subinterfaces use the ingress trust functionality.

Ingress Queue Scheduling

The ES20 line card does not support ingress queue scheduling.

Ingress Classification

After a frame is queued, the frame is passed on for classification. Classification entails using a traffic descriptor to categorize a packet within a specific group to define that packet and make it accessible for QoS handling on the network. Using packet classification, you can partition network traffic into multiple priority levels or classes of service.

Traffic is classified to determine whether it should be:

•Marked for further processing.

•Policed to rate limit specific traffic types.

The ES20 line card supports ingress classification. For information on configuring classification, see "Configuring Classification" section.

Ingress Policing

Policing provides a means to limit the amount of bandwidth that traffic traveling through a given port, or a collection of ports in a VLAN, can use. Policing works by defining an amount of data that the router is willing to send or receive in kilobytes per second.

When policing is configured, it limits the flow of data through the router by dropping or marking down the QoS value traffic that is out-of-profiles. Policing allows the router to limit the rate of specific types to a level lower than what they might get otherwise based only the interface bandwidth.

The ES20 line card supports ingress policing. For information on configuring policing, see "Configuring Policing" section.

Ingress Marking

After it has been classified, traffic can be marked. Marking is a way to selectively modify the classification bits in a packet to identify traffic within the network. Other interfaces can then match traffic based on the markings.

The ES20 line card supports ingress marking. For information on configuring marking, see "Configuring Marking" section.

Ingress Shaping

The ES20 line card does not support ingress shaping.

Egress QoS Functions in a Cisco 7600 Series Ethernet Services 20G Line Card

The following sections describe QoS functions on the ES20 line card egress ports.

Egress Classification

Classification entails using a traffic descriptor to categorize a packet within a specific group to define that packet and make it accessible for QoS handling on the network. Using packet classification, you can partition network traffic into multiple priority levels or classes of service.

Traffic is classified to determine whether it should be:

•Marked for further processing.

•Queued to rate limit specific traffic types.

The ES20 line card supports egress classification. For information on configuring classification, see "Configuring Classification" section.

Egress Policing

The ES20 line card supports egress port policing only when paired with the priority command.

Egress Marking

After traffic has been classified, the router can mark it. You use marking to selectively modify the classification bits in the packet to differentiate packets based on the designated markings.

The ES20 line card supports egress port marking on service instances, maininterfaces, and subinterfaces. For information on configuring marking, see "Configuring Marking" section.

Egress Shaping

Traffic shaping allows you to control the traffic going out an interface in order to match its flow to the speed of the remote target interface and to ensure that the traffic conforms to policies contracted for it. You can use shaping to meet downstream requirements, thereby eliminating bottlenecks in topologies with data-rate mismatches.

The ES20 line card supports shaping on egress port, maininterfaces, subinterfaces, and service instances. For information on configuring shaping, see "Configuring Shaping" section.

Egress Queue Scheduling

The egress line card uses congestion avoidance to help prevent congestion and keep its buffers from overflowing.

The ES20 line card supports Class-based Weighted Fair Queuing (CBWFQ), Low Latency Queueing (LLQ), and Weighted Random Early Detection (WRED).

Restrictions

Follow these restrctions and guidelines when you configure QoS in a ES20 line card:

•A policy-map output on a route processor is linecard specific because all the policy-map statistics are exported from the linecard to the route processor. In a ES20 linecard egress scenario, an active Ternary Content Addressable Memory (TCAM) entry requires a queueing ASIC to relay the packet out of an egress interface. This is because the queue id is mapped to an egress port number programmed in a queuing ASIC through which packets are relayed out. However, a packet is dropped if a valid queue id is not allocated, and the TCAM entry is active. Hence classification happens only for classes with a valid queuing action in an egress direction.

•You can configure a minimum bandwidth of 128kbps when using the bandwidth command.

Configuring QoS Features Using MQC

The Modular QoS CLI (MQC) is a CLI structure that allows users to create traffic policies and attach these policies to interfaces. A traffic policy contains a traffic class and one or more QoS features. A traffic class is used to select traffic, while the QoS features in the traffic policy determine how to treat the classified traffic.

To configure QoS features using the Modular QoS CLI on the ES20 line card, complete the following basic steps:

Step 1 Define a traffic class using the class-map command.

Step 2 Create a traffic policy by associating the traffic class with one or more QoS features (using the policy-map command).

Step 3 Attach the traffic policy to the interface using the service-policy command.

For a complete discussion about MQC, refer to the "Modular Quality of Service Command-Line Interface" section of the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2 publication at:

http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/12_2sr/qos_12_2sr_book.html

EVCS QoS Support

Ethernet Virtual Connection Services (EVCS) uses the concepts of service instances and EVCs (Ethernet virtual circuits). A service instance is the instantiation of an EVC on a given port on a given router. An EVC is an end-to-end representation of a single instance of a Layer 2 service being offered by a provider to a customer. It embodies the different parameters on which the service is being offered.

Mapping Between Bay and Ports

The following table maps the bay and port information in a ES20 line card:

Table 3-1 Mapping Between Bay and Ports

Restrictions and Usage Guidelines

When configuring QoS with EVCs on the ES20 line card, follow these restrictions and usage guidelines:

•Service instances use MQC.

•QoS supports 16 000 service instances per line card and 8000 per bay.

•HQoS supports 990 policy-maps per bay.

•Configuring EVcs or subinterfaces is not permissible with QoS on the main interface.

•Ingress shaping is not supported.

•For egress QoS, both hierarchical and flat policy-maps are supported.

•Before creating a service instance or a sub interface, remove any policy-maps on the maininterface.

•Only classes defined with match vlan and vlan-inner and class-default can exist in a parent policy.

•As service instance configurations change, you must remove and reapply the policy because the policy-map configuration may no longer be valid. However, changes on the main interface related to QoS are not cascaded to EVC QoS.

•Because the policy-map does not work to its optimum capacity due to 1% of the port bandwidth being reserved for control packets, ensure that the policy-map is configured to use only 99% of the port bandwidth.

•EVCs with default encapsulation support policy-maps similar to other supported EVCs.

•Layer 3 classification, Ingress and Egress Marking combinations are supported for the ES20 line card on the Cisco 7600 series router. For more information on the supported combinations, see "Layer 3 Ingress Marking Scenarios On a Service Instance".

EVC QoS support is as follows:

•For EVC QoS, classification is based on the following filters, which can be combined:

–Inner VLAN tag

–Outer VLAN tag

–CoS

–CoS Inner

–Precedence

–Dscp

–Mpls exp (for egress classification only)

•For EVC QoS, marking is based on:

–Copy or rewrite inner CoS

–Copy or rewrite outer CoS

–Copy inner to outer CoS or vice versa

–Copy or rewrite on EXP

–Rewrite precedence

–Rewrite dscp

•For EVC QoS, actions supported include:

–Marking, bandwidth, WRED aggregate, shape average, queue-limit, priority with police

For EVC QoS configuration examples, see "EVC Configuration Examples" section.

Restrictions and User Guidelines for EVC Port Channel

When configuring QoS on a EVC port channel, follow these restrictions and user guidelines:

•In a EVC port channel, the maximum number of restricted queues is 8000 per bay. Ensure that you do not exceed the 8000 limitation.

•Maximum number of member links that can be configured on a line card is 8.

•On a port channel, each EVC is replicated by the number of member links. Ensure that the total number of EVCs after replication per bay does not exceed 8000.

•EVC port channels do not support percentage values of bandwidth and policing.

•Egress IP Precedence and DSCP marking are supported for EVCs or for EVCs with port channels.

Configuring Qos Over an EVC Group

A Service group is a logical interface that helps you to group EVCs, and apply features on the aggregate logical entity. An EVC group helps you to configure a single QoS policy-map on different EVCs. You can globally configure service groups, and associate the group IDs with each members to add new members. For example, you can configure the group ID within each EVC to associate EVCs with a particular service group.

Each EVC belongs to only one service group at a time and the group must exist before any members (EVCs) can join the group. In addition to the policy on the service group of which it is a member, you can also apply a policy on each EVC. A policy map is rejected if you simultaneously apply the policy-map on a group and an EVC in the same direction.

In 12.2(33)SRE release, QoS is supported on the service groups, and you can add EVCs or EVCs over PC as members of a service-group. You can use this feature to apply a QoS policy (both in ingress and egress) within service groups having EVCs or EVCs over PortChannel as its members.

Restrictions and Usage Guidelines

When configuring Qos over a EVC group, follow these restrictions and usage guidelines:

•This feature is supported only on service instances.

•Each service instance can belong to only one service group.

•In EVCs, all members of a service group must reside within the same interface.

•In EVCs within a port-channel, all members of a service group must reside within the port-channel.

•You cannot individually assign a member of a service group to a load-balance link of a port-channel. You should assign the whole group to the link.

• An EVC group cannot have members that are assigned to multiple load-balance links of a port-channel.

• Ensure that you have configured a EVC group before adding a service instance to it.

• Service Group membership is extended only to EVCs (service instances).

•You can apply a Qos Policy on groups or individual EVCs that are part of groups.

•Ingress 1R2C policing is not supported on EVC groups.

•You cannot simultaneously apply QoS on a EVC and its group in the same direction.

•Service group supports hierarchical Qos and flat ( class-default ) policy-maps.

• All QoS parameters ( Shape, Set, Bandwidth, BRR, Police (2r3c ) , Set, Wred) within a class, applicable to an EVC, are also supported on a group.

• 2r3c policer is supported in a ingress policy-map on a group.

Table 3-2 lists the scalability values of EVC groups:

SUMMARY STEPS

1. enable

2. configure terminal

3. service-group ID number

4. service-policy [input| output]

5. sh service-group ID number

6. interface GigabitEthernet slot/bay/port

7. service instance name

8. group ID number

9. sh service-group ID number

10. end

DETAILED STEPS

Router> enable

Example

The following example shows the creation of a service group and attaching the policy map to the egress:

Router(config)# service-g

Router(config)# service-group ?

  <1-32768>  Service Group ID Number

Router(config)# service-group 1000

Router(config-service-group)#ser

Router(config-service-group)# service-policy ?

input   Attach a policy-map to ingress of a service group

output  Attach a policy-map to egress of a service group

Router(config-service-group)# service-policy output <policy-map name>

The following example shows the creation of a service instance and adding a service group to the service instance:

Router(config)# int gi 2/0/0

Router(config-if)# ser

Router(config-if)# service in

Router(config-if)# service instance 1 eth

Router(config-if-srv)# en

Router(config-if-srv)# encapsulation d

Router(config-if-srv)# encapsulation do 

Router(config-if-srv)# encapsulation dot1q 10

Router(config-if-srv)#?

Ethernet EFP configuration commands:

  bridge-domain   Bridge-domain

  default         Set a command to its defaults

  description     Service instance specific description

  encapsulation   Configure ethernet frame match criteria

  errdisable      Configure error disable

  ethernet        Configure ether lmi parameters

  exit            Exit from ETHER EFP configuration mode

  group           Join a service group

  ip              ip

  l2protocol      Configure l2 control protocol processing

  mac             Commands for MAC Address-based features

  no              Negate a command or set its defaults

  rewrite         Configure ethernet rewrite criteria

  service-policy  Attach a policy-map to an EFP 

  shutdown        Take the Service Instance out of Service

  snmp            Modify SNMP service instance parameters

  xconnect        Xconnect commands

Router(config-if-srv)# gr

Router(config-if-srv)# group 1000

Router(config-if-srv)#

Router#

Execute the sh run service-group 1 command to display the input and output policymaps applied on a service group:

Router#

Router#

Router#sh ser

Router# sh service

*Apr 24 01:17:21.904: %SYS-5-CONFIG_I: Configured from console by console

Router#sh service-g

Router#sh service-group 1000

Service Group 1000:

  Number of members:                      1

  State:                                  Up

  Interface:                              GigabitEthernet2/0/0

Number of members: 1

Dual Rate Three Color (2R3C) Ingress Policer on Service Instances

Dual Rate Three Color Policing (2R3C), elaborated in RFC 2698, lists the following characteristics of the data packets:

•Metered and colored as green, yellow or red.

•Marked for transmission drop or QoS marking.

•Replenished in token buffer mode.

Based on the new feature implementation in ES20 line cards, the policy meter operates in a color blind mode in flat policy-maps. You can configure dual rates policing using the conform, exceed, and violate actions in the ingress service instances on an ES20 line card. For more information on Dual rate Three Color policers, refer to the section "QoS: Color-Aware Policer" at the following URL:

http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/12s_cap.html

You can configure the policer in any classes supported for marking. You can use the match vlan, match vlan inner, match QoS, or match CoS inner filters to configure these classes. For more information on Policing in ES20 line cards, refer the section "Configuring Policing" section.

Restrictions and Usage Guidelines

When configuring 2R3C ingress service policy on a ES 20 line card, follow these restrictions and usage guidelines:

•You cannot configure 2R3C policer with the following characteristics:

–A single rate two color (1R2C) policer in the same policy-map.

–Packets marked for transmission drop.

–Simultaneous execution of the set command operations in the same class.

•Maximum of 3000 policers are supported on an ES20 line card (for a total of 6000 per line card).

•If a 1R2C policer is configured, and actions other than conform, transmit, exceed, or drop are configured, or 1R2C is not as class-default, the microprocessor performs policing.

•If you do not configure the values for cir and pir, the CLI commands are rejected.

•2R3C policer works with user-class and class-default values.

•2R3C policer does not support set- cos command within the policer. set- cos command are part of policer action such as set-cos transmit.

•To set the DBUS COS, you can use set-cos action command instead of the set mpls exp .

•You cannot configure 2R3C and 1R2C policer within the same policy-map.

•You can configure a minimum policer value of 128 Kbps.

•A hierarchical qos policymap in ingress should comprise of police at parent policy and marking cos in child policy. Configuration of police in both parent and child policy maps is not supported.

•You must not change the child-policy dynamically when the parent policy is still attached to the interface.

•Flat 2R3C policer is supported.

•conform, exceed, and violate commands are used to mark all the policing actions.

•The following policing actions are supported in an ES20 line card:

– drop.

– set-cos-inner-transmit (sets the outer tag Cos).

–set-cos-transmit (sets dbus cos no tag Cos).

–transmit

–set-prec-transmit

–set dscp-transmit

–set mpls-exp-imposition-transmit

•The following default policer actions are supported in an ES20 line card:

–transmit for conform.

–drop for exceed and violate.

•You can classify cos-inner, vlan, and vlan-inner policers.

•Ingress classification and policing is performed before an EVC rewrite.

Note Effective from 12.2(33)SRD release onwards, the service-policy configuration supports policy conform burst (bc) size setting on an ES20 interface. Releases earlier than 12.2(33)SRD, do not support setting policy bc size.

SUMMARY STEPS

1. enable

2. configure terminal

3. class-map match-any class name

4. match cos name

5. match [ip] precedence precedence-value

6. policy-map policer

7. class class name

8. police cir bc pir be

9. conform-action [ set-cos-inner-transmit | set-cos-transmit]

10. exceed-action [ set-cos-inner-transmit | set-cos-transmit ]

11. violate-action [ transmit | drop ]

12. interface GigabitEthernet slot/bay/port

13. service instance ethernet interface

14. service policy input policy-map-name

15. end

DETAILED STEPS

Router> enable

Example

The following example shows the 2R3C configuration in a class and policy-map:

policy-map test

class cos2

police 1000000 pir 2000000 conform-action set-cos-transmit 3 exceed-action 
set-cos-transmit 1 violate-action drop

The service policy should be attached to the service instance of the interface as follows:

interface gig2/0/0

service instance 1 eth

---- EVC configurations ---

service-policy input test

Ingress Policing on EVC Port Channel

The EVC port channel supports 1R0C and 2R3C policers. The classifications and police actions supported on regular EVCs are supported on an EVC port channel.

Restrictions and Usage Guidelines

When configuring ingress policing on EVC port channel, follow these restrictions and guidelines:

•1R0C is supported only in class-default (classification), and not for service groups.

•1R0C supports these policing actions on packets:

–transmit for conformed packets

–drop for exceed packets

•1R0C does not support set action for conformed and exceeded packets.

•1R0C supports flat and HQOS policy maps. HQOS policy maps support policing actions only for the parent class class-default and marking action in child classes.

•2R3C is supported in these user class and class-default classification:

–match precedence

–match dscp

–match vlan-outer

–match vlan-inner

–match cos-outer

–match cos-inner

•2R3C supports the following policing actions:

–Conformed packets: transmit, set-cos-transmit, set-cos-inner-transmit, set-prec-transmit, set-dscp-transmit, set-exp-transmit

–Exceed packets: transmit, drop, set-cos-transmit, set-cos-inner-transmit, set-prec-transmit, set-dscp-transmit, set-exp-transmit

–Violate packets: transmit, drop, set-prec-transmit, set-dscp-transmit, set-exp-transmit

•2R3C is supported for service groups.

•2R3C supports only flat policy-maps.

•Each NPU complex supports a maximum of 3000 2R3C policers.

•The maximum value for cir is limited to 990 Mbps for a 1 Gb port and 9.9 Gbps for a 10 Gb port. For 2R3C policer, the same restriction applies to pir.

Configuring Ingress Policing on EVC Port Channel

Configuring policing on EVC port channel is same as that for configuring policing on a regular EVC. For configuration, refer the section "Configuring Policing" section.

Configuring Classification

Use the QoS classification features to select your network traffic and categorize it into classes for further QoS processing based on matching certain criteria. The default class, named "class-default," is the class to which traffic is directed for any traffic that does not match any of the selection criteria in the configured class-maps.

Restrictions and Usage Guidelines

When configuring traffic classes on an ES20 line card, follow these restrictions and usage guidelines:

•You can define up to 256 unique classes in a policy-map including class-default .

•A single class-map can contain up to 8 different match command statements.

•The ES20 line card does not support combining matches on QoS group, CoS, or input VLAN with other types of matching criteria (for example, access control lists [ACLs]) in the same class or policy-map. You cannot configure a class c1 with match CoS and class c2 with match ip prec in the same policy-map at same level.

•When configuring hierarchical QoS on the ES20 line card, if you configure matching on an input VLAN in a parent policy, then only matching on a QoS group is supported in the child policy.

•For ingress marking on EVCs, service instances support the match vlan command, match vlan-inner command, match cos command, match precedence, match dscp and match cos-inner commands.

•For egress marking on EVCs, service instances support the match vlan command, match vlan-inner command, match cos command, match precedence, match dscp, match mpls experimental and the match cos-inner commands.

•QoS classification on Egress ACL is not supported with the following TCP/UDP port parameters:

•Port range

•Port gt (greater than)

•Port lt (lesser than)

• Established (matching on established connections)

Table 3-3 provides information about which QoS classification features are supported for the ES20 line card on the Cisco 7600 series router. For more information about most of the commands documented in this table, refer to the Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2SR, at:

http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/12_2sr/qos_12_2sr_book.html

Configuration Tasks

To create a user-defined QoS traffic class, use the following commands beginning in global configuration mode:

Examples

This example shows how to configure a class-map named ipp5, and enter a match statement for IP precedence 5:

Router(config)# class-map ipp5

Router(config-cmap)# match ip precedence 5

Router(config-cmap)# 

This is an example of configuring class matching on multiple match statements.

Router(config)# class-map match-any many (id 1047)

Router(config-cmap)# match ip  precedence 3 

Router(config-cmap)# match access-group  100 

Router(config-cmap)# match mpls experimental 5 

This is an example of configuring class matching on named ACLS.

Router(config)# class-map match-all acl9 (id 1049)

Router(config-cmap)# match access-group name rock

This example shows a logical AND operation in a child policy with match vlan and class-default in a parent.

Router(config)# class-map match-all childAND

Router(config-cmap)# match cos 2-3

Router(config-cmap)# match cos inner 5 6

Router(config)# policy-map testchildAND

Router(config-pmap)# class childAND

Router(config-pmap-c)# shape average 100000000

Router(config)# policy-map parentAND

Router(config-pmap)# class vlan12

Router(config-pmap-c)# shape average 500000000

Router(config-pmap-c)# service-policy testchild

This example shows how to display class-map information for a specific class-map using the show class-map command:

Router# show class-map ipp5

Class Map match-all ipp5 (id 1)

Match ip precedence 5

This example shows how to display class-map information matching on extended ACLs using the show class-map command.

head# show class-map acl5

 Class Map match-all acl5 (id 1042)

   Match access-group  102 

This example shows how to verify classification on a VLAN in the parent class of a HQoS policy.

head# show policy-map match

policy-map match4

  class child AND

   shape average 3000000

policy-map match2

  class child AND

    shape average 200000

Configuring Policing

This section describes information for configuring QoS traffic policing policies.

Restrictions and Usage Guidelines

The Cisco 7600 series routers support different forms of policing using the police command. See Table 3-4 to determine which policing features are supported by ES20 line card type.

When configuring ingress policing on main, subinterface, and VLAN, follow these restrictions and usage guidelines:

•The ES20 line card supports conform-action policing on input interfaces only.

•Egress policing command is executed when the priority is defined, and the policy-map is not rejected because we can add policing and priority. While you configure the LLQ values on a dynamically applied policy-map, ensure that you define police values followed by priority values.

•Egress policing command is executed when the priority is defined. The stand alone policing is not rejected because you can add priority values. When you configure the LLQ values on a dynamically applied policy-map, ensure that you define police values followed by bc and be priority values. You can configure these values and also define the queue limit.

•Use policing with priority queueing to limit the traffic rate in egress.When configuring policing paired with priority, the conform action is fixed to transmit while violate or exceed is fixed to drop. These action are not user configurable.

•When configuring one rate 2 color per EVC micro-flow policer:

–Up to 16,000 policers per line card are supported; only one per service instance configured within the class class-default.

–The conform-action or the exceed-action are statically defined and can not be altered.

–One form of policy configuration is support with optional marking in the child policy and policing in the parent policy.

Table 3-4 provides information about which policing features are supported for the ES20 line card on the Cisco 7600 series routers.

Table 3-5 provides information about the interfaces and their supported actions on an ES20 line card.

Table 3-5 One-Rate Two Color Ingress Support

Supported Interfaces	Conform Actions	Exceed Actions
Maininterface	•transmit •set dscp transmit •set precedence transmit •set mpls imposition exp	•drop •policed dscp transmit
Subinterface	•transmit •set dscp transmit •set precedence transmit •set mpls imposition exp	•drop •policed dscp transmit
EVC	transmit	drop Note EVC is supported only in class-default.
Switchport	•transmit •set dscp transmit •set precedence transmit •set mpls imposition exp	•drop •policed dscp transmit •set precdence •set dscp •set mpls imposition exp

Configuration Tasks

To create QoS traffic policies with policing, use the following commands beginning in global configuration mode:

Note Effective from 12.2(33)SRD release onwards, the service-policy configuration supports policy conform burst (bc) size setting on an ES20 interface. Releases earlier than 12.2(33)SRD, do not support setting policy bc size.

Note When creating QoS traffic policies as shown below, you can perform only one of the commands shown in Step 3 through Step 7 for each policy. You can perform Step 4 or Step 5 or Step 6 or Step 7; do not attempt to perform Step 3 through Step 7 in the same policy.

Examples

This example shows a traffic policing configuration with the average rate at 128kbps, the normal burst size at 128,000 bytes, and the excess burst size at 4000 bytes:

Router(config)# class-map acgroup2

Router(config-cmap)# match access-group 2

Router(config-cmap)# exit

Router(config)# policy-map police

Router(config-pmap)# class acgroup2

police cir 128000 pir 10000000 conform-action transmit exceed-action drop 4 violate-action 
drop set-cos-transmit 4 violate-action drop

Router(config-pmap-c)# exit

Router(config-pmap)# exit

Router(config)# interface gigethernet 1/0/0

Router(config-if)# service-policy input police

This example shows a policy that contains a one rate 2 color per EVC micro-flow policer with marking operations.

Router(config)# policy-map child

Router(config-pmap)# class cos1

Router(config-pmap-c)# set cos 5

Router(config-pmap)# class class-default

Router(config-pmap-c)# set cos 6

Router(config)# mls QoS

Router(config)# policy-map efppolicy

Router(config-pmap)# class class-default

Router(config-pmap-c)# police cir 200000000 bc 6250000 conform-action transmit 
exceed-action drop

Router(config-if)# service-policy child

This example shows a policy that contains a one- rate zero color (1R0C) policer:

Router(config)#policy-map 1r0c

Router(config-pmap)#class class-default

Router(config-pmap-c)#police cir 1000000 

Router(config-pmap-c-police)#end

This example shows a policy that contains a two- rate three color (2R3C) policer:

Router(config)#policy-map 2r3c

Router(config-pmap)#class cos1

Router(config-pmap-c)#police cir 1000000 pir 2000000 conform-action set-prec-transmit 3 

exceed-action set-prec-transmit 4 violate-action drop  
Router(config-pmap-c-police)#end

This example shows how to apply a policy-map on the EVC port channel:

Router(config)#int port-channel 100

Router(config-if)#service instance 1 ethernet 
Router(config-if-srv)#encapsulation dot1q 100 
Router(config-if-srv)#service-policy in 1r0c

Verification

Use the following commands to verify policing:

This example shows how to display policing statistics using the show policy-map interface command in the EXEC mode.

sh policy-map int gig 4/0/5

GigabitEthernet4/0/5 

Service-policy output: example

Counters last updated 00:00:00 ago

queue stats for all priority classes:

Queueing

queue limit 66 packets

(queue depth/total drops/no-buffer drops) 0/121416/0

(pkts output/bytes output) 428079/640406145

Class-map: prec1 (match-all)

497836 packets, 744762656 bytes

5 minute offered rate 18806000 bps, drop rate 828000 bps

Match: ip precedence 1 

police:

cir 3000000 bps, bc 93750 bytes

conformed 324764 packets, 485846905 bytes; actions: transmit

exceeded 121416 packets, 181636879 bytes; actions: drop

conformed 12256000 bps, exceed 842000 bps

Priority: Strict, b/w exceed drops: 121416

Class-map: class-default (match-any)

1761338 packets, 1138941205 bytes

5 minute offered rate 27792000 bps, drop rate 26713000 bps

Match: any 

Queueing

queue limit 66 packets

(queue depth/total drops/no-buffer drops) 70/824757/0

(pkts output/bytes output) 300574/420798000

shape (average) cir 2000000, bc 8000, be 8000

target shape rate 2000000

This is another example of displaying policing statistics using the show policy-map interface command; in this case the statistics are for a one rate 2 color per EVC micro-flow policer.

TenGigabitEthernet4/0/0: EFP 1 

Service-policy input: policesmall 

Counters last updated 00:00:00 ago 

Class-map: class-default (match-any) 

12353351 packets, 3627868092 bytes 

5 minute offered rate 671206 bps, drop rate 543206 bps 

Match: any 

police: 

cir 128000 bps, bc 4000 bytes 

conformed 2096904 packets, 130008048 bytes; actions: transmit 

exceeded 10256447 packets, 134308720 bytes; actions: drop 

conformed 127000 bps, exceed 543206 bps

Attaching a QoS Traffic Policy to an Interface

Before a traffic policy can be enabled for a class of traffic, it must be configured on an interface. A traffic policy also can be attached to Ethernet subinterfaces, maininterfaces, and service instances.

Traffic policies can be applied for traffic coming into an interface (input), and for traffic leaving that interface (output).

Attaching a QoS Traffic Policy for an Input Interface

When you attach a traffic policy to an input interface, the policy is applied to traffic coming into that interface. To attach a traffic policy for an input interface, use the following command beginning in interface configuration mode:

Attaching a QoS Traffic Policy to an Output Interface

When you attach a traffic policy to an output interface, the policy is applied to traffic leaving that interface. To attach a traffic policy to an output interface, use the following command beginning in interface configuration mode:

Configuring Marking

After you have created your traffic classes, you can configure traffic policies to configure marking features to apply certain actions to the selected traffic in those classes.

In most cases, the purpose of a packet mark is identification. After a packet is marked, downstream devices identify traffic based on the marking and categorize the traffic according to network needs. This categorization occurs when the match commands in the traffic class are configured to identify the packets by the mark (for example, match ip precedence, match ip dscp, match cos, and so on). The traffic policy using this traffic class can then set the appropriate QoS features for the marked traffic.

In some cases, the markings can be used for purposes besides identification. Distributed WRED, for instance, can use the IP precedence, CoS, IP DSCP, or MPLS EXP values to detect and drop packets.

Restrictions and Usage Guidelines

When configuring class-based marking on an ES20 line card, follow these restrictions and usage guidelines:

•Ingress packet marking is supported on maininterfaces, subinterfaces, and service instances. You can configure packet marking and queueing actions in the same traffic policy.

•If an ingress service policy configures both class-based marking and marking as part of a policing action, then the marking using policing takes precedence over any class-based marking.

•The Scalable EoMPLS on 7600-ESM-2X10GE and 7600-ESM-20X1GE feature supports mapping of the incoming VLAN dot1q p-bits to the outgoing MPLS EXP bits. Only outer tag dot1q pbits mapping is supported.

•The Scalable EoMPLS on 7600-ESM-2X10GE and 7600-ESM-20X1GE feature supports mapping of the incoming MPLS EXP bits to the outgoing VLAN dot1q p-bits.

•MultiPoint Bridging over Ethernet on 7600-ESM-2X10GE and 7600-ESM-20X1GE supports set cos and set cos inner commands in ingress marking. However, from 12.2(33) SRE onwards, ingress marking also supports set dscp and set precedence commands.

•Set operations are not allowed at the parent level.

•Up to two marking combinations can occur with the exception that Layer 2 marking is not combined with Layer 3 marking operations.

•You should configure no mls qos trust value for ingress marking on the main and subinterfaces.

Table 3-7 and Table 3-8 provides information about the various Ingress and Egress Marking combinations supported for a ES20 line card on the Cisco 7600 series router.

For example, in Table 3-7, ¸ marked against DSCP and Cos (row 4 col 1) indicates that you can mark DSCP and Cos within a single class. Similarly, a x marked against MPLS Experimental and Precedence (row 5 col 3) indicates that you cannot use both within a single class.

Table 3-7 Layer 3 Egress Marking Scenarios For EVCs

Table 3-8 Layer 3 Ingress Marking Scenarios On a Service Instance

The following example shows the sample ingress policy map for layer 3 marking support.

policymap policy1-in

class prec5

set cos 6

class cos_tos_all

set ip prec 4

class class-default

police cir 1000000

The following example shows Egress marking - port in set trust cos mode.

policymap policy1-eg-mark-BD 

class prec5

set cos 5

set ip dscp af31

shape average 1000000

class cos_in

set cos cos-inner

shape average 2000000

class cos_exp_all

set cos 6

shape average 3000000

policymap policy-hqos-eg-mark-BD 

class cosin_cos_dscp_all

set ip dscp af31

shape average 1000000

class class-default

shape average 2000000

service-policy policy1-eg-mark-BD 

The following example shows the sample output of the sh command.

pacv-7609S#sh policy-map interface ten4/0/1 service instance 1

TenGigabitEthernet4/0/1: EFP 1

Service-policy output: policy-hqos-eg-mark-BD

Counters last updated 00:00:04 ago

Class-map: cosin_cos_dscp_all (match-all)

0 packets, 0 bytes

5 minute offered rate 0000 bps, drop rate 0000 bps

Match: cos  1 

Match:  dscp 3 

Match: cos inner  3 

Queueing

queue limit 66 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 0/0

QoS Set

dscp af31

Packets marked 0

shape (average) cir 1000000, bc 4000, be 4000

target shape rate 1000000

Class-map: class-default (match-any)

0 packets, 0 bytes

5 minute offered rate 0000 bps, drop rate 0000 bps

Match: any 

Queueing

queue limit 66 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 0/0

shape (average) cir 2000000, bc 8000, be 8000

target shape rate 2000000

Service-policy : policy1-eg-mark-BD

Counters last updated 00:00:04 ago

Class-map: prec5 (match-any)

0 packets, 0 bytes

5 minute offered rate 0000 bps, drop rate 0000 bps

Match: ip precedence 5 

Queueing

queue limit 66 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 0/0

QoS Set

cos 5

Packets marked 0

dscp af31

Packets marked 0

shape (average) cir 1000000, bc 4000, be 4000

target shape rate 1000000

Class-map: cos_in (match-all)

0 packets, 0 bytes

5 minute offered rate 0000 bps, drop rate 0000 bps

Match: cos inner  4 

Queueing

Queue limit 66 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 0/0

QoS Set

cos cos-inner

Packets marked 0

shape (average) cir 2000000, bc 8000, be 8000

target shape rate 2000000

Class-map: cos_exp_all (match-all)

0 packets, 0 bytes

5 minute offered rate 0000 bps, drop rate 0000 bps

Match: mpls experimental topmost 3 

Match: cos  1 

Queueing

queue limit 66 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 0/0

QoS Set

cos 6

Packets marked 0

shape (average) cir 3000000, bc 12000, be 12000

target shape rate 3000000

Class-map: class-default (match-any)

0 packets, 0 bytes

5 minute offered rate 0000 bps, drop rate 0000 bps

Match: any 

queue limit 66 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 0/0

Table 3-9 Qos Class Based Marking Feature Support On A Main-Interface, Sub-Interface, and Serivce Instance

Configuration Tasks

To configure a QoS traffic policy with class-based marking, use the following commands beginning in global configuration mode:

Examples

This example shows the creation of a service policy called policy1. This service policy is associated to a previously defined classification policy through the use of the class command. This example assumes that a classification policy called class1 was previously configured.

Router(config)# policy-map policy1

Router(config-pmap)# class class1

Router(config-pmap-c)# set ip precedence 1 

Verification

Use the following commands to verify marking:

For more detailed information about configuring class-based marking features, refer to the Class-Based Marking document located at the following URL:

http://www.cisco.com/en/US/docs/ios/12_1t/12_1t5/feature/guide/cbpmark2.html

Configuring Shaping

This section describes information for configuring QoS traffic policies for shaping traffic.

Restrictions and Usage Guidelines

When configuring queueing features on an ES20 line card, follow these restrictions and usage guidelines:

•The Cisco 7600 series routers support different forms of queueing features. See Table 3-10 to determine which traffic shaping features are supported by the ES20 line card type.

•Use a hierarchical policy if you want to achieve minimum bandwidth guarantees using CBWFQ. First, configure a parent policy to shape to the total bandwidth required. Then, define a child policy using CBWFQ for the minimum bandwidth percentages.

•Traffic shaping is a queue with some CIR and excess information rate (EIR) value, such that CIR plus EIR is the shaped rate. Traffic shaping on an average cuts the flow of traffic from the queue at the configured shape rate over a mean period of time

For more detailed information about configuring congestion management features, refer to the Cisco IOS Quality of Service Solutions Configuration Guide document corresponding to your Cisco IOS software release.

Table 3-10 provides information about which QoS traffic shaping features are supported for the ES20 line card on the Cisco 7600 series router.

Configuration Tasks

Use MQC to configure traffic shaping. Create a class-map using the class-map command and a policy-map using the policy-map command. Attach the class to the policy using the class command and then use the shape command to configure shaping for that class.

Examples

This example shows traffic shaping on a main interface; traffic leaving interface Gig1/0/0 is shaped at the rate of 10 Mbps:

Router(config)# class-map class-interface-all

Router(config-cmap)# match ip precedence 1

Router(config-cmap)# exit

Router(config)# policy-map dts-interface-all-action

Router(config-pmap)# class class-interface-all

Router(config-pmap-c)# shape average 10000000

Router(config-pmap-c)# exit

Router(config)# interface gig 1/0/0

Router(config-if)# service-policy output dts-interface-all-action

This is an example of an output shaping policy on a switchport interface that matches on a CoS value queuing defined in the classes.

Router(config)# policy-map switchport-cos-policy

Router(config-pmap)# class cos1

Router(config-pmap-c)# shape ave 100000000

Now the policy is applied in the egress direction on the main switchport.

Router(config)# interface TenGigabitEthernet9/0/0

Router(config-if)# switchport

Router(config-if)# switchport access vlan 2000

Router(config-if)# switchport mode access

Router(config-if)# mls QoS trust cos

Router(config-if)# service-policy output switchport-cos-policy

In this example, the flat policy-map is applied in the egress direction to a subinterface.

Router(config)# policy-map x

Router(config-pmap)# class prec5

Router(config-pmap-c)# police 100000000

Router(config-pmap-c)# priority

Router(config-pmap)# class class-default

Router(config-pmap-c)# shape average 100000000

In this example, the following policy-map is applied in the egress direction to a subinterface.

Router(config)# policy-map child2

Router(config-pmap)# class prec5

Router(config-pmap-c)# shape average 100000000

Router(config)# policy-map pcd

Router(config-pmap)# class class-default

Router(config-pmap-c)# shape average 300000000

Router(config-if)# service-policy child2

Verification

Use the following commands to verify traffic shaping:

Configuring Shaping on the ES20 Main Interface

A traffic policy can be nested within a QoS policy when the service-policy command is used in a policy-map class configuration mode. A traffic policy that contains a nested traffic policy is called a hierarchical traffic policy.

A hierarchical traffic policy contains a child and a parent policy. The service-policy command associates the previously defined child policy with the new traffic policy and the parent policy uses the preexisting traffic policy.

Hierarchical traffic policies are supported on subinterfaces, EVCs, and EVC port channels. When hierarchical traffic policies are used, you c an use a single traffic policy (with a child and a parent policy) to shape and prioritize traffic.

You can use this feature to configure a HQoS on an ES20 main interface where the child policy-map is attached to the class-default of a parent policy-map. For more information on hierarchical shaping, refer to the section "Configuring Hierarchical QoS with Tiered Policy-Maps" section

About Traffic Shaping

Traffic shaping:

•Controls the outbound traffic of an interface to match its flow to the speed of the remote target interface.

•Manages the access to the available bandwidth.

•Regulates the traffic flow to avoid congestion.

•Ensures that the traffic conforms to policies contracted for it.

•Shapes the traffic to eliminate the bottlenecks in topologies with data-rate mismatches.

Cisco IOS QoS uses policing and shaping to regulate data traffic. The rate-limiting features of the Committed Access Rate (CAR) and the Traffic Policing feature provides the functionality to police the traffic and the features of Generic Traffic Shaping (GTS), Class-Based Shaping, and Distributed Traffic Shaping (DTS) provides the functionality to shape traffic.
For more information on Shaping, refer to the "HQoS Polices with Shape in Child Classes"section in the Cisco IOS Quality of Serivce Configuration Guide.

Cisco IOS QoS software uses two types of traffic shaping: GTS and Class-Based.

Their have:

•Similar traffic shaping methods using different CLIs.

•Different types of queues to contain and shape deferred traffic.

•Weighted fair queue to hold the delayed traffic for the deferred packets.

Restrictions and Usage Guidelines

Follow these restrictions and usage guidelines when you configure shaping on an ES20 main interface:

•When a child policy is added to the class-default, no other classes should exist on the parent level.

•When you apply a service policy on a main interface, ensure that the EVC or subinterface is not configured within the main interface.

•A minimum of 128 Kbps shape value and a maximum of 99% of interface bandwidth is supported.

Non example

In the following non example, the policy-map parent has a user-defined class prec1 and a class class-default with a attached child policy.

Based on the following example, this feature does not support policies with:

•user-defined classes at the parent level.

•Class defaults with attached child policies.

Policy-map parent

Class prec1

Shape average 10000000

Class class-default

Shape average 100000000

Service-policy child

Policy-map child

Class prec0

Shape average 50000000

Class class-default

Shape average 50000000

Though this feature does not support the following scenario, you can apply the policies in the following example.

Policy-map parent

Class vlan12 (matches on Vlan 12)

Shape average 10000000

Class class-default

Shape average 20000000

Service-policy child

policy-map child

class cos0

shape average 5000000

class cos1

shape average 5000000

class class-default

shape average 20000000

Configuring the Child Policy

SUMMARY STEPS

1. enable

2. configure terminal

3. policy-map policy name

4. class class-default

5. class class name

6. shape [average] mean-rate

7. class class-default

8. shape [average] mean-rate

9. exit

DETAILED STEPS

Router> enable

Configuring the Parent Policy

SUMMARY STEPS

1. enable

2. configure terminal

3. policy-map policy name

4. class class-default

5. shape [average] mean-rate

6. service-policy policy-map name

7. interface type value

8. service-policy [output class-default]

9. exit

DETAILED STEPS

Router> enable

Verification

You can execute the show run command to view the policy-map attached to the interface.In the following example, the child policy classifies and prioritizes the traffic, and the parent policy shapes the traffic.

USA# show policy-map int gig 1/0/0

GigabitEthernet1/0/0 

Service-policy output: parent

Counters last updated 00:00:00 ago

Class-map: class-default (match-any)

2 packets, 164 bytes

5 minute offered rate 0000 bps, drop rate 0000 bps

Match: any 

Queueing

queue limit 3315 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 2/164

shape (average) cir 100000000, bc 400000, be 400000

target shape rate 100000000

Service-policy : child

Counters last updated 00:00:00 ago

Class-map: prec0 (match-all)

0 packets, 0 bytes

5 minute offered rate 0000 bps, drop rate 0000 bps

Match: ip precedence 0 

Queueing

queue limit 1655 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 0/0

shape (average) cir 50000000, bc 200000, be 200000

target shape rate 50000000

Class-map: class-default (match-any)

2 packets, 164 bytes

5 minute offered rate 0000 bps, drop rate 0000 bps

Match: any 

Queueing

queue limit 1655 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 2/164

shape (average) cir 50000000, bc 200000, be 200000

target shape rate 50000000

end

Configuring QoS Queue Scheduling

This section describes ES20 line card-specific information for configuring QoS queue scheduling.

Restrictions and Usage Guidelines

When configuring queueing features on an ES20 line card, follow these restrictions and usage guidelines:

•The Cisco 7600 series routers support different forms of queueing features. See Table 3-11 to determine which queueing features are supported by ES20 line card type.

•You must use policing with priority queueing to limit the traffic rate.

•ES20 line card supports up to two LLQ queues per policy-maps with equal priority.

•If you receive any exceed errors on the line card, we recommend you to remove all the policy-maps from the erroneous port.

•Ensure that you configure the policy-maps to use 99% of the port bandwidth. Policy-map functions erroneously when it is configured to use the 100% bandwidth of the port because 1% of the port bandwidth is reserved for control packets.

•A maximum of 8000 queues are supported per bay.

•The maximum acceptable limit of the Excess Information Rate (EIR) limitation per port is 549 Gigabyte.

•Priority or low latency queue with bit rates (priority <kbps> command) is not supported.

•Priority or low latency queue with percent (priority percent command) is not supported.

For more detailed information about configuring congestion management features, refer to the Cisco IOS Quality of Service Solutions Configuration Guide document corresponding to your Cisco IOS software release.

Table 3-11 provides information about which QoS queueing features are supported for the ES20 line card on the Cisco 7600 series routers.

Configuring WRED

Note You can use a maximum of 4 random detect statements with a single class-map and total of 128 WRED statements per bay.

To configure a QoS WRED policy, use the following commands beginning in global configuration mode:

Examples

This is an example of a WRED configuration.

Router(config)# policy-map wredtest

Router(config-pmap)# class cos5

Router(config-pmap-c)# shape average 200000000

Router(config-pmap-c)# random-detect precedence-based aggregate

Router(config-pmap-c)# random-detect precedence values 0 min 100 max 200 mark-prob 1

Router(config-pmap-c)# random-detect precedence values 1 min 300 max 500 mark-prob 1

Router(config-pmap-c)# random-detect precedence values 2 min 600 max 900 mark-prob 1

The default line can also be configured as follows:

Router(config-pmap-c)# random-detect precedence-based aggregate min 200 max 300 mark-prob 
1

Min and max threshold values listed in the previous command signifies the number of 256 byte packet buffers.

Note Packets or datagrams or frames larger than 256 bytes consumes more packet buffers.

Note In a EVC, if WRED config with precedence is used, the CoS value is mapped to the Prec value.

Configuring CBWFQ

To configure a QoS CBWFQ policy, use the following commands beginning in global configuration mode:

Examples

This example shows a service policy called policy1 that specifies the amount of bandwidth to allocate for traffic classes 1 and 2:

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

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)#

Router(config)# interface gig 1/0/0 
Router(config-if)# service-policy output policy1 

Router(config-if)# exit

Use the following commands to verify CBWFQ:

Configuring LLQ

To configure LLQ, use the Modular QoS command-line interface. Define the class of traffic with the class-map command, create a policy-map that contains the priority command, and apply the policy to the appropriate interface with the service-policy command.

You can configure a maximum of 2 priority queue with policing on two different classes.

To configure a policy with LLQ and to assign the policy to an interface, perform the following tasks in global configuration mode:

Router(config-pmap)# class class-map-name

Router(config-pmap-c)# priority 

Examples

The following example configures an output LLQ policy on a switchport interface that matches on a CoS value queuing defined in the classes.

Router(config)# policy-map switchport-llq-policy

Router(config-pmap)# class cos0

Router(config-pmap-c)# police 500000000 

Router(config-pmap-c)# priority

Now the policy is applied to the interface.

Router(config)# interface TenGigabitEthernet9/0/0

Router(config-if)# switchport

Router(config-if)# switchport access vlan 2000

Router(config-if)# switchport mode access

Router(config-if)# mls QoS trust cos

Router(config-if)# service-policy output switchport-llq-policy

Configuring PFC QoS on a Cisco 7600 Series Ethernet Services 20G Line Card

The ES20 line card supports most of the same QoS features as those supported by the Policy Feature Card (PFC) on the Cisco 7600 series routers.

This section describes those QoS features that have ES20 line card-specific configuration guidelines. After you review the ES20 line card-specific guidelines described in this document, then refer to the Cisco 7600 Series Cisco IOS Software Configuration Guide, 12.2SR located at the following URL:

http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/swcg.html

PFC QoS on a Cisco 7600 Series Ethernet Services 20G Line Card Configuration Guidelines

•Output policing is not supported.

•PFC egress marking is not supported.

•Ingress marking and policing is performed with PFC Qos.

Configuring Hierarchical QoS

Table 3-12 provides information about where the hierarchical QoS features are supported.

Hybrid Policy Support

The following hybrid policy is not supported on an ES20 line card.

LLB#sh policy-map unsupp

Policy Map unsupp

Class voip

Average Rate Traffic Shaping 

cir 3000000 (bps)

service-policy child1

Class video

Average Rate Traffic Shaping

cir 2000000 (bps)

service-policy child2

Class class-default

Average Rate Traffic Shaping

cir 5000000 (bps)

service-policy child3

LLB#sh policy-map child1

Policy Map child1

Class prec3

Average Rate Traffic Shaping

cir 1500000 (bps)

Class prec4

Average Rate Traffic Shaping

cir 1000000 (bps)

LLB#sh policy-map child2

Policy Map child2

Class prec3

Average Rate Traffic Shaping

cir 1000000 (bps)

Class prec4

Average Rate Traffic Shaping

cir 1500000 (bps)

LLB#sh policy-map child3

Policy Map child3

Class prec3

Average Rate Traffic Shaping

cir 1500000 (bps)

Class prec4

Average Rate Traffic Shaping

cir 1000000 (bps)

LLB# sh policy-map unsupp

Policy Map unsupp

Class voip

Average Rate Traffic Shaping

cir 3000000 (bps)

Class video

Average Rate Traffic Shaping

cir 2000000 (bps)

Class class-default

Average Rate Traffic Shaping

cir 5000000 (bps)

service-policy child3

LLB#sh policy-map child3

Policy Map child3

Class prec3

Average Rate Traffic Shaping

cir 1500000 (bps)

Class prec4

Average Rate Traffic Shaping

cir 1000000 (bps) 

The following configuration is supported on the maininterfaces, switchport, and EVCs:

LLB#sh policy-map supp

Policy Map supp

Class voip

Average Rate Traffic Shaping

cir 3000000 (bps)

service-policy child1

Class video

Average Rate Traffic Shaping

cir 2000000 (bps)

service-policy child2

Class class-default

Average Rate Traffic Shaping

cir 5000000 (bps)

LLB#sh policy-map child1

Policy Map child1

Class prec3

Average Rate Traffic Shaping

cir 1500000 (bps)

Class prec4

Average Rate Traffic Shaping

cir 1000000 (bps)

LLB#sh policy-map child2

Policy Map child2

Class prec3

Average Rate Traffic Shaping

cir 1000000 (bps)

Class prec4

Average Rate Traffic Shaping

cir 1500000 (bps)

LLB#sh policy-map child3 

Policy Map child3

Class prec3

Average Rate Traffic Shaping

cir 1500000 (bps)

Class prec4

Average Rate Traffic Shaping

cir 1000000 (bps)

Configuring Hierarchical QoS with Tiered Policy-Maps

Hierarchical QoS with tiered policy-maps is a configuration where the actions associated with a class contain a queuing action (such as shaping) and a nested service policy, which in itself is a policy-map with classes and actions. This hierarchy of the QoS policy-map is then translated into a corresponding hierarchy of queues.

Configuration Guidelines

When configuring hierarchical QoS with tiered policy-maps on an ES20 line card, follow these restrictions and usage guidelines:

•You can configure up to two levels of hierarchy within the policy-maps.

•The parent policy-map has the following restrictions on a main switchport interface:

–Supports match vlan command in parent class and match cos command in the child class. You can configure shape or bandwidth queueing actions in any class (user-defined and class-default).

•When configuring hierarchical QoS for software-based EoMPLS, if you configure match input vlan in the parent policy, then you can only configure match QoS-group in the child policy.

•ES20 line card does not support a flat match QoS-group policy.

•In hierarchical QoS, the set command is not supported in the parent policy.

•In egress direction, the set command works if at least one queueing action is configured in the policy. This queueing action can also exist in the parent policy while child policies contain only marking.

•The child policy-map supports shape, bandwidth, priority, set operations, and WRED QoS features.

•With hierarchical QoS on a subinterface, the parent policy-map supports hierarchical QoS using only the shape average command as a queueing action in the default class (class-default) only.

•If you configure shaping at both the parent policy and the child policy, the traffic is shaped first according to the parameters defined in the parent policy, followed by the parameters of the child policy.

•Use a hierarchical policy if you want to achieve minimum bandwidth guarantees using CBWFQ with a map class. First, configure a parent policy to shape to the total bandwidth required. Then, define a child policy using CBWFQ for the minimum bandwidth percentages.

•ES20 supports class-default hQoS policy-maps. A user-defined class-map in the parent policy is not supported on subinterfaces. The following example shows an unsupported policy-map on a sub-interface:

pavement#sh policy-map unsup

Policy Map unsup

Class prec4 *** not supported

Average Rate Traffic Shaping

cir 300000000 (bps)

Class class-default

Average Rate Traffic Shaping

cir 200000000 (bps)

service-policy unsup2

pavement#sh policy-map unsup2

Policy Map unsup2

Class prec2

Average Rate Traffic Shaping

cir 50000000 (bps)

Class prec3

Average Rate Traffic Shaping

cir 100000000 (bps)

•You can configure hierarchical QoS up to the following limits, according to the current Cisco IOS software limits:

–Up to 1024 class-maps

–Up to 1024 policy-maps

–Up to 256 unique classes in a policy-map including class-default

The following example shows configuration of hierarchical QoS that maps to two levels of hierarchical queues. The first-level policy (the parent policy) configures the aggregated data rate to be shaped to 1 Mbps for the class-default class. The second-level policy (the child policy) configures the traffic in User-A class for 40 percent of the bandwidth and traffic in User-B class for 20 percent of the bandwidth.

! Configure the class-maps with your matching criteria

!

Router(config)# class-map match-any User-A

Router(config-cmap)# match access-group A

Router(config-cmap)# exit

Router(config)# class-map match-any User-B

Router(config-cmap)# match access-group B

Router(config-cmap)# exit

!

Configure the parent policy for class-default to shape all traffic in that class and apply a second-level policy.

Router(config)# policy-map child

Router(config-pmap)# class User-A

Router(config-pmap-c)# bandwidth percent 40

Router(config-pmap-c)# exit

Router(config-pmap)# class User-B

Router(config-pmap-c)# bandwidth percent 20

Router(config-pmap-c)# exit

Router(config-pmap)# exit

!

Router(config)# policy-map parent

Router(config-pmap)# class class-default

Router(config-pmap-c)# shape 1000000

Router(config-pmap-c)# service-policy child

Router(config-pmap-c)# exit

Router(config-pmap)# exit

!

Configure the child policy to allocate different percentages of bandwidth by class.

!Apply the parent service policy to an output subinterface.

!

Router(config)# interface TenGigabitEthernet 2/0/0.1

Router(config-if)# encapsulation dot1q 11

Router(config-if)# service-policy output parent

The following example shows configuration of hierarchical QoS that maps to two levels of hierarchical queues, where the parent policy configures average traffic shaping rates on both user-defined classes as well as the class-default class, which is supported beginning in Cisco IOS Release 12.2(33)SRA. This configuration does not show the corresponding class-map configuration, which also is required to support these policy-maps.

Configure the parent policy for user-defined and class-default classes to shape traffic in those classes and apply a second-level policy.

Configure the child policy to allocate different percentages of bandwidth by class.

!

Router(config)# policy-map child-pm

Router(config-pmap)# class cos0

Router(config-pmap-c)# bandwidth percent 10

Router(config-pmap-c)# exit

Router(config-pmap)# class cos1

Router(config-pmap-c)# bandwidth percent 10

Router(config-pmap-c)# exit

Router(config-pmap)# exit

!

Router(config)# policy-map parent

Router(config-pmap)# class vlan100

Router(config-pmap-c)# shape average 1000000

Router(config-pmap-c)# service-policy child-pm

Router(config-pmap-c)# exit

Router(config-pmap)# class vlan200

Router(config-pmap-c)# shape average 1000000

Router(config-pmap-c)# service-policy child-pm

Router(config-pmap-c)# exit

Router(config-pmap)# class class-default

Router(config-pmap-c)# shape average 2000000

Router(config-pmap-c)# exit

Router(config-pmap)# exit

!

! Apply the parent service policy to an output interface.

!

Router(config)# interface TenGigabitEthernet 2/0/0

Router(config-if)# switchport

Router(config-if)# switchport access vlan 2000

Router(config-if)# switchport mode access

Router(config-if)# mls QoS trust cos

Router(config-if)# service-policy output switchport-cos-policy

Router(config-if)# service-policy output parent-pm

This example shows how to display information a class-default HQoS policy with child policy matching on various supported criteria.

Router# show policy-map parent2

  Policy Map parent2

    Class class-default

Router(config-pmap-c)# shape average 3000000000 12000000 12000000

      service-policy child

head# show policy-map child  

  Policy Map child

    Class dscp3

shape average 100000000 400000 400000

Class prec5

     police cir 200000000 bc 6250000 be 6250000 conform-action transmit exceed-action drop

      priority

    Class acl2

shape average 50000000 200000 200000

    Class class-default

      bandwidth 10 (%)

Configuring Hierarchical QoS for EoMPLS VCs

The Hierarchical Quality of Service (HQoS) for EoMPLS VCs feature extends support for hierarchical, parent and child relationships in QoS policy-maps. This feature also provides EoMPLS per-VC QoS for point-to-point VCs.

The new feature adds the ability to match the virtual LAN (VLAN) IDs that were present on a packet when the packet was originally received by the router. It also supports the ability to match on a QoS group that is set to the same value of the IP precedence or 802.1P class of service (CoS) bits that are received on the incoming interface. This allows service providers to classify traffic easily for all or part of a particular EoMPLS network, as well as to preserve the customer's original differentiated services (DiffServ) QoS values.

In EoMPLS applications, the parent policy-map typically specifies the maximum or the minimum bandwidth for a group of specific VCs in an EoMPLS network. Then child policy-maps in the policy can implement a different bandwidth or perform other QoS operations (such as traffic shaping) on a subset of the selected VCs.

This feature enables service providers to provide more granular QoS services to their customers. It also gives service providers the ability to preserve customer IP precedence or CoS values in the network.

Hierarchical QoS with Service Instances

The Hierarchical Quality of Service (HQoS) with Service Instances extends support for hierarchical, parent and child relationships in QoS policy-maps. Both flat and hierarchical policies can be applied to service instances configured as Ethernet MPB, EoMPLS, local connect, or selective QinQ.

Configuration Guidelines

When configuring hierarchical QoS with Ethernet Service Instances on an ES20 line card, follow these restrictions and usage guidelines:

•You can classify on the inner VLAN tag, the outer VLAN tag, or a combination of both. You can classify on the inner VLAN tag and CoS or the outer VLAN tag and CoS. You can classify on CoS, or CoS inner or any combination of these filters.

•The following MQC actions are permitted:

–Shaping

–Bandwidth

–Two priority queues per policy

–Set cos, set cos-inner, set cos cos-inner, set cos-inner cos, and set mpls exp commands

–set mpls exp is supported in ingress (for Eompls only).

–WRED aggregate

–Queue-limit

•For marking, you can copy or rewrite the inner cos, the outer cos, or both inner and outer cos, or your can copy the inner cos to outer cos or vice versa.

EVC Configuration Examples

This example shows ingress QoS on scalable EoMPLS.

Router(config)# interface gig 1/0/0

Router(config-if)# service instance 1 ethernet