Cisco IOS XR Modular Quality of Service Configuration Guide for … · QC-ix Cisco IOS XR Modular Quality of Service Configuration Guide for the Cisco XR 12000 Series Router OL-24694-01

Preface

This document describes the Cisco IOS XR Quality of Service (QoS) feature for prioritizing traffic flow and providing preferential forwarding for higher-priority packets. The QoS techniques described include allocating bandwidth, improving loss characteristics, avoiding and managing network congestion, metering network traffic, and setting traffic-flow priorities across the network.

For QoS command descriptions, usage guidelines, and examples, refer to the Cisco IOS XR Modular Quality of Service Command Reference for the Cisco XR 12000 Series Router.

The preface contains the following sections:

• Changes to This Document, page IR-ix

• Obtaining Documentation and Submitting a Service Request, page IR-ix

Changes to This DocumentThe following table lists the technical changes made to this document.

Obtaining Documentation and Submitting a Service RequestFor information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What’s New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:

http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html

Subscribe to the What’s New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS version 2.0.

Table 1 Changes to This Document in Cisco IOS XR 4.1

Revision Date Change Summary

OL-24694-01 April, 2011 No new QoS features were introduced for the Cisco XR 12000 Series Router in Release 4.1.

QC-ixCisco IOS XR Modular Quality of Service Configuration Guide for the Cisco XR 12000 Series Router

OL-24694-01

http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html

Preface

QC-xCisco IOS XR Modular Quality of Service Configuration Guide for the Cisco XR 12000 Series Router

OL-24694-01

Modular QoS Overview on Cisco IOS XR Software

Quality of Service (QoS) is the technique of prioritizing traffic flows and providing preferential forwarding for higher-priority packets. The fundamental reason for implementing QoS in your network is to provide better service for certain traffic flows. A traffic flow can be defined as a combination of source and destination addresses, source and destination socket numbers, and the session identifier. A traffic flow can more broadly be described as a packet moving from an incoming interface that is destined for transmission to an outgoing interface. The traffic flow must be identified, classified, and prioritized on all routers and passed along the data forwarding path throughout the network to achieve end-to-end QoS delivery. The terms traffic flow and packet are used interchangeably throughout this module.

To implement QoS on a network requires the configuration of QoS features that provide better and more predictable network service by supporting bandwidth allocation, improving loss characteristics, avoiding and managing network congestion, metering network traffic, or setting traffic flow priorities across the network.

This module contains overview information about modular QoS features within a service provider network.

Contents• Information About Modular Quality of Service Overview on Cisco IOS XR Software, page 1

• Where to Go Next, page QC-6

• Additional References, page QC-6

Information About Modular Quality of Service Overview on Cisco IOS XR Software

Before configuring modular QoS on your network, you should understand the following concepts:

• Benefits of Cisco IOS XR QoS Features, page 2

• QoS Techniques on Cisco IOS XR Software, page 2

• Differentiated Service Model for Cisco IOS XR Software, page QC-4

• Additional Cisco IOS XR QoS Supported Features, page QC-5

QC-1Cisco IOS XR Modular Quality of Service Configuration Guide for the Cisco XR 12000 Series Router

OL-24694-01

Modular QoS Overview on Cisco IOS XR SoftwareInformation About Modular Quality of Service Overview on Cisco IOS XR Software

Benefits of Cisco IOS XR QoS FeaturesThe Cisco IOS XR QoS features enable networks to control and predictably service a variety of networked applications and traffic types. Implementing Cisco IOS XR QoS in your network promotes the following benefits:

• Control over resources. You have control over which resources (bandwidth, equipment, wide-area facilities, and so on) are being used. For example, you can limit bandwidth consumed over a backbone link by FTP transfers or give priority to an important database access.

• Tailored services. If you are an Internet Service Provider (ISP), the control and visibility provided by QoS enables you to offer carefully tailored grades of service differentiation to your customers.

• Coexistence of mission-critical applications. Cisco IOS XR QoS features make certain of the following conditions:

– That your WAN is used efficiently by mission-critical applications that are most important to your business.

– That bandwidth and minimum delays required by time-sensitive multimedia and voice applications are available.

– That other applications using the link get their fair service without interfering with mission-critical traffic.

QoS Techniques on Cisco IOS XR SoftwareQoS on Cisco IOS XR software relies on the following techniques to provide for end-to-end QoS delivery across a heterogeneous network:

• Packet classification

• Congestion management

• Congestion avoidance

Before implementing the QoS features for these techniques, you should identify and evaluate the traffic characteristics of your network because not all techniques are appropriate for your network environment.

Packet Classification

Packet classification techniques identify the traffic flow, and provide the capability to partition network traffic into multiple priority levels or classes of service. After traffic flow is identified, it can be marked as a traffic class.

Identification of a traffic flow can be performed by using several methods within a single router: access control lists (ACLs), protocol match, IP precedence, IP differentiated service code point (DSCP), and so on.

Marking of a traffic flow is performed by:

• Setting IP Precedence or DSCP bits in the IP Type of Service (ToS) byte.

• Setting Class of Service (CoS) bits in the Layer 2 headers (Ethernet, Spatial Reuse Protocol [SRP], and so on).

• Setting EXP bits within the imposed or the topmost Multiprotocol Label Switching (MPLS) label.

• Setting qos-group and discard-class bits.

Marking can be carried out:


OL-24694-01

Modular QoS Overview on Cisco IOS XR SoftwareInformation About Modular Quality of Service Overview on Cisco IOS XR Software

• Unconditionally—As part of the class-action.

• Conditionally—As part of a policer-action.

• Combination of conditionally and unconditionally.

For detailed conceptual and configuration information about packet marking, see the Configuring Modular Quality of Service Packet Classification on Cisco IOS XR Software module for unconditional marking, and Configuring Modular Quality of Service Congestion Management on Cisco IOS XR Software module for conditional marking.

Congestion Management

Congestion management techniques control congestion after it has occurred. One way that network elements handle an overflow of arriving traffic is to use a queueing algorithm to sort the traffic, then determine some servicing method of prioritizing it onto an output link.

Cisco IOS XR software implements the low-latency Queueing (LLQ) feature, which brings strict priority queueing (PQ) to the Modified Deficit Round Robin (MDRR) scheduling mechanism. LLQ with strict PQ allows delay-sensitive data, such as voice, to be dequeued and sent before packets in other queues are dequeued.

Cisco IOS XR software includes traffic policing capabilities available on a per-class basis as well as class-based shaping.

The traffic policing feature limits the input or output transmission rate of a class of traffic based on user-defined criteria, and can mark packets by setting values such as IP Precedence, QoS group, or DSCP value.

Traffic shaping allows control over the traffic that leaves an interface to match its flow to the speed of the remote target interface and ensure that the traffic conforms to the policies contracted for it. Thus, traffic adhering to a particular profile can be shaped to meet downstream requirements, thereby eliminating bottlenecks in topologies with data-rate mismatches.

Cisco IOS XR software supports a class-based traffic shaping method through a CLI mechanism in which parameters are applied per class.

For detailed conceptual and configuration information about congestion management, see the Configuring Modular Quality of Service Congestion Management on Cisco IOS XR Software module.

Congestion Avoidance

Congestion avoidance techniques monitor network traffic flows in an effort to anticipate and avoid congestion at common network and internetwork bottlenecks before problems occur. These techniques are designed to provide preferential treatment for traffic (such as a video stream) that has been classified as real-time critical under congestion situations while concurrently maximizing network throughput and capacity utilization and minimizing packet loss and delay. Cisco IOS XR software supports the Random Early Detection (RED), Weighted RED (WRED), and tail drop QoS congestion avoidance features.

For detailed conceptual and configuration information about congestion avoidance techniques, see the Configuring Modular Quality of Service Congestion Management on Cisco IOS XR Software module.


OL-24694-01

Modular QoS Overview on Cisco IOS XR SoftwareWhere to Go Next

Differentiated Service Model for Cisco IOS XR SoftwareCisco IOS XR software supports a differentiated service that is a multiple-service model that can satisfy different QoS requirements. However, unlike in the integrated service model, an application using differentiated service does not explicitly signal the router before sending data.

For differentiated service, the network tries to deliver a particular kind of service based on the QoS specified by each packet. This specification can occur in different ways, for example, using the IP Precedence bit settings in IP packets or source and destination addresses. The network uses the QoS specification to classify, mark, shape, and police traffic, and to perform intelligent queueing.

The differentiated service model is used for several mission-critical applications and for providing end-to-end QoS. Typically, this service model is appropriate for aggregate flows because it performs a relatively coarse level of traffic classification.

Additional Cisco IOS XR QoS Supported FeaturesThe following sections describe the additional features that play an important role in the implementation of QoS on Cisco IOS XR software.

Modular QoS Command-Line Interface

In Cisco IOS XR software, QoS features are enabled through the Modular QoS command-line interface (MQC) feature. The MQC is a command-line interface (CLI) structure that allows you 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 classify traffic, whereas the QoS features in the traffic policy determine how to treat the classified traffic. One of the main goals of MQC is to provide a platform-independent interface for configuring QoS across Cisco platforms.

For detailed conceptual and configuration information about the MQC feature, see the Configuring Modular Quality of Service Packet Classification on Cisco IOS XR Software module.

Fabric QoS

The fabricq queue selection mechanism is known as Fabric QoS. To provide class of service to the traffic under fabric congestion scenarios, configure Fabric QoS. The platform-independent user interface allows you to configure an MQC policy on the switch fabric queues. This policy is global for all line cards on the router.

Where to Go NextTo configure the packet classification features that involve identification and marking of traffic flows, see the Configuring Modular Quality of Service Packet Classification on Cisco IOS XR Software module.

To configure the queueing, scheduling, policing, and shaping features, see the Configuring Modular Quality of Service Congestion Management on Cisco IOS XR Software module.

To configure the WRED and RED features, see the Configuring Modular QoS Congestion Avoidance on Cisco IOS XR Software module.


OL-24694-01

Modular QoS Overview on Cisco IOS XR SoftwareWhere to Go Next

To configure fabric QoS, see the Configuring Fabric Quality of Service Policies and Classes on Cisco IOS XR Software module.


OL-24694-01

Modular QoS Overview on Cisco IOS XR SoftwareAdditional References

Additional ReferencesThe following sections provide references related to implementing QoS.

Related Documents

Standards

MIBs

RFCs

Related Topic Document Title

Initial system bootup and configuration Cisco IOS XR Getting Started Guide for the Cisco XR 12000 Series Router

Master command reference Cisco XR 12000 Series Router Master Command Listing

QoS commands Cisco IOS XR Modular Quality of Service Command Reference for the Cisco XR 12000 Series Router

User groups and task IDs “Configuring AAA Services on Cisco IOS XR Software” module of Cisco IOS XR System Security Configuration Guide

Standards Title

No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.

—

MIBs MIBs Link

— To locate and download MIBs using Cisco IOS XR software, use the Cisco MIB Locator found at the following URL and choose a platform under the Cisco Access Products menu: http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml

RFCs Title

No new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature.

—


OL-24694-01

http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml


Technical Assistance

Description Link

The Cisco Technical Support website contains thousands of pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.

http://www.cisco.com/techsupport


OL-24694-01




OL-24694-01

Configuring Modular QoS Service Packet Classification on Cisco IOS XR Software

Packet classification identifies and marks traffic flows that require congestion management or congestion avoidance on a data path. The Modular Quality of Service (QoS) command-line interface (MQC) is used to define the traffic flows that should be classified, where each traffic flow is called a class of service, or class. Subsequently, a traffic policy is created and applied to a class. All traffic not identified by defined classes falls into the category of a default class.

This module provides the conceptual and configuration information for QoS packet classification.

Feature History for Configuring Modular QoS Packet Classification on Cisco IOS XR Software

Release Modification

Release 3.2 The Packet Classification feature was introduced with the exception of the following:

• match discard-class command

• match protocol command

• match qos-group command

• set cos command

• set qos-group command

• Level 2 classes


OL-24694-01

Configuring Modular QoS Service Packet Classification on Cisco IOS XR SoftwareContents

Contents• Prerequisites for Configuring Modular QoS Packet Classification on Cisco IOS XR Software,

page 11

• Information About Configuring Modular QoS Packet Classification on Cisco IOS XR Software, page 11

Release 3.3.0 The following commands were added:

• match cos

• match vlan

The qos-group keyword was added to the set discard-class command.

The discard-class keyword was added to the set qos-group command.

The maximum number of classes permitted per policy map increased from 16 to 32.

The following commands were added:

• match qos-group command

• set cos command

• set qos-group command

• Level 2 classes

Release 3.4.0 The match vlan command range was changed from 0 to 8096 to 1 to 4094.

Release 3.5.0 The description command was introduced.

The show policy-map interface command output was updated to show when a policy is suspended on a multilink or T3 interface.

Release 3.6.0 The Fabric Quality of Service Policies and Classes content was moved to a new module. See Configuring Fabric Quality of Service Policies and Classes on Cisco IOS XR Software.

The Policy Propagation using BGP (QPPB) feature was introduced.

The ACL deny feature was introduced.

The maximum number of class permitted for each policy map was increased to 1000.

The match-all keyword was removed from the class-map command.

Release 3.7.0 The hierarchical ingress policing feature was introduced.

Release 3.8.0 The In-Place Policy Modification feature was introduced.

Support for the match-all keyword was introduced.

ATM Layer 2 ingress QoS for Layer 2 Virtual Private Network (L2VPN) feature was introduced.

The Enhanced Hierarchical Ingress Policing feature was introduced.

Release 3.9.0 Support for three-level hierarchical policy maps was introduced.

Added the current behavior for ACL Deny, which is to reject any ACL deny statements and display a warning message unless the ACL Deny feature is configured (CSCtc30846).


OL-24694-01

Configuring Modular QoS Service Packet Classification on Cisco IOS XR SoftwarePrerequisites for Configuring Modular QoS Packet Classification on Cisco IOS XR Software

• How to Configure Modular QoS Packet Classification on Cisco IOS XR Software, page 19

• Configuration Examples for Configuring Modular QoS Packet Classification on Cisco IOS XR Software, page 47

• Additional References, page 64

Prerequisites for Configuring Modular QoS Packet Classification on Cisco IOS XR Software

The following prerequisites are required for configuring modular QoS packet classification on your network:

• You must be in a user group associated with a task group that includes the proper task IDs.The command reference guides include the task IDs required for each command. If you suspect user group assignment is preventing you from using a command, contact your AAA administrator for assistance.

• You must be familiar with Cisco IOS XR QoS configuration tasks and concepts.

Information About Configuring Modular QoS Packet Classification on Cisco IOS XR Software

To implement QoS packet classification features in this document, you must understand the following concepts:

• Packet Classification Overview, page 12

• Traffic Class Elements, page 12

• Traffic Policy Elements, page 12

• Default Traffic Class, page 13

• Class-based Unconditional Packet Marking Feature and Benefits, page 13

• Specification of the CoS for a Packet with IP Precedence, page 14

• IP Precedence Compared to IP DSCP Marking, page 16

• QoS Policy Propagation Using Border Gateway Protocol, page 16

• QoS Policy Propagation Using Border Gateway Protocol, page 16

• Hierarchical Ingress Policing, page 17

• Enhanced Hierarchical Ingress Policing, page 18

• Three-Level Hierarchical Policy Maps, page 18

• In-Place Policy Modification, page 18


OL-24694-01

Configuring Modular QoS Service Packet Classification on Cisco IOS XR SoftwareInformation About Configuring Modular QoS Packet Classification on Cisco IOS XR Software

Packet Classification OverviewPacket classification involves categorizing a packet within a specific group (or class) and assigning it a traffic descriptor to make it accessible for QoS handling on the network. The traffic descriptor contains information about the forwarding treatment (quality of service) that the packet should receive. Using packet classification, you can partition network traffic into multiple priority levels or classes of service. The source agrees to adhere to the contracted terms and the network promises a quality of service. Traffic policers and traffic shapers use the traffic descriptor of a packet to ensure adherence to the contract.

Traffic policers and traffic shapers rely on packet classification features, such as IP precedence, to select packets (or traffic flows) traversing a router or interface for different types of QoS service. For example, by using the three precedence bits in the type of service (ToS) field of the IP packet header, you can categorize packets into a limited set of up to eight traffic classes. After you classify packets, you can use other QoS features to assign the appropriate traffic handling policies including congestion management, bandwidth allocation, and delay bounds for each traffic class.

Traffic Class ElementsThe purpose of a traffic class is to classify traffic on your router. Use the class-map command to define a traffic class.

A traffic class contains three major elements: a name, a series of match commands, and, if more than one match command exists in the traffic class, an instruction on how to evaluate these match commands. The traffic class is named in the class-map command. For example, if you use the word cisco with the class-map command, the traffic class would be named cisco.

The match commands are used to specify various criteria for classifying packets. Packets are checked to determine whether they match the criteria specified in the match commands. If a packet matches the specified criteria, that packet is considered a member of the class and is forwarded according to the QoS specifications set in the traffic policy. Packets that fail to meet any of the matching criteria are classified as members of the default traffic class. See the Default Traffic Class, page 13.

The instruction on how to evaluate these match commands needs to be specified if more than one match criterion exists in the traffic class. The evaluation instruction is specified with the class-map match-any command. If the match-any option is specified as the evaluation instruction, the traffic being evaluated by the traffic class must match at least one of the specified criteria. If the match-all option is specified, the traffic must match all of the match criteria.

Traffic Policy ElementsThe purpose of a traffic policy is to configure the QoS features that should be associated with the traffic that has been classified in a user-specified traffic class or classes. The policy-map command is used to create a traffic policy. A traffic policy contains three elements: a name, a traffic class (specified with the class command), and the QoS policies. The name of a traffic policy is specified in the policy map MQC (for example, the policy-map policy1 command creates a traffic policy named policy1). The traffic class that is used to classify traffic to the specified traffic policy is defined in class map configuration mode. After choosing the traffic class that is used to classify traffic to the traffic policy, the user can enter the QoS features to apply to the classified traffic.

The MQC does not necessarily require that users associate only one traffic class to one traffic policy. When packets match to more than one match criterion, as many as 1000 traffic classes can be associated to a single traffic policy. The 512 class maps include the default class and the classes of the child policies, if any.


OL-24694-01


The order in which classes are configured in a policy map is important. The match rules of the classes are programmed into the TCAM in the order in which the classes are specified in a policy map. Therefore, if a packet can possibly match multiple classes, only the first matching class is returned and the corresponding policy is applied.

The function of these commands is described more thoroughly in the Cisco IOS XR Modular Quality of Service Command Referencefor the Cisco XR 12000 Series Router.

The traffic policy configuration task is described in Creating a Traffic Policy, page 22.

Default Traffic ClassUnclassified traffic (traffic that does not meet the match criteria specified in the traffic classes) is treated as belonging to the default traffic class.

If the user does not configure a default class, packets are still treated as members of the default class. However, by default, the default class has no enabled features. Therefore, packets belonging to a default class with no configured features have no QoS functionality. These packets are then placed into a first in, first out (FIFO) queue and forwarded at a rate determined by the available underlying link bandwidth. This FIFO queue is managed by a congestion avoidance technique called tail drop. For further information about congestion avoidance techniques, such as tail drop, see Configuring Modular QoS Congestion Avoidance on Cisco IOS XR Software module.

Class-based Unconditional Packet Marking Feature and BenefitsThe Class-based, Unconditional Packet Marking feature provides users with a means for efficient packet marking by which the users can differentiate packets based on the designated markings.

The Class-based, Unconditional Packet Marking feature allows users to perform the following tasks:

• Mark packets by setting the IP precedence bits or the IP differentiated services code point (DSCP) in the IP ToS byte.

• Mark Multiprotocol Label Switching (MPLS) packets by setting the EXP bits within the imposed or topmost label.

• Mark packets by setting the Layer 2 class-of-service (CoS) value.

• Mark packets by setting the value of the qos-group argument.

• Mark packets by setting the value of the discard-class argument.

Unconditional packet marking allows you to partition your network into multiple priority levels or classes of service, as follows:

• Use QoS unconditional packet marking to set the IP precedence or IP DSCP values for packets entering the network. Routers within your network can then use the newly marked IP precedence values to determine how the traffic should be treated.

For example, weighted random early detection (WRED), a congestion avoidance technique, uses IP precedence values to determine the probability that a packet is dropped. In addition, low-latency queueing (LLQ) can then be configured to put all packets of that mark into the priority queue.

• Use QoS unconditional packet marking to assign MPLS packets to a QoS group. The router uses the QoS group to determine how to prioritize packets for transmission. To set the QoS group identifier on MPLS packets, use the set qos-group command in policy map class configuration mode.


OL-24694-01


• Use CoS unconditional packet marking to assign packets to set the priority value of 802.1p/Inter-Switch Link (ISL) packets. The router uses the CoS value to determine how to prioritize packets for transmission and can use this marking to perform Layer 2-to-Layer 3 mapping. To set the Layer 2 CoS value of an outgoing packet, use the set cos command in policy map configuration mode.

The configuration task is described in the Configuring Class-based Unconditional Packet Marking, page 26.

Note

Specification of the CoS for a Packet with IP PrecedenceUse of IP precedence allows you to specify the CoS for a packet. You use the three precedence bits in the ToS field of the IP version 4 (IPv4) header for this purpose. Figure 1 shows the ToS field.

Figure 1 IPv4 Packet Type of Service Field

Using the ToS bits, you can define up to eight classes of service. Other features configured throughout the network can then use these bits to determine how to treat the packet in regard to the ToS to grant it. These other QoS features can assign appropriate traffic-handling policies, including congestion management strategy and bandwidth allocation. For example, although IP precedence is not a queueing feature, queueing features, such as LLQ, can use the IP precedence setting of the packet to prioritize traffic.

By setting precedence levels on incoming traffic and using them in combination with the Cisco IOS XR QoS queueing features, you can create differentiated service.

So that each subsequent network element can provide service based on the determined policy, IP precedence is usually deployed as close to the edge of the network or administrative domain as possible. You can think of IP precedence as an edge function that allows core, or backbone, QoS features, such as WRED, to forward traffic based on CoS. IP precedence can also be set in the host or network client, but this setting can be overridden by policy within the network.

The configuration task is described in the Configuring Class-based Unconditional Packet Marking, page 26.

IPv4 packet

Data

ToS field

3-bit precedence

1675

7


OL-24694-01


IP Precedence Bits Used to Classify Packets

Use the three IP precedence bits in the ToS field of the IP header to specify the CoS assignment for each packet. As mentioned earlier, you can partition traffic into a maximum of eight classes and then use policy maps to define network policies in terms of congestion handling and bandwidth allocation for each class.

For historical reasons, each precedence corresponds to a name. These names are defined in RFC 791. Table 1 lists the numbers and their corresponding names, from least to most important.

The IP precedence feature allows you considerable flexibility for precedence assignment. That is, you can define your own classification mechanism. For example, you might want to assign precedence based on application or access router.

Note IP precedence bit settings 6 and 7 are reserved for network control information, such as routing updates.

IP Precedence Value Settings

By default, Cisco IOS XR software leaves the IP precedence value untouched. This preserves the precedence value set in the header and allows all internal network devices to provide service based on the IP precedence setting. This policy follows the standard approach stipulating that network traffic should be sorted into various types of service at the edge of the network and that those types of service should be implemented in the core of the network. Routers in the core of the network can then use the precedence bits to determine the order of transmission, the likelihood of packet drop, and so on.

Because traffic coming into your network can have the precedence set by outside devices, we recommend that you reset the precedence for all traffic entering your network. By controlling IP precedence settings, you prohibit users that have already set the IP precedence from acquiring better service for their traffic simply by setting a high precedence for all of their packets.

The class-based unconditional packet marking, LLQ, and WRED features can use the IP precedence bits.

You can use the following features to set the IP precedence in packets:

• Class-based unconditional packet marking. See Configuring Class-based Unconditional Packet Marking, page 26.

• QoS Policy Propagation Using Border Gateway Protocol (QPPB). See QoS Policy Propagation Using Border Gateway Protocol, page 16.

Table 1 IP Precedence Values

Number Name

0 routine

1 priority

2 immediate

3 flash

4 flash-override

5 critical

6 internet

7 network


OL-24694-01


IP Precedence Compared to IP DSCP MarkingIP precedence and DSCP markings are used to decide how packets should be treated in WRED.

The IP DSCP value is the first six bits in the ToS byte, and the IP precedence value is the first three bits in the ToS byte. The IP precedence value is actually part of the IP DSCP value. Therefore, both values cannot be set simultaneously. If both values are set simultaneously, the packet is marked with the IP DSCP value.

If you need to mark packets in your network and all your devices support IP DSCP marking, use the IP DSCP marking to mark your packets because the IP DSCP markings provide more unconditional packet marking options. If marking by IP DSCP is undesirable, however, or if you are unsure if the devices in your network support IP DSCP values, use the IP precedence value to mark your packets. The IP precedence value is likely to be supported by all devices in the network.

You can set up to 8 different IP precedence markings and 64 different IP DSCP markings.

QoS Policy Propagation Using Border Gateway Protocol Packet classification identifies and marks traffic flows that require congestion management or congestion avoidance on a data path. Quality-of-service Policy Propagation Using Border Gateway Protocol (QPPB) allows you to remark packets by IP precedence and QoS Group ID, based on Border Gateway Protocol (BGP) community lists, BGP autonomous system (AS) paths, Source Prefix address, or Destination Prefix address. After a packet has been classified, you can use other QoS features such as policing and weighted random early detection (WRED) to specify and enforce policies to fit your business model.

QoS Policy Propagation Using BGP (QPPB) allows you to map BGP prefixes and attributes to Cisco Express Forwarding (CEF) parameters that can be used to enforce traffic policing. QPPB allows BGP policy set in one location of the network to be propagated using BGP to other parts of the network, where appropriate QoS policies can be created.

QPPB allows you to classify packets based on the following:

• Access lists.

• BGP community lists. You can use community lists to create groups of communities to use in a match clause of a route policy. As with access lists, you can create a series of community lists.

• BGP autonomous system paths. You can filter routing updates by specifying an access list on both incoming and outbound updates, based on the BGP autonomous system path.

• Source Prefix address. You can classify a set of prefixes coming from the address of a BGP neighbor(s).

• Destination Prefix address. You can classify a set of BGP prefixes.

Classification can be based on the source or destination address of the traffic. BGP and CEF must be enabled for the QPPB feature to be supported.


OL-24694-01


ACL DenyA QOS policy can use a class map which in turn uses access lists (ACLs) to match packets. Unlike interface ACLs, QOS ACLs (as per the MQC specification) ignore permit and deny access control entries (ACEs). The ACL Deny feature allows deny ACEs in ACLs in a class map to be processed as deny actions. If the ACL Deny feature is not configured (the default), any deny ACEs in a class map are rejected and a warning message is displayed to this effect.

The ACL deny feature takes into account the action associated with the access control entry (permit or deny), treating the deny action in an ACL differently from the permit action. The ACE permit and deny actions in an access group within a class map are classified differently. Traffic matching an ACL with a deny action skips the class map and attempts to match subsequent classes. If there is no deny ACE for an ACL, the packet skips to the next class.

Hierarchical Ingress PolicingThe Hierarchical Ingress Policing feature is an MQC-based solution that supports hierarchical policing on ingress interfaces.

This feature allows enforcement of service level agreements (SLA) while applying the classification submodel for different QoS classes on the inbound interface.

The hiearachical ingress policing provides support at two levels:

• Parent level

• Child level

Hierarchical policing allows policing of individual traffic classes as well as on a collection of traffic classes. This is useful in a situation where you want the collective police rate to be less than the sum of individual police (or maximum) rates.

Hierarchical Policing for Frame Relay on Layer 2 VPN

To support hierarchical policing for Frame Relay on Layer 2 VPN, a policy with matching criteria based on the Frame Relay discard eligibility (DE) bit is attached on the main interface, which in turn produces a match, and applies the action for Layer 2 VPN. The supported hierarchical models are:

• 1CnD

• nCmD

The parent policy and child policy are configured with independent policers. The parent policy maintains an aggregate rate per permanent virtual circuit (PVC) of the Frame Relay subinterface. The child policy contains the match criteria based on the Frame Relay discard eligibility (DE) bit and a class default.

Note In the parent hierarchical policer, only a class default is supported. For the class default, the Frame Relay discard eligibility (DE) bit is set to zero.


OL-24694-01


Hierarchical Policing for ATM on Layer 2 VPN

A two-level hierarchical policy map is supported in the ingress direction to support policing of the VBR.2 and VBR.3 type of traffic. The parent policy contains the policing configuration for the peak cell rate (PCR) bucket matching on all traffic (excluding OAM traffic). The child policy contains the policing configuration for the sustainable cell rate (SCR) bucket, and typically matches on the CLP0 cells.

The marking actions are supported in the child policy; whereas the policing actions are allowed in the parent policy.

Note Only two policer buckets per Layer 2 circuit is allowed; one in the parent policy that defines the peak rate, and one in the child policy that defines the sustainable rate. Typically, the CLP0 cells are sent to the SCR bucket, but it is possible to police the CLP0 bit or CLP1 bit or both in the SCR bucket. To achieve this, the classification criteria is used in the child policy.

Enhanced Hierarchical Ingress PolicingIn hierarchical ingress policing, traffic is policed first at the child policer level and then at the parent policer level. It is possible for traffic that conforms to the maximum rate specified by the child policer to be dropped by the parent policer. This can occur when an exceed action in the child policer is an action other than to drop ingress traffic.

In Enhanced Hierarchical Ingress Policing, the child-conform-aware command prevents the parent policer from dropping any ingress traffic that conforms to the maximum rate specified in the child policer.

Three-Level Hierarchical Policy MapsThe three-level hierarchical policy map feature supports three levels of hierarchy in the egress direction. These levels are:

• Parent

• Child

• Grand-child

Using three levels allows classification of traffic going into the priority queue and the policing of the classified traffic streams at different rates. This means that the queue properties such as bandwidth, bandwidth remaining, shape, priority, random detect, and queue-limit still apply for all of the traffic streams together.

In-Place Policy ModificationThe In-Place Policy Modification feature allows you to modify a QoS policy even when the QoS policy is attached to one or more interfaces. When you modify the QoS policy attached to one or more interfaces, the QoS policy is automatically modified on all the interfaces to which the QoS policy is attached. A modified policy is subject to the same checks that a new policy is subject to when it is bound to an interface


OL-24694-01

Configuring Modular QoS Service Packet Classification on Cisco IOS XR SoftwareHow to Configure Modular QoS Packet Classification on Cisco IOS XR Software

However, if the policy modification fails on any one of the interfaces, an automatic rollback is initiated to ensure that the earlier policy is effective on all the interfaces. After successfully modifying a policy, the modifications take effect on all the interfaces to which the policy is attached.

The configuration session is blocked until the policy modification is successful on all the relevant interfaces. In case of a policy modification failure, the configuration session is blocked until the rollback is completed on all relevant interfaces.

Note You cannot resume the configuration on the routers until the configuration session is unblocked.

When a QoS policy attached to an interface is modified, QoS is first disabled on the interface, hardware is reprogrammed for the modified policy, and QoS is reenabled on the interface. For a short period of time, no QoS policy is active on the interface. In addition, the QoS statistics for the policy that is attached to an interface is lost (reset to 0) when the policy is modified.

Recommendations for Using In-Place Policy Modification

For a short period of time while a QoS policy is being modified, no QoS policy is active on the interface. In the unlikely event that the QoS policy modification and rollback both fail, the interface is left without a QoS policy.

For these reasons, it is best to modify QoS policies that affect the fewest number of interfaces at a time. Use the show policy-map targets command to identify the number of interfaces that will be affected during policy map modification.

How to Configure Modular QoS Packet Classification on Cisco IOS XR Software

This section contains instructions for the following tasks:

• Creating a Traffic Class, page 20 (required)

• Creating a Traffic Policy, page 22 (required)

• Attaching a Traffic Policy to an Interface, page 24 (required)

• Configuring Class-based Unconditional Packet Marking, page 26 (required)

• Configuring QoS Policy Propagation Using Border Gateway Protocol, page 30 (optional)

• Configuring ACL Deny, page 34 (optional)

• Configuring Hierarchical Ingress Policing, page 36 (optional)

• Configuring Enhanced Hierarchical Ingress Policing, page 38

• Configuring a Three-Level Hierarchical Policy, page 40

• Setting the Frame Relay Discard Eligibility Bit, page 44

• Setting the Frame Relay Discard Eligibility Bit, page 44 (optional)

• Matching the Frame Relay DE Bit, page 45 (optional)

• Matching the ATM CLP Bit, page 46 (optional)


OL-24694-01


Creating a Traffic ClassTo create a traffic class containing match criteria, use the class-map command to specify the traffic class name, and then use the following match commands in class-map configuration mode, as needed.

For conceptual information, see the Traffic Class Elements, page 12.

Restrictions

All match commands specified in this configuration task are considered optional, but you must configure at least one match criterion for a class.

SUMMARY STEPS

1. configure

2. class-map [match-any] [match-all] class-map-name

3. match access-group [ipv4 | ipv6] access-group-name

4. match cos [cos-value] [cos-value1 ... cos-value7]

5. match dscp [ipv4 | ipv6] dscp-value [dscp-value1 ... dscp-value7]

6. match mpls experimental topmost exp-value [exp-value1 ... exp-value7]

7. match precedence [ipv4 | ipv6] precedence-value [precedence-value1 ... precedence-value7]

8. match qos-group [qos-group-value1 ... qos-group-value7]

9. match vlan [vlanid | beginvlan-endvlan] [{vlanid | beginvlan-endvlan} ... {vlanid | beginvlan-endvlan}]

10. endorcommit

DETAILED STEPS

Command or Action Purpose

Step 1 configure

Example:RP/0/0/CPU0:router# configure

Enters global configuration mode.

Step 2 class-map [match-all] [match-any] class-map-name

Example:RP/0/0/CPU0:router(config)# class-map class201

Enters class map configuration mode.

• Creates a class map to be used for matching packets to the class whose name you specify.

• If you specify match-any, one of the match criteria must be met for traffic entering the traffic class to be classified as part of the traffic class. This is the default.

• If you specify match-all, all of the match criteria must be met for traffic entering the traffic class to be classified as part of the traffic class.


OL-24694-01


Step 3 match access-group [ipv4 | ipv6] access-group-name

Example:RP/0/0/CPU0:router(config-cmap)# match access-group ipv4 map1

(Optional) Configures the match criteria for a class map based on the specified access control list (ACL) name.

Step 4 match cos cos-value [cos-value1 ... cos-value7]

Example:RP/0/0/CPU0:router(config-cmap)# match cos 1

(Optional) Specifies a cos-value in a class map to match packets.

• The cos-value argument is specified as an integer from 0 to 7.

Step 5 match dscp [ipv4 | ipv6] dscp-value [dscp-value ... dscp-value]

Example:RP/0/0/CPU0:router(config-cmap)# match dscp ipv4 15

(Optional) Identifies a specific DSCP value as a match criterion.

• The value range is from 0 to 63.

• Reserved keywords can be specified instead of numeric values.

Step 6 match mpls experimental topmost exp-value [exp-value1 ... exp-value7]

Example:RP/0/0/CPU0:router(config-cmap)# match mpls experimental topmost 3

(Optional) Configure a class map so that the three-bit experimental field in the topmost Multiprotocol Label Switching (MPLS) labels are examined for experimental (EXP) field values.

The value range is from 0 to 7.

Step 7 match precedence [ipv4 | ipv6] precedence-value [precedence-value1 ... precedence-value6]

Example:RP/0/0/CPU0:router(config-cmap)# match precedence ipv4 5

(Optional) Identifies IP precedence values as match criteria.

• The value range is from 0 to 7.

• Reserved keywords can be specified instead of numeric values.

Step 8 match qos-group [qos-group-value1 ... qos-group-value8]

Example:RP/0/0/CPU0:router(config-cmap)# match qos-group 1 2 3 4 5 6 7 8

(Optional) Specifies service (QoS) group values in a class map to match packets.

• A QoS group value identifier argument is specified as the exact value from 0 to 31.

• Up to 8 values (separated by spaces) can be entered in one match statement.

• The match qos-group command is supported only on an egress policy.

Step 9 match vlan [vlanid | beginvlan-endvlan] [{vlanid | beginvlan-endvlan} ... {vlanid | beginvlan-endvlan}]

Example:RP/0/0/CPU0:router(config-cmap)# match vlan 1

(Optional) Specifies a VLAN ID or range of VLAN IDs in a class map to match packets.

• The vlan ID argument is specified as an integer from 0 to 4096.

• The total number of supported vlan values is 300.



OL-24694-01


Creating a Traffic PolicyTo create a traffic policy, use the policy-map global configuration command to specify the traffic policy name.

The traffic class is associated with the traffic policy when the class command is used. The class command must be issued after you enter the policy map configuration mode. After entering the class command, the router is automatically in policy map class configuration mode, which is where the QoS policies for the traffic policy are defined.

The following class-actions are supported:

• bandwidth—Configures the bandwidth for the class. See the Configuring Modular Quality of Service Congestion Management on Cisco IOS XR Software module.

• police—Police traffic. See the Configuring Modular Quality of Service Congestion Management on Cisco IOS XR Software module.

• priority—Assigns priority to the class. See the Configuring Modular Quality of Service Congestion Management on Cisco IOS XR Software module.

• queue-limit—Configures queue-limit (tail drop threshold) for the class. See the Configuring Modular QoS Congestion Avoidance on Cisco IOS XR Software module.

• random-detect—Enables Random Early Detection. See the Configuring Modular QoS Congestion Avoidance on Cisco IOS XR Software module.

• service-policy—Configures a child service policy.

• set—Configures marking for this class. See the Class-based Unconditional Packet Marking Feature and Benefits, page 13.

• shape—Configures shaping for the class. See the Configuring Modular Quality of Service Congestion Management on Cisco IOS XR Software module.

Step 10 end

or

commit

Example:RP/0/0/CPU0:router(config-cmap)# end

or

RP/0/0/CPU0:router(config-cmap)# commit

Saves configuration changes.

• When you issue the end command, the system prompts you to commit changes:

Uncommitted changes found, commit them before exiting(yes/no/cancel)?[cancel]:

– Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

– Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

– Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

• Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.



OL-24694-01


For additional commands that can be entered as match criteria, see the Cisco IOS XR Modular Quality of Service Command Reference for the Cisco XR 12000 Series Router.

For conceptual information, see Traffic Policy Elements, page 12.

Restrictions

Level 2 hierarchical classes are not supported.

SUMMARY STEPS

1. configure

2. policy-map policy-name

3. class class-name

4. set precedence [tunnel] precedence-value

5. endorcommit

DETAILED STEPS


Step 1 configure



Step 2 policy-map policy-name

Example:RP/0/0/CPU0:router(config)# policy-map policy1

Enters policy map configuration mode.

• Creates or modifies a policy map that can be attached to one or more interfaces to specify a service policy.

Step 3 class class-name

Example:RP/0/0/CPU0:router(config-pmap)# class class1

Specifies the name of the class whose policy you want to create or change.

Step 4 set precedence [tunnel] precedence-value

Example:RP/0/0/CPU0:router(config-pmap-c)# set precedence 3

Sets the precedence value in the IP header.

Note A policy configured with the set precedence tunnel command or the set dscp tunnel command can be applied on an IPSec interface in the egress direction.


OL-24694-01


Attaching a Traffic Policy to an InterfaceAfter the traffic class and traffic policy are created, you must use the service-policy interface configuration command to attach a traffic policy to an interface, and to specify the direction in which the policy should be applied (either on packets coming into the interface or packets leaving the interface).

For additional commands that can be entered in policy map class configuration mode, see the Cisco IOS XR Modular Quality of Service Command Referencefor the Cisco XR 12000 Series Router.

Prerequisites

A traffic class and traffic policy must be created before attaching a traffic policy to an interface.

Restrictions

None

SUMMARY STEPS

1. configure

2. interface type interface-path-id

3. service-policy {input | output} policy-map

4. endorcommit

5. show policy-map interface type interface-path-id [input | output]

Step 5 end

or

commit

Example:RP/0/0/CPU0:router(config-pmap-c)# end

or

RP/0/0/CPU0:router(config-pmap-c)# commit










OL-24694-01


DETAILED STEPS


Step 1 configure



Step 2 interface type interface-path-id

Example:RP/0/0/CPU0:router(config)# interface gigabitethernet 0/1/0/9

Enters interface configuration mode and configures an interface.

Step 3 service-policy {input | output} policy-map

Example:RP/0/0/CPU0:router(config-if)# service-policy output policy1

Attaches a policy map to an input or output interface to be used as the service policy for that interface.

• In this example, the traffic policy evaluates all traffic leaving that interface.

Step 4 end

or

commit

Example:RP/0/RSP0/CPU0:router(config-if)# end

or

RP/0/RSP0/CPU0:router(config-if)# commit







Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.

Step 5 show policy-map interface type interface-path-id [input | output]

Example:RP/0/RSP0/CPU0:router# show policy-map interface gigabitethernet 0/1/0/9

(Optional) Displays statistics for the policy on the specified interface.


OL-24694-01


Configuring Class-based Unconditional Packet MarkingThis configuration task explains how to configure the following class-based, unconditional packet marking features on your router:

• IP precedence value

• IP DSCP value

• QoS group value (ingress only)

•

• MPLS experimental value

• SRP priority (egress only)

• Discard class (ingress only)

• ATM CLP

Note IPv4 and IPv6 QoS actions applied to MPLS tagged packets are not supported. The configuration is accepted, but no action is taken.

SUMMARY STEPS

1. configure


3. class class-name

Choose one set command per class

4. set precedence [tunnel] number

5. set dscp [tunnel] dscp-value

6. set qos-group qos-group-value

7.

8. set mpls experimental {imposition | topmost} exp-value

9. set srp-priority priority-value

10. set discard-class discard-class-value

11. set atm-clp

12. exit

13. exit



16. endorcommit

17. show policy-map interface type instance [input | output]


OL-24694-01


Note Although this task illustrates all of the possible set commands, only one set command is supported per class.

DETAILED STEPS


Step 1 configure









Enters policy class map configuration mode.

• Specifies the name of the class whose policy you want to create or change.

Choose one set command per class

Step 4 set precedence [tunnel] number

Example:RP/0/0/CPU0:router(config-pmap-c)# set precedence 1

Sets the precedence value in the IP header.

• The tunnel keyword sets the IP precedence on the outer IP header. This option is available only on a Cisco XR 12000 Series Router with IPSec installed and configured.

Step 5 set dscp [tunnel] dscp-value

Example:RP/0/0/CPU0:router(config-pmap-c)# set dscp 5

Marks a packet by setting the DSCP in the ToS byte.

• The tunnel keyword sets the IP DSCP on the outer IP header. This option is available only on a Cisco XR 12000 Series Router with IPSec installed and configured.

Step 6 set qos-group qos-group-value

Example:RP/0/0/CPU0:router(config-pmap-c)# set qos-group 31

Sets the QoS group identifiers on IPv4 or MPLS packets.

The set qos-group command is supported only on an ingress policy.

Step 7 set mpls experimental {imposition | topmost} exp-value

Example:RP/0/0/CPU0:router(config-pmap-c)# set mpls experimental imposition 3

Sets the experimental value of the MPLS packet top-most or imposition labels.

• imposition can be used only in service policies that are attached in the ingress policy.

Step 8 set srp-priority priority-value

Example:RP/0/0/CPU0:router(config-pmap-c)# set srp-priority 3

Sets the spatial reuse protocol (SRP) priority value of an outgoing packet.

• This command can be used only in service policies that are attached in the output direction of an interface.


OL-24694-01


Step 9 set discard-class discard-class-value

Example:RP/0/0/CPU0:router(config-pmap-c)# set discard-class 3

Sets the discard class on IP Version 4 (IPv4) or Multiprotocol Label Switching (MPLS) packets.

• This command can be used only in service policies that are attached in the ingress policy.

Step 10 set atm-clp

Example:RP/0/0/CPU0:router(config-pmap-c)# set atm-clp

Sets the cell loss priority (CLP) bit.

Step 11 exit

Example:RP/0/0/CPU0:router(config-pmap-c)# exit

Returns the router to policy map configuration mode.

Step 12 exit

Example:RP/0/0/CPU0:router(config-pmap)# exit

Returns the router to global configuration mode.


Example:RP/0/0/CPU0:router(config)# interface pos 0/2/0/0


Step 14 service-policy {input | output]} policy-map






OL-24694-01


Step 15 end

or

commit

Example:RP/0/0/CPU0:router(config-if)# end

or

RP/0/0/CPU0:router(config-if)# commit









Example:RP/0/0/CPU0:router# show policy-map interface pos 0/2/0/0

(Optional) Displays policy configuration information for all classes configured for all service policies on the specified interface.



OL-24694-01


Configuring QoS Policy Propagation Using Border Gateway Protocol This section explains how to configure Policy Propagation Using Border Gateway Protocol (BGP) on a router based on BGP community lists, BGP autonomous system paths, access lists, source prefix address, or destination prefix address.

Policy Propagation Using BGP Configuration Task List

Policy propagation using BGP allows you to classify packets by IP precedence and/or QoS group ID, based on BGP community lists, BGP autonomous system paths, access lists, source prefix address and destination prefix address. After a packet has been classified, you can use other quality-of-service features such as weighted random early detection (WRED) to specify and enforce policies to fit your business model.

Overview of Tasks

To configure Policy Propagation Using BGP, perform the following basic tasks:

• Configure BGP and Cisco Express Forwarding (CEF). To configure BGP, see Cisco IOS XR Routing Configuration Guide. To configure CEF, see Cisco IOS XR IP Address and Services Configuration Guide for the Cisco XR 12000 Series Router.

• Configure a BGP community list or access list.

• Define the route policy. Set the IP precedence and/or QoS group ID, based on the BGP community list, BGP autonomous system path, access list, source prefix address or destination prefix address.

• Apply the route policy to BGP.

• Configure QPPB on the desired interfaces.

• Configure and enable a QoS Policy to use the above classification (IP precedence or QoS group ID). To configure committed access rate (CAR), WRED and tail drop, see the Configuring Modular QoS Congestion Avoidance on Cisco IOS XR Software module.

Defining the Route Policy

This task defines the route policy used to classify BGP prefixes with IP precedence or QoS group ID. See Route Policy Configuration: Example, page 54 for examples of route policy configuration.

Prerequisites

Configure the BGP community list, or access list, for use in the route policy.


OL-24694-01


SUMMARY STEPS

1. configure

2. route-policy name

3. set qos-group qos-group-value

4. end-policy

DETAILED STEPS


Step 1 configure



Step 2 route-policy name

Example:RP/0/0/CPU0:router(config)# route-policycostA

Enters route policy configuration mode and specifies the name of the route policy to be configured.

Step 3 set qos-group qos-group-value

Example:RP/0/0/CPU0:router(config-pmap-c)# set qos-group 31

Sets the QoS group identifiers on IPv4 or MPLS packets.

The set qos-group command is supported only on an ingress policy.

Step 4 end-policy

Example:RP/0/0/CPU0:router(config)# end-policy

Ends the definition of a route policy and exits route policy configuration mode.


OL-24694-01


Applying the Route Policy to BGP

This task applies the route policy to BGP.

Prerequisites

Configure BGP and Cisco Express Forwarding on the Cisco XR 12000 Series Router router.

SUMMARY STEPS

1. configure

2. router bgp as-number

3. address-family address-prefix

4. table-policy policy-name

5. end

or

commit

DETAILED STEPS


Step 1 configure



Step 2 router bgp as-number

Example:RP/0/0/CPU0:router(config)# router bgp 120

Enters BGP configuration mode, allowing you to configure the BGP routing process.

Step 3 address-family address-prefix

Example:RP/0/0/CPU0:router(config-bgp)#address-family ipv4 unicast

Enters address family configuration mode, allowing you to configure an address family.


OL-24694-01


Step 4 table-policy policy-name

Example:RP/0/0/CPU0:router(config-bgp-af)#table-policy qppb-comm6200

Applies a routing policy to routes being installed into the routing table.

Step 5 end

or

commit


or











OL-24694-01


Configuring QPPB on the Desired Interfaces

This task applies QPPB to a specified interface. The traffic begins to be classified, based on matching prefixes in the route policy. The source or destination IP address of the traffic can be used to match the route policy.

SUMMARY STEPS

1. configure


3. ipv4 bgp policy propagation input {ip-precedence | qos-group} {destination [ip-precedence {destination | source}] | source [ip-precedence {destination | source}] }

DETAILED STEPS

Configuring ACL DenyACL deny allows traffic matching an ACL with a deny access control entry (ACE) to skip the class map and attempt to match subsequent classes. If there is no deny ACE for the ACL, the ACL Deny feature does not take effect.

The ACL deny feature is disabled by default.

Note Configuring ACL Deny displays a warning message which mentions that the commit takes effect only after a LC reload.


Step 1 configure




Example:RP/0/0/CPU0:router(config)#interface POS 0/0/0/0

Enters interface configuration mode and associates one or more interfaces to the VRF.

Step 3 ipv4 bgp policy propagation input {ip-precedence | qos-group} {destination [ip-precedence {destination | source}] | source [ip-precedence {destination | source}] }

Example:RP/0/0/CPU0:router(config)#ipv4 bgp policy propagation input qos-group destination

Enables QPPB on an interface


OL-24694-01


SUMMARY STEPS

1. configure

2. hw-module qos acl-deny enable location node-id

3. endorcommit

DETAILED STEPS


Step 1 configure



Step 2 hw-module qos acl-deny enable location node-id

Example:RP/0/0/CPU0:router(config)# hw-module qos acl-deny enable location 0/2/0

Enables the ACL deny feature for the specified location.

Note When you configure the ACL Deny feature, the following warning message is displayed: The commit will take effect only after a LC reload.

Step 3 end

or

commit

Example:RP/0/0/CPU0:router(config)# end

or

RP/0/0/CPU0:router(config)# commit









OL-24694-01


Configuring Hierarchical Ingress PolicingThe hierarchical ingress policing is supported at two levels:

• Parent level

• Child level

Restrictions

The Modular QoS command-line interface (MQC) provides hierarchical configuration, with the following limitations:

• The parent level consists of class defaults or class maps that match VLAN (in the case of nCmD policy).

• The only allowed action on the parent class is to police without set actions.

• The child level consists of a flat policy that can be configured with the supported action or the class-map command.

• The parent policer value is used as a reference bandwidth for the child policy whenever required.

SUMMARY STEPS

1. configure


3. class class-name

4. service-policy policy-name

5. police rate percent percentage

6. conform-action action

7. exceed-action action

8. exit

DETAILED STEPS


Step 1 configure




Example:RP/0/0/CPU0:router(config)# policy-map parent


Creates or modifies a policy map that can be attached to one or more interfaces to specify a service policy


OL-24694-01



Example:RP/0/0/CPU0:router(config-pmap)# class class-default

Enters policy map class configuration mode.


Step 4 service-policy policy-name

Example:RP/0/0/CPU0:router(config-pmap-c)# service-policy child

Attaches a policy map to an input or output interface.

Step 5 police rate percent percentage

Example:RP/0/0/CPU0:router(config-pmap-c)# police rate percent 50

Configures traffic policing and enters policy map police configuration mode.

Step 6 conform-action action

Example:RP/0/0/CPU0:router(config-pmap-c-police)# conform-action transmit

Configures the action to take on packets that conform to the rate limit. The allowed action is:

transmit—Transmits the packets.

Step 7 exceed-action action

Example:RP/0/0/CPU0:router(config-pmap-c-police)# exceed-action drop

Configures the action to take on packets that exceed the rate limit. The allowed action is:

drop—Drops the packet.

Step 8 end

or

commit

Example:RP/0/0/CPU0:router(config-pmap-c-police)# end

or

RP/0/0/CPU0:router(config-pmap-c-police)# commit










OL-24694-01


Configuring Enhanced Hierarchical Ingress PolicingThe difference between configuring enhanced hierarchical ingress policing and configuring hierarchical ingress policing is the addition of the child-conform-aware command.

When used in the parent policer, the child-conform-aware command prevents the parent policer from dropping any ingress traffic that conforms to the maximum rate specified in the child policer.

Restrictions

The Modular QoS command-line interface (MQC) provides enhanced hierarchical ingress policing configuration, with the following limitations:

• Supported on 10 Gbps IP Services Engine (Engine 5) line cards

• Ingress direction only.

• Three-level hierarchical policies are not supported.

• Parent Policy

– Matched on VLAN or DLCI classes for nCmD.

– Can be used in the parent class-default.

– Only a single-rate two-color policer with default conform and exceed actions on the parent policy map is supported; parent policer remarking actions are not allowed.

– Parent policer conform rate must be greater than or equal to the sum of child policer conform rates.

• Child Policy

– Can be used in any child classes in nCmD/1CnD/nCnD models.

– Only police and set actions are allowed; queue actions in child classes are not allowed.

– Two-rate three-color policers in child classes are not supported.

SUMMARY STEPS

1. configure


3. class class-name


5. police rate percent percentage

6. child-conform-aware



9. end


OL-24694-01


DETAILED STEPS


Step 1 configure






Creates or modifies a policy map that can be attached to one or more interfaces to specify a service policy.







Attaches a policy map to an input or output interface.

Step 5 police rate percent percentage

Example:RP/0/0/CPU0:router(config-pmap-c)# police rate percent 50


Step 6 child-conform-aware

Example:RP/0/0/CPU0:router(config-pmap-c-police)# child-conform-aware

Prevents the parent policer from dropping any ingress traffic that conforms to the maximum rate specified in a child policer.


Example:RP/0/0/CPU0:router(config-pmap-c-police)# conform-action transmit


transmit—Transmits the packets.






OL-24694-01


Configuring a Three-Level Hierarchical PolicyThree-level hierarchical policy supports three levels:

• Parent level

• Child level

• Grand-child level

Restrictions

The following requirements and restrictions apply when using three-level hierarchical policy maps:

• Three-level hierarchical policy maps are not supported on:

– ingress streams

– ATM interfaces

– Layer 2 interfaces

• Two-rate three-color policers are not allowed on the child or grand-child level.

• Only 64 queues can be configured in the child-level policy map.

• Only a total of 1000 class maps can exist per policy map.

• IPv6 ACLs is not supported as a match criteria with three-level policy maps if WRED is configured at the child level.

The following requirements and restrictions exist for each of the three levels:

Parent Level

• Supports only class-default and match vlan, match dlci

Step 9 end

or

commit


or











OL-24694-01


• Supported actions are:

– shape average (optional)

– service-policy

Child Level


– shape average

– priority

– bandwidth

– bandwidth remaining

– random detect

– queue-limit

– police (only if the class does not call for a grand-child policy map)

– set (only if the class does not call for a grand-child policy map)

– service-policy (neither police nor set is allowed if service policy is configured)

• Class maps can be match all or match any

• If a policer set is configured at the grand-child level and a random-detect is configured at the child level, the random-detect must apply on the traffic based on the new parameter set as the result of the policer conform or exceed set.

Grand-Child Level


– police

– set

• Class maps can be match all or match any

• All of the classes (including class-default) in the grand-child policy of the priority class must have a policer configured.

• If a policer set is configured at the grand-child level and a random-detect is configured at the child level, the random-detect must apply on the traffic based on the new parameter set as the result of the policer conform or exceed set.

SUMMARY STEPS

1. configure


3. class class-name

4. shape average rate [units]



7. class class-name

8. priority



OL-24694-01


10. class class-name

11. set mpls experimental topmost exp-value


13. class class-name

14. police rate rate [units]

15. conform-action set mpls experimental topmost exp-value

16. exceed-action drop

17. end or commit

DETAILED STEPS


Step 1 configure











Step 4 shape average rate [units]

Example:RP/0/0/CPU0:router(config-pmap-c)# shape average 100 mbps

Shapes traffic to the indicated bit rate.



Attaches a policy map to be used as the service policy.


Example:RP/0/0/CPU0:router(config-pmap-c)# policy-map child



OL-24694-01



Example:RP/0/0/CPU0:router(config-pmap-c)# class gold


Step 8 priority

Example:RP/0/0/CPU0:router(config-pmap-c)# priority

Assigns a priority to a class of traffic belonging to a policy map.


Example:RP/0/0/CPU0:router(config-pmap-c)# service-policy grand-child

Attaches a policy map to be used as the service policy.


Example:RP/0/0/CPU0:router(config-pmap-c)# class class-default


Step 11 set mpls experimental topmost exp-value

Example:RP/0/0/CPU0:router(config-pmap-c)# set mpls exp topmost 1

Sets the experimental (EXP) value of the Multiprotocol Label Switching (MPLS) packet topmost label.


Example:RP/0/0/CPU0:router(config-pmap-c)# policy-map grand-child



Example:RP/0/0/CPU0:router(config-pmap-c)# class gold-voice


Step 14 police rate percent rate [units]

Example:RP/0/0/CPU0:router(config-pmap-c)# police rate 10 mbps



Example:RP/0/0/CPU0:router(config-pmap-c-police)# conform-action set mpls experimental topmost 5


set mpls experimental topmost 5—Sets the value to 5.



OL-24694-01


Setting the Frame Relay Discard Eligibility BitYou can use the discard eligibility (DE) bit in the address field of a Frame Relay frame to prioritize frames in congested Frame Relay networks. The Frame Relay DE bit has only one bit and can therefore, have only two settings, 0 or 1. If congestion occurs in a Frame Relay network, frames with the DE bit set to 1 are discarded before frames with the DE bit set to 0. Therefore, important traffic should have the DE bit set to 0, and less important traffic should be forwarded with the DE bit set to 1.

Note The default DE bit setting is 0. You can change the DE bit setting to 1 with the set fr-de command.

SUMMARY STEPS

1. configure


3. class class-name

4. set fr-de

5. exit





Step 17 end

or

commit


or











OL-24694-01


DETAILED STEPS

Matching the Frame Relay DE BitYou can use the match fr-de command to enable frames with a DE bit setting of 1 to be considered a member of a defined class and forwarded according to the specifications set in the service policy.

SUMMARY STEPS

1. configure

2. class-map class-name

3. match fr-de

4. exit


Step 1 configure




Example:RP/0/0/CPU0:router(config)# policy-map p1


Creates or modifies a policy map that can be attached to one or more interfaces to specify a service policy.


Example:RP/0/0/CPU0:router(config-pmap)# class c1



Step 4 set fr-de

Example:RP/0/0/CPU0:router(config-pmap-c)# set fr-de

Sets the Frame Relay DE bit setting for all packets that match the specified traffic class from 0 to 1.

Step 5 exit


Returns the router to the policy map configuration mode.


OL-24694-01


DETAILED STEPS

Matching the ATM CLP BitYou can use the match atm clp command to enable packet matching on the basis of the ATM cell loss priority (CLP).

SUMMARY STEPS

1. configure

2. class-map class-name

3. match atm clp

4. exit

DETAILED STEPS


Step 1 configure



Step 2 class-map class-name

Example:RP/0/0/CPU0:router(config)# class-map c1


Creates a class map to be used for matching packets to the class whose name you specify.

Step 3 match fr-de

Example:RP/0/0/CPU0:router(config-cmap)# match fr-de

Sets the Frame Relay DE bit setting for all packets that match the specified traffic class. The Frame Relay DE bit value can be 0 or 1.

Step 4 exit

Example:RP/0/0/CPU0:router(config-cmap)# exit

Returns the router to the global configuration mode.


Step 1 configure



Step 2 class-map class-name

Example:RP/0/0/CPU0:router(config)# class-map c1


Creates a class map to be used for matching packets to the class whose name you specify.


OL-24694-01

Configuring Modular QoS Service Packet Classification on Cisco IOS XR SoftwareConfiguration Examples for Configuring Modular QoS Packet Classification on Cisco IOS XR Software

Configuration Examples for Configuring Modular QoS Packet Classification on Cisco IOS XR Software

This section contains the following examples:

• Traffic Classes Defined: Example, page 47

• Traffic Policy Created: Example, page 48

• Traffic Policy Attached to an Interface: Example, page 48

• Default Traffic Class Configuration: Example, page 48

• class-map match-any Command Configuration: Example, page 49

• Traffic Policy as a QoS Policy (Hierarchical Traffic Policies) Configuration: Examples, page 49

• Class-based, Unconditional Packet Marking Examples, page 50

• Route Policy Configuration: Example, page 54

• ACL Deny Configuration: Example, page 60

• Hierarchical Ingress Policing: Example, page 61

• Enhanced Hierarchical Ingress Policing: Example, page 62

• In-Place Policy Modification: Example, page 62

• In-Place Policy Modification: Example, page 62

• Setting the Frame Relay Discard Eligibility Bit: Example, page 63

• Matching the Frame Relay DE Bit: Example, page 63

Traffic Classes Defined: ExampleIn the following example, two traffic classes are created and their match criteria are defined. For the first traffic class called class1, ACL 101 is used as the match criterion. For the second traffic class called class2, ACL 102 is used as the match criterion. Packets are checked against the contents of these ACLs to determine if they belong to the class.

class-map class1match access-group ipv4 101exit

!class-map class2

match access-group ipv4 102

Step 3 match atm clp

Example:RP/0/0/CPU0:router(config-cmap)# match atm clp

Sets the ATM cell loss priority (CLP) bit setting for all packets that match the specified traffic class. The ATM CLP bit value can be 0 or 1.

Step 4 exit

Example:RP/0/0/CPU0:router(config-cmap)# exit

Returns the router to the global configuration mode.



OL-24694-01


exit

Traffic Policy Created: ExampleIn the following example, a traffic policy called policy1 is defined to contain policy specifications for the two classes—class1 and class2. The match criteria for these classes were defined in the traffic classes created in the “Traffic Classes Defined: Example” section on page 47.

For class1, the policy includes a bandwidth allocation request and a maximum packet limit for the queue reserved for the class. For class2, the policy specifies only a bandwidth allocation request.

policy-map policy1class class1

bandwidth 3000 kbpsqueue-limit 1000 packets

!class class2

bandwidth 2000 kbps!

class class-default!end-policy-map!end

Traffic Policy Attached to an Interface: ExampleThe following example shows how to attach an existing traffic policy to an interface (see the Traffic Classes Defined: Example, page 47). After you define a traffic policy with the policy-map command, you can attach it to one or more interfaces to specify the traffic policy for those interfaces by using the service-policy command in interface configuration mode. Although you can assign the same traffic policy to multiple interfaces, each interface can have only one traffic policy attached at the input and only one traffic policy attached at the output.

interface pos 0/1/0/0service-policy output policy1 exit

!interface TenGigE 0/5/0/1

service-policy output policy1exit

Default Traffic Class Configuration: ExampleThe following example shows how to configure a traffic policy for the default class of the traffic policy called policy1. The default class is named class-default, consists of all other traffic, and is being shaped at 60 percent of the interface bandwidth.

policy-map policy1class class-default

shape average percent 60


OL-24694-01


class-map match-any Command Configuration: ExampleThe following example illustrates how packets are evaluated when multiple match criteria exist. Only one match criterion must be met for the packet in the class-map match-any command to be classified as a member of the traffic class (a logical OR operator). In the example, protocol IP OR QoS group 4 OR access group 101 have to be successful match criteria:

class-map match-any class1match qos-group 4match access-group ipv4 101

In the traffic class called class1, the match criteria are evaluated consecutively until a successful match criterion is located. The packet is first evaluated to determine whether IPv4 protocol can be used as a match criterion. If IPv4 protocol can be used as a match criterion, the packet is matched to traffic class class1. If IP protocol is not a successful match criterion, then QoS group 4 is evaluated as a match criterion. Each matching criterion is evaluated to see if the packet matches that criterion. Once a successful match occurs, the packet is classified as a member of traffic class class1. If the packet matches at least one of the specified criteria, the packet is classified as a member of the traffic class.

Note The match qos-group command is supported only on an egress policy and on an ingress policy for QoS Policy Propagation using BGP (QPPB)-based policies.

Traffic Policy as a QoS Policy (Hierarchical Traffic Policies) Configuration: Examples

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

Hierarchical traffic policies can be attached to all supported interfaces for this Cisco IOS XR software release, such as the OC-192 and 10-Gigabit Ethernet interfaces.

Two-Level Hierarchical Traffic Policy Configuration: Example

A two-level 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 pre-existing traffic policy is the parent policy. In the example in this section, the traffic policy called child is the child policy, and the traffic policy called parent is the parent policy.

In the following example, the child policy is responsible for prioritizing traffic, and the parent policy is responsible for shaping traffic. In this configuration, the parent policy allows packets to be sent from the interface, and the child policy determines the order in which the packets are sent.

policy-map childclass mpls

priority!policy-map parent

class class-defaultshape average 10000000service-policy child


OL-24694-01


Three-Level Hierarchical Traffic Policy Configuration: Example

A three-level hierarchical traffic policy contains a parent, child, and grand-child policy. The first level (parent) policy provides the shaper parameter. The second level (child) policy allows the highest level of complexity and defines queuing and scheduling behavior. The third level (grand-child) policy allows policing and set commands.

In the example, a three-level hierarchical policy is configured.

policy-map parentclass class-default

shape average 100 mbpsservice-policy child

!policy-map child

class goldpriorityservice-policy grand-child1

class silverbandwidth 50 mbpsrandom detect mpls experimental 4 100 packets 200 packetsservice-policy grand-child2

class bronzebandwidth 10 mbpsrandom detect mpls experimental 2 200 packets 400 packetsservice-policy grand-child3

class class-defaultset mpls experimental topmost 1

!policy-map grand-child1

class gold-voice1police rate 10 mbps

conform-action set mpls experimental topmost 5exceed-action drop

class bold-voice2police rate 10 mbps



class silver-data1police rate 30 mbps

conform-action set mpls experimental topmost 3exceed-action set mpls experimental topmost 0

class silver-data2police rate 20 mbps



class bronze-data1police rate 40 mbpsset mpls experimental topmost 2

class bronze-data2set mpls experimental topmost 0

Class-based, Unconditional Packet Marking ExamplesThe following are typical class-based, unconditional packet marking examples:

• IP Precedence Marking Configuration: Example, page 51


OL-24694-01


• IP Precedence Tunnel Marking Configuration: Example, page 51

• IP DSCP Marking Configuration: Example, page 51

• QoS Group Marking Configuration: Example, page 52

• Discard Class Marking Configuration: Example, page 52

• CoS Marking Configuration: Example, page 53

• MPLS Experimental Bit Imposition Marking Configuration: Example, page 53

• MPLS Experimental Topmost Marking Configuration: Example, page 53

IP Precedence Marking Configuration: Example

In the following example, a service policy called policy1 is created. This service policy is associated to a previously defined class map called class1 through the use of the class command, and then the service policy is attached to the output POS interface 0/1/0/0. The IP precedence bit in the ToS byte is set to 1:


set precedence 1!interface pos 0/1/0/0

service-policy output policy1

IP Precedence Tunnel Marking Configuration: Example

In the following example, a service policy called policy1 is created. This service policy is associated to a previously defined class map called class1 through the use of the class command, and then the service policy is attached in the input direction on an IPSec interface.The IP precedence value is set to priority (1):


set precedence tunnel priority!

interface service-ipsec 1service-policy output pre-enecrypt policy1

Note IP precedence tunnel marking is only supported in the outbound pre-encrypt direction.

Refer to Implementing IPSec Network Security on Cisco IOS XR Software in the Cisco IOS XR System Security Configuration Guide for the Cisco XR 12000 Series Router for more information on configuring IPSec.

IP DSCP Marking Configuration: Example

In the following example, a service policy called policy1 is created. This service policy is associated to a previously defined class map through the use of the class command. In this example, it is assumed that a class map called class1 was previously configured.

In the following example, the IP DSCP value in the ToS byte is set to 5:


set dscp 5


OL-24694-01


class class2set dscp ef

After you configure the settings shown for voice packets at the edge, all intermediate routers are configured to provide low-latency treatment to the voice packets, as follows:

class-map voicematch dscp ef

policy-map qos-policyclass voice

priority level 1police rate percent 10

The service policy configured in this section is not yet attached to an interface. For information on attaching a service policy to an interface, see the Modular Quality of Service Overview on Cisco IOS XR Software module.

QoS Group Marking Configuration: Example

In the following example, a service policy called policy1 is created. This service policy is associated to a class map called class1 through the use of the class command, and then the service policy is attached in the input direction on a GigabitEthernet interface 0/1/0/9. The qos-group value is set to 1.

class-map match-any class1match access-group ipv4 101


set qos-group 1!

interface gigabitethernet 0/1/0/9service-policy input policy1

Note The set qos-group command is supported only on an ingress policy.

Discard Class Marking Configuration: Example

In the following example, a service policy called policy1 is created. This service policy is associated to a class map called class1 through the use of the class command, and then the service policy is attached in the input direction on a POS interface 0/1/0/0. The discard-class value is set to 1.



set discard-class 1!

interface pos 0/1/0/0service-policy input policy1


OL-24694-01


CoS Marking Configuration: Example

In the following example, a service policy called policy1 is created. This service policy is associated to a class map called class1 through the use of the class command, and then the service policy is attached in the output direction on a 10-Gigabit Ethernet interface, TenGigE0/1/0/0. The 802.1p (CoS) bits in the Layer 2 header are set to 1.



set cos 1!

interface TenGigE0/1/0/0.100service-policy output policy1

Note The set cos command is supported only on egress.

MPLS Experimental Bit Imposition Marking Configuration: Example

In the following example, a service policy called policy1 is created. This service policy is associated to a class map called class1 through the use of the class command, and then the service policy is attached in the input direction on a 10-Gigabit Ethernet interface, TenGigE0/1/0/0. The MPLS EXP bits of all imposed labels are set to 1.



set mpls exp imposition 1 !interface TenGigE0/1/0/0

service-policy input policy1

Note The set mpls exp imposition command is supported only on an ingress policy.

MPLS Experimental Topmost Marking Configuration: Example

In the following example, a service policy called policy1 is created. This service policy is associated to a class map called class1 through the use of the class command, and then the service policy is attached in the output direction on a 10-Gigabit Ethernet interface, TenGigE0/1/0/0. The MPLS EXP bits on the TOPMOST label are set to 1:

class-map match-any class1match mpls exp topmost 2


set mpls exp topmost 1!

interface TenGigE0/1/0/0service-policy output policy1


OL-24694-01


Route Policy Configuration: Example

BGP Community Sample Configuration

The following configuration is an example of configuring route policy in a BGP community:

route-policy qppb-comm6200 if community matches-any (61100:10, 61200:20, 61300:30) then set qos-group 11 elseif community matches-any (62100:10, 62200:20, 62300:30) then set qos-group 12 else set qos-group 1 endif passend-policy!router bgp 100 bgp router-id 10.10.10.10 address-family ipv4 unicast table-policy qppb-comm6200 network 201.32.21.0/24 network 201.37.5.0/24 ! neighbor 201.1.0.2 remote-as 61100 address-family ipv4 unicast route-policy pass-all in route-policy pass-all out ! ! neighbor 201.2.0.2 remote-as 61200 address-family ipv4 unicast route-policy pass-all in route-policy pass-all out ! ! neighbor 201.32.21.2 remote-as 62100 address-family ipv4 unicast route-policy pass-all in route-policy pass-all out ! ! neighbor 201.32.22.2 remote-as 62200 address-family ipv4 unicast route-policy pass-all in route-policy pass-all out ! ! interface GigabitEthernet0/0/5/4 service-policy output comm-p1-out ipv4 address 201.1.0.1 255.255.255.0 ipv4 bgp policy propagation input qos-group destination negotiation auto !

interface GigabitEthernet0/1/5/6 service-policy input comm-p1-in


OL-24694-01


ipv4 address 201.32.21.1 255.255.255.0 ipv4 bgp policy propagation input qos-group source negotiation auto

!

Autonomous System Path Sample Configuration

The following configuration is an example of configuring a route policy in an autonomous system path:

policy-map p11-in class class-qos10 set discard-class 3 shape average percent 20 ! class class-qos20 set precedence flash-override shape average percent 30 ! class class-qos30 set precedence critical shape average percent 40 ! class class-qos11 set precedence priority shape average percent 10 ! class class-qos12 set precedence immediate shape average percent 20 ! class class-qos13 set precedence flash shape average percent 30 !

policy-map p11-out class class-qos10 set precedence priority police rate percent 20 ! ! class class-qos20 set precedence immediate police rate percent 30 ! ! class class-qos30 set precedence critical police rate percent 40 ! ! class class-qos11 set precedence immediate police rate percent 20 ! ! class class-qos12 set precedence flash police rate percent 30 ! ! class class-qos13


OL-24694-01


set precedence flash-override police rate percent 40 ! ! class class-default ! end-policy-map!

route-policy qppb-as6000 if as-path in (ios-regex '61100, 61200, 61300') then set qos-group 10 elseif as-path in (ios-regex '62100, 62200, 62300') then set qos-group 20 elseif as-path in (ios-regex '63100, 63200, 63300') then set qos-group 30 elseif as-path neighbor-is '61101' or as-path neighbor-is '61201' then set qos-group 11 elseif as-path neighbor-is '61102' or as-path neighbor-is '61202' then set qos-group 12 elseif as-path neighbor-is '61103' or as-path neighbor-is '61203' then set qos-group 13 else set qos-group 2 endifend-policy!

router bgp 100 bgp router-id 10.10.10.10 address-family ipv4 unicast table-policy qppb-as6000 network 201.32.21.0/24 network 201.37.5.0/24 ! neighbor 201.1.0.2 remote-as 61100 address-family ipv4 unicast route-policy pass-all in route-policy pass-all out ! ! neighbor 201.2.0.2 remote-as 61200 address-family ipv4 unicast route-policy pass-all in route-policy pass-all out ! ! neighbor 201.32.21.2 remote-as 62100 address-family ipv4 unicast route-policy pass-all in route-policy pass-all out ! ! neighbor 201.32.22.2 remote-as 62200 address-family ipv4 unicast route-policy pass-all in route-policy pass-all out ! !


OL-24694-01


interface GigabitEthernet0/0/5/4 service-policy output p11-out ipv4 address 201.1.0.1 255.255.255.0 ipv4 bgp policy propagation input qos-group destination negotiation auto !

interface GigabitEthernet0/1/5/6 service-policy input p11-in ipv4 address 201.32.21.1 255.255.255.0 ipv4 bgp policy propagation input qos-group source negotiation auto !

QPPB Source Prefix Configuration: Example

The following configuration is an example of configuring QPPB source prefix:

route-policy qppb-src10-20 if source in (201.1.1.0/24 le 32) then set qos-group 10 elseif source in (201.2.2.0/24 le 32) then set qos-group 20 else set qos-group 1 endif passend-policy!

router bgp 100 bgp router-id 10.10.10.10 address-family ipv4 unicast table-policy qppb-src10- ! neighbor 201.1.1.2 remote-as 62100 address-family ipv4 unicast route-policy pass-all in route-policy pass-all out ! ! neighbor 201.2.2.2 remote-as 62200 address-family ipv4 unicast route-policy pass-all in route-policy pass-all out ! ! neighbor 202.4.1.1 remote-as 100 address-family ipv4 unicast ! !! policy-map p1-in class class-qos10 set discard-class 4 shape average percent 20 ! class class-qos20 set precedence critical


OL-24694-01


shape average percent 30 ! class class-default ! end-policy-map!policy-map p2-out class class-qos10 set precedence priority police rate percent 30 ! class class-qos20 set precedence immediate police rate percent 40 ! class class-default ! end-policy-map!

interface GigabitEthernet0/0/5/4 service-policy output p1-in ipv4 address 201.1.0.1 255.255.255.0 ipv4 bgp policy propagation input qos-group source negotiation auto !

interface GigabitEthernet0/1/5/6 service-policy input p2-out ipv4 address 201.32.21.1 255.255.255.0 ipv4 bgp policy propagation input qos-group destination negotiation auto !

QPPB Destination Prefix Configuration: Example

The following configuration is an example of QPPB destination prefix:

route-policy qppb-des10to20 if destination in (10.10.0.0/16 le 28) then set qos-group 10 elseif destination in (10.11.0.0/16 le 28) then set qos-group 11 elseif destination in (10.12.0.0/16 le 28) then set qos-group 12 elseif destination in (10.13.0.0/16 le 28) then set qos-group 13 elseif destination in (10.14.0.0/16 le 28) then set qos-group 14 elseif destination in (10.15.0.0/16 le 28) then set qos-group 15 elseif destination in (20.20.0.0/16 le 28) then set qos-group 20 else set qos-group 1 endif passend-policy!

router bgp 100 bgp router-id 10.10.10.10 address-family ipv4 unicast


OL-24694-01


table-policy qppb-des10to20 ! neighbor 201.1.1.2 remote-as 62100 address-family ipv4 unicast route-policy pass-all in route-policy pass-all out ! ! neighbor 201.1.2.2 remote-as 62102 address-family ipv4 unicast route-policy pass-all in route-policy pass-all out ! ! neighbor 201.1.3.2 remote-as 62103 address-family ipv4 unicast route-policy pass-all in route-policy pass-all out ! ! neighbor 201.1.4.2 remote-as 62104 address-family ipv4 unicast route-policy pass-all in route-policy pass-all out ! ! neighbor 201.1.5.2 remote-as 62105 address-family ipv4 unicast route-policy pass-all in route-policy pass-all out ! !

policy-map p11-in class class-qos10 set precedence priority shape average percent 30 ! class class-qos11 set precedence immediate shape average percent 10 ! class class-qos12 set precedence flash shape average percent 15 ! class class-qos13 set precedence flash-override shape average percent 20 ! class class-qos14 set precedence flash shape average percent 25 ! class class-qos15 set precedence flash-override shape average percent 30 !


OL-24694-01


class class-qos20 set precedence critical shape average percent 40 ! class class-default ! end-policy-map!policy-map p1-out class class-qos10 set precedence priority police rate percent 30 ! class class-qos20 set precedence critical police rate percent 40 ! class class-default ! end-policy-map!

interface GigabitEthernet0/2/2/1 service-policy output p1-out ipv4 address 201.1.0.1 255.255.255.0 ipv4 bgp policy propagation input qos-group source negotiation auto!interface GigabitEthernet0/2/2/1.2 service-policy input p11-in ipv4 address 201.1.2.1 255.255.255.0 ipv4 bgp policy propagation input qos-group destination dot1q vlan 2!interface GigabitEthernet0/2/2/1.3 service-policy input p11-in ipv4 address 201.1.3.1 255.255.255.0 ipv4 bgp policy propagation input qos-group destination dot1q vlan 3!interface GigabitEthernet0/2/2/1.4 service-policy input p11-in ipv4 address 201.1.4.1 255.255.255.0 ipv4 bgp policy propagation input qos-group destination dot1q vlan 4!interface GigabitEthernet0/2/2/1.5 service-policy input p11-in ipv4 address 201.1.5.1 255.255.255.0 ipv4 bgp policy propagation input qos-group destination dot1q vlan 5!

ACL Deny Configuration: ExampleThe following configuration is an example of the ACL deny feature:

ipv4 access-list acl-permit-deny10 permit ipv4 host 10.0.0.0 any20 deny ipv4 any any!

class-map match-any class-acl-permit-deny


OL-24694-01


match access-group ipv4 acl-permit-deny!

policy-map pol-acl-permit-denyclass class-acl-permit-deny

shape average percent 40!

class class-defaultpolice rate percent 15

conform-action transmitexceed-action drop!

!!

In the example, traffic with the source IP address 10.0.0.0 is classified into the class “class-acl-permit-deny”, but any other IP traffic is expected to match the next class (class-default in this example) because the ACE action is deny for all other IP traffic.

Hierarchical Ingress Policing: ExampleThe following configuration is an example of typical hierarchical ingress policing:

policy-map parentclass class-defaultservice-policy childpolice rate percent 50 conform-action transmitexceed-action drop

This policy map can be applied on any interface or on a subinterface. The incoming traffic on the main interface or subinterface can be IPv4 unicast or multicast, MPLS, or IPv6 unicast or multicast. The child policy map can be a regular policy map that can be configured in the ingress direction on that interface.

If the policy map is applied on a main interface that has subinterfaces, then the configuration is considered as a 1CnD configuration model. Hence, the child policy must be applied on each subinterface and the parent policer polices the aggregate traffic from all subinterfaces.

For example:

interface Serial 0/4/1/1/0:0encapsulation frame-relayservice-policy input parent

interface Serial 0/4/1/1/0:0.1 point-to-point

interface Serial 0/4/1/1/0:0.2 point-to-point

In this configuration, the child policy is applied on each of the subinterfaces and the aggregate traffic from all subinterfaces is subjected to the parent policer. In this model, the child policy is not permitted any queueing actions.

An example of the configuration for a nCmD model is as follows:

class-map match-any customeramatch vlan 1-3

class-map match-any customerbmatch vlan 4-7

policy-map parentclass customeraservice-policy childapolice rate percent 50 conform-action transmitexceed-action drop


OL-24694-01


!class customerbservice-policy childbpolice rate percent 70 conform-action transmitexceed-action drop

!

Similar to the 1CnD model, the aggregate traffic from all subinterfaces that match each parent class map is subjected to the parent policer configured in that class map. Also, the child policy is not permitted any queuing actions.

Enhanced Hierarchical Ingress Policing: ExampleThis example shows parent and child policy maps in which two classes are defined in the child policy. In class AF1, the exceed action is set to an action other than to drop traffic.

If the child-conform-aware command were not configured in the parent policy, the parent policer would drop traffic that matches the conform rate of the child policer but exceeds the conform rate of the parent policer.

When used in the parent policer, the child-conform-aware command prevents the parent policer from dropping any ingress traffic that conforms to the maximum rate specified in the child policer.

policy-map parentclass class-default

service-policy childpolice rate percent 50

child-conform-awareconform-action transmitexceed-action drop

policy-map childclass EF

police rate 1 mbpsconform-action set mpls experimental imposition 4exceed-action drop

class AF1police rate percent 50

conform-action set mpls experimental imposition 3exceed-action set mpls experimental imposition 2

The police rate command allows you to police traffic to control the maximum rate of traffic sent or received on an interface. In the parent policy, the police rate percentage is a percentage of the interface rate. In the child policy, the police rate percentage is a percentage of the parent policer rate.

In this example, the parent policy configures a police rate of 50 percent, which is 50 percent of the maximum bandwidth allowed on the interface. Class AF1 in the child policy configures a police rate of 50 percent, which is 50 percent of the bandwidth allowed in the parent, in this case 25 percent of the maximum bandwidth allowed on the interface.

In-Place Policy Modification: ExampleThe following configuration is an example of in-place policy modification:

Defining a policy map:

configurepolicy-map policy1class class1


OL-24694-01


set precedence 3commit

Attaching the policy map to an interface:

configureinterface POS 0/6/0/1service-policy output policy1commit

Modifying the precedence value of the policy map:

configurepolicy-map policy1class class1set precedence 5commit

Note The modified policy policy1 takes effect on all the interfaces to which the policy is attached. Also, you can modify any class-map used in the policy-map. The changes made to the class-map takes effect on all the interfaces to which the policy is attached.

Setting the Frame Relay Discard Eligibility Bit: ExampleThe following example shows how to set the DE bit using the set fr-de command in the traffic policy:

class-map ip-precedencematch ip precedence 0 1exitpolicy-map set-declass ip-precedenceset fr-deexitexitinterface serial 1/0/0no ip addressencapsulation frame-relayinterface serial 1/0/0.1ip address 10.1.1.1 255.255.255.252no ip directed-broadcastservice-policy output set-de

Matching the Frame Relay DE Bit: ExampleThe following example creates a class called match-fr-de and matches packets on the basis of the Frame Relay DE bit setting:

class-map match-fr-dematch fr-deend


OL-24694-01

Configuring Modular QoS Service Packet Classification on Cisco IOS XR SoftwareAdditional References

Additional ReferencesThe following sections provide references related to implementing packet classification.

Related Documents

Standards

MIBs

RFCs







Standards Title


—

MIBs MIBs Link


RFCs Title


—


OL-24694-01




Description Link




OL-24694-01




OL-24694-01

Configuring Modular QoS Congestion Management on Cisco IOS XR Software

Congestion management controls congestion after it has occurred on a network. Congestion can be managed on Cisco IOS XR software by using packet queueing methods, and by shaping the packet flow through use of traffic regulation mechanisms.

Packet queueing methods define packet scheduling or the order in which packets are dequeued to the interface for transmission on the physical wire. Furthermore, queueing methods support minimum bandwidth guarantees and low latencies based on the order and number of times that a queue is serviced.

The following types of queueing methods and traffic regulation mechanisms are supported on the Cisco IOS XR software:

• Modified Deficit Round Robin (MDRR)

• Low-latency queueing (LLQ) with strict priority queueing (PQ)

• Traffic shaping

• Traffic policing

Feature History for Configuring Modular QoS Congestion Management on Cisco IOS XR Software


Release 3.2 The Congestion Avoidance feature was introduced with the exception of the following:

• Two-rate policer and two-token bucket algorithm

• The pir and violate-action keywords for the police command

• Packet-by-packet MDRR scheduling mechanism

Release 3.3.0 The police command was changed to the police rate command and the syntax changed.

Release 3.4.0 The police rate command enters policy map police configuration mode to configure the conform, exceed and violate actions.

The following new commands were added: conform-action, exceed-action and violate-action.

The cos, qos-group, atm-clp, and transmit actions were added to the policer.

Release 3.5.0 The show policy-map interface command output was updated to show when a policy is suspended on a multilink or T3 interface.


OL-24694-01

Configuring Modular QoS Congestion Management on Cisco IOS XR SoftwareContents

Contents• Prerequisites for Configuring QoS Congestion Management on Cisco IOS XR Software, page 68

• Information About Configuring QoS Congestion Management on Cisco IOS XR Software, page 69

• How to Configure QoS Congestion Management on Cisco IOS XR Software, page 79

• Configuration Examples for Configuring QoS Congestion Management on Cisco IOS XR Software, page 91


Prerequisites for Configuring QoS Congestion Management on Cisco IOS XR Software

The following prerequisites are required for configuring QoS congestion management on your network:

• You must be in a user group associated with a task group that includes the proper task IDs. The command reference guides include the task IDs required for each command. If you suspect user group assignment is preventing you from using a command, contact your AAA administrator for assistance.

• You must be familiar with Cisco IOS XR QoS configuration tasks and concepts.

Release 3.6.0 Increased Class scale from 32 to 1000 classes per policy map.

Unallocated remaining bandwidth is equally distributed among all the queueing classes that do not have remaining bandwidth configured explicitly.

For shape and police percentage parameters in child policy, reference is relative to the maximum rate of the parent.

For bandwidth percentage parameters in child policy, reference is relative to the minimum bandwidth of the parent class. If bandwidth is not configured in parent class, guaranteed service rate of parent class is used as reference.

Release 3.7.0 The Multi-Action Set/Policer feature was introduced.

Release 3.8.0 The Frame Relay QoS on Layer 2 VPN was introduced.

The Policer Granularity feature was introduced.

Release 3.9.0 The granularity of the rates specified in the bandwidth, police-rate, and shape average commands was changed from 64 kbps to 8 kbps.


OL-24694-01

Configuring Modular QoS Congestion Management on Cisco IOS XR SoftwareInformation About Configuring QoS Congestion Management on Cisco IOS XR Software

Information About Configuring QoS Congestion Management on Cisco IOS XR Software

To implement QoS congestion management features in this document, you must understand the following concepts:

• Congestion Management Overview, page 69

• Modified Deficit Round Robin, page 70

• Low-Latency Queueing with Strict Priority Queueing, page 70

• Qos-Group-Based Queuing, page 71

• Traffic Shaping, page 71

• Traffic-Shaping Mechanism Regulates Traffic, page 72

• Traffic Policing, page 73

• Regulation of Traffic with the Policing Mechanism, page 77

• Traffic Shaping Versus Traffic Policing, page 78

• Policer Granularity, page 78

Congestion Management OverviewCongestion management features allow you to control congestion by determining the order in which a traffic flow (or packets) is sent out an interface based on priorities assigned to packets. Congestion management entails the creation of queues, assignment of packets to those queues based on the classification of the packet, and scheduling of the packets in a queue for transmission. The congestion management features in Cisco IOS XR software allow you to specify creation of a different number of queues, affording greater or lesser degree of differentiation of traffic, and to specify the order in which that traffic is sent.

During periods with light traffic flow, that is, when no congestion exists, packets are sent out the interface as soon as they arrive. During periods of transmit congestion at the outgoing interface, packets arrive faster than the interface can send them. If you use congestion management features, packets accumulating at an interface are queued until the interface is free to send them; they are then scheduled for transmission according to their assigned priority and the queueing method configured for the interface. The router determines the order of packet transmission by controlling which packets are placed in which queue and how queues are serviced with respect to each other.

In addition to queueing methods, QoS congestion management mechanisms, such as policers and shapers, are needed to ensure that a packet adheres to a contract and service. Both policing and shaping mechanisms use the traffic descriptor for a packet. See the Configuring Modular QoS Congestion Management on Cisco IOS XR Software module for information about the traffic descriptor.

Policers and shapers usually identify traffic descriptor violations in an identical manner through the token bucket mechanism, but they differ in the way they respond to violations. A policer typically drops traffic flow; whereas, a shaper delays excess traffic flow using a buffer, or queueing mechanism, to hold the traffic for transmission at a later time.

Traffic shaping and policing can work in tandem. For example, a good traffic shaping scheme should make it easy for nodes inside the network to detect abnormal flows.


OL-24694-01


Modified Deficit Round RobinMDRR is a class-based composite scheduling mechanism that allows for queueing of up to eight traffic classes. It operates in the same manner as class-based weighted fair queueing (CBWFQ) and allows definition of traffic classes based on customer match criteria (such as access lists); however, MDRR does not use the weighted fair queueing algorithm.

When MDRR is configured in the queueing strategy, nonempty queues are served one after the other. Each time a queue is served, a fixed amount of data is dequeued. The algorithm then services the next queue. When a queue is served, MDDR keeps track of the number of bytes of data that were dequeued in excess of the configured value. In the next pass, when the queue is served again, less data is dequeued to compensate for the excess data that was served previously. As a result, the average amount of data dequeued per queue is close to the configured value. In addition, MDRR allows for a strict priority queue for delay-sensitive traffic.

Each queue within MDRR is defined by two variables:

• Quantum value—Average number of bytes served in each round.

• Deficit counter—Number of bytes a queue has sent in each round. The counter is initialized to the quantum value.

Packets in a queue are served as long as the deficit counter is greater than zero. Each packet served decreases the deficit counter by a value equal to its length in bytes. A queue can no longer be served after the deficit counter becomes zero or negative. In each new round, the deficit counter for each nonempty queue is incremented by its quantum value.

Note In general, the quantum size for a queue should not be smaller than the maximum transmission unit (MTU) of the interface to ensure that the scheduler always serves at least one packet from each nonempty queue.

Low-Latency Queueing with Strict Priority QueueingThe LLQ feature brings strict priority queueing (PQ) to the MDRR scheduling mechanism. PQ in strict priority mode ensures that one type of traffic is sent, possibly at the expense of all others. For PQ, a low-priority queue can be detrimentally affected, and, in the worst case, never allowed to send its packets if a limited amount of bandwidth is available or the transmission rate of critical traffic is high.

Strict PQ allows delay-sensitive data, such as voice, to be dequeued and sent before packets in other queues are dequeued.

LLQ enables the use of a single, strict priority queue within MDRR at the class level, allowing you to direct traffic belonging to a class. To rank class traffic to the strict priority queue, you specify the named class within a policy map and then configure the priority command for the class. (Classes to which the priority command is applied are considered priority classes.) Within a policy map, you can give one or more classes priority status. When multiple classes within a single policy map are configured as priority classes, all traffic from these classes is enqueued to the same, single, strict priority queue.

Through use of the priority command, you can assign a strict PQ to any of the valid match criteria used to specify traffic. These methods of specifying traffic for a class include matching on access lists, protocols, IP precedence, and IP differentiated service code point (DSCP) values. Moreover, within an access list you can specify that traffic matches are allowed based on the DSCP value that is set using the first six bits of the IP type of service (ToS) byte in the IP header.


OL-24694-01


Qos-Group-Based Queuing QoS-group based queuing is supported in the ingress and egress directions.

The local output queue selection for packets sent to the fabric on the ingress card is based on a fabric modular QoS CLI (MQC) policy. The match criteria for the policy is the MPLS Exp bits of the topmost label. For information fabric QoS, see the Configuring Fabric Quality of Service Policies and Classes on Cisco IOS XR Software module.

In the egress direction, the MQC policy attached to the Layer 2 ATM sub-interface is used to select and configure the segmentation and reassembly (SAR) queue. All the traffic, from different ATM virtual circuits (VCs), is directed to the default output queue in the buffer management ASIC (BMA). To differentiate between different classes of service, an MQC policy is attached to the main interface to select the output queues (including the low latency queuing (LLQ)) on the Layer 2 interfaces.

The QoS Group setting in the ingress direction is preserved across the fabric and can be used to choose the output queue in the egress direction. This functionality helps in achieving egress shaping based on the MPLS Exp values in the disposition router. Additionally, the discard class setting preserved across the fabric can be used to perform WRED on the output queues.

The MQC policy on the main interface co-exists with an MQC policy on the sub-interface, however, the two policies are independent of one another, which means the match criteria of one policy cannot be dependent on the set actions of another. This is applicable only to the virtual circuit (VC) and virtual path (VP) modes, since, the main interface is used for Layer 2 in the port mode.

The following MQC actions are supported on the egress MQC policy used to select the output queue:

• MDRR using the bandwidth and bandwidth percent command

• the shaping and shaping percent command

• the priority command for LLQ selection

• the random-detect command based on the discard class

• the queue-limit command

• policing (engine-based)

Traffic ShapingTraffic shaping allows you to control the traffic flow exiting an interface to match its transmission to the speed of the remote target interface and ensure that the traffic conforms to policies contracted for it. Traffic adhering to a particular profile can be shaped to meet downstream requirements, thereby eliminating bottlenecks in topologies with data-rate mismatches.

To match the rate of transmission of data from the source to the target interface, you can limit the transfer of data to one of the following:

• A specific configured rate

• A derived rate based on the level of congestion

The rate of transfer depends on these three components that constitute the token bucket: burst size, mean rate, and time (measurement) interval. The mean rate is equal to the burst size divided by the interval.

When traffic shaping is enabled, the bit rate of the interface does not exceed the mean rate over any integral multiple of the interval. In other words, during every interval, a maximum of burst size can be sent. Within the interval, however, the bit rate may be faster than the mean rate at any given time.


OL-24694-01


When the peak burst size equals 0, the interface sends no more than the burst size every interval, achieving an average rate no higher than the mean rate. However, when the peak burst size is greater than 0, the interface can send as many as the burst size plus peak burst bits in a burst, if in a previous time period the maximum amount was not sent. Whenever less than the burst size is sent during an interval, the remaining number of bits, up to the peak burst size, can be used to send more than the burst size in a later interval.

Traffic Shaping for Frame Relay on Layer 2 VPN

The shaping of all packets of the circuit is allowed in the disposition path. Shaping is configured in the imposition path by configuring bandwidth, queue-limit parameters, and WRED parameters.

The Layer 2 circuit acts like a subinterface for supporting QoS, which means that when a policy with queuing actions is attached to a Layer 2 circuit, it is assigned its own port and queues.

Note The matching criteria are qos-group and discard-class in the disposition path.

Traffic Shaping for ATM on Layer 2 VPN

The shape command under the PVC submode is applicable to the attachment circuits (AC) in the virtual circuit (VC) mode and the virtual path (VP) mode.

Note The default shape is UBR at line rate.

Traffic-Shaping Mechanism Regulates TrafficWhen incoming packets arrive at an interface, the packets are classified using a classification technique, such as an access control list (ACL) or the setting of the IP Precedence bits through the Modular QoS CLI (MQC). If the packet matches the specified classification, the traffic-shaping mechanism continues. Otherwise, no further action is taken.

Figure 1 illustrates how a traffic shaping mechanism regulates traffic flow.


OL-24694-01


Figure 1 How a Traffic Shaping Mechanism Regulates Traffic

Packets matching the specified criteria are placed in the token bucket. The maximum size of the token bucket is the confirm burst (Bc) size plus the Be size. The token bucket is filled at a constant rate of Bc worth of tokens at every Tc. This is the configured traffic shaping rate.

If the traffic shaping mechanism is active (that is, packets exceeding the configured traffic shaping rate already exist in a transmission queue) at every Tc, the traffic shaper checks to see if the transmission queue contains enough packets to send (that is, up to either Bc [or Bc plus Be] worth of traffic).

If the traffic shaper is not active (that is, there are no packets exceeding the configured traffic shaping rate in the transmission queue), the traffic shaper checks the number of tokens in the token bucket. One of the following occurs:

• If there are enough tokens in the token bucket, the packet is sent (transmitted).

• If there are not enough tokens in the token bucket, the packet is placed in a shaping queue for transmission at a later time.

Traffic PolicingIn general, traffic policing allows you to control the maximum rate of traffic sent or received on an interface, and to partition a network into multiple priority levels or class of service (CoS).

Traffic policing manages the maximum rate of traffic through a token bucket algorithm. The token bucket algorithm can use the user-configured values to determine the maximum rate of traffic allowed on an interface at a given moment in time. The token bucket algorithm is affected by all traffic entering or leaving (depending on where the traffic policy with traffic policing is configured) and is useful in managing network bandwidth in cases in which several large packets are sent in the same traffic stream.

Traffic entering the interface with traffic policing configured is placed into one of these categories. Within these three categories, users can decide packet treatments. For instance, packets that conform can be configured to be sent, packets that exceed can be configured to be sent with a decreased priority, and packets that violate can be configured to be dropped.

Traffic policing is often configured on interfaces at the edge of a network to limit the rate of traffic entering or leaving the network. In the most common traffic policing configurations, traffic that conforms is sent and traffic that exceeds is sent with a decreased priority or is dropped. Users can change these configuration options to suit their network needs.

ClassifyIncoming packets

"Token bucket"shaping

Packet classificationcriteria applied

(e.g., via the MQC) 1174

93

Match

Token bucket

Yes

No

Configured traffic shaping rate

Enoughtokens inthe tokenbucket? Outgoing packets

placed in shaping queue(transmitted later)

Outgoing packetstransmitted


OL-24694-01


Note Configured values take into account the Layer 2 encapsulation applied to traffic. This applies to both ingress and egress policing. For POS/SDH transmission, the encapsulation is considered to be 4 bytes. For Ethernet, the encapsulation is 14 bytes; whereas for 802.1Q, the encapsulation is 18 bytes.

Traffic policing also provides a certain amount of bandwidth management by allowing you to set the burst size (Bc) for the committed information rate (CIR). When the peak information rate (PIR) is supported, a second token bucket is enforced and the traffic policer is then called a two-rate policer.

Note The two-rate policer and two-token bucket algorithm is supported in Cisco IOS XR software.

For Cisco IOS XR software, a single-rate, two-color policer is supported that provides one token bucket with two actions for each packet: a conform action and an exceed action.

Multiple Action Set

The Multiple Action Set feature allows you to mark packets with multiple action sets (conditional and unconditional) through a class map.

To support multiple action sets, the following combinations are supported of conform and exceed actions:

• set-qos-group, set-discard-class

• set-mpls-exp-imp, set-qos-group

• set-mpls-exp-imp, set-discard-class

• set-mpls-exp-imp, set-qos-group and set-discard-class

• set-fr-de, set-prec-tunnel

• set-fr-de, set-dscp-tunnel

• set-fr-de, set-mpls-exp-imp

• set-mpls-exp-imp, set-prec-tunnel

• set-mpls-exp-imp, set-dscp-tunnel

• set-mpls-exp-imp, set-clp

Note If partial multiple set actions are used, hierarchical policing is not supported.

Table 1 shows a summary of marking combinations that are supported on conditional ingress policer marking and unconditional ingress QoS marking.

Table 1 Marking Combinations Supported on Conditional Ingress Policer and Unconditional

Ingress QoS Marking

Marking Combination Layer 2 Interfaces Layer 3 Interfaces

set qos-group + set discard-class Y N

set mpls exp imposition + set qos-group Y Y

set mpls exp imposition + set discard-class Y Y


OL-24694-01


Packet Marking Through the IP Precedence Value, IP DSCP Value, and the MPLS Experimental Value Setting

In addition to rate-limiting, traffic policing allows you to independently mark (or classify) the packet according to whether the packet conforms or violates a specified rate. Packet marking also allows you to partition your network into multiple priority levels or CoS. Packet marking as a policer action is conditional marking.

Use the traffic policer to set the IP precedence value, IP DSCP value, or Multiprotocol Label Switching (MPLS) experimental value for packets that enter the network. Then networking devices within your network can use this setting to determine how the traffic should be treated. For example, the Weighted Random Early Detection (WRED) feature uses the IP precedence value to determine the probability that a packet is dropped.

If you want to mark traffic but do not want to use traffic policing, see the “Class-based, Unconditional Packet Marking Examples” section to learn how to perform packet classification.

Note Marking IP fields on an MPLS-enabled interface results in non-operation on that particular interface.

Traffic Policing for Frame Relay on L2VPN

Policing each circuit individually in the ingress and egress path is allowed. The policer can be either one-rate, two-color (1R2C) or two-rate, three-color (2R3C) color-blind only. The policer action for conforming or exceeding packets can be one of the following:

• transmit

• drop

• set mpls exp imposition/topmost <exp> (AToM only)

• set tunnel prec/dscp (L2TPv3 only)

• set qos-group qos-group

• set discard-class discard-class

• set fr-de and set mpls exp (AToM only)

• set fr-de

• set tunnel prec/dscp (L2TPv3 only)

set mpls exp imposition + set precedence tunnel N Y

set mpls exp imposition + set dscp tunnel N Y

set mpls exp imposition + set qos-group + set discard-class Y Y

set clp + set mpls exp imposition Y N

set frame-relay DE + set mpls exp imposition Y N

set frame-relay DE + set precedence tunnel Y N

set frame-relay DE + set DSCP tunnel Y N

Table 1 Marking Combinations Supported on Conditional Ingress Policer and Unconditional

Ingress QoS Marking

Marking Combination Layer 2 Interfaces Layer 3 Interfaces


OL-24694-01


Note For a 2R3C policer, the action for violating packets is drop.

Note The matching criteria is based on the incoming Frame Relay discard eligibility (DE) bit in the Frame Relay header in the imposition path.

Traffic Policing on Layer 2 ATM Interfaces

Traffic policing is supported on the Layer 2 ATM interfaces in the ingress imposition path. The OAM cells are policed along with the user cells unless the QoS policy is explicitly configured to exclude the OAM cells from being policed.

Note Policing is supported for the virtual circuit (VC), and the virtual path (VP) modes. However, policing is not supported for the port mode on the Layer 2 ATM interfaces.

Different match criteria can be used in the policy map with class-default matching all the traffic including the OAM cells.

Policing is performed on the ATM Adaptation Layer type 0 (AAL0) cells but translates to ATM Adaptation Layer type 5 (AAL5) packets as described below:

• AAL5 packet conforms, if all the cells in the packet conform to peak cell rate (PCR) and sustainable cell rate (SCR) buckets.

• AAL5 packet exceeds, if at least one cell does not conform to the SCR bucket.

• AAL5 packet violates, if at least one cell does not conform to the PCR bucket.

The following policer options are supported:

• Rate in cells per second, and percent

• Peak rate in cells per second, and percent

• Delay tolerance in microseconds

• Maximum burst size in cells

The following policer actions are supported on the Layer 2 ATM interfaces in the ingress direction:

• transmit

• drop

• set mpls exp imposition <exp> (AToM only)

• set qos-group <qos-group> (AToM and local switching)

• set discard-class <discard-class> (AToM and local switching)

• set atm-clp (Exceed action only, AToM and local switching)

• drop (Violate action)

Multiple policing action is supported on the Layer 2 ATM interfaces using the following combination:

• set mpls exp imposition and set atm-clp.


OL-24694-01


Regulation of Traffic with the Policing MechanismFigure 2 illustrates how a single-rate token bucket policer marks packets as either conforming or exceeding a CIR.

Figure 2 How a Traffic Policing Mechanism Regulates Traffic

The time interval between token updates (Tc) to the token bucket is updated at the CIR value each time a packet arrives at the traffic policer. The Tc token bucket can contain up to the Bc value. If a packet of size B is greater than the Tc token bucket, then the packet exceeds the CIR value and a configured action is performed. If a packet of size B is less than the Tc token bucket, then the packet conforms and a different configured action is performed.

No

Packet of size B

No

Yes

Action

B>Tc

Exceed

Action

Conform

CIR

Bc

1270

91


OL-24694-01


Traffic Shaping Versus Traffic PolicingAlthough traffic shaping and traffic policing can be implemented together on the same network, there are distinct differences between them, as shown in Table 2.

Policer GranularityTable 3 shows the default policer granularity values.

The Policer Granularity feature allows you to override the default policer granularity values.

The police rate you set should be a multiple of the policer granularity. For example, if the police rate is set to 72 kbps but the default policer granularity is 64 kbps, the effective police rate is 64 kbps. To get an actual police rate of 72 kbps, configure the policer granularity to 8 kbps. Because 72 is a multiple of 8, the police rate will be exactly 72 kbps.

Policer granularity values, whether default or configured, apply to the SPA Interface Processor (SIP) and to all shared port adapters (SPAs) that are installed in the SIP.

Table 2 Differences Between Traffic Shaping and Traffic Policing

Traffic Shaping Traffic Policing

Triggering Event • Occurs automatically at regular intervals (Tc).

or

Occurs whenever a packet arrives at an interface.

• Occurs whenever a packet arrives at an interface.

What it Does • Classifies packets.

• If a packet does not meet match criteria, no further action is taken.

• Packets meeting match criteria are sent (if there are enough tokens in the token bucket)

or

Packets are placed in a queue for transmission later.

• If the number of packets in the queue exceed the queue limit, the packets are dropped.

• Classifies packets.

• If a packet does not meet match criteria, no further action is taken.

• Packets meeting match criteria and conforming to or exceeding a specified rate, receive the configured policing action (for example, drop, send, mark, then send).

• Packets are not placed in a queue for transmission later.

Table 3 Policer Granularity Default Values

SPA Interface Processor Policer Granularity Default Value

Cisco 12000 SIP-401 64 kbps




OL-24694-01

Configuring Modular QoS Congestion Management on Cisco IOS XR SoftwareHow to Configure QoS Congestion Management on Cisco IOS XR Software

How to Configure QoS Congestion Management on Cisco IOS XR Software


• Configuring Guaranteed and Remaining Bandwidths, page 79

• Configuring Low-Latency Queueing with Strict Priority Queueing, page 82

• Configuring Traffic Shaping, page 85

• Configuring Traffic Policing, page 87

• Configuring Policer Granularity, page 90

Configuring Guaranteed and Remaining BandwidthsThe bandwidth command allows you to specify the minimum guaranteed bandwidth to be allocated for a specific class of traffic. MDRR is implemented as the scheduling algorithm.

The bandwidth remaining command specifies a weight for the class to the MDRR. The MDRR algorithm derives the weight for each class from the bandwidth remaining value allocated to the class. If you do not configure the bandwidth remaining command for any class, the leftover bandwidth is allocated equally to all classes for which bandwidth remaining is not explicitly specified.

Guaranteed Service rate of a queue is defined as the bandwidth the queue receives when all the queues are congested. It is defined as:

Guaranteed Service Rate = minimum bandwidth + excess share of the queue

Restrictions

The amount of bandwidth configured should be large enough to also accommodate Layer 2 overhead.

A policy map can have all class bandwidths specified in kilobits per second or percentages but not a mixture of both in the same class.

The bandwidth command is supported only on policies configured on outgoing interfaces.

SUMMARY STEPS

1. configure


3. class class-name

4. bandwidth {rate [units] | percent value}

5. bandwidth remaining percent value

6. exit

7. class class-name

8. bandwidth {rate [units] | percent percent-value}


10. exit


OL-24694-01


11. exit



14. endorcommit


DETAILED STEPS


Step 1 configure








Example:RP/0/RP0/CPU0:router(config-pmap)# class class1


Step 4 bandwidth {rate [units]| percent value}

Example:RP/0/0/CPU0:router(config-pmap-c)# bandwidth percent 50


• Specifies the bandwidth allocated for a class belonging to a policy map.

• In this example, class class1 is guaranteed 50 percent of the interface bandwidth.

Step 5 bandwidth remaining percent value

Example:RP/0/0/CPU0:router(config-pmap-c)# bandwidth remaining percent 20

Specifies how to allocate leftover bandwidth to various classes.

• The remaining bandwidth of 40 percent is shared by class class1 and class2 (see Steps 8 and 9) in a 20:80 ratio: class class1 receives 20 percent of the 40 percent, and class class2 receives 80 percent of the 40 percent.

Step 6 exit





Specifies the name of a different class whose policy you want to create or change.


OL-24694-01


Step 8 bandwidth {rate [units] | percent value}


Specifies the bandwidth allocated for a class belonging to a policy map.

• In this example, class class2 is guaranteed 10 percent of the interface bandwidth.



Specifies how to allocate leftover bandwidth to various classes.

• The remaining bandwidth of 40 percent is shared by class class1 (see Steps 4 and 5) and class2 in a 20:80 ratio: class class1 receives 20 percent of the 40 percent, and class class2 receives 80 percent of the 40 percent.

Step 10 exit



Step 11 exit




Example:RP/0/0/CPU0:router(config)# interface POS 0/2/0/0








OL-24694-01


Configuring Low-Latency Queueing with Strict Priority QueueingThe priority command configures low-latency queueing (LLQ), providing strict priority queueing (PQ). Strict PQ allows delay-sensitive data, such as voice, to be dequeued and sent before packets in other queues are dequeued. When a class is marked as high priority using the priority command, we recommend that you configure a policer to limit the priority traffic. This configuration ensures that the priority traffic does not starve all of the other traffic on the line card, which protects low priority traffic from starvation. Use the police command to explicitly configure the policer.

Restrictions

• Within a policy map, you can give one or more classes priority status. When multiple classes within a single policy map are configured as priority classes, all traffic from these classes is queued to the same single priority queue.

• The bandwidth, priority, and shape average commands should not be configured together in the same class.

SUMMARY STEPS

1. configure


Step 14 end

or

commit


or










Example:RP/0/0/CPU0:router# show policy-map interface POS 0/2/0/0




OL-24694-01


3. class class-name

4. police rate {rate [units] | percent percentage}} [burst burst-size [burst-units]] [peak-burst peak-burst [burst-units]] [peak-rate value [units] | percent percentage]


6. priority

7. exit

8. exit



11. endorcommit


DETAILED STEPS


Step 1 configure




Example:RP/0/0/CPU0:router(config)# policy-map voice




Example:RP/0/0/CPU0:router(config-pmap)# class voice



Step 4 police rate {rate [units] | percent percentage}} [burst burst-size [burst-units]] [peak-burst peak-burst [burst-units]] [peak-rate value [units]] | percent percentage]

Example:RP/0/0/CPU0:router(config-pmap-c)# police rate 250


• In this example, the low-latency queue is restricted to 250 kbps to protect low-priority traffic from starvation and to release bandwidth.



Configures the action to take on packets that exceed the rate limit.


OL-24694-01


Step 6 priority


Specifies priority to a class of traffic belonging to a policy map.

Step 7 exit



Step 8 exit





Enters interface configuration mode, and configures an interface.





Step 11 end

or

commit


or














OL-24694-01


Configuring Traffic ShapingTraffic shaping allows you to control the traffic exiting an interface to match its transmission to the speed of the remote target interface and ensure that the traffic conforms to policies contracted for it.

Shaping on both incoming and outgoing interfaces is done at the Layer 3 level. Traffic shaping can be configured on Layer 2 or Layer 3 QoS packet size - it is configurable.

• On 10 Gbps IP Services Engine (Engine 5) line cards, the default QoS packet size is Layer 2. To change the QoS packet size to Layer 3, use the service-policy account nolayer2 command.

• On 2.5 Gbps IP Services Engine (Engine3) line cards, the default QoS packet size is Layer 3. QoS packet size can be changed only on outgoing interfaces of the 4-Port Gigabit Ethernet ISE line card. To change the QoS packet size, use the hw-module qos account layer2 encapsulation command.

Restrictions

The bandwidth, priority, and shape average commands should not be configured together in the same class.

SUMMARY STEPS

1. configure


3. class class-name

4. shape average {percent value | rate [units]} [burst-size [burst-units]]

5. exit

6. exit



9. endorcommit


DETAILED STEPS


Step 1 configure








OL-24694-01






Step 4 shape average {percent value | rate [units]} [burst-size [burst-units]]

Example:RP/0/0/CPU0:router(config-pmap-c)# shape average percent 50

Shapes traffic to the indicated bit rate according to average rate shaping in the specified units or as a percentage of the bandwidth.

Step 5 exit



Step 6 exit










Step 9 end

or

commit


or











OL-24694-01


Configuring Traffic PolicingTraffic policing allows you to control the maximum rate of traffic sent or received on an interface.

Restrictions

set cos is not allowed as an ingress policer action.

SUMMARY STEPS

1. configure


3. class class-name

4. police rate {rate [units] | percent percentage}} [burst burst-size [burst-units]] [peak-burst peak-burst [burst-units]] [peak-rate value [units] | percent percentage]



7. exit

8. exit

9. exit



12. endorcommit


Note The multi-action set/policer feature allows you to configure multiple conform and exceed actions. Hence, you can repeat the conform-action and exceed-action commands multiple times in your configuration.






OL-24694-01


DETAILED STEPS


Step 1 configure











Step 4 police rate {rate [units] | percent percentage} [burst burst-size [burst-units]] [peak-burst peak-burst [burst-units]] [peak-rate value [units] | percent percentage]

Example:RP/0/0/CPU0:router(config-pmap-c)# police rate 250000

Configures traffic policing and enters policy map police configuration mode. The traffic policing feature works with a token bucket algorithm.


Example:RP/0/0/CPU0:router(config-pmap-c-police)# conform-action set mpls experimental topmost 3

Configures the action to take on packets that conform to the rate limit. The action argument is specified by one of the following keywords:

• drop—Drops the packet.

• set—Has the following keywords and arguments:

– atm-clp value—Sets the cell loss priority (CLP) bit.

– cos value—Sets the class of service value. Range is 0 to 7.

– discard-class value—Sets the discard class on IP Version 4 (IPv4) or Multiprotocol Label Switching (MPLS) packets. Range is 0 to 7.

– dscp [tunnel] value—Sets the differentiated services code point (DSCP) value and sends the packet.

– mpls experimental {topmost | imposition} value—Sets the experimental (EXP) value of the Multiprotocol Label Switching (MPLS) packet topmost label or imposed label. Range is 0 to 7.

– precedence [tunnel] precedence—Sets the IP precedence and sends the packet.

• transmit—Transmits the packets.


OL-24694-01



Example:RP/0/0/CPU0:router(config-pmap-c-police)# exceed-action set mpls experimental topmost 4

Configures the action to take on packets that exceed the rate limit. The action argument is specified by one of the keywords specified in Step 5.

Step 7 exit

Example:RP/0/0/CPU0:router(config-pmap-c-police)# exit

Returns the router to policy map class configuration mode.

Step 8 exit



Step 9 exit





Enters configuration mode and configures an interface.





Step 12 end

or

commit


or











OL-24694-01


Configuring Policer GranularityUse the Policer Granularity feature to override the default policer granularity value so that the police rate you specify is a multiple of the policer granularity.

Restrictions

The Policer Granularity feature has the following limitations:

• Supported on Cisco 12000 SIP-401, Cisco 12000 SIP-501, and Cisco 12000 SIP-601.

• Policer granularity values apply to the SIP and to all SPAs that are installed on the SIP.

• If there are policies configured on the SIP, the SIP must be reloaded for configured policer granularity changes to take effect. (If there are no policies configured on the SIP, a reload is not required.)

• Effective police rate is a multiple of the policer granularity.

SUMMARY STEPS

1. configure

2. hw-module qos pol-gran granularity location location

3. end

DETAILED STEPS






Step 1 configure



Step 2 hw-module qos pol-gran granularity location location

Example:RP/0/0/CPU0:router(config)# hw-module qos pol-gran 8 location 0/4/CPU0

Overrides the default policer granularity for the SIP and sets it to 8 kbps.

The effective police rate will be a multiple of 8.

The range of granularity values is 8 kbps to 64 kbps.


OL-24694-01

Configuring Modular QoS Congestion Management on Cisco IOS XR SoftwareConfiguration Examples for Configuring QoS Congestion Management on Cisco IOS XR Software

Configuration Examples for Configuring QoS Congestion Management on Cisco IOS XR Software

This section provides the following configuration examples:

• Traffic Shaping for an Input Interface: Example, page 91

• Traffic Policing for a Bundled Interface: Example, page 92

• Traffic Policing for an IPSec Interface: Example, page 93

• Policer Granularity: Example, page 93

• ATM QoS on Layer 2 VPN: Examples, page 93

• Multiple Action Set: Examples, page 95

Traffic Shaping for an Input Interface: ExampleThe following example shows how to configure a policy map on an input interface:

policy-map p2 class voip shape average percent 20 ! class class-default ! end-policy-map!

The following example shows the display output for the previous policy map configuration:

Step 3 end

or

commit


or











OL-24694-01


RP/0/1/CPU0:router#show policy-map interface pos 0/9/0/0 Thu Mar 25 20:37:41.743 UTC POS0/9/0/0 input: p2 Class voip Classification statistics (packets/bytes) (rate - kbps) Matched : 0/0 0 Transmitted : 0/0 0 Total Dropped : 0/0 0 Queueing statistics Queue ID : 0 High watermark (Unknown) : 0 Inst-queue-len (packets) : 0 Avg-queue-len (packets) : 0 Taildropped(packets/bytes) : 0/0Class class-default Classification statistics (packets/bytes) (rate - kbps) Matched : 0/0 0 Transmitted : 0/0 0 Total Dropped : 0/0 0

Traffic Policing for a Bundled Interface: ExampleThe following example shows how to configure a policy map for a bundled interface. Note that for bundled interfaces, policing can be configured only as a percentage and not a specific rate per second:

policy-map p2 class voip police rate percent 20 ! ! class class-default ! end-policy-map!

The following example shows the display output for the successful policy map configuration in which policing was configuredas a percentage:

RP/0/8/CPU0:E5P-PE1#show policy-map interface bundle-pos 1Thu Mar 25 21:29:40.107 PST

Bundle-POS1 input: p2

Class voip Classification statistics (packets/bytes) (rate - kbps) Matched : 0/0 0 Transmitted : 0/0 0 Total Dropped : 0/0 0 Policing statistics (packets/bytes) (rate - kbps) Policed(conform) : 0/0 0 Policed(exceed) : 0/0 0 Policed(violate) : 0/0 0 Policed and dropped : 0/0 Class class-default Classification statistics (packets/bytes) (rate - kbps) Matched : 0/0 0 Transmitted : 0/0 0 Total Dropped : 0/0 0


OL-24694-01


Traffic Policing for an IPSec Interface: ExampleThe following example shows how to configure traffic policing on an IPSec interface:

policy-map policy2 class dscp4 police rate 64000 conform transmit exceed drop

priorityclass dscp1

police rate 128000 conform transmit exceed drop

interface service-ipsec 2 service-policy input pre-decrypt policy2

Refer to Implementing IPSec Network Security on Cisco IOS XR Software in the Cisco IOS XR System Security Configuration Guide for the Cisco XR 12000 Series Routerfor more information on configuring IPSec.

Policer Granularity: ExampleThe police rate you set should be a multiple of the policer granularity. For example, if the police rate is set to 72 kbps but the default policer granularity is 64 kbps, the effective police rate is 64 kbps. To get an actual police rate of 72 kbps, configure the policer granularity to 8 kbps. Because 72 is a multiple of 8, the police rate will be exactly 72 kbps.

This example shows how to set the policer granularity to 8 kbps:

hw-module qos pol-gran 8 location 0/1/CPU0

Use the show qos pol-gran location command to verify the policer granularity. The Admin value is the value configured using the hw-module qos pol-gran location command. The Oper value is the default policer granularity for this SIP.

show qos pol-gran location 0/1/CPU0

QoS Policer Granularity RateAdmin Value: 8 kbpsOper Value: 64 kbps

ATM QoS on Layer 2 VPN: ExamplesThe following examples shows how to configure ATM QoS on Layer 2 VPNs:

• Attaching a Service Policy to the Attachment Circuits (AC), page 93

• Configuring Policing Based on Service Type, page 94

• Configuring Dual Queue Limit, page 95

Attaching a Service Policy to the Attachment Circuits (AC)

The service-policy command under the PVC sub-mode is applicable to the AC in the virtual circuit (VC) mode. This command is also available for the AC in the virtual path (VP) mode and under the main interface for port mode. For the port mode, the service policy is attached in the l2transport sub-mode consistent with the behavior for the VC and VP modes. In non-port mode, the service policy is attached to the main interface under the interface submode.


OL-24694-01


VC mode:

Router(config)#interface ATM0/1/0/0.2 l2transportRouter(config-subif)#pvc 10/2Router(config-atm-vc)#service-policy output atm_policy_o

VP mode:

Router(config)#interface ATM0/1/0/0.3 l2transportRouter(config-subif)#pvp 30Router(config-atm-vc)#service-policy input atm_policy_i

Port mode:

Router(config)#interface ATM0/1/0/0Router(config-subif)# l2transportRouter(config-l2-transport)#service-policy input atm_policy_i

Main interface (non-port mode):

Router(config)#interface ATM0/1/0/0 Router(config-subif)# service-policy output atm_policy_o

Configuring Policing Based on Service Type

The following example shows how to configure policing based on service type:

CBR or UBR:

CBR.1 (real-time traffic) and UBR (best effort, non-real time traffic) require the peak cell rate (PCR) and delay tolerance parameters to be specified for policing. The main difference between the configurations for UBR.1 and UBR.2 traffic is that for UBR.2 traffic, the exceed action includes the set-clp-transmit option to tag the non-conforming cells.

policy-map CBR1 class class-default police rate <pcr> cellsps delay-tolerance <cdvt> us

conform-action <> exceed-action <>

The police rate is expressed in percentage.

VBR.1

VBR.1 is real-time and non-real time traffic, and requires the peak cell rate (PCR), sustainable cell rate (SCR) and delay tolerance parameters to be specified for policing. In addition, the atm-mbs parameter can be specified to define the burst allowed on the SCR bucket.

policy-map VBR1 class class-default police rate <scr> cellsps atm-mbs <mbs> cells peak-rate <pcr> cellsps delay-tolerance <cdvt> us


The police rate is expressed in percentage.

VBR.2 or VBR.3

VBR.2 and VBR.3 are real-time and non-real time traffic, and require the peak cell rate (PCR), sustainable cell rate (SCR) and delay tolerance parameters to be specified for policing. In addition, the atm-mbs parameter can be specified to define the burst allowed on the SCR bucket.


OL-24694-01


The main difference between VBR.1 and VBR.2 or VBR.3 is that the SCR bucket is for CLP0 cells only. A hierarchical policy is defined to support this configuration:

policy-map child class atm_clp0 police rate <scr> cellsps atm-mbs <mbs> cells


policy-map VBR2 class class-default

police rate <pcr> cellsps delay-tolerance <cdvt> us conform-action <> exceed-action <>

service-policy child

The police rates is expressed in percentage. The child policy can contain other set actions as well.

Exclude OAM cells

OAM cells can be excluded from being policed by configuring the classification criteria.

policy-map child class atm-oam set <> class class-default police rate <scr> cellsps atm-mbs <mbs> cells conform-action <> exceed-action <>

policy-map VBR2class class-default

police rate <pcr> cellsps delay-tolerance <cdvt> us conform-action <> exceed-action <>

service-policy child

Configuring Dual Queue Limit

Dual queue limit configuration is supported on the egress Layer 2 ATM interfaces to differentiate between CLP0 and CLP1 cells.

policy-map q-limitclass class-default

queue-limit atm clp <queue-size> {[ms|us|cells]} queue-limit <queue-size> {[ms|us|cells]

Multiple Action Set: ExamplesThe following examples show how to configure multiple action sets for both conditional and unconditional markings in both the ingress and egress directions:

• Conditional Policer Markings in the Ingress Direction: Example, page 96

• Unconditional Quality-of-Service Markings in the Ingress Direction: Examples, page 96

• Conditional Policer Markings in the Egress Direction: Example, page 96

• Unconditional Quality-of-Service Markings in the Egress Direction: Example, page 97


OL-24694-01


Conditional Policer Markings in the Ingress Direction: Example

The following example shows how to configure conditional policer markings in the ingress direction:

policy-map p1class c1police rate percent 30 peak-rate percent 50 conform-action set qos-group 2 conform-action set discard-class 3conform-action set mpls experimental imposition 3 exceed-action set precedence tunnel 4 exceed-action set mpls experimental imposition 4

!!

class class-default!end-policy-map

!

If policy map p1 is applied as an ingress policy, the following action sets are applied:

• By using the conform-action command, IP packets are marked with a discard class value of 3 and the MPLS experimental value for the imposition label is set to 3.

• By using the exceed-action command, IP packets are marked with the precedence value of 4 and the MPLS experimental value for the imposition label is set to 4.

Unconditional Quality-of-Service Markings in the Ingress Direction: Examples

The following example shows how to configure unconditional QoS markings in the ingress direction.

Note A maximum of three set actions are allowed.

configurepolicy-map p4class c1set discard-class 2set qos-group 4set mpls experimental imposition 3!

class class-default!

end-policy-map!

Conditional Policer Markings in the Egress Direction: Example

The following example shows how to configure conditional policer markings in the egress direction:

configurepolicy-map p3class c1police rate percent 30 peak-rate percent 50 conform-action set precedence 2 exceed-action set dscp 4 !


OL-24694-01


!class class-default!end-policy-map

!

Note Only one policer conform or exceed set is allowed in the egress direction.

Unconditional Quality-of-Service Markings in the Egress Direction: Example

The following example shows how to configure the unconditional QoS markings in the egress direction:

configurepolicy-map p6class c1set precedence 5!

class class-default!end-policy-map

!

If policy map p6 is applied as an egress policy, IP packets are marked with the precedence value of 5 from the set precedence command.


OL-24694-01

Configuring Modular QoS Congestion Management on Cisco IOS XR SoftwareAdditional References

Additional ReferencesThe following sections provide references related to implementing QoS congestion management.

Related Documents

Standards

MIBs

RFCs






Standards Title


—

MIBs MIBs Link


RFCs Title


—


OL-24694-01




Description Link




OL-24694-01




OL-24694-01

Configuring Modular QoS Congestion Avoidance on Cisco IOS XR Software

Congestion avoidance techniques monitor traffic flow in an effort to anticipate and avoid congestion at common network bottlenecks. Avoidance techniques are implemented before congestion occurs as compared with congestion management techniques that control congestion after it has occurred.

Congestion avoidance is achieved through packet dropping. Cisco IOS XR software supports the following quality of service (QoS) congestion avoidance techniques that drop packets:

• Random early detection (RED)

• Weighted random early detection (WRED)

• Tail drop

The module describes the concepts and tasks related to these congestion avoidance techniques.

Feature History for Configuring Modular QoS Congestion Avoidance on Cisco IOS XR Software

Contents• Prerequisites for Configuring Modular QoS Congestion Avoidance on Cisco IOS XR Software,

page 102

• How to Configure Modular QoS Congestion Avoidance on Cisco IOS XR Software, page 105

• Configuration Examples for Configuring Policy Maps, page 116



Release 3.2 The Congestion Avoidance feature was introduced.

Release 3.6.0 Weighted random early detection (WRED) support for IPv4 multicast egress QoS traffic was introduced on 2.5 Gbps IP Services Engine (Engine 3) linecards.

Release 4.0.0 In calculations for the average queue size, indicated that the exponential weight factor is not configurable (CSCeg75763).


OL-24694-01

Configuring Modular QoS Congestion Avoidance on Cisco IOS XR SoftwarePrerequisites for Configuring Modular QoS Congestion Avoidance on Cisco IOS XR Software

Prerequisites for Configuring Modular QoS Congestion Avoidance on Cisco IOS XR Software

The following prerequisite is required for configuring QoS congestion avoidance on your network:

You must be in a user group associated with a task group that includes the proper task IDs. The command reference guides include the task IDs required for each command. If you suspect user group assignment is preventing you from using a command, contact your AAA administrator for assistance.

Information About Configuring Modular QoS Congestion Avoidance on Cisco IOS XR Software

To configure QoS congestion avoidance techniques in this document you must understand the following concepts:

• Random Early Detection and TCP, page 102

• Weighted Random Early Detection for Preferential Traffic Handling, page 102

• WRED Support for IPv4 Multicast Egress QoS Traffic, page 104

• Tail Drop and the FIFO Queue, page 105

Random Early Detection and TCPThe RED congestion avoidance technique takes advantage of the congestion control mechanism of TCP. By randomly dropping packets prior to periods of high congestion, RED tells the packet source to decrease its transmission rate. Assuming the packet source is using TCP, it decreases its transmission rate until all packets reach their destination, indicating that the congestion is cleared. You can use RED as a way to cause TCP to slow transmission of packets. TCP not only pauses, but it also restarts quickly and adapts its transmission rate to the rate that the network can support.

RED distributes losses in time and maintains normally low queue depth while absorbing traffic bursts. When enabled on an interface, RED begins dropping packets when congestion occurs at a rate you select during configuration.

Weighted Random Early Detection for Preferential Traffic HandlingWRED provides the ability to define multiple RED profiles within a single class, based on certain match criteria (DSCP, discard class and so on), so that different drop precedences can be configured based on the relative importance of packets. WRED can selectively discard lower priority traffic when the interface begins to get congested and provide differentiated performance characteristics for different classes of service. You can configure WRED to ignore IP precedence when making drop decisions so that nonweighted RED behavior is achieved.

WRED makes early detection of congestion possible and provides for multiple classes of traffic. It also protects against global synchronization. For these reasons, WRED is useful on any output interface in which you expect congestion to occur.


OL-24694-01

Configuring Modular QoS Congestion Avoidance on Cisco IOS XR SoftwareInformation About Configuring Modular QoS Congestion Avoidance on Cisco IOS XR Software

However, WRED is usually used in the core routers of a network, rather than at the edge of the network. Edge routers assign IP precedences to packets as they enter the network. WRED uses these precedences to determine how to treat different types of traffic.

WRED provides separate drop thresholds (minimum and maximum) for different classification criteria (such as IP precedences, MPLS EXP values), allowing you to provide different qualities of service in regard to packet dropping for different traffic types. Standard traffic may be dropped more frequently than premium traffic during periods of congestion.

WRED treats non-IP traffic as precedence 0, the lowest precedence. Therefore, non-IP traffic, in general, is more likely to be dropped than IP traffic.

WRED is useful only when the bulk of the traffic is TCP/IP traffic. With TCP, dropped packets indicate congestion, so the packet source reduces its transmission rate. With other protocols, packet sources may not respond or may resend dropped packets at the same rate. Thus, dropping packets does not decrease congestion.

Figure 1 illustrates how WRED works.

Figure 1 Weighted Random Early Detection

Average Queue Size for WRED

The router automatically determines the parameters to use in the WRED calculations. The average queue size is based on the previous average and current size of the queue. The formula is:

average = (old_average * (1-2 -x)) + (current_queue_size * 2 -x)

where x is the exponential weight factor.

For high values of x, the previous average becomes more important. A large factor smooths out the peaks and lows in queue length. The average queue size is unlikely to change very quickly, avoiding a drastic change in size. The WRED process is slow to start dropping packets, but it may continue dropping packets for a time after the actual queue size has fallen below the minimum threshold. The slow-moving average accommodates temporary bursts in traffic.

Incoming packetsTransmitqueue

Outgoingpackets

FIFO scheduling

Queueingbuffer

resources

1675

9

Discard test based on:Buffer queue depthIP Precedence

RSVP session

Classify

Discard test


OL-24694-01

Configuring Modular QoS Congestion Avoidance on Cisco IOS XR SoftwareInformation About Configuring Modular QoS Congestion Avoidance on Cisco IOS XR Software

Note The exponential weight factor, x, is fixed and is not user configurable.

Note If the value of x gets too high, WRED does not react to congestion. Packets are sent or dropped as if WRED were not in effect.

For low values of x, the average queue size closely tracks the current queue size. The resulting average may fluctuate with changes in the traffic levels. In this case, the WRED process responds quickly to long queues. Once the queue falls below the minimum threshold, the process stops dropping packets.

If the value of x gets too low, WRED overreacts to temporary traffic bursts and drops traffic unnecessarily.

WRED Support for IPv4 Multicast Egress QoS TrafficWeighted random early detection (WRED) is supported for IPv4 multicast egress QoS traffic. The following features are supported:

• Classification based on precedence and differentiated services code point (DSCP)

• Queue selection

• Maximum and minimum guaranteed bandwidth

• Detection of remaining bandwidth

• Priority queuing

• Queue limit

• Random early detection (RED)

• Traffic shaping

• Layer 2 set on ATM and Ethernet

Policy map configurations that use Random Early Detection (RED) must comply with the following requirements. These requirements must be met across all interfaces in the line card for precedence and DSCP-based WRED to be supported for multicast traffic. The policy map configuration requirements are specific to a line card and not across the line cards:

• Multicast must be enabled.

• The same class maps must be used in all the policy maps.

• The class maps must be configured in the same order in all of the policy maps.

• The same RED statements must be configured in a class map across policy maps. The minimum and maximum threshold values can be different for each policy map.

• If a RED profile is used by more than one DSCP or precedence in a class, the precedence or DSCP values share the same RED profile in all the different policy maps.

If the policy map requirements are not met for all interfaces in the line card and are not met for at least one policy map, RED configuration is not applied to the multicast traffic and all multicast traffic in the line card is tail-dropped. See the “Tail Drop and the FIFO Queue” section on page 105.

Interfaces with no policy maps and interfaces with policy maps that do not use RED function normally.


OL-24694-01

Configuring Modular QoS Congestion Avoidance on Cisco IOS XR SoftwareHow to Configure Modular QoS Congestion Avoidance on Cisco IOS XR Software

For hierarchal policy maps that use WRED, only the child policies should conform to the policy map configuration requirements.

Restrictions

The following features are not supported by WRED for IPv4 multicast egress QoS traffic:

• Discard-class-based RED. WRED is supported fully on ATM line cards and is supported with restrictions on POS and Ethernet line cards.

• Classification other than DSCP or precedence.

• Layer 3 set.

• QoS is not active when packets go to the slow path. All packets go to the default queue.

• IPv6 multicast.

• Policing traffic. The hw-module qos multicast priorityq disable command is used to prevent traffic from reaching the priority queue.

Supported Platforms

WRED is supported for IPv4 multicast egress QoS traffic on the following Cisco XR 12000 Series Router platforms:

• POS line cards

– Cisco XR 12000 Series 4xOC12c/STM4c POS Rev B

– Cisco XR 12000 Series 16xOC3c/STM1c POS Rev B

– Cisco XR 12000 Series 8xOC3c/STM1c POS



• Ethernet line card

– Cisco XR 12000 Series 4xGE

Tail Drop and the FIFO QueueTail drop is a congestion avoidance technique that drops packets when an output queue is full until congestion is eliminated. Tail drop treats all traffic flow equally and does not differentiate between classes of service. It manages the packets that are unclassified, placed into a first-in, first-out (FIFO) queue, and forwarded at a rate determined by the available underlying link bandwidth.

See the “Default Traffic Class” section of the “Configuring Modular Quality of Service Packet Classification on Cisco IOS XR Software” module.

How to Configure Modular QoS Congestion Avoidance on Cisco IOS XR Software



OL-24694-01


• Configuring Random Early Detection, page 106 (required)

• Configuring Weighted Random Early Detection, page 108 (required)

• Configuring Tail Drop, page 111 (required)

• Configuring Multicast Egress QoS, page 114 (optional)

Configuring Random Early DetectionYou can configure Random Early Detection (RED) by not specifying IP precedence or any other match criteria. In this way, a single RED profile is applied to all packets matching the class.

This configuration task is similar to that used for WRED except that the random-detect precedence command is not configured and the random-detect command with the default keyword must be used to enable RED.

Restrictions

For the random-detect command to take effect, you must configure either the shape average, bandwidth/bandwidth remaining percent command in the user defined policy map class. This dependency is not applicable to the policy map class class-default.

SUMMARY STEPS

1. configure


3. class class-name

4. random-detect {discard-class value | dscp value | exp value | precedence value | min-threshold [units] max-threshold [units] }

5. bandwidth {bandwidth [units] | percent value}


7. shape average {percent percentage | value [units]}

8. exit

9. exit



12. endorcommit


OL-24694-01


DETAILED STEPS


Step 1 configure











Step 4 random-detect {discard-class value | dscp value | exp value | precedence value | min-threshold [units] max-threshold [units] }

Example:RP/0/0/CPU0:router(config-pmap-c)# random-detect 1000000 2000000

Enables RED with default minimum and maximum thresholds.

Step 5 bandwidth {bandwidth [units] | percent value}


(Optional) Specifies the bandwidth allocated for a class belonging to a policy map.



(Optional) Specifies how to allocate leftover bandwidth to various classes.

Step 7 shape average {percent percentage | value [units]}


(Optional) Shapes traffic to the specified bit rate or a percentage of the available bandwidth.

Step 8 exit



Step 9 exit




OL-24694-01


Configuring Weighted Random Early DetectionWRED drops packets selectively based on IP precedence. Edge routers assign IP precedences to packets as they enter the network. WRED uses these precedences to determine how to treat different types of traffic.

When a packet arrives, the following actions occur:

• The average queue size is calculated.

• If the average queue size is less than the minimum queue threshold, the arriving packet is queued.

• If the average queue size 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.




Step 11 service-policy {input | output}policy-map




Step 12 end

or

commit


or











OL-24694-01


Restrictions

You cannot configure WRED in a class that has been set for priority queueing (PQ).

You cannot use the random-detect command in a class configured with the priority command.

For the random-detect command to take effect, you must configure either the shape average or bandwidth/bandwidth remaining percent command in the user defined policy map class. This dependency is not applicable to the policy map class class-default.

SUMMARY STEPS

1. configure


3. class class-name

4. random-detect dscp dscp-value min-threshold [units] max-threshold [units]

5. bandwidth {bandwidth [units] | percent value}


7. shape average {percent | value [units]}

8. exit



11. endorcommit

DETAILED STEPS


Step 1 configure












OL-24694-01


Step 4 random-detect dscp dscp-value min-threshold [units] max-threshold [units]

Example:RP/0/0/CPU0:router(config-pmap-c)# random-detect dscp af11 1000000 bytes 2000000 bytes

Changes the minimum and maximum packet thresholds for the DSCP value.

• Enables RED.

• dscp-value—Number from 0 to 63 that sets the DSCP value. Reserved keywords can be specified instead of numeric values.

• min-threshold—Minimum threshold in the specified units. The value range of this argument is from 512 to 1073741823. When the average queue length reaches the minimum threshold, WRED randomly drops some packets with the specified DSCP value.

• max-threshold—Maximum threshold in the specified units. The value range of this argument is from the value of the min-threshold argument to 1073741823. When the average queue length exceeds the maximum threshold, WRED drops all packets with the specified DSCP value.

• units—Units of the threshold value. This can be bytes, gbytes, kbytes, mbytes, ms (milliseconds), packets, or us (microseconds). The default is packets.

• This example shows that for packets with DSCP AF11, the WRED minimum threshold is 1,000,000 bytes and maximum threshold is 2,000,000 bytes.

Step 5 bandwidth {bandwidth [units] | percent value}


(Optional) Specifies the bandwidth allocated for a class belonging to a policy map.

• This example guarantees 30 percent of the interface bandwidth to class class1.




• The remaining bandwidth of 70 percent is shared by all configured classes.

• In this example, class class1 receives 20 percent of the 70 percent.

Step 7 shape average {percent percentage | value [units]}


(Optional) Shapes traffic to the specified bit rate or a percentage of the available bandwidth.

Step 8 exit





OL-24694-01


Configuring Tail DropPackets satisfying the match criteria for a class accumulate in the queue reserved for the class until they are serviced. The queue-limit command is used to define the maximum threshold for a class. When the maximum threshold is reached, enqueued packets to the class queue result in tail drop (packet drop).

The queue-limit value uses the guaranteed service rate (GSR) of the queue as the reference value for the queue_bandwidth. If the class has bandwidth percent associated with it, the queue-limit is set to a proportion of the bandwidth reserved for that class.

When a class has no guaranteed service rate, the default queue limit depends on whether shaping is applied. If shaping is not applied, the default queue limit is 16384 packets. If shaping is applied, the default queue limit is:

default queue limit (in packets) = (200 ms * (queue bandwidth or shaper rate) / 8) / average packet size, which is 250 bytes

Step 9 interface type inteface-path-id







• Ingress policies are not valid; the bandwidth and bandwidth remaining commands cannot be applied to ingress policies.

Step 11 end

or

commit


or











OL-24694-01


Restrictions

• When configuring the queue-limit command in a class, you must configure one of the following commands: priority, shape average, bandwidth, or bandwidth remaining, except for the default class.

SUMMARY STEPS

1. configure


3. class class-name

4. queue-limit value [units]

5. priority [level priority-level]

6. class class-name


8. exit

9. exit



12. endorcommit

DETAILED STEPS


Step 1 configure











Step 4 queue-limit value [units]

Example:RP/0/0/CPU0:router(config-pmap-c)# queue-limit 1000000 bytes

Specifies or modifies the maximum the queue can hold for a class policy configured in a policy map. The default value of the units argument is packets.

• In this example, when the queue limit reaches 1,000,000 bytes, enqueued packets to the class queue are dropped.


OL-24694-01


Step 5 priority [level priority-level]

Example:RP/0/0/CPU0:router(config-pmap-c)# priority level 1





• In this example, class2 is configured.




• This example allocates 20 percent of the leftover interface bandwidth to class class2.

Step 8 exit



Step 9 exit





Enters configuration mode, and configures an interface.







OL-24694-01


Configuring Multicast Egress QoSThis task configures multicast egress QoS and disables multicast egress traffic on the priority queue.

Prerequisites

Multicast egress QoS can be configured only on an interface that is already configured for multicast routing. See Cisco IOS XR Multicast Configuration Guide for Cisco XR 12000 Series Router for information on configuring multicast routing.

Restrictions

The “Restrictions” section on page 105 lists the restrictions for configuring multicast egress QoS.

SUMMARY STEPS

1. configure

2. hw-module qos multicast location node-id

3. hw-module qos multicast priorityq disable location node-id

4. endorcommit

Step 12 end

or

commit


or











OL-24694-01


DETAILED STEPS


Step 1 configure



Step 2 hw-module qos multicast location node-id

Example:RP/0/0/CPU0:router(config)# hw-module qos multicast location 0/2/0

Enables multicast egress QoS for a specified location.

This command is needed only for multicast QoS on 2.5 Gbps IP Services Engine (Engine 3) linecards.

Step 3 hw-module qos multicast priorityq disable location node-id

Example:RP/0/0/CPU0:router(config)# hw-module qos multicast priorityq disable location 0/2/0

Diverts multicast traffic slated for the priority queue to the default queue QoS for a specified location.

Step 4 end

or

commit


or










OL-24694-01

Configuring Modular QoS Congestion Avoidance on Cisco IOS XR SoftwareConfiguration Examples for Configuring Policy Maps

Configuration Examples for Configuring Policy MapsThis section provides the following configuration examples:

• Enabling WRED for IPv4 Egress Multicast Traffic, page 116

Enabling WRED for IPv4 Egress Multicast TrafficThe following example shows a policy map configuration that meets the requirements to enable WRED for IPv4 egress multicast traffic:

policy-map policy_Aclass prec0123 bandwidth percent 20 random-detect precedence routine 1000 packets 2000 packets random-detect precedence priority 1000 packets 4000 packets random-detect precedence immediate 2000 packets 5000 packetsclass prec45 bandwidth percent 40 random-detect precedence flash-override 4000 packets 8000 packets

policy-map policy_Bclass prec0123 bandwidth percent 10 random-detect precedence routine 1000 packets 4000 packets random-detect precedence priority 2000 packets 5000 packets random-detect precedence immediate 3000 packets 6000 packetsclass prec45 bandwidth percent 30 random-detect precedence flash-override 4000 packets 8000 packets

policy-map policy_Cclass prec012 bandwidth percent 20class prec34 bandwidth percent 40

interface pos0/1/0/0service-policy output policy_A

interface pos 0/1/0/1service-policy output policy_B

interface pos 0/1/0/3service-policy output policy_C

The interfaces mapped to policy_A and policy_B are configured with the same classes and RED statements. The precedences for policy_A and policy_B are mapped to the same RED profile although the minimum and maximum RED thresholds are different. The interface mapped to policy_C is configured differently than the interfaces mapped to policy_A and policy_B.


OL-24694-01

Configuring Modular QoS Congestion Avoidance on Cisco IOS XR SoftwareAdditional References

Additional ReferencesThe following sections provide references related to implementing QoS congestion avoidance.

Related Documents

Standards

MIBs

RFCs






Standards Title


—

MIBs MIBs Link


RFCs Title


—


OL-24694-01


Configuring Modular QoS Congestion Avoidance on Cisco IOS XR SoftwareAdditional References


Description Link




OL-24694-01


Configuring Fabric QoS Policies and Classes on Cisco IOS XR Software

This module provides the conceptual and configuration information for fabric QoS.

Feature History for Configuring Fabric Quality of Service Policies and Classes on Cisco IOS XR Software

Contents• Prerequisites for Configuring Fabric Quality of Service Policies and Classes on Cisco IOS XR

Software, page 119

• Information About Configuring Fabric Quality of Service Policies and Classes on Cisco IOS XR Software, page 120

• How to Configure Fabric Quality of Service Policies and Classes on Cisco IOS XR Software, page 120

• Configuration Examples for Configuring Fabric Quality of Service Policies and Classes on Cisco IOS XR Software, page 123


Prerequisites for Configuring Fabric Quality of Service Policies and Classes on Cisco IOS XR Software

The following prerequisites are required for configuring modular fabric QoS on your network:

• You must be in a user group associated with a task group that includes the proper task IDs. The command reference guides include the task IDs required for each command. If you suspect user group assignment is preventing you from using a command, contact your AAA administrator for assistance.


Release 3.3.0 The Fabric QoS Policies and Classes feature was introduced.


OL-24694-01

Configuring Fabric QoS Policies and Classes on Cisco IOS XR SoftwareInformation About Configuring Fabric Quality of Service Policies and Classes on Cisco IOS XR Software

Information About Configuring Fabric Quality of Service Policies and Classes on Cisco IOS XR Software

To implement fabric QoS features in this document, you must understand the following concepts:

• Overview, page 120

• Ingress Policy and Fabric QoS Policy Interaction, page 120

OverviewThe fabricq queue selection mechanism is known as Fabric QoS. To provide class of service to the traffic under fabric congestion scenarios, configure Fabric QoS. The platform-independent user interface allows you to configure an MQC policy on the switch fabric queues. This policy is global for all line cards on the router.

A maximum of six classes can be specified within the fabric QoS policy. Only one class can have priority. Each class has 16 queues. The only applicable actions that can be assigned to a class are:

• priority

• bandwidth remaining percent

Fabric QoS policy class maps are restricted to matching a subset of the following classification options:

• precedence ipv4

• mpls experimental

Ingress Policy and Fabric QoS Policy InteractionBe careful when applying ingress QoS policies when they must interact with a fabric QoS policy. Fabric QoS classification is independent of ingress QoS classification. The fabric QoS policy overrides any traffic classification conducted by the ingress policy when determining which traffic should be placed into which fabric QoS queue.

Fabric QoS is constrained to a subset of the possible match criteria that can be used in its class maps. This approach enables multiple ingress QoS policies to interact in the expected manner with a fabric QoS policy.

How to Configure Fabric Quality of Service Policies and Classes on Cisco IOS XR Software


• Creating a Traffic Class, page 121 (required)

• Creating a Fabric QoS Service Policy, page 121 (required)


OL-24694-01

Configuring Fabric QoS Policies and Classes on Cisco IOS XR SoftwareHow to Configure Fabric Quality of Service Policies and Classes on Cisco IOS XR Software

Creating a Traffic ClassSee the “Creating a Traffic Class” section in the “Configuring Modular Quality of Service Packet Classification on Cisco IOS XR Software” module.

Creating a Fabric QoS Service PolicyThis configuration task explains how to configure a fabric QoS policy.

Restrictions

• A maximum of six classes can be specified within the fabric QoS policy.

• Only one class can have priority.

• The only applicable actions that can be assigned to a class are:

– priority

– bandwidth remaining percent

• Fabric QoS policy class maps are restricted to matching a subset of the following classification options:

– precedence ipv4

– mpls experimental

SUMMARY STEPS

1. configure

2. class-map class-map-name

3. match precedence ipv4 precedence-value


5. class class-name

6. priority

7. switch-fabric service-policy

8. endorcommit


OL-24694-01

Configuring Fabric QoS Policies and Classes on Cisco IOS XR SoftwareHow to Configure Fabric Quality of Service Policies and Classes on Cisco IOS XR Software

DETAILED STEPS


Step 1 configure



Step 2 class-map class-map-name

Example:RP/0/0/CPU0:router(config)# class-map class201


• Creates a class map to be used for matching packets to the class whose name you specify.

• If you specify match-any, one of the match criteria must be met for traffic entering the traffic class to be classified as part of the traffic class. This is the default.

Step 3 match precedence ipv4 precedence value

Example:RP/0/0/CPU0:router(config-cmap)# match precedence ipv4 5

Specifies a precedence value that is used as the match criteria against which packets are checked to determine if they belong to the class specified by the class map.

Note Fabric QoS is supported for IPv4 only.


Example:RP/0/0/CPU0:router(config-cmap)# policy-map policy1






Step 6 priority



Step 7 switch-fabric service-policy

Example:RP/0/0/CPU0:router(config)# switch-fabric service-policy policy1

Configures a service policy for the switch fabric.


OL-24694-01

Configuring Fabric QoS Policies and Classes on Cisco IOS XR SoftwareConfiguration Examples for Configuring Fabric Quality of Service Policies and Classes on Cisco IOS XR Software

Configuration Examples for Configuring Fabric Quality of Service Policies and Classes on Cisco IOS XR Software

This section contains the following examples:

• Configuring Fabric Quality of Service Policies and Classes: Example, page 123

Configuring Fabric Quality of Service Policies and Classes: ExampleThe following example shows a fabric QoS configuration:

class-map match-any fab_1match precedence ipv4 priority

class-map match-any fab_2match precedence ipv4 immediate

class-map match-any fab_3match precedence ipv4 flash

class-map match-any fab_4match precedence ipv4 flash-override

class-map match-any fab_5match precedence ipv4 critical

class-map match-any fab_6match precedence ipv4 internet

policy-map fab

Step 8 end

or

commit


or




Uncommitted changes found, commit them before exiting (yes/no/cancel)?[cancel]:







OL-24694-01

Configuring Fabric QoS Policies and Classes on Cisco IOS XR SoftwareConfiguration Examples for Configuring Fabric Quality of Service Policies and Classes on Cisco IOS XR Software

class fab_1bandwidth remaining percent 5!class fab_2bandwidth remaining percent 25!class fab_3bandwidth remaining percent 30!class fab_4bandwidth remaining percent 20!class fab_5bandwidth remaining percent 20!class fab_6priority!

switch-fabric service-policy fabcommit


OL-24694-01

Configuring Fabric QoS Policies and Classes on Cisco IOS XR SoftwareAdditional References

Additional ReferencesThe following sections provide references related to implementing fabric QoS policies and classes.

Related Documents

Standards

MIBs

RFCs






Standards Title


—

MIBs MIBs Link


RFCs Title


—


OL-24694-01


Configuring Fabric QoS Policies and Classes on Cisco IOS XR SoftwareAdditional References


Description Link




OL-24694-01


Configuring Modular QoS on Link Bundles on Cisco IOS XR Software

A link bundle is a group of one or more ports that are aggregated together and treated as a single link. This module describes QoS on link bundles.

Feature History for Configuring Modular QoS Congestion Avoidance on Cisco IOS XR Software

Contents• Link Bundling Overview, page 127

• Load Balancing, page 128

• QoS and Link Bundling, page 129


Link Bundling OverviewThe Link Bundling feature allows you to group multiple point-to-point links together into one logical link and provide higher bidirectional bandwidth, redundancy, and load balancing between two routers. A virtual interface is assigned to the bundled link. The component links can be dynamically added and deleted from the virtual interface.

The virtual interface is treated as a single interface on which one can configure an IP address and other software features used by the link bundle. Packets sent to the link bundle are forwarded to one of the links in the bundle.

The advantages of link bundles are as follows:

• Multiple links can span several line cards and SPAs to form a single interface. Thus, the failure of a single link does not cause a loss of connectivity.


Release 3.6.0 The QoS on Link Bundles feature was introduced.


OL-24694-01

Configuring Modular QoS on Link Bundles on Cisco IOS XR SoftwareLoad Balancing

• Bundled interfaces increase bandwidth availability, because traffic is forwarded over all available members of the bundle. Therefore, traffic can move onto another link if one of the links within a bundle fails. You can add or remove bandwidth without interrupting packet flow. For example, you can upgrade from an OC-48c PLIM modular services card to an OC-192 PLIM modular services card without interrupting traffic.

All links within a bundle must be of the same type. For example, a bundle can contain all Ethernet interfaces, or it can contain all POS interfaces, but it cannot contain Ethernet and POS interfaces at the same time.

Cisco IOS XR software supports the following methods of forming bundles of Ethernet and POS interfaces:

• IEEE 802.3ad—Standard technology that employs a Link Aggregation Control Protocol (LACP) to ensure that all the member links in a bundle are compatible. Links that are incompatible or have failed are automatically removed from a bundle.

• EtherChannel or POS Channel—Cisco proprietary technology that allows the user to configure links to join a bundle, but has no mechanisms to check whether the links in a bundle are compatible. (EtherChannel applies to Ethernet interfaces, and POS Channel applies to POS interfaces.)

The following types of link bundling are supported:

• EtherChannel is used bundle multiple Gigabit Ethernet (GE) interfaces.

• Gigabit EtherChannel link bundles are at Layer 2 and use one MAC address and one IP address for all GigabitEthernet interfaces in the bundle.

• POS Channel is used to bundle multiple Packet-over-SONET (POS) interfaces.

Gigabit EtherChannel and POS Channel link bundling provide the following benefits:

• Flexible, incremental bandwidth

• Transparency to network applications

• Support for IP unicast and MPLS traffic

• Load balancing (equal cost) across all active links on the bundle

• Redundancy: if there is a failure of an individual GE or POS link, the traffic flow through the channel is evenly distributed across the available links.

• Interoperability with link bundling implementations in other Cisco and OEM routers and switches.

• Out-of-service support: a Gigabit EtherChannel or POS Channel is brought down if the minimum number of Gigabit Ethernet or POS links are not up.

• Bandwidth propagation support: bandwidth changes in a Gigabit EtherChannel or POS Channel can be (optionally) propagated to the upper-layer protocols until the amount of bandwidth required in the link bundle exceeds a specified threshold.

Load BalancingLoad balancing is supported on all links in the bundle. Load balancing function is a forwarding mechanism to distribute traffic over multiple links based on layer 3 routing information in the router. There are two types of load balancing schemes:

• Per-Destination Load Balancing

• Per-Packet Load Balancing


OL-24694-01

Configuring Modular QoS on Link Bundles on Cisco IOS XR SoftwareQoS and Link Bundling

When a traffic stream arrives at the router, per-packet load balancing allows the traffic to be evenly distributed among multiple equal cost links. Per-packet schemes make routing decision based on round-robin techniques, regardless of the individual source-destination hosts.

Only Per-Destination Load Balancing is supported.

Per-destination load balancing allows the router to distribute packets over one of the links in the bundle to achieve load sharing. The scheme is realized through a hash calculating based on the source-destination address and user sessions.

When the per-destination load balancing is enabled, all packets for a certain source-destination pair will go through the same link, though there are multiple links available. In other words, per-destination load balancing can ensure that packets for a certain source-destination pair could arrive in order.

QoS and Link BundlingQuality of Service (QoS) features, currently supported on Ethernet and Packet-over-SONET (POS) interfaces, are also supported on Link Bundle interfaces. This section describes the features and restrictions that apply to QoS Link Bundles.

FeaturesThe following QoS features are supported on Link Bundles interfaces:

• IP precedence

• Differentiated Services Code Point (DSCP)

• MPLS Exp

• Class of Service (CoS)

• Discard

• Multicast QoS

• QoS group

• Shaping

• Hierarchical Policing

• Policing

• Bandwidth

• Bandwidth Remaining

• Policy Map Modification

The following QoS features are supported on Link Bundles only through the Modular QoS CLI (MQC).

• Marking (IP prec, MPLS exp, 802.1Q, DSCP)

• Priority

• Shaping

• Input/Output Committed Access Rate (CAR) policing

• Weighted Random Early Detection (WRED)

• Modified Deficit Round Robin (MDRR)


OL-24694-01


Restrictions QoS is configured on Link Bundles primarily in the same way that it is configured on individual interfaces. However, there are some important restrictions that must be observed:

• QoS features are applied only on Link Bundle interfaces — never on individual members.

• For all calculations, the total bandwidth used on a Link Bundle line card is the sum of all bandwidths for all members of all bundles on the line card. Consequently, all rates for policing, shaping, and bandwidth must be configured in percentages instead of absolute values, and the WRED/Qlimit must be configured in units of time.

• In general, show commands aggregate statistics across all line cards on which a bundle interfaces have been replicated.

• The show-policy map command displays information for a bundle. As a result, queue-related information is not displayed in the output of this command.

• The show qos commands for output policies display data and queueing information in the Execution Agent (EA), for each member. For egress QoS policies, the policer is applied at bundle level, while all other QoS features (e.g. shaping) are applied at member level. As a result, the police information is displayed on a per bundle basis, while all other QoS information is displayed on a per member basis. For ingress QoS policies, all output from show qos commands is displayed on a per bundle basis.

• Queueing actions are applied on each link-bundle-member. This may cause unexpected QoS behaviour in some cases. For example, if 50% bandwidth is guaranteed on a bundle with two member links, using the bandwidth command, the effect is to guarantee 50% bandwidth on each member link. Since the traffic distributuon on the members may not be 50% each, the bandwidth for each bundle may be different to what is expected.

• There is no QoS in slow path for Link Bundles.

• VLAN-based load sharing is not supported on EtherBundles, and QoS reflects this.

• match cos and match vlan commands are not supported on link bundles.

In additon, the following points should be noted, when configuring link bundles which contain both 2.5 Gbps IP Services Engine (E3) Line Card and 10 Gbps IP Services Engine (E5) Line Card links.

• 2.5 Gbps IP Services Engine (Engine 3) and 10 Gbps IP Services Engine (Engine 5) hardware granularities are different for shaper and policer. Hence, for the same configured rate, traffic flow via E3 and E5 line card links may differ.

• For E3 Line Card links, policy accounting is peformed at Layer 3, by default. For E5line card links, policy accounting is performed at Layer 2, by default.

• Full QoS for multicast traffic is supported on E5 Line Cards. The QoS policing and marking features are not supported for multicast traffic on E3 Line Cards.

MarkingWhen traffic matches a certain class, marking (coloring) can be used to set or change the value of these fields in packet headers:

• IP Precedence

• MPLS EXP


OL-24694-01


• IP DSCP

• QoS Group

• Discard Class

• Dot1q P

Note Dot1q P marking occurs at L2 layer. All other fields are marked at L3 layer.

Multiple re-marking is possible on bundle interfaces using the following calculation on the same class:

"set mpls exp imposition <>" + "set qos-group" + "set discard-class"

IP Precedence Marking

The IP precedence value in the Type of Service (TOS) field of an input or output IP packet may be set or changed by a user configured value.

MPLS EXP Marking

The three MPLS EXP (experimental) bits in the shim header of an input or output MPLS packet header may be set or changed by a user configured value.

DSCP Marking

The six Differentiated Services Code Point (DSCP) bits in the IP header field of an input or output IP packet on an Ether channel may be set or changed by a user configured value.

QoS Group Marking

The QoS Group field of an input IP packet received on an Ether Bundle may be set or changed by a user configured value, using the set qos-group command.

Discard Class Marking

The Discard Class field of an input or output IP packet on an Ether Bundle may be set or changed by a user configured value, using the set discard-class command. For egress only for continue-bit case may be set.

Dot1q P Bit Marking

The 3 priority bits in the Dot1q P field of a tagged ethernet frame may be set or changed by a user configured value. Tagged Ethernet frames are normal Ethernet frames with additional 4 bytes of information inserted between the Source Address (S/A) field and the Type or Length (T/L) field.

PolicingTraffic policing is used to control the rate of traffic transmitted and received on an interface, based on certain matching criteria defined by the user. Traffic policing performs 2 basic functions:

• Controlling the reception and transmission rates for traffic with different Classes of Service (CoS), based on user-defined criteria.

• Marking reception and transmission packets by setting the following fields in packet headers:

– IP Precedence

– MPLS EXP


OL-24694-01


– IP DSCP

– QoS Group

– Discard Class

– Dot1q P

When traffic conforms to or exceeds a configured rate limit, policing performs the following configurable actions:

• transmit

• drop

• set precedence

• set dscp and set qos

Packets that conform to a rate limit are handled with the configured conform-action. Packets that do not conform to a rate limit are handled with the configured exceed-action.

Policing is supported on Link Bundles for ingress and egress traffic.

Single-Rate Color Policing

Single-rate 2-color policing is supported on Link Bundles.Single-rate 3-color policing is supported on Link Bundles.

Dual-Rate Color Policing

Dual-rate 3-color policing is supported on Link Bundles, using the peak-rate keyword of the police rate command:

police rate peak-rate conform-action exceed-action

QoS Group as a Policing Action

You can set the QoS Group as a policing action, using the police command:

police conform-action set qos-group

police exceed-action set qos-group

Note Only one conform-action or one exceed-action may bet set per action type.

Hierarchical Policing

Both hierarchical ingress policing and enhanced hierarchical ingress policing is supported, where different policing actions may be configured at different levels; on the parent class level and on one or more of its child classes.


OL-24694-01

Configuring Modular QoS on Link Bundles on Cisco IOS XR SoftwareAdditional References

Additional ReferencesThe following sections provide references related to implementing QoS on Link Bundles.

Related Documents

Standards

MIBs

RFCs



Link Bundling “Configuring Link Bundling on Cisco IOS XR Software” module of Cisco IOS XR Interface and Hardware Component Configuration Guide for the the Cisco XR 12000 Series Router




Standards Title


—

MIBs MIBs Link


RFCs Title


—


OL-24694-01


Configuring Modular QoS on Link Bundles on Cisco IOS XR SoftwareAdditional References


Description Link




OL-24694-01


Modular QoS Deployment Scenarios on Cisco IOS XR Software

This module provides deployment scenarios use cases for specific QoS features or for QoS implementations of features that are described in other technology guides, such as L2VPN or MPLS.

Feature History for QoS Deployment Scenarios on Cisco IOS XR Software

Contents• ATM Layer 2 QoS, page 135

• IP Header Compression QoS, page 141

• QoS on Multicast VPN, page 143

• VPLS QoS, page 144

• Related Information, page 146

ATM Layer 2 QoSThe following ATM Layer 2 QoS features are supported:

• Layer 2 Ingress QoS – policing, marking, and queueing are supported


Release 3.7.0 The VPLS QoS feature was introduced.

Release 3.8.0 The Qos on Multicast VPN feature was introduced.

Release 3.9.0 The ATM Layer 2 QoS feature was introduced.

The IP Header Compression QoS feature was introduced.

Release 4.0.1 ATM Layer 2 QoS support was added for Circuit Emulation over Packet Shared Port Adapters (CEoPs).

Ingress policing support was added for ATM AAL5SNAP, AAL5MUX, and AAL5NLPID encapsulated packets, for all 10 Gbps IP Services Engine (Engine 5) ATM SPAs.


OL-24694-01

Modular QoS Deployment Scenarios on Cisco IOS XR SoftwareATM Layer 2 QoS

• Layer 2 Egress Main Interface QoS – shaping, policing, and queueing are supported. Marking is not supported. This feature works on both Layer 2 and Layer 3 PVCs independent of any subinterface QoS policies.

• The Modular QoS CLI (MQC) actions are supported for ATM traffic in the ingress direction only.

– match atm clp

– match atm oam

– set atm clp

– set mpls exp imp

– set precedence tunnel (L2TPv3 only)

– set dscp tunnel (L2TPv3 only)

• Traffic is classified based on Cell Loss Priority–CLP1, CLP0, or OAM.

• OAM traffic can be excluded from policing by using the match-oam classification in a hierarchical policy map

• The following set actions are supported:

– set mpls exp imp

– set precedence tunnel

– set dscp tunnel

– set qos-group

– set discard-class

– set atm-clp (exceed action only)

• Policy map counters are supported.

Matching The following match criteria is supported on Layer 2 ATM interfaces in the ingress direction only:

• match atm clp0

• match atm clp1

• match atm oam

The following match criteria is supported on Layer 2 ATM interfaces in the egress direction only:

• match mpls exp topmost (egress only)

• match qos-group (egress only)

Note The match-all command does not support the above match criteria.

MarkingThe following marking actions are supported on Layer 2 ATM interfaces:

• set mpls exp imposition (AToM only)

• set qos-group (AToM and local switching)


OL-24694-01


• set discard-class (AToM and local switching)

• set mpls exp imposition and set atm-clp (AToM only)

• set dscp tunnel (L2TPv3 only)

• set precedence tunnel (L2TPv3 only)

Note Packets can be matched and remarked for CLP0, CLP1, and OAM.

PolicingPolicing is supported on Layer 2 ATM interfaces in the ingress direction only. Policing is performed during segmentation and reassembly (SAR) for the following ATM traffic classes:

• CBR.1

• VBR.1

• VBR.2

• VBR.3

• UBR.1

• UBR.2

Policing is supported for VC, VP, and Port mode L2 ATM interfaces.

OAM cells are policed along with user cells, unless the QOS policy is explicitly configured to exclude OAM cells from being policed. This can be achieved using different match criteria in the policy map. A specific class can be configured to match OAM cells, and the remaining traffic can be matched to the default class.

Policing is done on AAL0 packets with the same conditions as AAL5 packets as follows:

• AAL5 packet is conforming if all the cells in the packet conform to PCR and SCR buckets.

• AAL5 packet is exceeding if at least one cell does not conform to the SCR bucket.

• AAL5 packet is violating if at least one cell does not conform to the PCR bucket.

Note The Martini Control Word C bit is set for all exceeding AAL5 packets. All violating AAL5 packets are dropped.

The following policing options are supported for ATM TM4.0 GCRA policing:

• Rate in cellsps and percent

• Peak rate in cellsps and percent

• Delay tolerance in us

• Maximum burst size in cells

The following conform and exceed actions are supported for Layer 2 ATM interfaces in the ingress direction:

• transmit

• drop

• set mpls exp imposition (AToM only)


OL-24694-01


• set qos-group (AToM and Local switching)

• set discard-class (AToM and Local switching)

• set atm-clp (exceed action only, AToM and Local switching)

• set precedence tunnel (L2TPv3 only)

• set dscp tunnel (L2TPv3 only)

Note The only violate action that is supported is the drop action.

The following combination of multiple policing actions is supported:

• set mpls exp imposition and set atm-clp (exceed action only, AToM only)

Hierarchical Policy Maps For VBR.2 and VBR.3 traffic classes, 2-level hierarchical policy maps are supported in the ingress direction only. Attempts to attach hierarchical policy maps in the egress direction are denied.

The parent policy contains the policing configuration for the PCR bucket and matches on all traffic. The parent policy may exclude OAM traffic.

The child policy contains the policing configuration for the SCR bucket and typically matches on CLP0 cells.

Marking actions are supported only in child policy maps. All other policing actions are allowed in parent policy maps.

Only two policing buckets per Layer 2 circuit are allowed; one in the parent policy that defines the peak rate, and one in the child policy that defines the SCR.

Typically CLP0 cells are sent to the SCR bucket, but it is possible to send both CLP0 and CLP1 cells to the SCR bucket, using the classification criteria in the child policy.

Note For ATM Layer 2 QoS, in policy maps, the set atm-clp command is supported only as a police exceed action. It is not supported as a standalone set action.

Attaching a Service-Policy to an Attachment Circuit Configuration: Example

PVC Modeconfig interface ATM 0/1/0/0.2 l2transport pvc 10/2 service-policy input | output atm_policy_o

PVP Modeconfig interface ATM 0/1/0/0.3 l2transport pvp 30 service-policy input atm_policy_i


OL-24694-01


Port Modeconfig interface ATM 0/1/0/0 l2transport service-policy input atm_policy_i

Main Interface (non-port mode)config interface ATM 0/1/0/0 service-policy input | output atm_policy_o

Policy Map Configuration for CBR/UBR: ExampleFor CBR.1 (real-time traffic) and UBR (best effort, non-real time traffic) you must specify the PCR and delay tolerance parameters for policing. The main difference between the configurations for UBR.1 and UBR.2 traffic is that for UBR.2 traffic, the exceed action includes the set-clp-transmit option to tag non-conforming cells. The police rate can also be expressed as a percentage.

The following example shows how to configure a QoS policy map for CBR/UBR:

policy-map CBR1 class class-default police rate pcr cellsps delay-tolerance cdvt us conform-action action exceed-action action

Policy Map Configuration for VBR.1: Example For VBR.1 real-time and non-real time traffic you must specify the PCR, SCR, and delay tolerance parameters for for policing. The atm-mbs parameter can be specified to define the burst allowed on the SCR bucket. The police rates can also be expressed as percentages. Class atm_clp1 is allowed with police actions.

The following example shows how to configure a QoS policy map for VBR.1:

policy-map VBR1 class class-default police rate scr cellsps atm-mbs mbs cells peak-rate pcr cellsps delay-tolerance cdvt us conform-action action exceed-action action

Policy Map Configuration for VBR.2 and VBR.3: Example For VBR.2 and VBR.3 real-time and non-real time traffic you must specify the PCR, SCR, and delay tolerance parameters for policing. The atm-mbs parameter can be specified to define the burst allowed on the SCR bucket. The main difference between VBR.1 and VBR.2/VBR.3 is that the SCR bucket is for CLP0 cells only. The police rates can be expressed as percentages. The child policy can have other set actions and can match on ATM CLP1.

The following example shows how to configure a hierarchical policy for VBR.2:

policy-map child class atm_clp0 police rate scr cellsps atm-mbs mbs cells conform-action action


OL-24694-01


exceed-action action

policy-map VBR2 class class-default police rate pcr cellsps delay-tolerance cdvt us conform-action action exceed-action action service-policy child

Policy Map Configuration to Exclude OAM Cells: ExampleOAM cells can be excluded from being policed by configuring the classification criteria. Since match not is not supported, the different classes must be explicitly configured:.

The following example shows how to configure a policy map to exclude OAM cells:

class-map clp-0-1 match clp 0 match clp 1

policy-map child class atm-oam set class class-default police rate scr cellsps atm-mbs mbs cells conform-action action exceed-action action

policy-map VBR2 class clp-0-1 police rate pcr cellsps delay-tolerance cdvt us conform-action action exceed-action action service-policy child

Policy Map Configuration for Dual Queue Limit: ExampleDual Queue limit configuration is supported on egress L2 ATM interfaces to differentiate between CLP0 and CLP1 cells.

Note For dual queue, only output service policies are supported. Input service policies are not supported.

The following example shows how to configure a policy map for Dual Queue Limit:

policy-map q-limit class class-default queue-limit atm-clp Threshold {[ms|us|cells]} Tail-drop-threshold {[ms|us|cells]}

Verifying ATM Layer 2 QoS Configuration: Examples The following examples show how to display policing results for an ATM interface policy map:

show policy-map interface ATM 0/3/0/0.12 input

ATM 0/3/0/0.12 input: pvc1


OL-24694-01

Modular QoS Deployment Scenarios on Cisco IOS XR SoftwareIP Header Compression QoS

Class class-default Classification statistics (packets/bytes) (rate - kbps) Matched : 0/0 0 Transmitted : 0/0 0 Total Dropped : 0/0 0

show policy-map interface ATM 0/3/0/0.12 output

ATM 0/3/0/0.12 output: pvc1

Class class-default Classification statistics (packets/bytes) (rate - kbps) Matched : 0/0 0 Transmitted : 0/0 0 Total Dropped : 0/0 0

The following examples show how to display the configured QoS properties for an ATM interface policy map:

show qos interface atm 0/3/0/0.12 input

Interface ATM0_3_0_0.12 -- Direction: inputPolicy : pvc1Total number of classes: 1Cell Packing Criteria = CELL_PACK_TIMER_MTU---------------------------------------------------LEVEL1 class: classid = 0x1class name = class-defaultnew exp = 6

show qos interface atm 0/3/0/0.12 output

Interface ATM0_3_0_0.12 -- Direction: outputPolicy : pvc1Total number of classes: 1Cell Packing Criteria = CELL_PACK_TIMER_MTU---------------------------------------------------LEVEL1 class: classid = 0x1class name = class-defaultnew exp = 6

IP Header Compression QoSAn IP Header Compression (IPHC) profile can be enabled on an interface so that the IPHC profile applies only to packets that match a QoS service policy. In this case, the QoS service-policy class attributes determine which packets are compressed. This allows users to fine tune IPHC with greater granularity.

Policy maps are attached to an interface using the service-policy command. IPHC action applies only to output service policies. IPHC is not supported on input service policies. (IPHC is supported in the input direction but there is no use case to configure IPHC in an input policy.)

You can configure IPHC using QoS as follows:

• Create a QoS policy with the compress header ip action.

• Attach the IPHC profile to the interface using the ipv4 iphc profile profile_name mode service-policy command.

• Attach the QoS policy with compress header ip action using the service-policy output command.


OL-24694-01

Modular QoS Deployment Scenarios on Cisco IOS XR SoftwareIP Header Compression QoS

You can also display IPHC statistics using the show policy-map interface command, as shown in the following example:

show policy-map interface Serial0/0/3/0/3:0 output

show policy-map int Serial0/0/3/0/3:0 outputMon May 18 22:06:14.698 UTC Serial0/0/3/0/3:0 output: p1Class class-default Classification statistics (packets/bytes) (rate - kbps) Matched : 0/0 0 Transmitted : 0/0 0 Total Dropped : 0/0 0 Queueing statistics Queue ID : 0 High watermark (Unknown) : 0 Inst-queue-len (packets) : 0 Avg-queue-len (packets) : 0 Taildropped(packets/bytes) : 0/0 Compression Statistics Header ip rtp Sent Total (packets) : 880 Sent Compressed (packets) : 877 Sent full header (packets) : 342 Saved (bytes) : 31570 Sent (bytes) : 24750 Efficiency improvement factor : 2.27

IP Header Compression QoS: ExampleIn this example, IPHC is configured through QoS as an action under the class map using the compress header ip command.

The packets are classified according to the criteria in the class maps. The policy map specifies which behavior to apply to which classes. IPHC is enabled using the compress header ip action for the class. An IPHC profile with a QoS service policy is attached to a serial interface.

class-map match-all voice1 match precedence 2

class-map match-all voice2 match access-group acl_iphc

access-list acl_iphc permit udp any range lower-bound src udp port 5000 upper-bound src udp port15000 any lower-bound udp dst port 5000 upper-bound dst udp port 15000

policy-map iphc_policy class iphc_class_1

compress header ipclass iphc_class_2

compress header ip

interface serial 0/1/0/1:1 ipv4 iphc profile Profile_3 mode service-policy

service-policy output iphc_policy


OL-24694-01

Modular QoS Deployment Scenarios on Cisco IOS XR SoftwareQoS on Multicast VPN

QoS on Multicast VPNThe support for QoS services on a multicast VPN (mVPN) enabled network involves the marking of DSCP or precedence bits on the tunnel IP header. This feature enables MPLS carriers to offer QoS on mVPN services. The mVPN network uses generic routing encapsulation (GRE) tunnels between provider edge (PE) devices. Multicast packets are placed in GRE tunnels for transmission across the MPLS core network.

The ingress interfaces use the set precedence tunnel and set dscp tunnel commands (both conditional and unconditional) within an ingress policy applied to the ingress interface. shows a typical mVPN network. When an IP packet arrives at PE1 on the ingress interface E1, the packet is sent out of the tunnel interface E2 into the core network by encapsulating the IP packet inside a GRE tunnel.

Figure 1 mVPN Network

If the set dscp tunnel command or the set precedence tunnel command is configured on the ingress interface E1, the DSCP or precedence values are set in the GRE tunnel header of the encapsulated packet being sent out of the interface E2. As a result:

• The set dscp command or the set precedence command (conditional or unconditional) marks the DSCP or precedence values within the IP header.

• The set dscp tunnel or the set precedence tunnel command (conditional or unconditional) marks the DSCP or precedence values within the GRE header.

QoS on Multicast VPN: ExampleSupporting QoS in an mVPN-enabled network requires conditional and unconditional marking of the DSCP or precedence bits onto the tunnel header. Unconditional marking marks the DSCP or precedence tunnel as a policy action. Conditional marking marks the DSCP or precedence values on the tunnel header as a policer action (conform, exceed, or violate).

Unconditional Marking

class-map c1match vlan 1-10

policy-map p1class c1

2723

70

CE1 PE1 PE2 CE2

P1 P2

E1E2


OL-24694-01

Modular QoS Deployment Scenarios on Cisco IOS XR SoftwareVPLS QoS

set precedence tunnel 3

Conditional Marking

policy-map p2class c1

police rate percent 50conform action set dscp tunnel af11exceed action set dscp tunnel af12

VPLS QoSTo support QoS on a virtual private LAN service (VPLS)-enabled network, packets are classified based on the following VPLS-specific match criteria:

• Match on vpls-known

• Match on vpls-unknown

• Match on vpls-multicast

Note VPLS-specific classification is performed only in the ingress direction.

Figure 2 illustrates a typical VPLS topology with the following configuration (in PE class c1):

class c1match vpls known

!class c2

match vpls unknown!class c3

match vpls-multicast!policy-map p1

class c1set qos-group2

!class c2

set qos-group3!class c3

set discard-class4!


OL-24694-01

Modular QoS Deployment Scenarios on Cisco IOS XR SoftwareVPLS QoS

Figure 2 VPLS Components

In the VPLS-enabled network:

• If a unicast packet arrives on the ingress interface of the PE router with a known MAC address (which means the destination MAC address of the packet is found in the MAC forwarding table), it matches class c1.

• If a unicast packet arrives on the ingress interface of the PE router with an unknown MAC address (which means the destination MAC address of the packet is not found in the MAC forwarding table), it matches class c2.

• If a VPLS multicast packet arrives on the ingress interface of the PE router, it matches class c3.

The packets that meet the VPLS-specific match criteria receive QoS treatment according to the policy actions defined in the policy.

Note Packets with unknown destination MAC address, multicast packets, and broadcast packets are flooded.

VPLS QoS: ExampleIn this example, the packets that meet the VPLS-specific match criteria receive QoS treatment according to the policy actions defined in the policy. Apply the policy to the VPLS AC interface.

class-map match-any c1 match vpls known end-class-map!

class-map match-any c2 match vpls unknown end-class-map!

class-map match-any c3 match vpls multicast end-class-map!

policy-map p2

IP/MPLS

PEPE

2724

27

Tunnel LSP

PE

TunnelLSP

TunnelLSPRed VSI Red VSI

CE CE

PW

PW PW

Red VSI

AttachmentCircuit

AttachmentCircuit

IP/MPLS

PEPE

2724

27

Tunnel LSP

PE

TunnelLSP

TunnelLSPRed VSI Red VSI

CE CE

PW

PW PW

Red VSI

AttachmentCircuit

AttachmentCircuit


OL-24694-01

Modular QoS Deployment Scenarios on Cisco IOS XR SoftwareRelated Information

class c1 set qos-group 3 set mpls experimental imposition 4 shape average percent 40 !

class c2 bandwidth remaining percent 10 set mpls experimental imposition 5 !

class c3 bandwidth remaining percent 10 set mpls experimental imposition 7 !

class class-default ! end-policy-map!

Related InformationThe information in this module focuses on the QoS implementation of features that are described in other technology guides. The following table indicates the guides where you can find more information about these features.

Table 1 Related Information

Feature Guide

ATM Layer 2 QoS Cisco IOS XR Interface and Hardware Component Configuration Guide for the Cisco XR 12000 Series Router

Cisco IOS XR Interface and Hardware Component Command Reference for the Cisco XR 12000 Series Router

IP Header Compression

Cisco IOS XR Interface and Hardware Component Configuration Guide for the Cisco XR 12000 Series Router

Cisco IOS XR Interface and Hardware Component Command Reference for the Cisco XR 12000 Series Router

QoS on Multicast VPN

Cisco IOS XR Multicast Configuration Guide for the Cisco XR 12000 Series Router

Cisco IOS XR Multicast Command Reference for the Cisco XR 12000 Series Router

VPLS QoS Cisco IOS XR MPLS Configuration Guide for the Cisco XR 12000 Series Router

Cisco IOS XR MPLS Command Reference for the Cisco XR 12000 Series Router


OL-24694-01



OL-24694-01



OL-24694-01

Cisco IOS XR Modular Quality of Service ConfiguOL-24694-01

BC Cisco IOS Bridging and IBM Networking Configuration Guide

D1C Cisco IOS Dial Technologies Configuration Guide:Dial Access

D2C Cisco IOS Dial Technologies Configuration Guide:Large-Scale Dial Applications

FC Cisco IOS Configuration Fundamentals Configuration Guide

IC Cisco IOS Interface Configuration Guide

IPC Cisco IOS IP Routing Configuration Guide

MWC Cisco IOS Mobile Wireless Configuration Guide

P2C Cisco IOS AppleTalk and Novell IPX Configuration Guide

P3C Cisco IOS Apollo Domain, Banyan VINES, DECnet, ISO CLNS, and XNS Configuration Guide

QC Cisco IOS Quality of Service Solutions Configuration Guide

SC Cisco IOS Security Configuration Guide

TC Cisco IOS Terminal Services Configuration Guide

VC Cisco IOS Voice, Video, and Fax Configuration Guide

WC Cisco IOS Wide-Area Networking Configuration Guide

XC Cisco IOS Switching Services Configuration Guide

I N D E X

A

ACL Deny QC-17

ATM CLP bit, matching on QC-46

ATM Layer 2 QoS QC-135

ATM on Layer 2 VPN QC-18

B

bandwidth command QC-80

C

class-based packet marking

configuring QC-26

set qos-group command QC-27

class command QC-122

classification

description QC-12

QoS group QC-14

See class-based packet marking

See IP precedence

set cos command QC-14


summary QC-2

class-map command QC-20

class map submode

match access-group command QC-21

match dscp command QC-21

match precedence command QC-21

match qos-group command QC-21

conform-action command QC-88

congestion avoidance

defined QC-101

description QC-101

summary QC-3

congestion management, summary QC-3

CoS (class of service), defining classes QC-14

D

default traffic class

summary QC-13

tail drop QC-13

differentiated service model, classification QC-14

E

enhanced hierarchical ingress policing

configuring QC-38

exceed-action command QC-83

QC-149ration Guide for the Cisco XR 12000 Series Router

Index

F

fabric quality of service

configuring QC-120

configuring (examples) QC-123

creating a fabric QoS service policy QC-121

overview QC-120

policy-map command QC-122

Frame Relay discard eligibility bit

matching QC-45

setting QC-44

Frame Relay on Layer 2 VPN QC-17

G

granularity

policer QC-78

H

hierarchical ingress policing

configuring QC-36

example QC-61

I

in-place policy modification

(examples) QC-62

description QC-18

interfaces

Link Bundling QC-127

interface submode

service-policy command QC-25

IP DSCP (differentiated services code point) value, when to use QC-16

IP header compression QC-141

IP precedence

default QC-15

edge router function QC-14

QC-150Cisco IOS XR Modular Quality of Service Configuration Guide for

low-latency queueing (LLQ) QC-13

overview QC-14

packet classification QC-15

QoS features supported QC-15

reset recommendation QC-15

ToS field QC-14

values (table) QC-15

when to use QC-16

WRED QC-13

L

LLQ (low-latency queueing)

See queueing

M

marking combinations

conditional and unconditional on ingress QC-74

conform and exceed actions QC-74

match access-group command QC-21

match cos command QC-21

match dscp command QC-21

match precedence command QC-21

match qos-group command QC-21

match vlan command QC-21

MDRR (Modified Deficit Round Robin), defined QC-70

MDRR (modified deficit round robin), description QC-70

MQC (modular QoS command-line interface), description QC-4

Multicast VPN QC-143

multiple action set

(examples) QC-95

description QC-74

P

partitioning network, QoS packet marking QC-13

police command QC-88

the Cisco XR 12000 Series RouterOL-24694-01

Index

policer granularity QC-78

policers and shapers, description QC-69

policy map class submode

bandwidth command QC-80

police command QC-88

set cos command QC-27, QC-28

set discard-class command QC-28

set dscp command QC-27

set precedence command QC-27


set srp-priority command QC-27

shape average command QC-110

policy map police submode

conform-action command QC-88


policy map submode

class command QC-122

Q

QoS (Quality of Service)

benefits QC-2

characteristics QC-1

congestion mechanisms, policers and shapers QC-69

features

class-based packet marking QC-13

traffic policing QC-3

traffic shaping QC-3

techniques

classification QC-12

congestion avoidance QC-3

congestion management QC-3

packet classification QC-2

queueing

low-latency queuing (LLQ) QC-70

quantum size QC-70

scheduling mechanism QC-70

strict priority QC-70

Cisco IOS XR Modular Quality of ServicOL-24694-01

R

RFC 791, Internet Protocol QC-15

S

service models, end-to-end, differentiated service QC-4

service-policy command QC-25

service-policy command, attaching traffic policies QC-24

set cos command QC-27, QC-28

set discard-class command QC-28

set dscp command QC-27

set precedence command QC-27


set srp-priority command QC-27


show policy-map interface command QC-25

T

traffic class

class-map command QC-12

creating QC-20

major elements QC-12

match commands QC-12

traffic policer

committed information rate (CIR) QC-74

peak information rate (PIR) QC-74

purpose QC-75

single-rate, two color policer QC-74

traffic policers and traffic shapers, use of traffic descriptor QC-12

traffic policing

description QC-73


packet marking QC-75

single-rate token bucket QC-77

summary QC-3

traffic policy

QC-151e Configuration Guide for the Cisco XR 12000 Series Router

Index

attaching to an interface QC-24

class command QC-12

creating QC-22

elements QC-12

maximum number of traffic classes QC-13

policy-map command QC-12

purpose QC-12

traffic shaping

description QC-71

enabled QC-71


token bucket QC-73

traffic policing, contrasted with QC-78

V

VPLS QoS QC-144

W

WRED (weighted random early detection)

average queue size QC-103

IP Precedence QC-102

overview QC-102

TCP QC-103

uses QC-102

QC-152Cisco IOS XR Modular Quality of Service Configuration Guide for
the Cisco XR 12000 Series Router
OL-24694-01