Cisco IOS XR Modular Quality of Service Configuration Guide for the Cisco CRS-1 Router
Configuring Modular QoS Packet Classification
Downloads: This chapterpdf (PDF - 891.0KB) The complete bookPDF (PDF - 3.31MB) | Feedback

Configuring Modular Quality of Service Packet Classification on Cisco IOS XR Software

Table Of Contents

Configuring Modular Quality of Service Packet Classification on Cisco IOS XR Software

Contents

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

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

Packet Classification Overview

Traffic Class Elements

Traffic Policy Elements

Default Traffic Class

Class-based Unconditional Packet Marking Feature and Benefits

Unconditional Multiple Action Set

Specification of the CoS for a Packet with IP Precedence

IP Precedence Bits Used to Classify Packets

IP Precedence Value Settings

IP Precedence Compared to IP DSCP Marking

QoS Policy Propagation Using Border Gateway Protocol

In-Place Policy Modification

Bidirectional Forwarding Detection Echo Packet Prioritization

QoS Services on Multicast VPN

VPLS QoS

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

Creating a Traffic Class

Restrictions

Creating a Traffic Policy

Restrictions

Attaching a Traffic Policy to an Interface

Prerequisites

Restrictions

Configuring Class-based Unconditional Packet Marking

Configuring QoS Policy Propagation Using Border Gateway Protocol

Policy Propagation Using BGP Configuration Task List

Overview of Tasks

Defining the Route Policy

Prerequisites

Restrictions

Applying the Route Policy to BGP

Prerequisites

Configuring QPPB on the Desired Interfaces

Configuring Hierarchical Ingress Policing

Restrictions

Configuring QoS Services on mVPN

Configuring Conditional Markings on the Tunnel Header

Restrictions

Configuring Unconditional Markings on the Tunnel Header

Restrictions

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

Traffic Classes Defined: Example

Traffic Policy Created: Example

Traffic Policy Attached to an Interface: Example

Default Traffic Class Configuration: Example

class-map match-any Command Configuration: Example

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

Two-Level Hierarchical Traffic Policy Configuration: Example

Class-based, Unconditional Packet Marking Examples

IP Precedence Marking Configuration: Example

IP DSCP Marking Configuration: Example

QoS Group Marking Configuration: Example

Discard Class Marking Configuration: Example

CoS Marking Configuration: Example

MPLS Experimental Bit Imposition Marking Configuration: Example

MPLS Experimental Topmost Marking Configuration: Example

Route Policy Configuration: Example

BGP Community Sample Configuration

Autonomous System Path Sample Configuration

QPPB Source Prefix Configuration: Example

QPPB Destination Prefix Configuration: Example

Hierarchical Ingress Policing: Example

In-Place Policy Modification: Example

QoS Services on mVPN: Example

Unconditional Marking: Example

Conditional Marking: Example

VPLS QoS: Example

Where to Go Next

Additional References

Related Documents

Standards

MIBs

RFCs

Technical Assistance


Configuring Modular Quality of 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 on Cisco IOS XR software.


Note For additional conceptual information about QoS in general and complete descriptions of the QoS commands listed in this module, see the "Related Documents" section of this module. To locate documentation for other commands that might appear in the course of executing a configuration task, search online in the Cisco IOS XR software master command index. F


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

Release
Modification

Release 2.0

This feature was introduced on the Cisco CRS-1.

Release 3.0

No modification.

Release 3.2

IPv6 addressing was supported for the match dscp and match precedence commands.

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 not keyword was added to all match commands, except the match access-group command.

Release 3.4.0

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

Release 3.5.0

No modification.

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.

Policy Propagation using BGP (QPPB) was supported.

The maximum number of classes permitted for each policy map was increased from 32 to 512.

The match not vlan command was not supported.

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

Release 3.7.0

No modification.

Release 3.8.0

The In-Place Policy Modification feature was supported.

Support for QoS services on multicast VPN was introduced.

Support for VPLS QoS was introduced.

The Unconditional Multiple Action Set feature was supported.

Release 3.9.0

Added support for match precendence tunnel and match dscp tunnel for some Layer 2 ingress interfaces (CSCsv50430).


Contents

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

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

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

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

Where to Go Next,

Additional References

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

Traffic Class Elements

Traffic Policy Elements

Default Traffic Class

Class-based Unconditional Packet Marking Feature and Benefits

Specification of the CoS for a Packet with IP Precedence

IP Precedence Compared to IP DSCP Marking

QoS Policy Propagation Using Border Gateway Protocol

QoS Policy Propagation Using Border Gateway Protocol

In-Place Policy Modification

Bidirectional Forwarding Detection Echo Packet Prioritization

VPLS QoS

Packet Classification Overview

Packet 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.

Methods of classification may consist of the logical combination of any fields in the packet header, where a packet header may be a Layer 2, a Layer 3, or a Layer 4 header; or classification based on the incoming or outgoing physical or virtual interface.

Traffic Class Elements

The 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.


Note The class-map command supports the match-any keyword only. The match-all keyword is not supported.


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.

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. The match-any keyword is the only evaluation option supported.

Table 1 lists the traffic class match criteria supported on the Cisco CRS-1 router.


Note Unless otherwise indicated, the match criteria for Layer 3 physical interfaces applies to bundle interfaces.


Table 1 Cisco CRS-1 Traffic Class Match Criteria

match criteria 1   2
Layer 2 Ingress
Layer 2 Egress
Layer 3 Ingress
Layer 3 Egress
 
PAC 3
CAC 4
p-C 5
PAC
CAC
p-C
Phy 6
SIf 7
P-SIf 8
Phy
SIf
P-SIf

prec

N

N

N

N

N

N

Y

Y

Y

Y

Y

Y

dscp

N

N

N

N

N

N

Y

Y

Y

Y

Y

Y

vlan

Y

N

Y

Y

N

Y

Y

N

Y

Y

N

Y

CoS

Y

Y

Y

Y

Y

Y

Y9

Y9

Y9

N

N

N

QoS Group

N

N

N

Y

Y

Y

Y

Y

Y

Y

Y

Y

Discard-class

N

N

N

Y

Y

Y

N

N

N

Y

Y

Y

EXP

N

N

N

N

N

N

Y

Y

Y

Y

Y

Y

Protocol

N

N

N

N

N

N

Y

Y

Y

Y

Y

Y

access-group

N

N

N

N

N

N

Y

Y

Y

Y

Y

Y

mac, src

Y

Y

Y

N

N

N

N

N

Y

N

N

N

mac, dst

N

N

N

Y

Y

Y

N

N

N

N

N

Y

SRP Priority

N

N

N

N

N

N

Y9

Y9

Y9

N

N

N

vpls known

Y10

Y10

Y10

N

N

N

N

N

Y

N

N

Y

vpls unknown

Y10

Y10

Y10

N

N

N

N

N

Y

N

N

Y

vpls multicast

Y10

Y10

Y10

N

N

N

N

N

Y

N

N

Y

1 NOTE: match qos-group is supported on ingress (Layer 3) for QPPB only.

2 NOTE: match not is not supported with vlan, access-group, src-mac, or dst-mac matches.

3 Port attachment circuit.

4 Customer attachment circuit.

5 Physical interface with underlying CACs.

6 Physical interface.

7 Subinterface.

8 Physical interface with underlying subinterfaces.

9 Not supported on bundle interfaces.

10 Not supported on ATM interfaces.


The function of these commands is described more thoroughly in the Cisco IOS XR Modular Quality of Service Command Reference for the Cisco CRS-1 Router.

The traffic class configuration task is described in the Creating a Traffic Class.

Traffic Policy Elements

The 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 512 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.

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 Reference for the Cisco CRS-1 Router.

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

Default Traffic Class

Unclassified 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 Benefits

The 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 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.

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.

Table 2 shows the supported class-based unconditional packet marking operations.


Note Unless otherwise indicated, the class-based unconditional packet marking for Layer 3 physical interfaces applies to bundle interfaces.


Table 2 CRS-1 Class-based Unconditional Packet Marking Operations

marking operation
Layer 2 Ingress
Layer 2 Egress
Layer 3 Ingress
Layer 3 Egress
 
PAC 1
CAC 2
p-C 3
PAC
CAC
p-C
Phy 4
SIf 5
P-SIf 6
Phy
SIf
P-Sif

prec

N

N

N

N

N

N

Y

Y

Y

Y

Y

Y

prec tunnel

Y7

Y7

Y7

N

N

N

Y

Y

Y

N

N

N

dscp

N

N

N

N

N

N

Y

Y

Y

Y

Y

Y

dscp tunnel

Y7

Y7

Y7

N

N

N

Y

Y

Y

N

N

N

CoS

N

N

N

Y

Y

Y

N

N

N

Y

Y

Y

srp-priority

N

N

N

Y

Y

Y

N

N

N

Y

Y

Y

qos-group

Y

Y

Y

N

N

N

Y

Y

Y

N

N

N

Discard-class

Y

Y

Y

N

N

N

Y

Y

Y

N

N

N

EXP, imposition

Y

Y

Y

N

N

N

Y

Y

Y

N

N

N

EXP, topmost

N

N

N

N

N

N

Y

Y

Y

Y

Y

Y

1 Port attachment circuit.

2 Customer attachment circuit.

3 Physical interface with underlying CACs.

4 Physical interface.

5 Subinterface.

6 Physical interface with underlying subinterfaces.

7 Not supported on ATM interfaces.


Unconditional Multiple Action Set

The Unconditional Multiple Action Set feature allows you to mark packets with unconditional multiple action sets through a class map. The following unconditional markings are supported.

Unconditional Ingress Markings

Both the discard-class and qos-group packets are marked independent of other markings. In addition to the discard-class and qos-group, at the maximum, two set actions are supported in each of the data paths (IP, MPLS, and Layer 2).

In a hierarchical policy, markings for a parent and markings for a child cannot exceed more than two actions, which is different from the discard-class and qos-group packets.

If the same type of marking is configured in both parent and child, it is considered as a single marking as child marking overrides the parent marking.

Table 3 lists the unconditional QoS ingress markings that are supported for IP, MPLS, or Layer 2 data paths.


Note Unless otherwise indicated, the unconditional QoS ingress marking for Layer 3 physical interfaces applies to bundle interfaces.


Table 3 Unconditional QoS Ingress Markings 

Common Packets for IP, MPLS, or Layer 2
Layer 3 IP Packets
Layer 3 MPLS Packets
Layer 2 Packets

discard-class

DSCP or precedence1

MPLS experimental imposition

MPLS experimental imposition

qos-group

tunnel DSCP or tunnel precedence2

MPLS experimental topmost

tunnel DSCP or tunnel precedence3

MPLS experimental imposition

1 Both DSCP and precedence packets are mutually exclusive.

2 Both tunnel DSCP and tunnel precedence packets are mutually exclusive.

3 Not supported on ATM interfaces.


Unconditional Egress Markings

Both cos and srp-priority packets are marked as independent from other markings. In addition to the cos and srp-priority packets, one more set action is supported in the IP and MPLS data paths. In a hierarchical policy, markings for a parent and markings for a child cannot exceed more than one, which is different from the cos and srp-priority packets.

If the same type of marking is used for both a parent and child, the marking type is considered as a single marking as the marking at child level overrides the marking at parent level.

Table 4 lists the unconditional QoS egress markings that are supported for IP, MPLS, or Layer 2 data paths.


Note Unless otherwise indicated, the unconditional QoS egress marking for Layer 3 physical interfaces applies to bundle interfaces.


Table 4 Unconditional QoS Egress Markings 

Common Packets for IP, MPLS, or Layer 2
Layer 3 IP Packets
Layer 3 MPLS Packets

cos or srp-priority1

DSCP or precedence2

MPLS experimental topmost

1 Both cos and srp-priority packets are mutually exclusive

2 Both DSCP and precedence packets are mutually exclusive.



Note For a list of supported conditional marking operations, see Table 3 in the Configuring Modular Quality of Service Congestion Management on Cisco IOS XR Software module.


Specification of the CoS for a Packet with IP Precedence

Use 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.

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 5 lists the numbers and their corresponding names, from least to most important.

Table 5 IP Precedence Values 

Number
Name

0

routine

1

priority

2

immediate

3

flash

4

flash-override

5

critical

6

internet

7

network


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:

Policy-based Routing. See Configuring Class-based Unconditional Packet Marking.

QoS Policy Propagation Using Border Gateway Protocol (QPPB). See QoS Policy Propagation Using Border Gateway Protocol.

IP Precedence Compared to IP DSCP Marking

IP 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 classify packets by Qos Group ID, based on access lists (ACLs), Border Gateway Protocol (BGP) community lists, and 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.

In-Place Policy Modification

The 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.

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.

Bidirectional Forwarding Detection Echo Packet Prioritization

If no QoS policy is attached to the interface on which BFD echo packets are received and switched back, then the BFD echo packets are marked as vital packets (when received) and are sent to the high priority queue in the ingressq ASIC reserved for transit control traffic.

If ingress QOS policy is present on the interface on which BFD echo packets are received and switched back, then the BFD echo packets are marked as vital packets (when received) and all QOS actions of the matching class except for taildrop and WRED are performed on the packets. The packets are then sent to the high priority queue in the ingressq ASIC reserved for transit control traffic, overriding the queue selected by the ingress QOS policy.

In the egress direction, the BFD echo packets are treated like other vital packets (locally originated control packets) and are sent to the high priority queue of the interface in the egressq ASIC.

QoS Services on Multicast VPN

The support for QoS services on a multicast VPN (mVPN) enabled network involves the marking of differentiated services code point (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.

For more information on configuring multicast QoS, refer to Cisco IOS XR Multicast Configuration Guide for the Cisco CRS-1 Router.

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. In a typical mVPN network, as shown in , 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 2

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. Hence,

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.

VPLS QoS

To 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.


VPLS Components illustrates a typical VPLS topology with the following configuration (in which policy p1 is applied on the n-PE router in the ingress direction):

class c1
match vpls-known
!
class c2
match vpls unknown
!
class c3
match vpls-multicast
!
policy-map p1
class c1
set qos-group2
!
class c2
set qos-group3
!
class c3
set discard-class4
!
!

Figure 3

VPLS Components

In the VPLS-enabled network:

If a unicast packet arrives on the ingress interface of the n-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 n-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 n-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.


For more information about configuring and implementing VPLS, see the Implementing Virtual Private LAN Services on Cisco IOS XR Software module of the Cisco IOS XR MPLS Configuration Guide for the Cisco CRS-1 Router. To see an example of the VPLS QoS configuration, see VPLS QoS: Example.

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

This section contains instructions for the following tasks:

Creating a Traffic Class (required)

Creating a Traffic Policy (required)

Attaching a Traffic Policy to an Interface (required)

Configuring Class-based Unconditional Packet Marking (required)

Configuring QoS Policy Propagation Using Border Gateway Protocol (optional)

Configuring Hierarchical Ingress Policing (optional)

Configuring QoS Services on mVPN (optional)

Creating a Traffic Class

To 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.

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 [not] cos [cos-value] [cos-value1 ... cos-value7]

5. match destination-address mac destination-mac-address

6. match [not] discard-class discard-class-value [discard-class-value1 ... discard-class-value6]

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

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

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

10. match [not] protocol {number | name}

11. match [not] qos-group [qos-group-value1 ... qos-group-value7]

12. match source-address mac source-mac-address

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

14. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

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

Example:

RP/0/RP0/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.

Step 3 

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

Example:

RP/0/RP0/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 [not] cos cos-value [cos-value1 ... cos-value7]

Example:

RP/0/RP0/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 destination-address destination-mac-address

Example:

RP/0/RP0/CPU0:router(config-cmap)#match destination-address mac 00.00.00

(Optional) Configures the match criteria for a class map based on the specified destination MAC address.

Step 6 

match [not] discard-class discard-class-value [discard-class-value1 ... discard-class-value6]

Example:

RP/0/RP0/CPU0:router(config-cmap)# match discard-class 5

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

The discard-class-value argument is specified as an integer from 1 to 7.

The match discard-class command is supported only on an egress policy.

Step 7 

match [not] dscp [ipv4 | ipv6] dscp-value [dscp-value ... dscp-value]

Example:

RP/0/RP0/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.

Upto 8 values/range can be added per match statement. The router supports up to a maximum of 63 such values/range.

Step 8 

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

Example:

RP/0/RP0/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 9 

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

Example:

RP/0/RP0/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 10 

match [not] protocol {number | name}

Example:

RP/0/RP0/CPU0:router(config-cmap)# match protocol igmp

(Optional) Configures the match criteria for a class map on the basis of the specified protocol.

Step 11 

match [not] qos-group [qos-group-value1 ... qos-group-value8]

Example:

RP/0/RP0/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 12 

match source-address mac source-mac-address

Example:

RP/0/RP0/CPU0:router(config-cmap)#match source-address mac 00.00.00

(Optional) Configures the match criteria for a class map based on the specified source MAC address.

Step 13 

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

Example:

RP/0/RP0/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.

Step 14 

end

or

commit

Example:

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

or

RP/0/RP0/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.

Creating a Traffic Policy

To 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 on the Cisco CRS-1 Router :

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.

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

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

For conceptual information, see Traffic Policy Elements.

Restrictions

A maximum of 512 classes (including Level 1 and Level 2 hierarchical classes as well as implicit default classes) can be applied to one policy map.

For a hierarchical policy (with Level 1 and Level 2 hierarchical classes) applied on a subinterface, the only allowed Level 1 class in the policy is the class-default class.

SUMMARY STEPS

1. configure

2. policy-map policy-name

3. class class-name

4. set precedence [tunnel] precedence-value

5. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

policy-map policy-name

Example:

RP/0/RP0/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/RP0/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/RP0/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 any Layer 3 interface in the ingress direction.

Step 5 

end

or

commit

Example:

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

or

RP/0/RP0/CPU0:router(config-pmap-c)# 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.

Attaching a Traffic Policy to an Interface

After 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 CRS-1 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. end
or
commit

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

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

interface type interface-path-id

Example:

RP/0/RP0/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/RP0/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

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.

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.

Configuring Class-based Unconditional Packet Marking

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

CoS value (egress only)

MPLS experimental value

SRP priority (egress only)

Discard class (ingress only)

For a list of supported unconditional marking criteria action, see Table 2.


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

2. policy-map policy-name

3. class class-name

Choose one set command per class

4. set precedence number

5. set dscp dscp-value

6. set qos-group qos-group-value

7. set cos cos-value

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

9. set srp-priority priority-value

10. set discard-class discard-class-value

11. exit

12. exit

13. interface type interface-path-id

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

15. end
or
commit

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


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


DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

policy-map policy-name

Example:

RP/0/RP0/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/RP0/CPU0:router(config-pmap)# class class1

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 number

Example:

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

Sets the precedence value in the IP header.

Step 5 

set dscp dscp-value

Example:

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

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

Step 6 

set qos-group qos-group-value

Example:

RP/0/RP0/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 cos cos-value

Example:

RP/0/RP0/CPU0:router(config-pmap-c)# set cos 7

Sets the specific IEEE 802.1Q Layer 2 CoS value of an outgoing packet. Values are from 0 to7.

Sets the Layer 2 CoS value of an outgoing packet.

This command should be used by a router if a user wants to mark a packet that is being sent to a switch. Switches can leverage Layer 2 header information, including a CoS value marking.

The set cos command is supported only on Layer 2 ingress or egress policies. Packets entering an interface cannot be set with a CoS value.

Step 8 

set mpls experimental {imposition | topmost} exp-value

Example:

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

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

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

Step 9 

set srp-priority priority-value

Example:

RP/0/RP0/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.

Step 10 

set discard-class discard-class-value

Example:

RP/0/RP0/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 11 

exit

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

Returns the router to policy map configuration mode.

Step 12 

exit

Example:

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

Returns the router to global configuration mode.

Step 13 

interface type interface-path-id

Example:

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

Enters interface configuration mode and configures an interface.

Step 14 

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

Example:

RP/0/RP0/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 15 

end

or

commit

Example:

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

or

RP/0/RP0/CPU0:router(config-if)# 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.

Step 16 

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

Example:

RP/0/RP0/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.

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 CRS-1 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 for examples of route policy configuration.

Prerequisites

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

Restrictions

The Cisco CRS-1 Router only supports the setting of the QoS group ID using QPPB.

SUMMARY STEPS

1. configure

2. route-policy name

3. set qos-group qos-group-value

4. end-policy

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

route-policy name

Example:

RP/0/RP0/CPU0:router(config)# route-policy

costA

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/RP0/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/RP0/CPU0:router(config)# end-policy

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

Applying the Route Policy to BGP

This task applies the route policy to BGP.

Prerequisites

Configure BGP and Cisco Express Forwarding on the Cisco CRS-1 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

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

router bgp as-number

Example:

RP/0/RP0/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/RP0/CPU0:router(config-bgp)#

address-family ipv4 unicast

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

Step 4 

table-policy policy-name

Example:

RP/0/RP0/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

Example:

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

or

RP/0/RP0/CPU0:router(config-if)# 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.

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

2. interface type interface-path-id

3. ipv4 bgp policy propagation input qos-group destination

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

interface type instance

Example:

RP/0/RP0/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 qos-group [destination | source]

Enables QPPB on an interface

Configuring Hierarchical Ingress Policing

The 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

2. policy-map policy-name

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

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

policy-map policy-name

Example:

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

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/RP0/CPU0:router(config-pmap)# class class-default

Enters policy map class configuration mode.

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

Step 4 

service-policy policy-name

Example:

RP/0/RP0/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/RP0/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/RP0/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/RP0/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/RP0/CPU0:router(config-pmap-c-police)# end

or

RP/0/RP0/CPU0:router(config-pmap-c-police)# 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.

Configuring QoS Services on mVPN

Supporting QoS in an mVPN-enabled network requires conditional and unconditional marking of the DSCP or precedence bits onto the tunnel header. For more information on configuring multicast QoS, refer to Cisco IOS XR Multicast Configuration Guide for the Cisco CRS-1 Router.

Configuring Conditional Markings on the Tunnel Header

Conditional marking marks the DSCP or precedence values on the tunnel header as a policer action (conform, exceed, or violate).

Restrictions

Conditional marking is supported in the ingress direction only.

SUMMARY STEPS

1. configure

2. class-map class-name

3. match precedence precedence-value

4. exit

5. policy-map policy-name

6. class class-name

7. police rate percent percentage

8. conform-action action

9. exceed-action action

10. exit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

class-map class-name

Example:

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

Enters class map configuration mode.

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

Step 3 

match precedence precedence-value

Example:

RP/0/RP0/CPU0:router(config-cmap)# match precedence 1

Identifies IP precedence values as match criteria.

Step 4 

exit

Example:

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

Returns the router to global configuration mode.

Step 5 

policy-map policy-name

Example:

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

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 6 

class class-name

Example:

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

Enters policy map class configuration mode.

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

Step 7 

police rate percent percentage

Example:

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

Configures traffic policing and enters policy map police configuration mode.

Step 8 

conform-action action

Example:

RP/0/RP0/CPU0:router(config-pmap-c-police)# conform-action set precedence tunnel 3

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

Step 9 

exceed-action action

Example:

RP/0/RP0/CPU0:router(config-pmap-c-police)# exceed-action set precedence tunnel 4

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

Step 10 

exit

Example:

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

Returns the router to policy map class configuration mode.

Configuring Unconditional Markings on the Tunnel Header

Unconditional marking marks the DSCP or precedence tunnel as a policy action.

Restrictions

Unconditional marking is supported in the ingress direction only.

SUMMARY STEPS

1. configure

2. class-map class-name

3. match precedence precedence-value

4. exit

5. policy-map policy-name

6. class class-name

7. set precedence tunnel precedence-value

8. exit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

class-map class-name

Example:

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

Enters class map configuration mode.

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

Step 3 

match precedence precedence-value

Example:

RP/0/RP0/CPU0:router(config-cmap)# match precedence 1

Identifies IP precedence values as match criteria.

Step 4 

exit

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

Returns the router to global configuration mode.

Step 5 

policy-map policy-name

Example:

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

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 6 

class class-name

Example:

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

Enters policy map class configuration mode.

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

Step 7 

set precedence tunnel precedence value

Example:

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

Sets or marks the IP precedence value in the tunnel header of a tunneled packet.

Step 8 

exit

Example:

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

Returns the router to policy map configuration mode.

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

This section contains the following examples:

Traffic Classes Defined: Example

Traffic Policy Created: Example

Traffic Policy Attached to an Interface: Example

Default Traffic Class Configuration: Example

class-map match-any Command Configuration: Example

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

Class-based, Unconditional Packet Marking Examples

Route Policy Configuration: Example

Hierarchical Ingress Policing: Example

QoS Services on mVPN: Example

In-Place Policy Modification: Example

VPLS QoS: Example

Traffic Classes Defined: Example

In 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 class1
  match access-group ipv4 101
  exit
!
class-map class2
  match access-group ipv4 102
  exit
 
   

Use the not keyword with the match command to perform a match based on the values of a field that are not specified. The following example includes all packets in the class qos_example with a DSCP value other than 4, 8, or 10.

class-map match-any qos_example
  match not dscp 4 8 10
!
end
 
   

Traffic Policy Created: Example

In 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 (see the Traffic Classes Defined: Example).

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

policy-map policy1
  class class1
    bandwidth 3000
    queue-limit bytes 1000000000
    exit
!
  class class2
    bandwidth 2000
    exit

Traffic Policy Attached to an Interface: Example

The following example shows how to attach an existing traffic policy to an interface (see the Traffic Classes Defined: Example). 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/0
  service-policy output policy1 
  exit
!
interface TenGigE 0/5/0/1
  service-policy output policy1
  exit

Default Traffic Class Configuration: Example

The 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 policy1
  class class-default
    shape average percent 60

class-map match-any Command Configuration: Example

The 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 class1
  match protocol ipv4
  match qos-group 4
  match 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 child
  class mpls
    priority
!
policy-map parent
  class class-default
    shape average 10000000
    service-policy child
 
   

Class-based, Unconditional Packet Marking Examples

The following are typical class-based, unconditional packet marking examples:

IP Precedence Marking Configuration: Example

IP DSCP Marking Configuration: Example

QoS Group Marking Configuration: Example

Discard Class Marking Configuration: Example

CoS Marking Configuration: Example

MPLS Experimental Bit Imposition Marking Configuration: Example

MPLS Experimental Topmost Marking Configuration: Example

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 classification policy 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:

policy-map policy1
  class class1
    set precedence 1
!
interface pos 0/1/0/0
  service-policy output policy1

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 classification policy through the use of the class command. In this example, it is assumed that a classification policy called class1 was previously configured.

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

policy-map policy1
  class class1
    set dscp 5
 
   
  class class2
    set 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 voice
  match dscp ef
policy qos-policy
  class voice
    priority
 
   

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 classification policy 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 class1
  match protocol ipv4
  match access-group ipv4 101
 
   
policy-map policy1
  class class1
    set qos-group 1
  !
interface gigabitethernet 0/1/0/9
  service-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 classification policy 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.

class-map match-any class1
  match protocol ipv4
  match access-group ipv4 101
 
   
policy-map policy1
  class class1
    set discard-class 1
  !
interface pos 0/1/0/0
  service-policy input policy1
 
   

Note The unconditional set discard-class command is supported only on a Cisco CRS-1 ingress policy.


CoS Marking Configuration: Example

In the following example, a service policy called policy1 is created. This service policy is associated to a classification policy 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.

class-map match-any class1
  match protocol ipv4
  match access-group ipv4 101
 
   
policy-map policy1
  class class1f
    set cos 1
  !
interface TenGigE0/1/0/0
  service-policy output policy1
 
   

Note The set cos command is supported only on an egress policy.


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 classification policy 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.

class-map match-any class1
  match protocol ipv4
  match access-group ipv4 101
 
   
policy-map policy1
  class class1
    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 classification policy 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 class1
  match mpls exp topmost 2
 
   
policy-map policy1
  class class1
    set mpls exp topmost 1
  !
interface TenGigE0/1/0/0
  service-policy output policy1

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
  pass
end-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
 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
  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
  endif
end-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
  !
 !
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
  pass
end-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
  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
  pass
end-policy
!
 
   
router bgp 100
 bgp router-id 10.10.10.10
 address-family ipv4 unicast
  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 
 !
 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
!

Hierarchical Ingress Policing: Example

The following configuration is an example of typical hierarchical ingress policing:

policy-map parent
          class class-default
	service-policy child
	police rate percent 50 
   	    conform-action transmit
   	    exceed-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:0
     encapsulation frame-relay
     service-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 customera
          match vlan 1-3
class-map match-any customerb
          match vlan 4-7
policy-map parent
          class customera
	service-policy childa
	police rate percent 50 
   	    conform-action transmit
   	    exceed-action drop
	!
           class customerb
	service-policy childb
	police rate percent 70 
   	    conform-action transmit
   	    exceed-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.

In-Place Policy Modification: Example

The following configuration is an example of in-place policy modification:

Defining a policy map:

configure
policy-map policy1
class class1
set precedence 3
commit

Attaching the policy map to an interface:

configure
interface POS 0/6/0/1
service-policy output policy1
commit

Modifying the precedence value of the policy map:

configure
policy-map policy1
class class1
set precedence 5
commit


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.


QoS Services on mVPN: Example

The following configuration is an example of the QoS Service on mVPN:

Unconditional Marking: Example

class-map c1
match vlan 1-10
policy-map p1
class c1
set precedence tunnel 3

Conditional Marking: Example

policy-map p2
class c1
police rate percent <>
conform action set dscp tunnel af11
exceed action set dscp tunnel af12

VPLS QoS: Example

The following example shows how to configure VPLS QoS:

class-map match-any c1
 match vpls known 
 end-class-map
!
 
   
class-map match-any c2
 match vpls unknown 
 end-class-map
!
 
   
policy-map p2
 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 class-default
 !
 end-policy-map
!

Where to Go Next

To configure class-based traffic shaping, traffic policing, and low-latency queueing, see the Configuring Modular QoS Congestion Avoidance on Cisco IOS XR Software module.

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

Additional References

The following sections provide references related to implementing QoS service packet classification on Cisco IOS XR software.

Related Documents

Related Topic
Document Title

Cisco IOS XR QoS commands: complete command syntax, command modes, command history, defaults, usage guidelines, and examples

Cisco IOS XR Modular Quality of Service Command Reference for the Cisco CRS-1 Router

Traffic shaping, traffic policing, low-latency queueing, and MDDR

Configuring QoS Congestion Management on Cisco IOS XR Software

WRED, RED, and tail drop

Configuring QoS Congestion Avoidance on Cisco IOS XR Software

Cisco IOS XR getting started material

Cisco IOS XR Getting Started Guide

Information about user groups and task IDs

Configuring AAA Services on Cisco IOS XR Software module of the Cisco IOS XR System Security Configuration Guide for the Cisco CRS-1 Router

Cisco IOS XR QoS overview information

Modular Quality of Service Overview on Cisco IOS XR Software


Standards

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

RFCs
Title

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


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