Feedback
Table Of Contents
Configuring Modular Quality of Service Packet Classification on Cisco IOS XR Software
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
Class-based Unconditional Packet Marking Feature and Benefits
Specification of the CoS for a Packet with IP Precedence
IP Precedence Bits Used to Classify Packets
IP Precedence Compared to IP DSCP Marking
QoS Policy Propagation Using Border Gateway Protocol
Hierarchical Policing for Frame Relay on Layer 2 VPN
Hierarchical Policing for ATM on Layer 2 VPN
Enhanced Hierarchical Ingress Policing
Three-Level Hierarchical Policy Maps
How to Configure Modular QoS Packet Classification on Cisco IOS XR Software
Attaching a Traffic Policy to an Interface
Configuring Class-based Unconditional Packet Marking
Configuring QoS Policy Propagation Using Border Gateway Protocol
Policy Propagation Using BGP Configuration Task List
Applying the Route Policy to BGP
Configuring QPPB on the Desired Interfaces
Configuring Hierarchical Ingress Policing
Configuring Enhanced Hierarchical Ingress Policing
Configuring a Three-Level Hierarchical Policy
Configuring Policer Granularity
Configuring QoS Services on Multicast VPN
Configuring Conditional Markings on the Tunnel Header
Configuring Unconditional Markings on the Tunnel Header
Setting the Frame Relay Discard Eligibility Bit
Matching the Frame Relay DE Bit
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
Three-Level Hierarchical Traffic Policy Configuration: Example
Class-based, Unconditional Packet Marking Examples
IP Precedence Marking Configuration: Example
IP Precedence Tunnel 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
ACL Deny Configuration: Example
Hierarchical Ingress Policing: Example
Enhanced Hierarchical Ingress Policing: Example
In-Place Policy Modification: Example
QoS Services on Multicast VPN: Example
Unconditional Marking: Example
Setting the Frame Relay Discard Eligibility Bit: Example
Matching the Frame Relay DE Bit: Example
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.
Feature History for Configuring Modular QoS Packet Classification on Cisco IOS XR Software
Contents
•
•
•
•
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:
•
•
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
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.
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.
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. If the match-all option is specified, the traffic must match all of the match criteria.
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 1000 traffic classes can be associated to a single traffic policy. The 512 class maps include the default class and the classes of the child policies, if any.
The order in which classes are configured in a policy map is important. The match rules of the classes are programmed into the TCAM in the order in which the classes are specified in a policy map. Therefore, if a packet can possibly match multiple classes, only the first matching class is returned and the corresponding policy is applied.
The function of these commands is described more thoroughly in the Cisco IOS XR Modular Quality of Service Command Referencefor the Cisco XR 12000 Series Router.
The traffic policy configuration task is described in Creating a Traffic Policy.
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:
•
•
•
•
•
Unconditional packet marking allows you to partition your network into multiple priority levels or classes of service, as follows:
•
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.
•
•
The configuration task is described in the Configuring Class-based Unconditional Packet Marking.
Note
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 1 lists the numbers and their corresponding names, from least to most important.
Table 1 IP Precedence Values
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 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:
•
•
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 remark packets by IP precedence and QoS Group ID, based on Border Gateway Protocol (BGP) community lists, BGP autonomous system (AS) paths, Source Prefix address, or Destination Prefix address. After a packet has been classified, you can use other QoS features such as policing and weighted random early detection (WRED) to specify and enforce policies to fit your business model.
QoS Policy Propagation Using BGP (QPPB) allows you to map BGP prefixes and attributes to Cisco Express Forwarding (CEF) parameters that can be used to enforce traffic policing. QPPB allows BGP policy set in one location of the network to be propagated using BGP to other parts of the network, where appropriate QoS policies can be created.
QPPB allows you to classify packets based on the following:
•
•
•
•
•
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.
ACL Deny
A QOS policy can use a class map which in turn uses access lists (ACLs) to match packets. Unlike interface ACLs, QOS ACLs (as per the MQC specification) ignore permit and deny access control entries (ACEs). The ACL Deny feature allows deny ACEs in ACLs in a class map to be processed as deny actions. If the ACL Deny feature is not configured (the default), any deny ACEs in a class map are rejected and a warning message is displayed to this effect.
The ACL deny feature takes into account the action associated with the access control entry (permit or deny), treating the deny action in an ACL differently from the permit action. The ACE permit and deny actions in an access group within a class map are classified differently. Traffic matching an ACL with a deny action skips the class map and attempts to match subsequent classes. If there is no deny ACE for an ACL, the packet skips to the next class.
Hierarchical Ingress Policing
The Hierarchical Ingress Policing feature is an MQC-based solution that supports hierarchical policing on ingress interfaces.
This feature allows enforcement of service level agreements (SLA) while applying the classification submodel for different QoS classes on the inbound interface.
The hiearachical ingress policing provides support at two levels:
•
•
This allows you to police the ingress interface while applying different classification modes on ingress interfaces.
Hierarchical Policing for Frame Relay on Layer 2 VPN
To support hierarchical policing for Frame Relay on Layer 2 VPN, a policy with matching criteria based on the Frame Relay discard eligibility (DE) bit is attached on the main interface, which in turn produces a match, and applies the action for Layer 2 VPN. The supported hierarchical models are:
•
•
The parent policy and child policy are configured with independent policers. The parent policy maintains an aggregate rate per permanent virtual circuit (PVC) of the Frame Relay subinterface. The child policy contains the match criteria based on the Frame Relay discard eligibility (DE) bit and a class default.
Note
Hierarchical Policing for ATM on Layer 2 VPN
A two-level hierarchical policy map is supported in the ingress direction to support policing of the VBR.2 and VBR.3 type of traffic. The parent policy contains the policing configuration for the peak cell rate (PCR) bucket matching on all traffic (excluding OAM traffic). The child policy contains the policing configuration for the sustainable cell rate (SCR) bucket, and typically matches on the CLP0 cells.
The marking actions are supported in the child policy; whereas the policing actions are allowed in the parent policy.
Note
Enhanced Hierarchical Ingress Policing
In hierarchical ingress policing, traffic is policed first at the child policer level and then at the parent policer level. It is possible for traffic that conforms to the maximum rate specified by the child policer to be dropped by the parent policer. This can occur when an exceed action in the child policer is an action other than to drop ingress traffic.
In Enhanced Hierarchical Ingress Policing, the child-conform-aware command prevents the parent policer from dropping any ingress traffic that conforms to the maximum rate specified in the child policer.
Three-Level Hierarchical Policy Maps
The three-level hierarchical policy map feature supports three levels of hierarchy in the egress direction. These levels are:
•
•
•
Using three levels allows classification of traffic going into the priority queue and the policing of the classified traffic streams at different rates. This means that the queue properties such as bandwidth, bandwidth remaining, shape, priority, random detect, and queue-limit still apply for all of the traffic streams together.
Policer Granularity
Table 2 shows the default policer granularity values.
Table 2 Policer Granularity Default Values
Cisco 12000 SIP-401
64 kbps
Cisco 12000 SIP-501
64 kbps
Cisco 12000 SIP-601
64 kbps
The Policer Granularity feature allows you to override the default policer granularity values. The police rate you set should be a multiple of the policer granularity.
For example, if the police rate is set to 72 kbps but the default policer granularity is 64 kbps, the effective police rate is 64 kbps. To get an actual police rate of 72 kbps, configure the policer granularity to 8 kbps. Because 72 is a multiple of 8, the police rate will be exactly 72 kbps.
Policer granularity values, whether default or configured, apply to the SPA Interface Processor (SIP) and to all shared port adapters (SPAs) that are installed in the SIP.
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
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.
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 XR 12000 Series 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. As a result:
•
•
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:
•
•
•
Note
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 c1match vpls known!class c2match vpls unknown!class c3match vpls-multicast!policy-map p1class c1set qos-group2!class c2set qos-group3!class c3set discard-class4!!Figure 3
VPLS Components
In the VPLS-enabled network:
•
•
•
The packets that meet the VPLS-specific match criteria receive QoS treatment according to the policy actions defined in the policy.
Note
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 XR 12000 Series 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
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.
2.
3.
4.
5.
6.
7.
8.
9.
{vlanid | beginvlan-endvlan}]10.
or
commitDETAILED STEPS
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:
•
•
•
•
•
•
•
•
For additional commands that can be entered as match criteria, see the Cisco IOS XR Modular Quality of Service Command Reference for the Cisco XR 12000 Series Router.
For conceptual information, see Traffic Policy Elements.
Restrictions
Level 2 hierarchical classes are not supported.
SUMMARY STEPS
1.
2.
3.
4.
5.
or
commitDETAILED STEPS
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 XR 12000 Series Router.
Prerequisites
A traffic class and traffic policy must be created before attaching a traffic policy to an interface.
Restrictions
None
SUMMARY STEPS
1.
2.
3.
4.
or
commit5.
DETAILED STEPS
Configuring Class-based Unconditional Packet Marking
This configuration task explains how to configure the following class-based, unconditional packet marking features on your router:
•
•
•
•
•
•
•
•
Note
SUMMARY STEPS
1.
2.
3.
Choose one set command per class
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
or
commit17.
Note
DETAILED STEPS
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:
•
•
•
•
•
•
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.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
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.
2.
3.
4.
5.
or
commit
DETAILED STEPS
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.
2.
3.
DETAILED STEPS
Configuring ACL Deny
ACL deny allows traffic matching an ACL with a deny access control entry (ACE) to skip the class map and attempt to match subsequent classes. If there is no deny ACE for the ACL, the ACL Deny feature does not take effect.
The ACL deny feature is disabled by default.
Note
SUMMARY STEPS
1.
2.
3.
or
commitDETAILED STEPS
Configuring Hierarchical Ingress Policing
The hierarchical ingress policing is supported at two levels:
•
•
Restrictions
The Modular QoS command-line interface (MQC) provides hierarchical configuration, with the following limitations:
•
•
•
•
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
DETAILED STEPS
Configuring Enhanced Hierarchical Ingress Policing
The difference between configuring enhanced hierarchical ingress policing and configuring hierarchical ingress policing is the addition of the child-conform-aware command.
When used in the parent policer, the child-conform-aware command prevents the parent policer from dropping any ingress traffic that conforms to the maximum rate specified in the child policer.
Restrictions
The Modular QoS command-line interface (MQC) provides enhanced hierarchical ingress policing configuration, with the following limitations:
•
•
•
•
–
–
–
–
•
–
–
–
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
DETAILED STEPS
Configuring a Three-Level Hierarchical Policy
Three-level hierarchical policy supports three levels:
•
•
•
Restrictions
The following requirements and restrictions apply when using three-level hierarchical policy maps:
•
–
–
–
•
•
•
•
The following requirements and restrictions exist for each of the three levels:
Parent Level
•
•
–
–
Child Level
•
–
–
–
–
–
–
–
–
–
•
•
Grand-Child Level
•
–
–
•
•
•
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
or
commitDETAILED STEPS
Configuring Policer Granularity
Use the Policer Granularity feature to override the default policer granularity value so that the police rate you specify is a multiple of the policer granularity.
Restrictions
The Policer Granularity feature has the following limitations:
•
•
•
•
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Configuring QoS Services on Multicast VPN
Supporting QoS in a multicast VPN-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 XR 12000 Series 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.
2.
3.
4.
5.
6.
7.
8.
9.
10.
DETAILED STEPS
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.
2.
3.
4.
5.
6.
7.
8.
DETAILED STEPS
Setting the Frame Relay Discard Eligibility Bit
You can use the discard eligibility (DE) bit in the address field of a Frame Relay frame to prioritize frames in congested Frame Relay networks. The Frame Relay DE bit has only one bit and can therefore, have only two settings, 0 or 1. If congestion occurs in a Frame Relay network, frames with the DE bit set to 1 are discarded before frames with the DE bit set to 0. Therefore, important traffic should have the DE bit set to 0, and less important traffic should be forwarded with the DE bit set to 1.
Note
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Matching the Frame Relay DE Bit
You can use the match fr-de command to enable frames with a DE bit setting of 1 to be considered a member of a defined class and forwarded according to the specifications set in the service policy.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Matching the ATM CLP Bit
You can use the match atm clp command to enable packet matching on the basis of the ATM cell loss priority (CLP).
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Configuration Examples for Configuring Modular QoS Packet Classification on Cisco IOS XR Software
This section contains the following examples:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
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 class1match access-group ipv4 101exit!class-map class2match access-group ipv4 102exitTraffic 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 created in the "Traffic Classes Defined: Example" section.
For class1, the policy includes a bandwidth allocation request and a maximum packet limit for the queue reserved for the class. For class2, the policy specifies only a bandwidth allocation request.
policy-map policy1class class1bandwidth 3000 kbpsqueue-limit 1000 packets!class class2bandwidth 2000 kbps!class class-default!end-policy-map!endTraffic 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/0service-policy output policy1exit!interface TenGigE 0/5/0/1service-policy output policy1exitDefault 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 policy1class class-defaultshape average percent 60class-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 class1match protocol ipv4match qos-group 4match access-group ipv4 101In 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
Traffic Policy as a QoS Policy (Hierarchical Traffic Policies) Configuration: Examples
A traffic policy can be nested within a QoS policy when the service-policy command is used in policy map class configuration mode. A traffic policy that contains a nested traffic policy is called a hierarchical traffic policy.
Hierarchical traffic policies can be attached to all supported interfaces for this Cisco IOS XR software release, such as the OC-192 and 10-Gigabit Ethernet interfaces.
Two-Level Hierarchical Traffic Policy Configuration: Example
A two-level hierarchical traffic policy contains a child and a parent policy. The child policy is the previously defined traffic policy that is being associated with the new traffic policy through the use of the service-policy command. The new traffic policy using the pre-existing traffic policy is the parent policy. In the example in this section, the traffic policy called child is the child policy, and the traffic policy called parent is the parent policy.
In the following example, the child policy is responsible for prioritizing traffic, and the parent policy is responsible for shaping traffic. In this configuration, the parent policy allows packets to be sent from the interface, and the child policy determines the order in which the packets are sent.
policy-map childclass mplspriority!policy-map parentclass class-defaultshape average 10000000service-policy childThree-Level Hierarchical Traffic Policy Configuration: Example
A three-level hierarchical traffic policy contains a parent, child, and grand-child policy. The first level (parent) policy provides the shaper parameter. The second level (child) policy allows the highest level of complexity and defines queuing and scheduling behavior. The third level (grand-child) policy allows policing and set commands.
In the example, a three-level hierarchical policy is configured.
policy-map parentclass class-defaultshape average 100 mbpsservice-policy child!policy-map childclass goldpriorityservice-policy grand-child1class silverbandwidth 50 mbpsrandom detect mpls experimental 4 100 packets 200 packetsservice-policy grand-child2class bronzebandwidth 10 mbpsrandom detect mpls experimental 2 200 packets 400 packetsservice-policy grand-child3class class-defaultset mpls experimental topmost 1!policy-map grand-child1class gold-voice1police rate 10 mbpsconform-action set mpls experimental topmost 5exceed-action dropclass bold-voice2police rate 10 mbpsconform-action set mpls experimental topmost 5exceed-action drop!policy-map grand-child2class silver-data1police rate 30 mbpsconform-action set mpls experimental topmost 3exceed-action set mpls experimental topmost 0class silver-data2police rate 20 mbpsconform-action set mpls experimental topmost 4exceed-action drop!policy-map grand-child3class bronze-data1police rate 40 mbpsset mpls experimental topmost 2class bronze-data2set mpls experimental topmost 0Class-based, Unconditional Packet Marking Examples
The following are typical class-based, unconditional packet marking examples:
•
•
•
•
•
•
•
•
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 policy1class class1set precedence 1!interface pos 0/1/0/0service-policy output policy1IP Precedence Tunnel Marking Configuration: Example
In the following example, a service policy called policy1 is created. This service policy is associated to a previously defined classification policy called class1 through the use of the class command, and then the service policy is attached in the input direction on an IPSec interface.The IP precedence value is set to priority (1):
policy-map policy1class class1set precedence tunnel priority!interface service-ipsec 1service-policy output pre-enecrypt policy1
Note
Refer to Implementing IPSec Network Security on Cisco IOS XR Software in the Cisco IOS XR System Security Configuration Guide for the Cisco XR 12000 Series Router for more information on configuring IPSec.
IP DSCP Marking Configuration: Example
In the following example, a service policy called policy1 is created. This service policy is associated to a previously defined 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 policy1class class1set dscp 5class class2set dscp efAfter you configure the settings shown for voice packets at the edge, all intermediate routers are configured to provide low-latency treatment to the voice packets, as follows:
class-map voicematch dscp efpolicy qos-policyclass voicepriorityThe 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 class1match access-group ipv4 101policy-map policy1class class1set qos-group 1!interface gigabitethernet 0/1/0/9service-policy input policy1
Note
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 class1match access-group ipv4 101policy-map policy1class class1set discard-class 1!interface pos 0/1/0/0service-policy input policy1CoS 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 class1match access-group ipv4 101policy-map policy1class class1fset cos 1!interface TenGigE0/1/0/0.100service-policy output policy1
Note
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 class1match access-group ipv4 101policy-map policy1class class1set mpls exp imposition 1!interface TenGigE0/1/0/0service-policy input policy1
Note
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 class1match mpls exp topmost 2policy-map policy1class class1set mpls exp topmost 1!interface TenGigE0/1/0/0service-policy output policy1Route Policy Configuration: Example
BGP Community Sample Configuration
The following configuration is an example of configuring route policy in a BGP community:
route-policy qppb-comm6200if community matches-any (61100:10, 61200:20, 61300:30) thenset qos-group 11elseif community matches-any (62100:10, 62200:20, 62300:30) thenset qos-group 12elseset qos-group 1endifpassend-policy!router bgp 100bgp router-id 10.10.10.10address-family ipv4 unicasttable-policy qppb-comm6200network 201.32.21.0/24network 201.37.5.0/24!neighbor 201.1.0.2remote-as 61100address-family ipv4 unicastroute-policy pass-all inroute-policy pass-all out!!neighbor 201.2.0.2remote-as 61200address-family ipv4 unicastroute-policy pass-all inroute-policy pass-all out!!neighbor 201.32.21.2remote-as 62100address-family ipv4 unicastroute-policy pass-all inroute-policy pass-all out!!neighbor 201.32.22.2remote-as 62200address-family ipv4 unicastroute-policy pass-all inroute-policy pass-all out!!interface GigabitEthernet0/0/5/4service-policy output comm-p1-outipv4 address 201.1.0.1 255.255.255.0ipv4 bgp policy propagation input qos-group destinationnegotiation auto!interface GigabitEthernet0/1/5/6service-policy input comm-p1-inipv4 address 201.32.21.1 255.255.255.0ipv4 bgp policy propagation input qos-group sourcenegotiation 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-inclass class-qos10set discard-class 3shape average percent 20!class class-qos20set precedence flash-overrideshape average percent 30!class class-qos30set precedence criticalshape average percent 40!class class-qos11set precedence priorityshape average percent 10!class class-qos12set precedence immediateshape average percent 20!class class-qos13set precedence flashshape average percent 30!policy-map p11-outclass class-qos10set precedence prioritypolice rate percent 20!!class class-qos20set precedence immediatepolice rate percent 30!!class class-qos30set precedence criticalpolice rate percent 40!!class class-qos11set precedence immediatepolice rate percent 20!!class class-qos12set precedence flashpolice rate percent 30!!class class-qos13set precedence flash-overridepolice rate percent 40!!class class-default!end-policy-map!route-policy qppb-as6000if as-path in (ios-regex '61100, 61200, 61300') thenset qos-group 10elseif as-path in (ios-regex '62100, 62200, 62300') thenset qos-group 20elseif as-path in (ios-regex '63100, 63200, 63300') thenset qos-group 30elseif as-path neighbor-is '61101' or as-path neighbor-is '61201' thenset qos-group 11elseif as-path neighbor-is '61102' or as-path neighbor-is '61202' thenset qos-group 12elseif as-path neighbor-is '61103' or as-path neighbor-is '61203' thenset qos-group 13elseset qos-group 2endifend-policy!router bgp 100bgp router-id 10.10.10.10address-family ipv4 unicasttable-policy qppb-as6000network 201.32.21.0/24network 201.37.5.0/24!neighbor 201.1.0.2remote-as 61100address-family ipv4 unicastroute-policy pass-all inroute-policy pass-all out!!neighbor 201.2.0.2remote-as 61200address-family ipv4 unicastroute-policy pass-all inroute-policy pass-all out!!neighbor 201.32.21.2remote-as 62100address-family ipv4 unicastroute-policy pass-all inroute-policy pass-all out!!neighbor 201.32.22.2remote-as 62200address-family ipv4 unicastroute-policy pass-all inroute-policy pass-all out!!interface GigabitEthernet0/0/5/4service-policy output p11-outipv4 address 201.1.0.1 255.255.255.0ipv4 bgp policy propagation input qos-group destinationnegotiation auto!interface GigabitEthernet0/1/5/6service-policy input p11-inipv4 address 201.32.21.1 255.255.255.0ipv4 bgp policy propagation input qos-group sourcenegotiation auto!QPPB Source Prefix Configuration: Example
The following configuration is an example of configuring QPPB source prefix:
route-policy qppb-src10-20if source in (201.1.1.0/24 le 32) thenset qos-group 10elseif source in (201.2.2.0/24 le 32) thenset qos-group 20elseset qos-group 1endifpassend-policy!router bgp 100bgp router-id 10.10.10.10address-family ipv4 unicasttable-policy qppb-src10-!neighbor 201.1.1.2remote-as 62100address-family ipv4 unicastroute-policy pass-all inroute-policy pass-all out!!neighbor 201.2.2.2remote-as 62200address-family ipv4 unicastroute-policy pass-all inroute-policy pass-all out!!neighbor 202.4.1.1remote-as 100address-family ipv4 unicast!!!policy-map p1-inclass class-qos10set discard-class 4shape average percent 20!class class-qos20set precedence criticalshape average percent 30!class class-default!end-policy-map!policy-map p2-outclass class-qos10set precedence prioritypolice rate percent 30!class class-qos20set precedence immediatepolice rate percent 40!class class-default!end-policy-map!interface GigabitEthernet0/0/5/4service-policy output p1-inipv4 address 201.1.0.1 255.255.255.0ipv4 bgp policy propagation input qos-group sourcenegotiation auto!interface GigabitEthernet0/1/5/6service-policy input p2-outipv4 address 201.32.21.1 255.255.255.0ipv4 bgp policy propagation input qos-group destinationnegotiation auto!QPPB Destination Prefix Configuration: Example
The following configuration is an example of QPPB destination prefix:
route-policy qppb-des10to20if destination in (10.10.0.0/16 le 28) thenset qos-group 10elseif destination in (10.11.0.0/16 le 28) thenset qos-group 11elseif destination in (10.12.0.0/16 le 28) thenset qos-group 12elseif destination in (10.13.0.0/16 le 28) thenset qos-group 13elseif destination in (10.14.0.0/16 le 28) thenset qos-group 14elseif destination in (10.15.0.0/16 le 28) thenset qos-group 15elseif destination in (20.20.0.0/16 le 28) thenset qos-group 20elseset qos-group 1endifpassend-policy!router bgp 100bgp router-id 10.10.10.10address-family ipv4 unicasttable-policy qppb-des10to20!neighbor 201.1.1.2remote-as 62100address-family ipv4 unicastroute-policy pass-all inroute-policy pass-all out!!neighbor 201.1.2.2remote-as 62102address-family ipv4 unicastroute-policy pass-all inroute-policy pass-all out!!neighbor 201.1.3.2remote-as 62103address-family ipv4 unicastroute-policy pass-all inroute-policy pass-all out!!neighbor 201.1.4.2remote-as 62104address-family ipv4 unicastroute-policy pass-all inroute-policy pass-all out!!neighbor 201.1.5.2remote-as 62105address-family ipv4 unicastroute-policy pass-all inroute-policy pass-all out!!policy-map p11-inclass class-qos10set precedence priorityshape average percent 30!class class-qos11set precedence immediateshape average percent 10!class class-qos12set precedence flashshape average percent 15!class class-qos13set precedence flash-overrideshape average percent 20!class class-qos14set precedence flashshape average percent 25!class class-qos15set precedence flash-overrideshape average percent 30!class class-qos20set precedence criticalshape average percent 40!class class-default!end-policy-map!policy-map p1-outclass class-qos10set precedence prioritypolice rate percent 30!class class-qos20set precedence criticalpolice rate percent 40!class class-default!end-policy-map!interface GigabitEthernet0/2/2/1service-policy output p1-outipv4 address 201.1.0.1 255.255.255.0ipv4 bgp policy propagation input qos-group sourcenegotiation auto!interface GigabitEthernet0/2/2/1.2service-policy input p11-inipv4 address 201.1.2.1 255.255.255.0ipv4 bgp policy propagation input qos-group destinationdot1q vlan 2!interface GigabitEthernet0/2/2/1.3service-policy input p11-inipv4 address 201.1.3.1 255.255.255.0ipv4 bgp policy propagation input qos-group destinationdot1q vlan 3!interface GigabitEthernet0/2/2/1.4service-policy input p11-inipv4 address 201.1.4.1 255.255.255.0ipv4 bgp policy propagation input qos-group destinationdot1q vlan 4!interface GigabitEthernet0/2/2/1.5service-policy input p11-inipv4 address 201.1.5.1 255.255.255.0ipv4 bgp policy propagation input qos-group destinationdot1q vlan 5!ACL Deny Configuration: Example
The following configuration is an example of the ACL deny feature:
ipv4 access-list acl-permit-deny10 permit ipv4 host 10.0.0.0 any20 deny ipv4 any any!class-map match-any class-acl-permit-denymatch access-group ipv4 acl-permit-deny!policy-map pol-acl-permit-denyclass class-acl-permit-denyshape average percent 40!class class-defaultpolice rate percent 15conform-action transmitexceed-action drop!!!In the example, traffic with the source IP address 10.0.0.0 is classified into the class "class-acl-permit-deny", but any other IP traffic is expected to match the next class (class-default in this example) because the ACE action is deny for all other IP traffic.
Hierarchical Ingress Policing: Example
The following configuration is an example of typical hierarchical ingress policing:
policy-map parentclass class-defaultservice-policy childpolice rate percent 50conform-action transmitexceed-action dropThis policy map can be applied on any interface or on a subinterface. The incoming traffic on the main interface or subinterface can be IPv4 unicast or multicast, MPLS, or IPv6 unicast or multicast. The child policy map can be a regular policy map that can be configured in the ingress direction on that interface.
If the policy map is applied on a main interface that has subinterfaces, then the configuration is considered as a 1CnD configuration model. Hence, the child policy must be applied on each subinterface and the parent policer polices the aggregate traffic from all subinterfaces.
For example:
interface Serial 0/4/1/1/0:0encapsulation frame-relayservice-policy input parentinterface Serial 0/4/1/1/0:0.1 point-to-pointinterface Serial 0/4/1/1/0:0.2 point-to-pointIn this configuration, the child policy is applied on each of the subinterfaces and the aggregate traffic from all subinterfaces is subjected to the parent policer. In this model, the child policy is not permitted any queueing actions.
An example of the configuration for a nCmD model is as follows:
class-map match-any customeramatch vlan 1-3class-map match-any customerbmatch vlan 4-7policy-map parentclass customeraservice-policy childapolice rate percent 50conform-action transmitexceed-action drop!class customerbservice-policy childbpolice rate percent 70conform-action transmitexceed-action drop!!Similar to the 1CnD model, the aggregate traffic from all subinterfaces that match each parent class map is subjected to the parent policer configured in that class map. Also, the child policy is not permitted any queuing actions.
Enhanced Hierarchical Ingress Policing: Example
This example shows parent and child policy maps in which two classes are defined in the child policy. In class AF1, the exceed action is set to an action other than to drop traffic.
If the child-conform-aware command were not configured in the parent policy, the parent policer would drop traffic that matches the conform rate of the child policer but exceeds the conform rate of the parent policer.
When used in the parent policer, the child-conform-aware command prevents the parent policer from dropping any ingress traffic that conforms to the maximum rate specified in the child policer.
policy-map parentclass class-defaultservice-policy childpolice rate percent 50child-conform-awareconform-action transmitexceed-action droppolicy-map childclass EFpolice rate 1 mbpsconform-action set mpls experimental imposition 4exceed-action dropclass AF1police rate percent 50conform-action set mpls experimental imposition 3exceed-action set mpls experimental imposition 2The police rate command allows you to police traffic to control the maximum rate of traffic sent or received on an interface. In the parent policy, the police rate percentage is a percentage of the interface rate. In the child policy, the police rate percentage is a percentage of the parent policer rate.
In this example, the parent policy configures a police rate of 50 percent, which is 50 percent of the maximum bandwidth allowed on the interface. Class AF1 in the child policy configures a police rate of 50 percent, which is 50 percent of the bandwidth allowed in the parent, in this case 25 percent of the maximum bandwidth allowed on the interface.
Policer Granularity: Example
The police rate you set should be a multiple of the policer granularity. For example, if the police rate is set to 72 kbps but the default policer granularity is 64 kbps, the effective police rate is 64 kbps. To get an actual police rate of 72 kbps, configure the policer granularity to 8 kbps. Because 72 is a multiple of 8, the police rate will be exactly 72 kbps.
This example shows how to set the policer granularity to 8 kbps:
hw-module qos pol-gran 8 location 0/1/CPU0Use the show qos pol-gran location command to verify the policer granularity. The Admin value is the value configured using the hw-module qos pol-gran location command. The Oper value is the default policer granularity for this SIP.
show qos pol-gran location 0/1/CPU0QoS Policer Granularity RateAdmin Value: 8 kbpsOper Value: 64 kbpsIn-Place Policy Modification: Example
The following configuration is an example of in-place policy modification:
Defining a policy map:
configurepolicy-map policy1class class1set precedence 3commit
Attaching the policy map to an interface:
configureinterface POS 0/6/0/1service-policy output policy1commit
Modifying the precedence value of the policy map:
configurepolicy-map policy1class class1set precedence 5commit
Note
QoS Services on Multicast VPN: Example
The following configuration is an example of the QoS Service on multicast VPN:
Unconditional Marking: Example
class-map c1match vlan 1-10policy-map p1class c1set precedence tunnel 3Conditional Marking: Example
policy-map p2class c1police rate percent <>conform action set dscp tunnel af11exceed action set dscp tunnel af12Setting the Frame Relay Discard Eligibility Bit: Example
The following example shows how to set the DE bit using the set fr-de command in the traffic policy:
class-map ip-precedencematch ip precedence 0 1exitpolicy-map set-declass ip-precedenceset fr-deexitexitinterface serial 1/0/0no ip addressencapsulation frame-relayinterface serial 1/0/0.1ip address 10.1.1.1 255.255.255.252no ip directed-broadcastservice-policy output set-deMatching the Frame Relay DE Bit: Example
The following example creates a class called match-fr-de and matches packets on the basis of the Frame Relay DE bit setting:
class-map match-fr-dematch fr-deendVPLS QoS: Example
The following example shows how to configure VPLS QoS:
class-map match-any c1match vpls knownend-class-map!class-map match-any c2match vpls unknownend-class-map!policy-map p2class c1set qos-group 3set mpls experimental imposition 4shape average percent 40!class c2bandwidth remaining percent 10set 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
Standards
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
—
MIBs
—
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
No new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature.
—
Technical Assistance
