Configuring a Queuing Policy-map
When QoS feature is enabled, all ports in the Qumran device will be applied with a default policy-map of queuing type. The default policy-map is created with the name “default-out-policy” which is reserved and modifying parameters in this policy-map will reflect on all ports which don't have customized queuing policy-map. Customized queuing policy-maps can be created and bound to ports to treat ports differently from default configuration.
Creating a user-defined queuing policy-map
Qumran supports creation of customized policy-map in which new four queues can be configured for each services. If any priority queue class-map is not configured, default behavior among these new queues is weighted fair queuing. New queues and port default queues will also have weighted fair queuing between them as default behavior.
The following command is used to create a class-map:
(no|) class-map type queuing NAME
These class-maps will be matching some services for which new queues will be created. These classes can be empty classes in order to create hierarchy and club services in a hierarchy.
Matching criteria of a queuing class-map
Queuing class-map can have four matching criteria:
1. queue: queue selection
CLI: (no|) match queue <0-7>
Note: match queue range 0-7 is valid only for port queues classification.
For service queues, valid range is 0-3.
2. service-template: service related classification
CLI: match service-template NAME
no match service-template
3. vlan: list VLAN ID
CLI: match vlan <1-4094>
no match vlan
4. interface: interface name
CLI: match interface IFNAME
no match interface
Note: The interface name can be either VLAN interface or subinterface.
The following is the command to create a customized policy-map:
policy-map type queuing NAME
no policy-map NAME
Once the policy-map is configured, the queuing class-maps can be configured with following command:
class type queuing NAME
no class type queuing NAME
Binding/Unbinding a QoS Policy-map on an Interface
Customized queuing policy-maps take affect only when the configuration is bound to a port.
Queuing policy-maps can be bound/unbound to the out-port with following command:
(no|) service-policy type queuing output NAME
Where “NAME” represents the name of the queuing policy-map.
Binding/Unbinding a QoS Policy-map as a Child Service Policy
A policy-map can be configured as a child policy in order to create a hierarchy. Queuing policy-maps can be bound to a policy-map as a child policy with following command:
(no|) service-policy NAME
Where NAME represents the name of the queuing policy-map.
Note: Child policy needs to be attached to a parent policy-map inside a class.
For example:
class-map type queuing data
match queue 0
!
class-map type queuing service1
match service-template ETH-2016
!
class-map type queuing service2
match service-template ETH-2017
!
class-map type queuing signal
match queue 3
!
class-map type queuing voice
match queue 1
!
policy-map type queuing configPolicy1
class type queuing class-default-q
exit
class type queuing data
exit
class type queuing signal
exit
class type queuing voice
exit
!
policy-map type queuing customer1
class type queuing service1
service-policy configPolicy1
class type queuing class-default-q
exit
!
interface xe11
service-policy type queuing output customer1
Here, “customer1” is L0-level policy-map and “configPolicy1” is L1-level policy-map. Policy-map “customer1” is having a class-default-q which is having port default queues. Policy-map “configPolicy1” is having class-default-q which is representing remaining queue i.e. queue 2 as queue3 is mapped to class signal, queue1 is mapped to class voice and queue0 is mapped to class data.
WRED and taildrop configuration is applicable only in the class in which queues are mapped. If in a policy-map having a class matching the service is not having any child policy-map, then all the new queues will be mapped to the same class and WRED and taildrop configuration is valid for this class. If the class matching service is having child policy matching queues, then WRED and taildrop is valid for the child service-policy only.
Policy-map having classes matching the queues can only be configured as a child service-policy inside a class matching service or at L0 class-default-q. It cannot be attached on an interface directly
If the user-defined child service policy is applied matching queues in L0 class-default-q which are mapping port queues, supported match queue range is 0-7.
For service queues, valid range is 0-3 as only 4 new queues are created for each service.Since the queues created are 4, 8 traffic classes are mapped implicitly to 4 queues as shown in
Table 18-11.
Table 18-11: Traffic class to queue mapping
Traffic class | Queue |
|---|
0 | 0 |
1, 2, 3 | 1 |
4, 5 | 2 |
6, 7 | 3 |
Ingress mapping profile like cos-to-queue, dscp-to-queue, and exp-to-queue actually maps packet fields (cos/dscp/exp) to 8 traffic classes. These traffic classes are mapped one-to-one when we have 8 queues in case of physical port and to 4 queues in case of services as shown above.
Until the child service-policy is applied on L0 class-default-q (port queues), port queues will follow default mapping profiles.
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.
The following section explains the basic configuration details involved to apply queue level treatment on the port.
Note: Please refer to MPLS configuration guide for service-template configurations.
(config)# class-map type queuing customer1
(config-cmap-que)# match service-template customer1Vlan
(config-cmap-que)#exit
(config)# class-map type queuing customer2
(config-cmap-que)# match service-template customer2Vlan
(config-cmap-que)#exit
(config)# class-map type queuing customer3
(config-cmap-que)# match service-template customer3Vlan
(config-cmap-que)#exit
(config)# class-map type queuing customer4
(config-cmap-que)# match service-template customer4Vlan
(config-cmap-que)#exit
(config)#class-map type queuing data
(config-cmap-que)# match queue 0
(config-cmap-que)# exit
(config)#class-map type queuing voice
(config-cmap-que)# match queue 1
(config-cmap-que)#exit
(config)# class-map type queuing signaling
(config-cmap-que)# match queue 3
(config-cmap-que)# exit
(config)#class-map type queuing area1
(config-cmap-que)# exit
(config)#class-map type queuing area2
(config-cmap-que)# exit
(config)#policy-map type queuing traffic_policy
(config-pmap-que)# class type queuing data
(config-pmap-c-que)# shape 10 mbps
(config-pmap-c-que)# exit
(config-pmap-que)# class type queuing voice
(config-pmap-c-que)# exit
(config-pmap-c-que)# shape 2 mbps
(config-pmap-que)# class type queuing signaling
(config-pmap-c-que)# exit
(config-pmap-c-que)# shape 1 mbps
(config-pmap-c-que)# exit
(config-pmap-que)#policy-map type queuing area1_policy
(config-pmap-que)# class type queuing customer1
(config-pmap-c-que)# shape 12 mbps
(config-pmap-c-que)# service-policy traffic_policy
(config-pmap-c-que)# exit
(config-pmap-que)# class type queuing customer2
(config-pmap-c-que)# shape 12 mbps
(config-pmap-c-que)# exit
(config-pmap-que)#policy-map type queuing area2_policy
(config-pmap-que)# class type queuing customer3
(config-pmap-c-que)# shape 12 mbps
(config-pmap-c-que)# service-policy traffic_policy
(config-pmap-c-que)# exit
(config-pmap-que)# class type queuing customer4
(config-pmap-c-que)# shape 12 mbps
(config-pmap-c-que)# exit
(config-pmap-que)#policy-map type queuing xe16_policy
(config-pmap-que)# class type queuing area1
(config-pmap-c-que)# shape 100 mbps
(config-pmap-c-que)# service-policy area1_policy
(config-pmap-c-que)# exit
(config-pmap-que)# class type queuing area2
(config-pmap-c-que)# shape 100 mbps
(config-pmap-c-que)# service-policy area2_policy
(config-pmap-c-que)# exit
(config-pmap-que)#interface xe16
(config-if)# service-policy type queuing output xe16_policy
(config-if)#exit
Displaying Policy-map Configuration
The following is an example of show policy-map interface command:
(config)#show policy-map interface xe16
Interface xe16
Type QoS statistics status : enabled
Service-policy (queuing) output: xe16_policy
Interface Bandwidth 1000000 kbps
-----------------------------------
Class-map (queuing): area1
shape 100 mbps
wfq-queue weight 1
Service-policy (queuing) output: area1_policy
-----------------------------------
Class-map (queuing): customer1
match service-template customer1Vlan
shape 12 mbps
wfq-queue weight 1
Service-policy (queuing) output: traffic_policy
-----------------------------------
Class-map (queuing): class-default-q
shape 12000 kbps (inherited)
wfq-queue weight 1
queue-limit 15040 bytes/10 ms (default)
match queue 1
Class-map (queuing): data
shape 10 mbps
wfq-queue weight 1
queue-limit 12544 bytes/10 ms (default)
match queue 0
Output
Total : 66681 packets, 66681000 bytes
Green : 66681 packets, 66681000 bytes
Yellow : 0 packets, 0 bytes
Class-map (queuing): signaling
shape 1 mbps
wfq-queue weight 1
queue-limit 9472 bytes/76 ms (default)
match queue 3
Class-map (queuing): voice
shape 2 mbps
wfq-queue weight 1
queue-limit 9472 bytes/38 ms (default)
match queue 2
Class-map (queuing): customer2
match service-template customer2Vlan
shape 12 mbps
wfq-queue weight 1
queue-limit 15040 bytes/10 ms (default)
match queue 0
match queue 1
match queue 2
match queue 3
Class-map (queuing): area2
shape 100 mbps
wfq-queue weight 1
Service-policy (queuing) output: area2_policy
-----------------------------------
Class-map (queuing): customer3
match service-template customer3Vlan
shape 12 mbps
wfq-queue weight 1
queue-limit 15040 bytes/10 ms (default)
match queue 0
match queue 1
match queue 2
match queue 3
Class-map (queuing): customer4
match service-template customer4Vlan
shape 12 mbps
wfq-queue weight 1
Service-policy (queuing) output: traffic_policy
-----------------------------------
Class-map (queuing): class-default-q
shape 12000 kbps (inherited)
wfq-queue weight 1
queue-limit 15040 bytes/10 ms (default)
match queue 1
Class-map (queuing): data
shape 10 mbps
wfq-queue weight 1
queue-limit 12544 bytes/10 ms (default)
match queue 0
Class-map (queuing): signaling
shape 1 mbps
wfq-queue weight 1
queue-limit 9472 bytes/76 ms (default)
match queue 3
Class-map (queuing): voice
shape 2 mbps
wfq-queue weight 1
queue-limit 9472 bytes/38 ms (default)
match queue 2
Class-map (queuing): class-default-q
shape 1000000 kbps (inherited)
wfq-queue weight 1
queue-limit 1253376 bytes/10 ms (default)
match queue 0
match queue 1
match queue 2
match queue 3
match queue 4
match queue 5
match queue 6
match queue 7
QoS Configuration on User-defined Policy-map
All the queuing configurations such as WRED, taildrop, WFQ, shaping are same for user-defined policy as they are in default-policy-map except the priority queue configuration.
In default-policy-map, max priority supported is 8 i.e. 0-7, while in user-defined policy-map, max priority level is 4, i.e.0-3.
Priority class will always have priority over weighted class in default policy. But in user-defined policy, when all the 4 priorities are assigned with weighted classes, priority 0 class will be in fair queuing with the total weighted queues. If 3 or less than 3 priority class are present with weighted classes, than priority class will have priority over weighted class.
For example:
(config-pmap-que)#policy-map type queuing area2_policy
(config-pmap-que)# class type queuing customer1
(config-pmap-c-que)# priority level 0
(config-pmap-c-que)# service-policy traffic_policy
(config-pmap-que)# class type queuing customer2
(config-pmap-c-que)# priority level 1
(config-pmap-c-que)# service-policy traffic_policy
(config-pmap-que)# class type queuing customer3
(config-pmap-c-que)# priority level 2
(config-pmap-c-que)# service-policy traffic_policy
(config-pmap-que)# class type queuing customer4
(config-pmap-c-que)# priority level 3
(config-pmap-c-que)# service-policy traffic_policy
(config-pmap-que)# class type queuing customer5
(config-pmap-c-que)# wfq-queue weight 1
(config-pmap-c-que)# service-policy traffic_policy
(config-pmap-que)# class type queuing customer6
(config-pmap-c-que)# wfq-queue weight 2
(config-pmap-c-que)# service-policy traffic_policy
In this case, customer4 will have the highest priority, while 50% of the remaining bandwidth after distributing among priority classes will be used by Customer1, and the remaining 50% will be shared by Customer5 and Customer6 (FQ between priority 0 and weighted class).
If there are only three priority classes, for example:
(config-pmap-que)#policy-map type queuing area2_policy
(config-pmap-que)# class type queuing customer1
(config-pmap-c-que)# priority level 0
(config-pmap-c-que)# service-policy traffic_policy
(config-pmap-que)# class type queuing customer2
(config-pmap-c-que)# priority level 1
(config-pmap-c-que)# service-policy traffic_policy
(config-pmap-que)# class type queuing customer3
(config-pmap-c-que)# priority level 2
(config-pmap-c-que)# service-policy traffic_policy
(config-pmap-que)# class type queuing customer4
(config-pmap-c-que)# wfq-queue weight 1
(config-pmap-c-que)# service-policy traffic_policy
(config-pmap-que)# class type queuing customer5
(config-pmap-c-que)# wfq-queue weight 2
(config-pmap-c-que)# service-policy traffic_policy
Here, Customer3 has the highest priority. Customer1 has priority 0 and will have priority over Custimer4 and Customer5.