QoS Limitations and Guidelines
Global QoS Limitations
The following limitations apply to multiple QoS features for the Cisco ASR 903 Series Router:
-
When EVCs under a physical interface have a QoS policy attached, the following limitations apply:
–
The port-level policy is limited to the class-default class
–
Only the
shape
command is supported in the port-level policy
-
The Cisco ASR 903 Series Router supports up to 64 unique QoS classification service instances in a given bridge domain. QoS service instances refer to ports, VLAN classes, EFPs associated with a QoS classification policy.
-
Modification of class-map definitions while applied to an interface or Ethernet Flow Point is not supported.
-
Policy validation—Some QoS policy configurations are not validated until you apply the policy-map to an interface or Ethernet Flow Point. If a QoS configuration is invalid, the router rejects the configuration when you apply it to an interface. In some cases, a QoS configuration may be rejected due to hardware resource exhaustion or limitations. If you receive such an error message, detach the policy and adjust your QoS configuration.
-
The
match-all
keyword is supported only for QinQ classification.
-
SAToP and CESoPSN pseudowire traffic has a default MPLS Exp priority setting of 5 (high).
-
QoS is supported on POS interfaces on optical interface module.
-
Three-level QoS policies are not supported on the OC-3/OC-12 serial, MLPPP, and PoS interfaces. You can only apply QoS policies on two levels on these interfaces.
-
QoS does not account for CRC values on an interface and assumes that the value is 2 bytes. CRC differences can cause accuracy issues for 2 to 3% of the 128-byte traffic.
-
The Cisco ASR 903 router supports a maximum of 128 internal and reserved labels that represent PHB (cos/dscp/exp/prec) values on a QoS policy. A label exhaustion message is displayed if a policy exceeds the maximum number of labels.
QoS Features Using MQC Limitations
Table 13-3 lists the QoS MQC scaling limitations on router per release.
Table 13-3 Qos on MQC Limitations
Supported on Cisco ASR 903
|
|
|
|
|
|
|
No. of unique policy-maps
|
1024
|
|
4096
|
No. of classes per policy-map
|
512
|
4096
|
No. of filters per class-map
|
16
|
Etherchannel QoS Limitations
An EtherChannel bundles individual Ethernet links into a single logical link that provides the aggregate bandwidth of up to eight physical links. Release 3.9 introduces support for QoS policies on layer 3 Etherchannel interfaces.
The following features are supported on either etherchannels or member links, ingress and egress direction:
Note You cannot configure these features on an etherchannel interface and a member link at the same time.
The following features are supported only on member links:
-
shaping
-
bandwidth
-
priority
-
QL/WRED
Ingress QoS
Restrictions for Ingress QoS in the Cisco IOS Release 3.9 and later:
–
Only policing and marking are supported.
–
A class-map can have any type of filter, including the
match vlan
and
match service instance
commands.
–
Only policing and marking are supported.
–
Match service instance is
not
supported.
–
Only policing and marking are supported.
–
Policy-map on a member link is
not
supported with EVC configured at the port-channel level.
-
Policy-map application is allowed only on the EC main interface, EC member link, or EC EVC.
-
Ingress TCAM entries are used even if no member links exist for a policy on the EC main interface and EC EVCs.
Egress QoS
Restrictions for Egress QoS in the Cisco IOS XE Release 3.9 and later:
–
Classification statistics for the policy-map on a port-channel main interface are
not
supported as no queues are allocated for a port-channel main interface.
–
Policing and marking actions are only allowed in the policy-map on a port-channel main interface.
–
Queuing actions are
not
supported.
–
Egress TCAM entries are used even in the absence of member links.
–
Classification statistics for the policy-map on port-channel EVC/TEFP are
not
supported as no queues are allocated for port-channel EVC/TEFP.
–
Policing and marking actions are only allowed in the policy-map on port-channel EVC/TEFP.
–
Queuing actions are
not
supported.
–
Egress TCAM entries are used even if there are no member links present.
–
For egress match service-instance policy-map on EC member links, the same policy must be present on all other EC member links.
–
Match service-instance policy-map is replicated automatically for all the member links when the first policy is applied on any of the member links.
–
For non-match service-instance policy-map, the same policy-map can be applied for all member-links.
–
Dynamic modification of match service-instance policy-map actions is
not
allowed.
–
Deleting a global match service instance policy-map is
not
allowed if it applied to the member links.
–
Policing, marking and queuing action are supported on port-channel member links.
–
The running configuration displays the first member link on the first policy applied in a service-policy configuration.
–
The s
how policy-map interface brief
command only displays the policy-map applied on the running configuration.
–
Applying a same policy again on other member links where a policy-map was already applied will not display any error. A differently named policy if applied again will display an error.
–
For match service instance policy-map on egress member links, the policy-map statistics information is reset, when a member link is added or deleted from a port-channel either by configuration or by LACP port-bundling/unbundling action.
–
There is no difference in behavior for non-match service instance policies on the member links. They continue to work in the legacy mode. There is no conservation of TCAM entries in this mode, even if the same policy is applied on all member links.
–
Policy-map application is allowed only on either EC main interface, or EC member link, or EC EVC.
Routed Port-Channel
Routed Port-channel Interface
The following features are supported for the ingress policy-map on a routed port-channel interface:
-
Marking
-
Policing
-
Conditional marking
-
Marking and policing
-
Classification criteria is prec, dscp or ip acl.
This is an example:
policy-map routed_pc_ingress police cir 150m conform-action set-prec-transmit 4 exceed-action drop
The following features are supported for egress policy-map on routed port-channel interface:
-
Marking
-
Policing
-
Classification criteria is prec or dscp.
This is an example:
Member-links on Routed Port-channel Interface
The following features are supported for ingress policy-map on member links on the routed port-channel interface:
-
Marking
-
Policing
-
Conditional marking
-
marking and policing
-
Classification criteria is prec, dscp or ip acl.
The following features are supported for egress policy-map on member links on the routed port-channel interface:
-
Shaping
-
Queue-limit
-
Bandwidth (kbps, percent)
-
Bandwidth remaining (ratio, percent)
-
WRED
-
Port Shaper
-
Low Latency Queue (LLQ or priority queue)
This is an example:
policy-map mem_link_egress
Port-channel with EFP
The following features are supported for ingress policy-map on port-channel on EFP:
-
Marking
-
Policing
-
Conditional marking
-
marking and policing
-
The classification criteria is VLAN or EFP, Cos in child.
This is an example:
policy-map efp_pc_ingress
The following features are supported for egress policy-map on port-channel on EFP:
-
Marking
-
Policing
-
Conditional marking
-
marking and policing
-
The classification criteria is VLAN or EFP, Cos in child
This is an example:
policy-map efp_pc_ingress
EFP of Port-channel with EFP Configuration
-
The following features are supported for ingress and egress policy-map on EFP of port-channel on EFP:
–
Marking
–
Policing
–
Conditional marking
–
marking and policing
–
The classification criteria is VLAN or EFP, Cos in child.
Note Match EFP is cannot be configured.
Member Links of Port-channel with EFP Configuration
-
The following features are supported for ingress and egress policy-map on member links of port-channel on EFP:
–
Marking
–
Policing
–
Conditional marking
–
marking and policing
–
The classification criteria is VLAN or EFP, Match VLAN and Cos in child.
Restrictions for Hierarchical Policies
The Cisco ASR 903 Router supports hierarchical QoS policies with up to three levels, allowing for a high degree of granularity in traffic management.
There are limitations on the supported classification criteria at each level in the policy-map hierarchy. The following limitations apply when configuring hierarchical policy-map classification:
-
The topmost policy-map in a three-level hierarchy only supports classification using class-default.
Sample Hierarchical Policy Designs
The following are examples of supported policy-map configurations:
-
Three-Level Policy—You can only apply a three-level policy to a physical port on the router. A three-level policy consists of:
–
Topmost policy: class-default
–
Middle policy: match vlan
–
Lowest policy: match qos-group/match prec/match cos/match dscp
The following sample policy uses a flat class-default policy on the port and VLAN policies on EFP interfaces to unique QoS behavior to each EFP.
Sample Policy
–
Topmost policy: match vlan
–
Lowest policy: match qos-group/match prec/match cos/match dscp
–
Topmost policy: class-default
–
Lowest policy: match vlan
–
Topmost policy: class-default
–
Lowest policy: match mpls experimental topmost
-
Flat policy: match ip dscp
-
Flat policy: match vlan inner
-
Flat policy: class-default
Ingress and Egress Hierarchical Policing
In releases before Cisco IOS XE Release 3.9, policing was supported only at one level in the ingress and egress policy. It was only at the PHB or class level.
Effective with Cisco IOS XE Release 3.9, policing is supported at two levels of the policy-map.
–
Port and EFP level
–
EFP and Class level
–
Port and Class level
–
EFP and Class level
–
Port and Class level
Note Egress hierarchical policing is supported on two levels but one of the levels must be Class level.
If an Ingress hierarchal policy is configured on the interface, the
show Ethernet service instance interface
command does not display the service instance statistics.
The class-level in an Egress hierarchal policy is configured internally as shaper.
MPLS VPN QoS Mapping
Table 13-4
summarizes the default MPLS mappings for the Cisco ASR 903 Series Router.
Table 13-4 Default MPLS QoS Mapping
|
|
|
L3VPN, MPLS
|
IP Prec bit copied to MPLS Exp bit.
|
IP Prec bit is unchanged.
If a VLAN tag is pushed at egress, CoS bit is set to 0.
|
L2VPN
(EoMPLS, VPLS)
|
MPLS Exp bit is set to 0
|
IP Prec bit is unchanged.
If a VLAN tag is pushed at egress, CoS bit is set to 0.
|
MPLS-TP
|
|
|
CESoPN
|
MPLS Exp bit is set to 5
|
IP Prec bit is unchanged.
|
SAToP
|
MPLS Exp bit is set to 5
|
IP Prec bit is unchanged.
|
6VPE, 6PE
|
Prec bit value is copied to the MPLS Exp bit
|
IP Prec bit is unchanged.
If a VLAN tag is pushed at egress, CoS bit is set to 0.
|
Note You can modify the default mapping behaviors using explicit marking policies.
QoS Policer and Shaper Calculation
Table 13-5
summarizes the packet accounting information used to make policer and shaper calculations on the Cisco ASR 903 Series Router.
Table 13-5 QoS Accounting Calculation
|
|
|
|
Policing
|
Ingress
|
IPv4/L3VPN
|
L2 overhead, VLAN tag, CRC
|
Shaping
|
Egress
|
IPv4/L3VPN
|
L2 Ethernet overhead, VLAN tag, CRC, preamble, IPG
|
Policing
|
Egress
|
IPv4/L3VPN
|
Layer 2 Ethernet overhead, VLAN
|
Policing
|
Ingress
|
L2VPN
|
Layer 2 Ethernet overhead, VLAN tag, CRC
|
Shaping
|
Egress
|
L2VPN
|
Layer 2 Ethernet overhead, VLAN tag, CRC, preamble, IPG
|
Policing
|
Egress
|
L2VPN
|
Layer 3 payload (without CRC)
|
The following considerations also apply when understanding QoS policer and shaper calculations:
-
Egress shaping is applied at layer 1.
-
Ingress packet length accounting is performed at egress.
-
Egress shaping and policing do not account for newly pushed VLAN tags and MPLS labels.
-
If two policers are configured at egress, the statistics on the child PHB or PQ level are
not
displayed.
Implementing MPLS Diffserv Tunneling Modes
The MPLS specification defines three Diffserv operation modes:
-
Uniform—There is only one DiffServ marking that is relevant for a packet when traversing the MPLS network.
-
Pipe—The network uses two markings for traffic: the original marking value, which is used once the packets leave the MPLS network, and a separate marking value that is used while the traffic crosses intermediate nodes on the LSP span. The second marking value is dropped when traffic exits the MPLS network.
-
Short-Pipe—the egress LSR uses the original packet marking instead of using the marking used by the intermediate LSRs.
The following sections describe how to implement these modes on the Cisco ASR 903 Series Router using QoS policies.
Implementing Uniform Mode
Use the following guidelines to implement uniform mode on the Cisco ASR 903 Series Router:
Imposition
To copy the diffserv value to the MPLS Exp bit, create a QoS configuration as follows:
–
Classify based on Prec bit or DSCP bit at ingress.
–
Set the qos-group.
–
Classify on qos-group.
–
Set the MPLS exp value.
–
Classify based on Prec bit or DSCP bit at ingress.
–
Set the mpls Exp bit at imposition.
Tag-to-tag Transfer
To ensure that outer tag values are copied to inner tags, explicitly mark the outer Exp value on the inner Exp bit.
Disposition
To copy the MPLS Exp bit to the diffserv/IP prec bit, create a QoS configuration as follows:
-
Classify based on MPLS Exp bit on the ingress interface.
-
Set the qos-group value.
-
Classify based on qos-group on the egress interface.
-
Mark the IP prec or DSCP bit.
Implementing Pipe Mode
Use the following guidelines to implement pipe mode on the Cisco ASR 903 Series Router:
Imposition
To set the MPLS Exp bit by policy, create a QoS configuration as follows:
–
Set the qos-group on the egress interface.
–
Classify based on qos-group on the egress interface.
–
Set the MPLS Exp value.
–
Apply the set mpls exp imposition command at ingress.
Disposition
To preserve the original IP Prec or diffserv value so that egress queuing is based on MPLS exp value, create a QoS configuration as follows:
-
Classify on MPLS Exp value on the ingress interface.
-
Set the qos-group on the egress interface.
-
Classify based on qos-group value on the egress interface.
Implementing Short-Pipe Mode
Use the following guidelines to implement short-pipe mode on the Cisco ASR 903 Series Router:
Disposition
To preserve the original IP Prec or diffserv value so that egress queuing is based on MPLS Prec or diffserv value, create a QoS configuration as follows:
-
Classify based on IP prec or DSCP value on the egress interface.
-
Mark the IP prec or DSCP bit.
Classification
Classifying network traffic allows you to organize packets into traffic classes or categories on the basis of whether the traffic matches specific criteria. Classifying network traffic (used in conjunction with marking network traffic) is the foundation for enabling many quality of service (QoS) features on your network.
Table 13-5
summarizes the QoS Classification limitations for the Cisco ASR 903 Series Router.
Table 13-6 QoS Classification Limitations
|
|
|
|
|
|
|
|
|
|
|
|
Features
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Multiple match statements
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.9
|
3.9
|
3.9
|
3.9
|
3.5
|
3.5
|
3.9
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
X
|
3.7.1
|
access-group
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.9
|
3.9
|
3.9
|
3.9
|
3.5
|
3.5
|
3.9
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
X
|
3.7.1
|
all
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.9
|
3.9
|
3.9
|
3.9
|
3.5
|
3.5
|
3.9
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
X
|
3.7.1
|
any
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.9
|
3.9
|
3.9
|
3.9
|
3.5
|
3.5
|
3.9
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
X
|
3.7.1
|
class-map
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
cos
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.9
|
3.9
|
3.9
|
3.9
|
3.5
|
3.5
|
3.9
|
3.9
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
cos inner
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.9
|
3.9
|
3.9
|
3.9
|
3.5
|
3.5
|
3.9
|
3.9
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
destination-address
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
discard-class
|
X
|
3.5
|
X
|
3.5
|
X
|
3.5
|
X
|
3.9
|
X
|
3.9
|
X
|
3.5
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
X
|
3.7.1
|
dscp (IPv4)
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.9
|
3.9
|
3.9
|
3.9
|
3.5
|
3.5
|
3.9
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
X
|
3.7.1
|
dscp (IPv6)
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.9
|
3.9
|
3.9
|
3.9
|
3.5
|
3.5
|
3.9
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
X
|
3.7.1
|
flow pdp
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
frde
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
frdlci
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
ip dscp
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.9
|
3.9
|
3.9
|
3.9
|
3.5
|
3.5
|
3.9
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
X
|
3.7.1
|
ip precedence (IPv4)
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.9
|
3.9
|
3.9
|
3.9
|
3.5
|
3.5
|
3.9
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
X
|
3.7.1
|
ip precedence (IPv6)
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.9
|
3.9
|
3.9
|
3.9
|
3.5
|
3.5
|
3.9
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
X
|
3.7.1
|
ip rtp
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
mpls experimental
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.9
|
3.9
|
3.9
|
3.9
|
3.5
|
3.5
|
3.9
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
X
|
3.7.1
|
mpls experimental topmost
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.9
|
3.9
|
3.9
|
3.9
|
3.5
|
3.5
|
3.9
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
X
|
3.7.1
|
not
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
packet length
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
precedence (IPv4)
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.9
|
3.9
|
3.9
|
3.9
|
3.5
|
3.5
|
3.9
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
X
|
3.7.1
|
precedence (IPv6)
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.9
|
3.9
|
3.9
|
3.9
|
3.5
|
3.5
|
3.9
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
X
|
3.7.1
|
protocol
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
qos-group
|
X
|
3.5
|
X
|
3.5
|
X
|
3.5
|
X
|
3.9
|
X
|
3.9
|
X
|
3.5
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
X
|
3.7.1
|
service instance ethernet
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
source-address
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
vlan
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.9
|
3.9
|
3.9
|
3.9
|
3.5
|
3.5
|
3.9
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
X
|
3.7.1
|
vlan inner
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.5
|
3.9
|
3.9
|
3.9
|
3.9
|
3.5
|
3.5
|
3.9
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
X
|
3.7.1
|
Ingress Classification Limitations
The following limitations apply to QoS classification on the Cisco ASR 903 Series Router:
-
If you configure egress classification for a class of traffic affected by an input policy-map, you must use the same QoS criteria on the ingress and egress policy-maps.
Egress Classification Limitations
-
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.
-
If you configure egress classification for a class of traffic affected by an input policy-map, you must use the same QoS criteria on the ingress and egress policy-maps.
Classifying Traffic on MLPPP Interfaces
Release 3.7(1) introduces support for egress QoS on MLPPP interfaces. The Cisco ASR 903 Series Router supports the following
match
commands in a QoS class-map applied to an egress MLPPP interface.
-
match discard-class
-
match dscp
-
match ip dscp
-
match ip precedence
-
match precedence
-
match qos-group
Additional Classification Limitations
The following additional marking usage guidelines apply in Release 3.9:
-
The topmost policy-map in a three-level hierarchy only supports classification using class-default.
-
If you configure egress classification for a class of traffic affected by an input policy-map, you must use the same QoS criteria on the ingress and egress policy-maps.
Classifying Traffic using an Access Control List
You can classify inbound packet based on an IP standard or IP extended access control list (ACL). Follow these steps to classify traffic based on an ACL:
1.
Create an access list using the
access-list
or ip
access-list
commands
2.
Reference the ACL within a QoS class map using the match access-group configuration command
3.
Attach the class map to a policy map
Limitations and Usage Guidelines
The following limitations and usage guidelines apply when classifying traffic using an ACL:
-
QoS ACLs are supported only for IPv4 traffic
-
QoS ACLs are supported only for ingress traffic
-
You can use QoS ACLs to classify traffic based on the following criteria:
–
Source and destination host
–
Source and destination subnet
–
TCP source and destination
–
UDP source and destination
-
Named and numbered ACLs are supported.
-
You can apply QoS ACLs only to the third level class (bottom-most).
-
The following range of numbered access lists are supported:
–
1-99—IP standard access list
–
100-199—IP extended access list
–
1300-1999—IP standard access list (expanded range)
–
2000-2699—IP extended access list (expanded range)
-
You must create an ACL before referencing it within a QoS policy.
-
Deny statements within an ACL are ignored for the purposes of classification.
-
Classifying traffic based on TCP flags using an ACL is not supported.
-
Classifying traffic using multiple mutually exclusive ACLs within a
match-all
class-map is not supported.
-
Classifying traffic on a logical/physical level using an ACL is not supported.
-
Applying QoS ACLs to MAC addresses is not supported.
-
Port matching with the
neq
keyword is only supported for a single port.
-
Matching on multiple port numbers using the
eq
keyword is supported for up to 8 ports.
-
You can only configure 8 port matching operations on a given interface. A given command can consume multiple matching operations if you specify a source and destination port, as shown in the following examples:
–
permit tcp any lt 1000 any
—Uses one port matching operation
–
permit tcp any lt 1000 any gt 2000
—Uses two port matching operations
–
permit tcp any range 1000 2000 any 400 500
—Uses two port matching operations
You can use the following commands to verify your configuration:
–
show platform hardware
pp
{
active
|
standby
}
acl
label
labelindex—
Displays information about security ACL labels; the number of available input VMRs reflects the number of available port range operations.
-
Only the following combination of matches are currently supported for Ingress policies:
–
Combination A: DSCP, Outer COS, UDP/TCP Source and Destination port number, IP SA/DA
–
Combination B: IP SA/DA, Outer COS, Inner COS, DSCP, MPLS EXP
–
Combination C: MAC DA, Outer COS, Inner COS, DSCP, MPLS Exp
Note Policy with match on L4 ACL and MPLS EXP together is currently not supported.
For more information about configuring QoS, see
http://www.cisco.com/en/US/products/ps11610/products_installation_and_configuration_guides_list.html.
For more information about configuring access control lists, see the
Security Configuration Guide: Access Control Lists, Cisco IOS XE Release 3S (Cisco ASR 903).
Configuring Multiple match Statements
In IOS XE Release 3.5, the Cisco ASR 903 Series Router supported a single
match
or
match-any
command in a given QoS class-map, as shown in the following example:
IOS XE 3.5 Class Map Example
class-map match-any my-restrict-class_00 class-map match-any my-restrict-class_01 class-map match-any my-restrict-class_03
match cos 3
IOS XE Release 3.6 introduces support for multiple
match
or
match-any
commands in a given QoS class-map, as shown in the following example:
IOS XE 3.6 Class Map Example
class-map match-any my-class
The router treats the statements as a logical OR operation and classifies traffic that matches any
match
statement in the class map.
Classifying Traffic Using Match EFP Service Instance Feature
Service Provider configurations have various service instances on the PE. QoS policy-maps are applied on these service instances or group of service instances. Cisco IOS XE Release 3.9S introduces the Match EFP Service Instance feature. The benefits of this feature are:
-
Identify the various types of service-instances like EFP, Trunk EFPs
-
Apply policies on these service instances at the port
-
Manage bandwidth and priority across the service instances on the port and across classes within the service instance
-
Apply policies on a group of transport service instances such as applying similar policies to a group of EFPs.
Configuring Match Service Instances
Restrictions
-
Ethernet service instances configured under the interface can be classified in a class of a policy-map. The class can match on a group or set of match service instance statements.
class-map match-any policeServiceInstance match service instance ethernet 100 match service instance ethernet 200
-
Ingress and Egress Match service instance are supported.
-
match service instance and match PHB per flows classification are defined at respective levels in the policy hierarchy under the port.
-
The number of EFPs supported per group is 256. Only 256 match statements are supported per class.
-
Match EFP policy-map can be configured only on the port and
not
under the service instance.
Example
interface GigabitEthernet0/3/4 service-policy output BTS_Total service instance 10 ethernet rewrite ingress tag pop 1 symmetric service instance trunk 20 ethernet encapsulation dot1q 20-29 rewrite ingress tag pop 1 symmetric bridge-domain from-encapsulation service instance 30 ethernet xconnect 192.44.32.21 101 encapsulation mpls class-map match-any service-instance-group-with-BMG match service instance ethernet 10 match service instance ethernet 20 class-map service-instance-30 match service instance ethernet 30 class-map service-instance-20 match service instance ethernet 20 class service-instance-group-with-BMG class service-instance-30 service-policy BTS_OUT_Bi
Marking
QoS marking allows you to set a desired value on network traffic to make it easy for core devices to classify the packet.
Table 13-7
summarizes the QoS Marking limitations for the Cisco ASR 903 Series Router.
Table 13-7 Marking QoS Limitations
|
|
|
|
|
|
|
|
|
|
|
|
set
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
atm-clp
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
cos
|
3.5
|
3.6
|
3.5
|
3.6
|
3.5.1
|
3.6
|
3.9
|
3.9
|
3.9
|
3.9
|
3.5
|
3.5
|
3.9
|
3.9
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
cos inner
|
3.5
|
3.6
|
3.5
|
3.6
|
3.5.1
|
3.6
|
3.9
|
3.9
|
3.9
|
3.9
|
3.5
|
3.5
|
3.9
|
3.9
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
discard-class
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
3.9
|
X
|
3.9
|
X
|
3.5
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
dscp
|
3.6
|
3.6
|
3.6
|
3.6
|
3.6
|
3.6
|
3.9
|
3.9
|
3.9
|
3.9
|
3.6
|
3.6
|
3.9
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
dscp-transmit
|
3.5
|
X
|
3.5
|
X
|
3.5.1
|
X
|
3.9
|
X
|
3.9
|
X
|
3.5
|
X
|
3.9
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
ip dscp
|
3.5
|
3.6
|
3.5
|
3.6
|
3.5.1
|
3.6
|
3.9
|
3.9
|
3.9
|
3.9
|
3.5
|
3.5
|
3.9
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
ip precedence
|
3.5
|
3.6
|
3.5
|
3.6
|
3.5.1
|
3.6
|
3.9
|
3.9
|
3.9
|
3.9
|
3.5
|
3.5
|
3.9
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
mpls experimental
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mpls experimental imposition
|
3.5
|
X
|
3.5
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.5
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
mpls experimental imposition qos-group
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
mpls experimental topmost
|
3.5
|
3.6
|
3.5
|
3.6
|
3.5.1
|
3.6
|
3.9
|
3.9
|
3.9
|
3.9
|
3.5
|
3.5
|
3.9
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
precedence
|
3.6
|
3.6
|
3.6
|
3.6
|
3.6
|
3.6
|
3.9
|
3.9
|
3.9
|
3.9
|
3.6
|
3.6
|
3.9
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
prec-transmit
|
3.5
|
X
|
3.5
|
X
|
3.5.1
|
X
|
3.9
|
X
|
3.9
|
X
|
3.5
|
X
|
3.9
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
qos-group
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
3.9
|
X
|
3.9
|
X
|
3.5
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
X
|
Marking Overview
The Cisco ASR 903 Series Router supports the following parameters with the
set
command:
-
set cos
-
set discard-class
-
set ip dscp
-
set ip precedence
-
set mpls experimental imposition
(ingress marking)
-
set mpls experimental topmost
-
set qos-group
CoS Marking Limitations
The following limitations apply when configuring CoS marking:
-
set cos
—This set action has no effect unless there is a egress push action to add an additional header at egress. The COS value set by this action will be used in the newly added header as a result of the push rewrite. If there are no push rewrite on the packet, the new COS value will have no effect.
-
The
set cos inner
command is not supported.
Ingress Marking Limitations
The following limitations apply to QoS marking on the Cisco ASR 903 Series Router:
-
The Cisco ASR 903 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. Marking and policing are not supported on the same level of a policy-map.?
Egress Marking Limitations
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 not supported.
-
The
set mpls experimental topmost
command is supported for marking MPLS Exp bits; other commands for marking MPLS Exp bits are not supported.
Marking Traffic on MLPPP Interfaces
Release 3.7(1) introduces support for egress QoS on MLPPP interfaces. The Cisco ASR 903 Series Router supports the following parameters with the
set
command on egress MLPPP interfaces:
-
set ip dscp
-
set ip precedence
Marking IPv6 Traffic
The Cisco ASR 903 supports the following commands for marking both IPv4 and IPv6 packets:
For more information about IPv6 QoS, see:
Additional Marking Limitations
The following additional marking usage guidelines apply in Release 3.9:
-
CoS marking Limitation— The
set cos
action has no effect unless there is a egress push action to add an additional header at egress. The COS value set by this action will be used in the newly added header as a result of the push rewrite. If there are no push rewrite on the packet, the new COS value will have no effect.
-
The Cisco ASR 903 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. Marking and policing are not supported on the same level of a policy-map.
-
Ingress marking is not supported on Etherchannel interfaces or member links.
-
Release 3.9 introduces support for ingress MPLS Exp marking on pseudowire CEM and ATM interfaces, including SAToP, CESoPSN, ATM IMA, and ATMoMPLS. For more information about configuring bit marking, see Implementing MPLS Diffserv Tunneling Modes.
-
Marking is supported on Etherchannel interfaces and individual member links; however, you cannot configure marking on both interface levels at once.
Policing
Traffic policing allows you to control the maximum rate of traffic sent or received on an interface, and to partition a network into multiple priority levels or class of service (CoS). This section describes the policing limitations and configuration guidelines for the Cisco ASR 903 Series Router.
The Cisco ASR 903 Series Router supports the following policing types:
-
Single-rate policer with two color marker (1R2C) (color-blind mode)
-
Two-rate policer with three color marker (2R3C) (color-blind mode)
Table 13-8
summarizes the QoS policing limitations for the Cisco ASR 903 Series Router.
Table 13-8 Policing QoS Limitations
|
|
|
|
|
|
|
|
|
|
|
|
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Rate Limiting
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
One rate
|
3.5
|
3.6
|
3.5
|
3.6
|
3.6
|
3.6
|
3.9
|
3.9
|
3.9
|
3.9
|
3.5
|
3.6
|
3.9
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
One rate and two marking
|
3.5
|
3.6
|
3.5
|
3.6
|
3.6
|
3.6
|
3.9
|
3.9
|
3.9
|
3.9
|
3.5
|
3.6
|
3.9
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
Two rates and two Marking
|
3.5
|
X
|
3.5
|
X
|
3.6
|
X
|
3.9
|
X
|
3.9
|
X
|
3.5
|
X
|
3.9
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
Two rates and three actions
|
3.5
|
X
|
3.5
|
X
|
3.6
|
X
|
3.9
|
X
|
3.9
|
X
|
3.5
|
X
|
3.9
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
Color Aware policing
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Commands
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
bandwidth
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
X
|
X
|
X
|
X
|
3.6
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
bandwidth remaining ratio
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
X
|
X
|
X
|
X
|
3.6
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
bandwidth percent
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
X
|
X
|
X
|
X
|
3.6
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
police
(percent)
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
police
(policy map)
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
police
(policy map class)
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
police
(two rates)
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
priority
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
drop
|
3.5
|
X
|
3.5
|
X
|
3.5.1
|
X
|
3.9
|
X
|
3.9
|
X
|
3.5
|
X
|
3.9
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
set-qos-transmit
|
3.5
|
X
|
3.5
|
X
|
3.5.1
|
X
|
3.9
|
X
|
3.9
|
X
|
3.5
|
X
|
3.9
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
set-cos-transmit
|
3.5
|
X
|
3.5
|
X
|
3.5.1
|
X
|
3.9
|
X
|
3.9
|
X
|
3.5
|
X
|
3.9
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
set-dscp-transmit
|
3.5
|
X
|
3.5
|
X
|
3.5.1
|
X
|
3.9
|
X
|
3.9
|
X
|
3.5
|
X
|
3.9
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
set-prec-transmit
|
3.5
|
X
|
3.5
|
X
|
3.5.1
|
X
|
3.9
|
X
|
3.9
|
X
|
3.5
|
X
|
3.9
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
set-discard-class-transmit
|
3.5
|
X
|
3.5
|
X
|
3.5.1
|
X
|
3.9
|
X
|
3.9
|
X
|
3.5
|
X
|
3.9
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
set-mpls-experimental-topmost-transmit
|
3.5
|
3.6
|
3.5
|
3.6
|
3.5.1
|
3.6
|
3.9
|
3.9
|
3.9
|
3.9
|
3.5
|
3.6
|
3.9
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
set-mpls-experimental-imposition-transmit
|
3.5
|
X
|
3.5
|
X
|
3.5.1
|
X
|
3.9
|
X
|
3.9
|
X
|
3.5
|
X
|
3.9
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
transmit
|
3.5
|
X
|
3.5
|
X
|
3.5.1
|
X
|
3.9
|
X
|
3.9
|
X
|
3.5
|
X
|
3.9
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
Supported Commands
The Cisco ASR 903 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 903 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.
Supported Actions
The Cisco ASR 903 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
Configuring Percentage Policing
The router calculates percentage policing rates based on the maximum port PIR rate. The PIR rate is determined as follows:
-
Default—Port line rate
-
Speed command applied—Operational rate
-
Port shaping applied to port—Shaped rate
Ingress Policing Limitations
The following limitations apply to QoS policing on the Cisco ASR 903 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.
Egress Policing Limitations
IOS XE Release 3.6 introduces support for egress policing. The Cisco ASR 903 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:
police cir 200000 bc 8000 bandwidth remaining percent 40 bandwidth remaining percent 50
-
The
priority
and
police
commands must not be applied to a class containing the
priority
command
-
The
priority
and
police
commands must be applied on a single class.
The following is a sample supported configuration:
police cir 200000 bc 8000
-
Egress MLPPP interfaces support a single-rate policer with two color marker (1R2C) (color-blind mode) at the LLQ level.
-
Policing is supported on Etherchannel interfaces and individual member links; however, you cannot configure marking on both interface levels at once.
-
Egress port-level policing is supported with ingress EFP policy on the router.
The following is a sample supported configuration:
Policy-map ingress_policy interface GigabitEthernet0/4/0 service instance 100 ethernet service-policy input ingress_policy >>>> Ingress policy in EFP interface GigabitEthernet0/4/0 service-policy output egress_policy >>>>>Egress policy on Port service instance 100 ethernet
-
Release 3.7(1) introduces support for QoS features on egress policing 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
Effective 3.10 and later,
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
Starting Cisco IOS XE Release 3.6 and later, policing is supported at the egress on non priority queues.
Sample configuration:
Router#sh policy-map testp police cir 20000000 bc 625000 police cir 20000000 bc 625000 police cir 50000000 bc 1562500
Shaping
Traffic shaping allows you to control the speed of traffic that is leaving an interface in order to match the flow of traffic to the speed of the receiving interface. Percentage-based policing allows you to configure traffic shaping based on a percentage of the available bandwidth of an interface.Configuring traffic shaping in this manner enables you to use the same policy map for multiple interfaces with differing amounts of bandwidth.
This section describes the shaping limitations and configuration guidelines for the Cisco ASR 903 Series Router.
Table 13-9
summarizes the QoS shaping limitations for the Cisco ASR 903 Series Router.; an X indicates support.
Table 13-9 Shaping Limitations by Interface
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Class-Based
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Distributed
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Frame
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Generic
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
adaptive
|
|
X
|
|
|
|
X
|
|
X
|
|
|
X
|
|
|
|
|
|
|
|
|
|
|
|
|
|
average
|
|
X
|
|
|
|
X
|
|
X
|
|
|
X
|
|
|
|
|
|
|
|
|
|
|
X
|
|
|
fecn-adapt
|
|
X
|
|
|
|
X
|
|
X
|
|
|
X
|
|
|
|
|
|
|
|
|
|
|
|
|
|
max-buffers
|
|
X
|
|
|
|
X
|
|
X
|
|
|
X
|
|
|
|
|
|
|
|
|
|
|
|
|
|
peak
|
|
X
|
|
|
|
X
|
|
X
|
|
|
X
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Additional Shaping Limitations
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.
Configuring Egress Shaping on EFP Interfaces
Configuring an EFP port shaper allows you to shape all EFPs on a port using a port policy with a class-default shaper configuration, as in the following partial sample configuration:
service-policy child-policy
The following configuration guidelines apply when configuring an EFP port shaping policy:
-
When the configuration specifies a shaper rate using a percentage, the router calculates the value based on the operational speed of a port. The operational speed of a port can be the line rate of the port or the speed specified by the
speed
command.
-
The rates for
bandwidth percent
and
police percent
commands configured under a port-shaper are based on the absolute rate of the port-shaper policy.
-
You can combine a port shaper policy (a flat shaper policy with no user-defined classes) with an egress EFP QoS shaping policy.
-
Configure the port shaper policy before configuring other egress QoS policies on EFP interfaces; when removing EFP QoS configurations, remove other egress EFP QoS policies before removing the port shaper policy.
Congestion Management
Congestion management features allow you to control congestion by determining the order in which packets are sent out an interface based on priorities assigned to those packets. Congestion management entails the creation of queues, assignment of packets to those queues based on the classification of the packet, and scheduling of the packets in a queue for transmission.
This section describes the classification limitations and configuration guidelines for the Cisco ASR 903 Series Router.
Table 13-10
summarizes the QoS congestion management and queuing limitations for the Cisco ASR 903 Series Router.
Table 13-10 Congestion Management QoS Limitations
|
|
|
|
|
|
|
|
|
|
|
|
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
CBWFQ
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
X
|
X
|
X
|
X
|
3.6
|
X
|
3.9
|
X
|
3.8
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
D-CBWFQ
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
IP RTP priority
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
Frame Relay IP RTP
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
Frame Relay PVC Interface Priority Queuing
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
LLQ
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
X
|
X
|
X
|
X
|
3.6
|
X
|
3.9
|
X
|
3.8
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
D-LLQ
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
LLQ-FR
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Custom queuing
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Priority Queuing
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
bandwidth
(kbps)
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
X
|
X
|
X
|
X
|
3.6
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
bandwidth percent
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
X
|
X
|
X
|
X
|
3.6
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
bandwidth remaining percent
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
X
|
X
|
X
|
X
|
3.6
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
bandwidth remaining ratio
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
X
|
X
|
X
|
X
|
3.6
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
compression header ip
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
drop
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
fair-queue
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
priority
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
X
|
X
|
X
|
X
|
3.6
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
priority
(kbps)
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
priority
(without queue-limit)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
priority percent
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
queue-limit
(cells)
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
X
|
X
|
X
|
X
|
3.6
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
queue-limit
(packets)
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
Ingress Queuing Limitations
The Cisco ASR 903 Series Router does not support queuing on ingress interfaces.
Egress Queuing Limitations
The Cisco ASR 903 Series Router supports tail drop queuing on egress interfaces using the
queue-limit
command. The following limitations apply to egress queuing:
-
If you configure a queue 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.
-
Release 3.8 extends the maximum
bytes
value of the
queue-limit
number-of-packets
[
bytes
|
ms
|
packets
] command. The previous maximum value was 491520 bytes; the new value is 2 MB.
-
Release 3.8 enhances the
show policy-map interface
command to display the default queue-limit.
-
Release 3.8 introduces support for the
queue-limit
percent
command.
Support for Queuing Features on MLPPP Interfaces
Release 3.7(1) introduces support for QoS features on egress MLPPP interfaces. The following queuing features are supported on egress MLPPP interfaces:
-
Tail drop queuing using the
queue-limit
command
MLPPP egress queuing is supported only on the 3rd level classes (bottom-most).
Additional Queuing Limitations
The following additional queuing usage guidelines apply in Release 3.9:
-
If you configure a queue 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.
-
The maximum
bytes
value of the
queue-limit
number-of-packets
[
bytes
|
ms
|
packets
] command is 491520 bytes.
-
MLPPP egress queuing is supported only on the 3rd level classes (bottom-most).
-
3-level policies are not supported on MLPPP interfaces.
-
The Cisco ASR 903 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 2nd and 3rd level classes.
-
Class-based shaping is supported at all levels.
-
Class-based excess bandwidth scheduling is supported on 2nd and 3rd level QoS classes.
-
MLPPP egress queuing is supported only on the 3rd level classes (bottom-most).
Congestion Avoidance
Congestion avoidance techniques monitor network traffic loads in an effort to anticipate and avoid congestion at common network bottlenecks. Congestion avoidance is achieved through packet dropping. Among the more commonly used congestion avoidance mechanisms is Random Early Detection (RED), which is optimum for high-speed transit networks. Cisco IOS QoS includes an implementation of RED that, when configured, controls when the router drops packets. If you do not configure Weighted Random Early Detection (WRED), the router uses the cruder default packet drop mechanism called tail drop.
Table 13-11
summarizes the QoS congestion avoidance limitations for the Cisco ASR 903 Series Router.
Table 13-11 Congestion Avoidance QoS Limitations
|
|
|
|
|
|
|
|
|
|
|
|
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Ingress
|
Egress
|
Tail Drop (default)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
RED
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
random-detect
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
X
|
X
|
X
|
X
|
3.6
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
WRED
|
not supported on ingress ifcs
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
random-detect discard-class
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
random-detect discard-class-based
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
X
|
X
|
X
|
X
|
3.6
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
random-detect exponential-weighting-constant
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
X
|
X
|
X
|
X
|
3.6
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
|
fair-queue
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
precedence
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
random-detect cos-based
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
X
|
X
|
X
|
X
|
3.6
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
random-detect dscp-based
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
X
|
X
|
X
|
X
|
3.6
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
random-detect precedence-based
|
X
|
3.6
|
X
|
3.6
|
X
|
3.6
|
X
|
X
|
X
|
X
|
X
|
3.6
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.9
|
X
|
3.7.1
|
|
shape
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
D-WRED
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Flow-based WRED
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Diffserv WRED
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Configuring Congestion Avoidance
The following sections describe the supported congestion avoidance features on the Cisco ASR 903 Series Router:
Supported Commands
The Cisco ASR 903 Series Router supports the following commands for WRED:
-
random-detect cos-based
—Outer CoS
-
random-detect dscp-based
— IPv4 DSCP
-
random-detect precedence-based
— IPv4 Precedence bit
Supported Interfaces
WRED is supported at the PHB level but not on logical or physical interfaces. You can apply WRED policies on the following interface types:
-
Main Layer 3 interface
-
Port-channel Layer 3 member-links
-
Service instances
-
Trunk EFPs
Verifying the Configuration
You can use the
show policy-map interface
command to display the number of WRED drops and tail drops.
For more information about configuring congestion avoidance, see the following documents:
Ingress Congestion Avoidance Limitations
WRED is not supported on ingress interfaces.
Egress Congestion Avoidance Limitations
The following limitations apply when configuring congestion avoidance on the Cisco ASR 903 Series Router:
-
WRED is only supported on egress interfaces.
-
You must apply WRED within a policy map.
-
WRED is not supported in priority queues.
-
You can configure a maximum of 2 WRED curves per class.
-
You can configure WRED with either the
shape
or the
fair-queue
(CBWFQ) commands.
-
The default value for
exponential-weighting-constant
is 9.
-
The default value for
mark-probability
is 10.
-
You can specify the minimum-threshold and maximum-threshold in terms of bytes or microseconds. Setting threshold values in terms of packets is not supported.
Egress Congestion Avoidance on MLPPP Interfaces
Release 3.7(1) introduces support for the following egress congestion features on MLPPP interfaces:
-
RED queuing using the
random-detect
command
-
WRED queuing using the
random-detect
command. You can apply WRED to:
–
DSCP
–
Precedence
–
Qos-group
–
Discard-class
MLPPP egress queuing is supported only on the 3rd level classes (bottom-most).
-
Class-based Weighted Fair Queuing (CBWFQ) using the
bandwidth
and
bandwidth percent
commands. CBWFQ is supported on 2nd and 3rd level classes.
-
Class-based Shaping using the
shape average
and
shape average percent
commands. Class-based shaping is supported at all levels.
-
Class-based excess bandwidth scheduling using the
bandwidth remaining percent
and
bandwidth remaining ratio
commands. Class-based excess bandwidth scheduling is supported on 2nd and 3rd level QoS classes.
Additional Congestion Avoidance Limitations
-
The following additional congestion avoidance usage guidelines apply in Release 3.9:
-
Queuing feature to support WRED in a class such as shape or bandwidth are supported
-
You must apply WRED within a policy map.
-
WRED is not supported in priority queues.
-
You can configure a maximum of 2 WRED curves per class.
-
You can configure WRED with either the
shape
or the
fair-queue
(CBWFQ) commands.
-
The default value for
exponential-weighting-constant
is 9.
-
The default value for
mark-probability
is 10.
-
You can specify the minimum-threshold and maximum-threshold in terms of bytes or microseconds. Setting threshold values in terms of packets is not supported.
-
Policies using Class-based Weighted Fair Queuing (CBWFQ) and WRED are supported only on individual member links of an etherchannel. Applying a CBWFQ policy directly on an etherchannel interface is not supported.
-
WRED is not supported in the class-default class if there are no other user-defined classes in the policy-map.
-
Aggregate-WRED is not supported. However, multiple random-detect statements with the same curve are supported in the same class.
Verifying the Configuration
You can use the
show policy-map interface
command to display the number of WRED drops and tail drops.
For more information about configuring congestion avoidance, see the following documents:
Scheduling
This section describes the scheduling limitations and configuration guidelines for the Cisco ASR 903 Series Router.
Ingress Scheduling Limitations
The Cisco ASR 903 Series Router does not support scheduling on ingress interfaces.
Egress Scheduling Limitations
-
If you configure a CIR, PIR, or EIR rate 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 only configure one
priority
value on each parent class applied to a QoS class or logical interface.
-
You can only configure priority on one class in a QoS policy.
-
You can not configure
priority
value and a policer in the same class.
The following limitations apply when configuring a 3-level scheduling policy on an egress interface configured as an EFP:
-
Only two of the three levels can contain scheduling actions such as
bandwidth
,
shape
, or
priority
.
-
One of the levels containing scheduling actions must be the class (bottom) level.
Egress Scheduling on MLPPP Interfaces
Release 3.7(1) introduces support for QoS features on egress MLPPP interfaces including scheduling. The following scheduling features are supported:
-
Strict priority using the
priority
command; strict priority is supported on 2nd and 3rd level classes.
-
Multi-level priority using the
priority level
command. You can configure two priority levels; the feature is supported on 3rd level classes.
SThe following limitations apply when configuring a 3-level scheduling policy on an egress interface configured as an EFP:
-
Only two of the three levels can contain scheduling actions such as
bandwidth
,
shape
, or
priority
.
-
QoS policies using the
priority
command are supported only on individual member links of an etherchannel.