Configuring a QoS Policy-map
The following section explains the configuration of basic infrastructure to apply QoS treatment on the ingress interface.
Ingress QoS treatment can be achieved by two types of configuration.
• Policy-map configuration
• Profile mapping configuration
This section explains policy-map configuration method. QoS feature must be enabled to configure policy-maps.
This infrastructure contains two entities - class-map and policy-map. Class-map holds the match criteria and class-maps can be bound to policy-map to configure QoS treatment for the matching traffic.
Creating a QoS class-map
A Class-map contains the matching criteria for the traffic. Class-maps with no match criteria will match all the data traffic.
Class-maps support the following match criteria: vlan, inner vlan, cos, inner cos, dscp, precedence, layer4 tcp/udp port, exp, Ether-type, or ACL.
Class-map can be of two types, match-any or match-all type. By default class-map is of match-all type. For match-all class-maps, only the traffic that qualifies all match criteria configured in class-map will take QoS action. For match-any class-maps, traffic qualifying any one of the configured match criteria will take QoS action.
Class-maps can be created once the QoS feature is enabled.
Use the following command to create a class-map:
class-map (type qos|) (match-any|match-all|) NAME
This command will create a class-map entity that can be configured with one or more match criteria.
Class-map can be of two types:
1. Empty class-map: Class-map with no matching criteria is called empty class. Empty class will classify all the traffic coming on the port on which the policy containing empty class will be applied.
2. Non-empty class-map: Class-map with matching criteria is called non-empty class. It will classify the traffic according to the given matching criteria.
User can always add/delete/modify the matching criteria of the class-map. User is not allowed to make a non-empty class as empty class if the class is attached to a policy-map. User has to remove the class from policy-map to modify the matching criteria. User is allowed to add matching criteria to an empty class attached to a policy-map.
Use the following commands to add match criteria:
match vlan WORD
match vlan inner WORD
match cos WORD
match cos inner WORD
match dscp [WORD | af11 | af12 | af13 | af21 | af22 | af23 | af31 | af32 | af33 | af41 | af42 | af43 | cs1 | cs2 | cs3 | cs4 | cs5 | cs6 | cs7 | default | ef]
match precedence [WORD | critical | flash | flashoverride | immediate | internet | network | priority | routine]
match mpls experimental topmost WORD
match ip rtp WORD
match ethertype WORD
match layer4 (tcp|udp|any) (source-port|destination-port) WORD
match access-group NAME
An example of creating a class-map with match VLAN configuration is shown below:
(config)#qos enable
(config)#class-map n1-class-10
(config-cmap-qos)#match vlan 10
(config-cmap-qos)#exit
Notice that data traffic with an outer VLAN value of 10 will be matched for QoS treatment.
Creating a QoS policy-map
Policy-maps can be configured with multiple class-maps with each class-map configured with policing or other supported actions.
Use the following command to create a policy-map:
policy-map (type qos|) NAME
This command will create a policy-map entity in which one or more class-map entities can be bound.
Binding a class-map to a policy-map
In order to apply QoS treatment to traffic that matches the criteria configured in a class-map, the class-map must be bound to the policy-map entity, then QoS treatment actions can be configured on that node.
Use the following command to bind a class-map to a policy-map:
class (type qos|) NAME
This command will create a class node for class-map unique to the policy-map. This class node can then be configured with QoS treatment actions.
There are two types of actions, police and set.
• Police actions can be used to control the rate of traffic flow and is explained in the next section.
• Set actions can be used to set internal priority or packet priority.
Use the following commands to add set actions:
set (dscp (<0-63>| af11| af12| af13| af21| af22| af23| af31| af32| af33| af41| af42| af43| cs1| cs2| cs3| cs4| cs5| cs6| cs7| default| ef ))
set cos <0-7>
set queue <0-7>
An example of creating a policy-map and binding a class-map to it with the set action is shown below:
(config)#policy-map n1-police-10
(config-pmap-qos)#class n1-class-10
(config-pmap-c-qos)#set cos 3
(config-pmap-c-qos)#exit
(config-pmap-qos)#exit
In case of multiple class-maps, implicit priority of class-maps will be decided based on the following the type of class-map as shown:
match-all > match-any > default class-map
If all class-maps are of type match-all, the class-map with the higher number match criteria will have higher priority. If the class-maps have the same number of match criteria, then the behavior can be unpredictable if traffic matches both class-map criteria. In such cases, class-maps can be explicitly prioritized using the priority command.
priority <1-1000>
An example of configuring priority per class-map is shown below:
(config)#policy-map p1
(config-pmap-qos)#class c1
(config-pmap-c-qos)#priority 2
A higher the value means higher priority, and user defined priority is always higher prioritized over implicit priority.
If the match criteria is ACL, different hardware resources will be used. Therefore, configuring match ACL class-map and other non-ACL match classes in a single policy is not allowed because if a policy-map with two class-maps (one with ACL match criteria and one with some other match criteria) are allowed (configured in different hardware resource groups), traffic matching both match criteria can take actions of both class-maps if the actions are not conflicting but since statistics are common and can be read once (hardware limitation), statistics will be displayed for one matching criteria only.
Assumptions and limitations
DSCP and precedence matches are mutually exclusive and can’t be part of same class-map.
Each rule of an ACL is matched independently, so ACL matches are allowed to be configured only on match-any type class-map. If the configured matches on class-maps bound to and interface via policy-map are not mutually exclusive, there are chances of multiple class-maps matching a single stream of traffic. In this case, implicit priority of the class-map based on number of rules decides which class-map the traffic will hit. When implicit priority is the same for class-maps, their behavior will be random, and the user is expected to configure class priority in such a case.
Binding a QoS policy-map
Policy-map configuration is effective only when it is bound to a supported ingress interface. Use the following command to bind a policy-map to an interface:
service-policy type qos input NAME
Notice that NAME represents the name of the qos policy-map.
Note: A QoS TCAM group must be enabled before binding a policy-map to an interface. See the hardware-profile filter and show hardware-profile filters commands in the System Management Guide for more about hardware filter groups.
An example of binding a policy-map to an interface is shown below:
(config)#hardware-profile filter qos-ext enable
(config)#interface xe1
(config-if)#service-policy type qos input n1-police-10
(config-if)#exit
In this example, traffic with VLAN value 10 received on interface xe1 is matched by class-map configuration, and traffic will be set with internal and packet priority (cos) 3 (as shown in the previous example).
Note: For an ACL match configuration, ingress-l2-ext/ingress-ipv4-ext/ingress-ipv6 TCAM group must be enabled based on ACL type.
When the class-map is configured with match ACL, only the police action is supported – set actions are not supported.