Usage Guidelines

Within a policy map, the class (policy-map) command can be used to specify the name of the class whose policy you want to create or change. The policy map must be identified first.

To identify the policy map (and enter the required policy map configuration mode), use the policy-map command before you use the class (policy-map) command. After you specify a policy map, you can configure the policy for new classes or modify the policy for any existing classes in that policy map.

The class name that you specify in the policy map ties the characteristics for that class—that is, its policy—to the class map and its match criteria, as configured using the class-map command.

RP/0/RP0/CPU0:router(config)# class-map p2
RP/0/RP0/CPU0:router(config-cmap)# match precedence 2
RP/0/RP0/CPU0:router(config-cmap)# end-class-map
RP/0/RP0/CPU0:router(config)# commit

RP/0/RP0/CPU0:router(config)# policy-map pm2 
RP/0/RP0/CPU0:router(config-pmap)# class p2 
RP/0/RP0/CPU0:router(config-pmap-c)# set precedence 3 
RP/0/RP0/CPU0:router(config-pmap-c)# end-policy-map 
RP/0/RP0/CPU0:router(config)# commit 
RP/0/RP0/CPU0:router(config)# end 


RP/0/RP0/CPU0:router# show run policy-map pm2 
policy-map pm2
class p2
set precedence 3
! 
class class-default
! 
end-policy-map
!
  

Usage Guidelines

The class-map command specifies the name of the class for which you want to create or modify class map match criteria. Use of this command enables class map configuration mode in which you can enter any match command to configure the match criteria for this class. Packets arriving on the interface are checked against the match criteria configured for a class map to determine if the packet belongs to that class.

These commands can be used in a class map match criteria for the ingress direction:

• match access-group
• match [not] dscp
• match [not] mpls experimental topmost
• match [not] precedence
• match [not] protocol

Usage Guidelines

No specific guidelines impact the use of this command.

Usage Guidelines

No specific guidelines impact the use of this command.

Usage Guidelines

The router must be reloaded for the hw-module command to be functional.

Usage Guidelines

The line card must be reloaded for the hw-module command to be functional.

Usage Guidelines

The line card must be reloaded for the hw-module command to be functional.

Usage Guidelines

The router must be reloaded for the hw-module command to be functional.

After enabling the QoS peering feature using the hw-module profile qos ingress-model peering command, you can set the Layer 2 class of service (CoS) or drop eligible indicator (DEI) values at the egress using the set cos or set dei commands, respectively. However, at the egress, ensure you don’t set the MPLS experimental imposition (EXP) values (using the set mpls experimental imposition command). Otherwise, when committing the policy map with these configurations at the egress, you will encounter an error. This error occurs because the internal fields required for egress EXP marking are not available with peering enabled.

When you enable the peering mode (using the hw-module profile qos ingress-model peering command), the QPPB feature doesn’t work.

Usage Guidelines

The router must be reloaded for the hw-module command to be functional.

You must configure the hw-module profile qos ipv6 short command for QPPB to work with IPv6 address families and packets.

Usage Guidelines

The router must be reloaded for the hw-module command to be functional.

Usage Guidelines

Reload the router for the hw-module command to be functional.

Usage Guidelines

The router must be reloaded for the hw-module command to be functional. This command only applies to ingress traffic policies.

In releases prior to Cisco IOS XR 7.5.1 release, only 4, 8, 16, or 32 class-maps per ingress traffic policy are supported. Egress traffic policies can support up to 8 class-maps per traffic policy.

Starting Cisco IOS XR 7.5.1 release, the hw-module profile qos max-classmap-size command allows you to set the maximum number of class-map permitted per policy to 2 in addition to existing support of 4, 8, 16, 32 class-maps on N540-ACC-SYS, N540X-ACC-SYS, N540-24Z8Q2C-SYS, N540-28Z4C-SYS-A/D, N540X-16Z4G8Q2C-A/D, N540-12Z20G-SYS-A/D, N540X-12Z16G-SYS-A/D, N540X-6Z18G-SYS-A/D and N540X-8Z16G-SYS-A/D variants.

Usage Guidelines

• The increase in QoS policer allocation is supported only on Cisco NCS 5700 series SE line cards.

• When more than 32000 policers are allocated for QoS, it reduces policers for BGP Flowspec. For example, if you allocate 48000 policers for QoS, the BGP Flowspec policer count reduces from 32000 to 16000.

• Since Enhanced QoS mode configuration does not support more than 32000 policers, you cannot enable the hw-module profile qos policer-scale and hw-module profile stats qos-enhanced commands at the same time.

• The QoS policer scale numbers are only applicable when the hw-module profile mdb l3max-se or hw-module profile mdb l2max-se command is enabled. For more information on hardware MDB profiles, see NCS5700 MDB Profile in the NCS 5500 System Setup and Software Installation Guide.

• After enabling this command, reload the router.

Some examples of increase in QoS policer allocation:

• If you allocate 48000 policers with 16 class-maps, then 2999 policers are allocated per core and 5998 policers per NPU.

• If you allocate 64000 policers with 16 class-maps, then 3999 policers are allocated per core and 7998 policers per NPU.

Usage Guidelines

This command applies only to Layer 2 ingress QoS policies.

Usage Guidelines

The router must be reloaded for the hw-module command to be functional.

Usage Guidelines

• You must reload the router for the feature to be functional.

• The L2 counters/accounting will not work once this command is enabled.

Usage Guidelines

The router must be reloaded for the hw-module command to be functional.

Usage Guidelines

The router must be reloaded for the hw-module command to be functional.

Usage Guidelines

For class-based features (such as marking and policing), you define traffic classes based on match criteria, including ACLs and input interfaces. Packets satisfying the match criteria for a class constitute the traffic for that class.

The match access-group command specifies an ACL whose contents are used as the match criteria against which packets are checked to determine if they belong to the class specified by the class map.

The match access-group command is supported only in the ingress direction. The maximum allowed entries: 8

To use the match access-group command, you must first enter the class-map command to specify the name of the class whose match criteria you want to establish. You can specify up to eight IPv4 and IPv6 ACLs in a match statement.

QoS classification based on the packet length or TTL (time to live) field in the IPv4 and IPv6 headers is not supported. In Release 7.7.1, QoS support was added for classifying ingress IPv4 and IPv6 traffic, based on its packet length.

When an ACL list is used within a class-map, the deny action of the ACL is ignored and the traffic is classified based on the specified ACL match parameters.

Usage Guidelines

The match cos command is supported only in the ingress direction.

The match cos command specifies a class of service that is used as the match criteria against which packets are checked to determine if they belong to the class specified by the class map.

To use the match cos command, you must first enter the class-map command to specify the name of the class whose match criteria you want to establish. If you specify more than one match cos command in a class map, the values of subsequent match statements are added to the first match cos command.

Usage Guidelines

The match dei command specifies a DEI value that is used as the match criteria against which packets are checked to determine if they belong to the class specified by the class map.

Usage Guidelines

The match destination-address command is supported only in the ingress direction. The maximum allowed entries (any combination of IPv4 and IPv6 addresses, with a maximum of 4 addresses for each): 8

To use the match destination-address command, you must first enter the class-map command to specify the name of the class whose match criteria you want to establish. You can specify up to a total of eight IPv4 and IPv6 addresses in a match statement.

Usage Guidelines

The match dscp command is supported only in the ingress direction. The minimum value is 0 and maximum value is 63. The maximum allowed entries: 64.

The match dscp command specifies a DSCP value that is used as the match criteria against which packets are checked to determine if they belong to the class specified by the class map.

To use the match dscp command, you must first enter the class-map command to specify the name of the class whose match criteria you want to establish

The match dscp command examines the higher-order six bits in the type of service (ToS) byte of the IP header. If you specify more than one match dscp command in a class map, the new values are added to the existing statement.

The IP DSCP value is used as a matching criterion only. The value has no mathematical significance. For instance, the IP DSCP value 2 is not greater than 1. The value simply indicates that a packet marked with the IP DSCP value of 2 should be treated differently than a packet marked with an IP DSCP value of 1. The treatment of these marked packets is defined by the user through the setting of policies in policy map class configuration mode.

Usage Guidelines

The match mpls disposition class-map <cmap-name> command is supported only in the ingress direction. It contains the child class-map name as argument which can have match dscp <value> or match precedence <value> statements. The minimum value for DSCP is 0 and the maximum value is 63. The maximum allowed entries are 8.

The class map uses this command to identify DSCP and/or precedence values matching on a packet.

To use this command, you must first enter the class-map command to specify the name of the class whose match criteria you want to establish. If you specify more than one match mpls disposition class-map <cmap-name> command in a class map, the new values are added to the existing match statement.

This command examines the DSCP/precedence bits contained in the IPv4/IPv6 header.

Usage Guidelines

The match mpls experimental topmost command is supported only in the ingress direction. The minimum value is 0 and maximum value is 7. The maximum allowed entries: 8.

The match mpls experimental topmost command is used by the class map to identify MPLS experimental values matching on a packet.

To use the match mpls experimental topmost command, you must first enter the class-map command to specify the name of the class whose match criteria you want to establish. If you specify more than one match mpls experimental topmost command in a class map, the new values are added to the existing match statement.

This command examines the three experimental bits contained in the topmost label of an MPLS packet. Up to eight experimental values can be matched in one match statement. For example, match mpls experimental topmost 2 4 5 7 returns matches for experimental values of 2, 4, 5, and 7. Only one of the four values is needed to yield a match (OR operation).

The experimental values are used as a matching criterion only. The value has no mathematical significance. For instance, the experimental value 2 is not greater than 1. The value indicates that a packet marked with the experimental value of 2 should be treated differently than a packet marked with the EXP value of 1. The treatment of these different packets is defined by the user through the setting of QoS policies in policy map class configuration mode.

Usage Guidelines

The match precedence command is supported only in the ingress direction. The minimum value is 0 and maximum value is 7. The maximum allowed entries: 8.

The match precedence command specifies a precedence value that is used as the match criteria against which packets are checked to determine if they belong to the class specified by the class map.

To use the match precedence command, you must first enter the class-map command to specify the name of the class whose match criteria you want to establish. If you specify more than one match precedence command in a class map, the new values are added to the existing statement.

The match precedence command examines the higher-order three bits in the type of service (ToS) byte of the IP header. Up to eight precedence values can be matched in one match statement. For example, match precedence ipv4 0 1 2 3 4 5 6 7 returns matches for IP precedence values of 0, 1, 2, 3, 4, 5, 6, and 7. Only one of the eight values is needed to yield a match (OR operation).

The precedence values are used as a matching criterion only. The value has no mathematical significance. For instance, the precedence value 2 is not greater than 1. The value simply indicates that a packet marked with the precedence value of 2 is different than a packet marked with the precedence value of 1. The treatment of these different packets is defined by the user through the setting of QoS policies in policy map class configuration mode.

This table lists the IP precedence value number and associated name in descending order of importance.

Usage Guidelines

The match protocol command is supported only in ingress direction. The maximum allowed entry is 1.

Definitions of traffic classes are based on match criteria, including protocols, access control lists (ACLs), input interfaces, QoS labels, and experimental (EXP) field values. Packets satisfying the match criteria for a class constitute the traffic for that class.

The match protocol command specifies the name of a protocol to be used as the match criteria against which packets are checked to determine if they belong to the class specified by the class map. Available protocol names are listed in the table that follows.

The protocol-value argument supports a range of protocol numbers. After you identify the class, you may use the match protocol command to configure its match criteria.

Usage Guidelines

The egress default class will implicitly match qos-group 0. The minimum value is 1 and maximum value is 7, and 1 and 511 for peering profiles.

The match qos-group command sets the match criteria for examining QoS groups marked on the packet. One class map can match only one qos-group value from 1 through 7, and from 1 through 511 for peering profiles.

The QoS group value is used as a matching criterion only. The value has no mathematical significance. For instance, the QoS group value 2 is not greater than 1. The value simply indicates that a packet marked with the QoS group value of 2 should be treated differently than a packet marked with a QoS group value of 1. The treatment of these different packets is defined using the service-policy command in policy map class configuration mode.

The QoS group setting is limited in scope to the local router. Typically, the QoS group is set on the ingress on the local router to be used locally and the router to give differing levels of service based on the group identifier.

Usage Guidelines

The match traffic-class command is supported only in the egress direction.

The match traffic-class command specifies a traffic-class ID that is used as the match criteria against which packets are checked to determine if they belong to the queue set by an ingress policy-map.

To use the match traffic-class command, you must first enter the class-map command to specify the name of the class whose match criteria you want to establish.

Usage Guidelines

WRED is a congestion avoidance mechanism that slows traffic by randomly dropping packets when congestion exists. WRED is most useful with protocols like TCP that respond to dropped packets by decreasing the transmission rate.

If you set a discard-class of 3, the packet is dropped at ingress itself.

When you configure the random-detect discard-class command on an interface, packets are given preferential treatment based on the discard class of the packet.

When the value of the units argument is packets, packets are assumed to be 256 bytes in size.

Usage Guidelines

Use the set cos command 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 in the ingress direction. Only unconditional COS marking in the ingress direction is supported.

Usage Guidelines

The set dei command specifies a DEI value in a policy map class. For example, traffic can be policed and the excess traffic can be marked with DEI value of 1, so that it can be preferentially dropped in the egress interface or further downstream, when there is congestion.

Note	On NCS 5700 Series Routers, for L3 forwarded packets, the LSB ECN bit is copied to DEI when no egress marking policy with CoS is applied and CoS/DEI is not set from ingress. This is a limitation on ASIC.

Usage Guidelines

The set discard-class command associates a discard class ID with a packet. After the discard class is set, other QoS services such as Weighted Random Early Detection (WRED) can operate on the bit settings.

If however, you set a discard-class of 3, the packet is dropped at ingress itself.

Discard-class indicates the discard portion of the per hop behavior (PHB). The set discard-class command is typically used in Pipe mode. Discard-class is required when the input PHB marking is used to classify packets on the output interface.

The set discard-class command is supported only in the ingress direction. Unconditional discard-class marking is supported.

The discard-class values can be used to specify the type of traffic that is dropped when there is congestion.

Note	Marking of the discard class has only local significance on a node. Discard class cannot be associated with a QoS profile in peering mode.

Usage Guidelines

While marking a packet, ensure you don’t set the IP DSCP (using the set dscp  command) and the MPLS experimental imposition values (using the set mpls experimental imposition  command) for the same class map. Else, neither the DSCP remarking nor the MPLS EXP values may take effect at the ingress. This will cause, per default QoS behavior, the IP precedence values to be copied to the EXP bits on the imposed packets. Such an action could lead to unintended packets marked as high-priority by your customer being forwarded as high-priority MPLS packets in the network.

After the DSCP bit is set, other quality-of-service (QoS) services can then operate on the bit settings. The set dscp is supported only in the ingress direction.

The network gives priority (or some type of expedited handling) to marked traffic. Typically, you set the DSCP value at the edge of the network (or administrative domain); data then is queued based on the DSCP value.

Usage Guidelines

• The set ip encapsulation class-of-service command is not allowed in egress QoS policies.

• The IP encapsulation marking (set ip encapsulation class-of-service) and the MPLS experimental imposition marking (set mpls experimental) features are mutually exclusive. Both the configurations are not allowed at the same time.

• On the NCS 5500 series routers, the set ip encapsulation class-of-service command is allowed only when the policy-map-extend oprion is enabled. On the NCS 5700series routers, the command is supported in native mode without enabling the policy-map-extend.

• The policy-map-extend option enables 6-bit DSCP marking for both L2 and L3 modes at the same time. It is not feasible to enable the policy-map-extend option exclusively for L2 and L3 modes due to the shared hardware resources for L2 and L3 SRv6 traffic-class.

• To support DSCP marking on the NCS 5700 series routers, the propagate option must be enabled in the SRv6 configurations.

Usage Guidelines

After enabling the QoS peering feature using the hw-module profile qos ingress-model peering command, you can set the Layer 2 class of service (CoS) or drop eligible indicator (DEI) values at the egress using the set cos or set dei commands, respectively. However, at the egress, ensure you don’t set the MPLS experimental imposition (EXP) values (using the set mpls experimental imposition command). Otherwise, when committing the policy map with these configurations at the egress, you will encounter an error. This error occurs because the internal fields required for egress EXP marking are not available with peering enabled.

While marking a packet, ensure you don’t set the IP DSCP (using the set dscp  command) and the MPLS experimental imposition values (using the set mpls experimental imposition  command) for the same class map. Else, neither the DSCP remarking nor the MPLS EXP values may take effect at the ingress. This will cause, per default QoS behavior, the IP precedence values to be copied to the EXP bits on the imposed packets. Such an action could lead to unintended packets marked as high-priority by your customer being forwarded as high-priority MPLS packets in the network.

After the MPLS experimental bits are set, other QoS services can then operate on the bit settings.

This command is supported only in ingress direction. Unconditional MPLS experimental marking is supported.

The network gives priority (or some type of expedited handling) to the marked traffic. Typically, the MPLS experimental value is set at the edge of the network (or administrative domain) and queuing is acted on it thereafter.

While upgrading to Release 6.5.3 and above, if set mpls experimental { topmost } exp-value command is used in the egress PM of label imposition node, replace it with set mpls experimental { imposition } exp-value before the upgrade. Else, configuration fails after upgrade. This is because set mpls experimental { topmost } exp-value command does not work in egress.

Usage Guidelines

Precedence can be set using a number or corresponding name. After IP Precedence bits are set, other QoS services can then operate on the bit settings.

The set precedence command is supported only in the ingress direction. Unconditional precedence marking is supported.

The network gives priority (or some type of expedited handling) to the marked traffic. IP precedence can be set at the edge of the network (or administrative domain) and have queueing act on it thereafter.

The mapping from keywords such as 0 (routine) and 1 (priority) to a precedence value is useful only in some instances. That is, the use of the precedence bit is evolving. You can define the meaning of a precedence value by enabling other features that use the value. In the case of high-end Internet QoS, IP precedences can be used to establish classes of service that do not necessarily correspond numerically to better or worse handling in the network.

Usage Guidelines

The set qos-group command is supported only in the ingress direction.

The set qos-group is used to group incoming traffic and then to classify and remark packets on the egress interface

Usage Guidelines

If you set a traffic class at the ingress policy and don’t have a matching class at egress for the corresponding traffic class value, then the traffic at ingress with this class isn't accounted for in the default class at the egress policy map.

The set traffic-class command is supported only on ingress policies.

If the ingress policy doesn't explicitly set the traffic-class value, it’s implicitly set to 0.

Usage Guidelines

The shape average command is supported only in the egress direction.

When you use the shape average command, egress shaping is done at the Layer 1 level and includes the Layer 1 header in the rate calculation. If you have both shape and bandwidth configured for a class, ensure that the shape percent value is always greater than the percent value for bandwidth. For bundled interfaces, shape average can be configured only as a percentage.

The priority and shape average commands can be configured together in the same class.

The default burst size is bytes (when no unit is specified).

The per-class statistics for a shaper action do not reflect the Layer 1 header and the overhead bytes (if any configured) even though the shaper includes them in the rate calculation.

From Release 7.11.1, for Hierarchical QoS (H-QoS) and egress traffic management (ETM) models:

• Port shaper and burst on a particular physical interface are programmed when an egress policy map with only a class-default configuration and a configured shaper value is applied on that interface.

• The shaper rate on the default class is calculated as the port shaper and the burst as the port burst.

From Release 7.11.1, for non-H-QoS and non-ETM models:

• Port level burst on a particular interface is programmed when you configure it along with port shaper.

• You must attach an egress QoS parent policy map to the main interface.

• The shaper rate on the parent policy configured for the default class is considered as port shaper and the burst as port burst.

Usage Guidelines

The show qos hw-module-status command displays all QoS hardware module profile names on the router. The router must be reloaded for the hw-module profiles to be functional.