• This example shows policing action on the service group:

  policy-map qos-group-in
  class cos1
  police cir 64000
  policy-map qos-group-out
  class cos2
  police cir 64000
  policy-map qos-member-out1
  class cos3
  police cir 64000
  policy-map qos-member-out2
  class cos4
  police cir 64000

• This example shows both Ingress and Egress policies supported on the service group:

  service-group 1
  service-policy in qos-group-in
  service-policy out qos-group-out
  int gigabitEthernet1/0/0
  service instance 101 ethernet
  group 1
  service-policy out qos-member-out1
  service instance 102 ethernet
  group1
  service-policy out qos-member-out2
  int gigabitEthernet1/0/1
  service instance 200 ethernet
  group 1
  service-policy out qos-member-out1
  service instance 300 ethernet
  service-policy out qos-member-out2

• Use the show running-config service group command to verify the service groups configuration:

  Router# show running-config service-group 1

  Building configuration...
  Current configuration:
  service-group 1
  service-policy input co1
  end

• Use the show platform software uea-qos service-group stats command to verify the statistics of service groups:

  Router# show platform software uea-qos service-group 1 stats

  Service Group 1
  Service-policy input: co1
  class-map: co1:
  policy name co1, parent class , parent policy
  conformed 54645 packets, 3497280 bytes
  exceeded 3705853 packets, 237174592 bytes
  violated 0 packets, 0 bytes
  conformed 93000 bps, exceeded 6300000 bps

The following limitations apply to QoS classification on the Cisco ASR 920 Series Router:

• If you configure egress classification for a class of traffic affected by an input policy-map, you must use the same classification criteria on the ingress and egress policy-maps.

• Egress policy-map with police action is supported on port-channel interface(LAG).

• When applying a QoS policy to a link aggregation group (LAG) bundle, you must assign the policy to a physical link within the bundle; you cannot apply the policy to the LAG bundle or the port channel interface associated with the bundle.

• MPLS Pipe Mode Limitations—When you configure pipe mode for Time to Live (TTL), the router enables pipe mode for QoS as well. When pipe mode is enabled, you cannot enable egress classification based on the header on an egress interface. For example, you cannot classify based on egress DSCP value for MPLS IP packets when the router is in pipe mode.

• MPLS classification using EXP values in an egress policy are applied to normal IP packets in an MPLS core network. When Egress classification for EXP values are converted to equivalent IP precedence values, the first 5 bits in the DSCP values will be used to classify the MPLS packets. However, normal IP packets will be classified as well.

  It is recommended to move the EXP classification to ingress policy and egress classification to be moved to the QoS group set from ingress policy to avoid classification of normal IP packets.

• The topmost policy-map in a three-level hierarchy only supports classification using class-default.

The following limitations apply to QoS marking on the Cisco ASR 920 Series Router:

• The Cisco ASR 920 Series Router does not support hierarchical marking.

• You can configure marking and policing for any number of classes on any one of the three levels of the policy-map hierarchy. If you configure marking on one level, you can configure policing without marking (transmit, drop) on another level.

• In the flow of the packet, if both ingress and egress markings are needed, you must classify the packet with the ingress marked phb class at egress and remark it to preserve the ingress marking. Marking in class-default of the ingress marked packets will not preserve the ingress markings.

IOS XE Release 3.6 introduces support for egress marking. The following limitations apply when configuring marking on egress interfaces:

• The set cos inner command is not supported.

• The set mpls experimental imposition command is supported.

• The set mpls experimental topmost command is supported for marking MPLS Exp bits; other commands for marking MPLS Exp bits are not supported.

The following additional marking usage guidelines apply in Release 3.9:

• Release 3.9 introduces support for ingress MPLS Exp marking on pseudowire CEM and ATM interfaces, including SAToP, CESoPSN, ATM IMA, and ATMoMPLS.

• Marking is supported on Etherchannel interfaces and individual member links; however, you cannot configure marking on both interface levels at once.

The following example shows how to enable CoS marking on protocols.

platform cos-mark protocol protocol cos-value cos-value

platform cos-mark protocol snmp cos-value 7 mark

Note	In CoS_mark double tagged packets, if the values remain same then the outer tag CoS value is also copied to inner tag. For the supported protocols, user configured CoS value is marked in outer tag and inner tag.

The Cisco ASR 920 Series Router supports the following policing commands on ingress interfaces:

• police (percent)—police cir percent percentage [burst-in-msec] [bc conform-burst-in-msec ms] [be peak-burst-in-msec ms] [pir percent percentage] [conform-action action [exceed-action action [violate-action action]]]

• police (policy map)—police cir bps [[bc] normal-burst-bytes [maximum-burst-bytes | [be] [burst-bytes]]] [pir bps [be burst-bytes]] [conform-action action [exceed-action action [violate-action action]]]

• police (two rates)—police cir cir [bc conform-burst] [pir pir] [be peak-burst] [conform-action action [exceed-action action [violate-action action]]]

The Cisco ASR 920 Series Router supports the following policing commands on egress interfaces:

• bandwidth (policy-map class)—bandwidth {bandwidth-kbps | remaining percent percentage | percent percentage} [account {qinq | dot1q} aal5 subscriber-encapsulation]

• bandwidth remaining ratio —bandwidth remaining ratio ratio [account {qinq | dot1q} [aal5] {subscriber-encapsulation | user-define d offset}]

• police (policy map)—police cir bps [[bc] normal-burst-bytes [maximum-burst-bytes | [be] [burst-bytes]]] [pir bps [be burst-bytes]] [conform-action action [exceed-action action [violate-action action]]]

• priority—priority {bandwidth-kbps | percent percentage} [burst]

Several restrictions apply when using egress policing; see the Egress Policing Limitations section for more information.

The Cisco ASR 920 Series Router supports the following policing actions on ingress interfaces:

• transmit

• drop

• set-qos-transmit

• set-cos-transmit

• set-dscp-transmit

• set-prec-transmit

• set-discard-class-transmit

• set-mpls-experimental-topmost-transmit

• set-mpls-experimental-imposition-transmit

The following limitations apply to QoS policing on the Cisco ASR 920 Series Router:

• If you configure a policer rate or burst-size that the router cannot achieve within 1% accuracy, the configuration is rejected. The command output presents recommendations for the closest possible lower and higher configuration value.

• You can configure marking and policing for any number of classes on any one of the three levels of the policy-map hierarchy. If you configure marking on one level, you can configure policing without marking (transmit, drop) on another level.

• If you configure marking using the set command, you can only configure policing on that level using the transmit and drop command.

• If you configure a policer using a set command, you cannot use the set command at other levels of the hierarchical policy-map.

The Cisco ASR 920 Series Router supports the bandwidth and bandwidth-remaining commands on egress interfaces under the following conditions:

• Mixed bandwidth types are not supported in the same policy. For example, you cannot configure a policy containing both the bandwidth remaining percent command and bandwidth remaining ratio command.

• The bandwidth and bandwidth-remaining commands are not supported in a class containing the priority command. The bandwidth and bandwidth-remaining commands must be configured on classes of the same level.

• If you want to create a configuration that uses the bandwidth or bandwidth-remaining commands and the priority command, you must include a police statement in the QoS class.

  The following is a sample supported configuration:

  
  Router# show policy-map
    Policy Map PHB
      Class cos1
       police cir 200000 bc 8000
         conform-action transmit
         exceed-action drop
        priority
      Class cos2
        bandwidth 100
        bandwidth remaining percent 40
      Class cos3
        bandwidth 200
        bandwidth remaining percent 50
  

• The priority and police commands must be applied on a single class.

  The following is a sample supported configuration:

  
  Router# show policy-map
    Policy Map PHB
      Class cos1
       police cir 200000 bc 8000
         conform-action transmit
         exceed-action drop
        priority
      Class cos2
        bandwidth 100
      Class cos3
        bandwidth 200
  

• Egress MLPPP interfaces support a single-rate policer with two color marker (1R2C) (color-blind mode) at the LLQ level.

• Egress port-level policing is supported with ingress EFP policy on the router.

  The following is a sample supported configuration:

  
  Policy-map ingress_policy
    Class cos3
      Set cos 5
  Policy-map egress policy
    Class cos5
      Shape average 30m
  
  ###Ingress
  interface GigabitEthernet0/4/0
  no ip address
  negotiation auto
  service instance 100 ethernet
    encapsulation dot1q 100
    service-policy input ingress_policy  >>>> Ingress policy in EFP
    bridge-domain 100
  
  ###Egress
  interface GigabitEthernet0/4/0
  no ip address
  negotiation auto
  service-policy output egress_policy   >>>>>Egress policy on Port
  service instance 100 ethernet
    encapsulation dot1q 100
    bridge-domain 100
  

• QoS features on egress policing is supported on MLPPP interfaces using the police command. Egress MLPPP interfaces support a single-rate policer with two color marker (1R2C) (color-blind mode) at the LLQ level.

• Police and Set in same policy class-map

  police and set commands can be configured together in the egress policy class-map. In prior releases, a error message was displayed when both police and set commands were configured.

  Sample example displaying the error message:

  
  Router(config)#policy-map egress
  Router(config-pmap)#class p1
  Router(config-pmap-c)#police cir 200m
  Router(config-pmap-c-police)#set prec 2
  Qos:Configuration failed - Set and police not allowed in same class p1 of policy egress
  QoS: Configuration failed. Invalid set
  

• Egress Policing on Non Priority Queue

  Policing is supported at the egress on non priority queues.

Sample configuration:

Router#sh policy-map testp
  Policy Map testp
    Class cos1
      priority
     police cir 20000000 bc 625000
       conform-action transmit
       exceed-action drop
    Class cos2
     police cir 20000000 bc 625000
       conform-action transmit
       exceed-action drop
    Class cos4
     police cir 50000000 bc 1562500
       conform-action transmit
       exceed-action drop

The following additional shaping usage guidelines apply in Release 3.9:

• Policies using shaping are supported only on individual member links of an etherchannel. Applying a shaping policy directly on an etherchannel interface is not supported.

• Class-based shaping is supported at all levels.

The Cisco ASR 920 Series Router does not support queuing on ingress interfaces.

The Cisco ASR 920 Series Router supports tail drop queuing on egress interfaces using the queue-limit command. The following limitations apply to egress queuing:

The following additional queuing usage guidelines:

• The router supports QoS policies that allow for low-latency queuing (LLQ) across multiple EFPs. For more information about this feature, see http://www.cisco.com/en/US/docs/ios-xml/ios/qos_plcshp/configuration/xe-3s/qos-plcshp-ehqos-pshape.html.

• CBWFQ is supported on second and third level classes.

• Queue-limit is supported only in leaf-level (per-hop behavior) classes.

• Queue-limit can not be configured without first configuring a scheduling action (bandwidth, shape average, or priority).

• Queue-limit can not co-exist with queue-limit percent.

• Queue-limit percent and WRED can not be configured in the same class.

• Queue-limit percent can not be configured with different qualifiers (cos, dscp, prec, and Qos-group).

• Queue-limit policy can be applied only on egress interface.

• Queue-limit can be configured in bytes or microseconds, or percent per class in the egress-policy.

• Default queue-limits for 1 and 10 G are 80 and 120 KB, repectively.

• Maximum queue-limit that can be configured in bytes is 2 MB.