Subinterface Queuing
In Qumran devices, every physical port has default eight priority queues and subinterface has default 4 priority queues when service-queue profile1 is active and 8 queues (distributed between 4 priorities) when service-queue profile2 is active. Physical port queues are created during initialization while the subinterface queues will be created/deleted when encap is set/unset respectively on subinterface. Whenever QoS feature is enabled, all priority queues of the physical ports/subinterafce will be configured with certain default egress queuing parameters.
In order to customize the treatment on the priority queues, queuing policy-map infrastructure need to be used.
Configuring Subinterface Queues
Subinterface queues are nothing different then the physical ports queues expect that number of queues assigned to a subinterface can be set via profile and by-default profile1 is set which sets 4 queues to be created for services.
User can configure the service-queue profile via cli "hardware-profile service-queue (profile1 | profile2)".
Profile1 supports 4 new queues creation for services,which is also a default profile. Profile2 supports 8 new queues creation for services.
These queues will be created or deleted when the encap is set or unset on a subinterface respectively. Like and other interface, subinterface has a default ingress egress mapping profile. i.e. dscp-to-queue and dscp-color-to-dscp respectively. Subinterface has default queuing-policy in order to support QoS treatment on the queues.
Mapping profiles (dscp-to-queue and dscp-color-to-dscp) maps packets dscp to/from 8 traffic classes. When the hardware-queues created are 4, 8 traffic classes will be mapped to these 4 hardware-queues implicitly as shown in
Table 21-13:
Table 21-13: Traffic class to queue mapping
Traffic class | Queue |
|---|
0 | 0 |
1, 2, 3 | 1 |
4, 5 | 2 |
6-7 | 3 |
This map can be checked via this command:
show queue remapping
Output:
Port queue remapping:
+------------+-----------------------+
| Queue/tc | hardware-queue |
+------------+-----------------------+
| 0 | 0 |
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
| 4 | 4 |
| 5 | 5 |
| 6 | 6 |
| 7 | 7 |
+------------+-----------------------+
Service queue remapping:
+------------+-----------------------+
| Queue/tc | hardware-queue |
+------------+-----------------------+
| 0 | 0 |
| 1 | 1 |
| 2 | 1 |
| 3 | 1 |
| 4 | 2 |
| 5 | 2 |
| 6 | 3 |
| 7 | 3 |
+------------+-----------------------+
When the number of profile 2 is active, number of new queues created will be 8 and the traffic class to hardware queues map will be one to one.
This map can be checked via this command:
show queue remapping
Output:
Port queue remapping:
+------------+-----------------------+
| Queue/tc | hardware-queue |
+------------+-----------------------+
| 0 | 0 |
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
| 4 | 4 |
| 5 | 5 |
| 6 | 6 |
| 7 | 7 |
+------------+-----------------------+
Service queue remapping:
+------------+-----------------------+
| Queue/tc | hardware-queue |
+------------+-----------------------+
| 0 | 0 |
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
| 4 | 4 |
| 5 | 5 |
| 6 | 6 |
| 7 | 7 |
+------------+-----------------------+
Configuring Default Queuing Policy-Map
When the QoS feature is enabled, all subinterfaces is supplied with a default policy-map of queuing type. The default policy-map is created with the name "default-subif-out-policy" which is reserved and modifying parameters in this policy-map is reflected on all subinterfaces that do not have customized queuing policy-maps. Customized queuing policy-maps can be created and bound to subinterface to treat subinterface differently from the default configuration.
Default queuing-policy can be accessed via following cli:
policy-map type queuing default subif-default-out-policy
Classes mapped to default queues can be accessed via the following commands.
In case of profile1:
class type queuing default (q0|q1|q2|q3)
In case of profile2:
class type queuing default (q0|q1|q2|q3|q4|q5|q6|q7)
User can configure all the queue parameters like shaping, scheduling, wred, taildrop same as on port. Show commands to verify the config and stats are same. For these configurations please check respective chapters as described in the document.
Displaying Policy-Map Configuration
With profile1 enabled, 4 priority level 0-3 will be configured by default on 4 queues as below:
• Queue 0: priority level 0
• Queue 1: priority level 1
• Queue 2: priority level 2
• Queue 3: priority level 3
(config)#show policy-map interface xe11.1
Interface xe11.1
Type Queuing policy-map : subif-default-out-policy
Class-map (queuing): q0
shape 1000000 kbps (inherited)
priority level 0
queue-limit 1253376 bytes/10 ms (default)
Class-map (queuing): q1
shape 1000000 kbps (inherited)
priority level 1
queue-limit 1253376 bytes/10 ms (default)
Output
Total : 4109055 packets, 279534060 bytes
Green : 4120123 packets, 280222424 bytes
Yellow : 0 packets, 0 bytes
Rate : 768646.000 kbps
Class-map (queuing): q2
shape 1000000 kbps (inherited)
priority level 2
queue-limit 1253376 bytes/10 ms (default)
Class-map (queuing): q3
shape 1000000 kbps (inherited)
priority level 3
queue-limit 1253376 bytes/10 ms (default)
With profile2 enabled, 4 priority level 0-3 will be configured by default on 8 queues as below:
• Queue 0: priority level 0
• Queue 1: priority level 1
• Queue 2: priority level 1
• Queue 3: priority level 1
• Queue 4: priority level 2
• Queue 5: priority level 2
• Queue 6: priority level 3
• Queue 7: priority level 3
(config)#show policy-map interface xe11.1
Interface xe11.1
Type Queuing policy-map : subif-default-out-policy
Class-map (queuing): q0
shape 1000000 kbps (inherited)
priority level 0
queue-limit 1253376 bytes/10 ms (default)
Class-map (queuing): q1
shape 1000000 kbps (inherited)
priority level 1
queue-limit 1253376 bytes/10 ms (default)
Class-map (queuing): q2
shape 1000000 kbps (inherited)
priority level 1
queue-limit 1253376 bytes/10 ms (default)
Class-map (queuing): q3
shape 1000000 kbps (inherited)
priority level 1
queue-limit 1253376 bytes/10 ms (default)
Class-map (queuing): q4
shape 1000000 kbps (inherited)
priority level 2
queue-limit 1253376 bytes/10 ms (default)
Class-map (queuing): q5
shape 1000000 kbps (inherited)
priority level 2
queue-limit 1253376 bytes/10 ms (default)
Class-map (queuing): q6
shape 1000000 kbps (inherited)
priority level 3
queue-limit 1253376 bytes/10 ms (default)
Class-map (queuing): q7
shape 1000000 kbps (inherited)
priority level 3
queue-limit 1253376 bytes/10 ms (default)
Creating a User-Defined Queuing Policy-Map
Qumran supports the creation of customized policy-map in which all 4 priority queues can be accessed. The following is the command to create a customized default policy-map:
(no|) policy-map type queuing NAME
Class-maps can be configured matching queues via following cli:
(no|) class-map type queuing NAME
Match queue/queues in the class-map via following cli :
(no|) match queue <0-7>
Note: The match queue range 0-7 is valid only for port queues classification when service-queue profile1 is active.
In case of profile1, service queues can be matched from 0-3 only.
For service queues/subinterface, the valid range is 0-3 with service-queue profile1 (4 queue per subinterface) and 0-7 with profile2 (8 queue per subinterface).
Once the policy-map and class-maps are configured, class-maps can be configured in the policy-map with the following command:
class type queuing NAME
Binding a User-Defined Queuing Policy-Map
Customized queuing policy-maps take affect only when the configuration is bound to an interface. Queuing policy-maps can be bound to the port with the following command:
service-policy type queuing output NAME
Where NAME represents the name of the queuing policy-map.
For example:
class-map type queuing data
match queue 0
!
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
!
interface xe11.1
service-policy type queuing output configPolicy1
Queue(s) which are not matched in any class in a user-defined policy-map, will be mapped to Class-default-q by default. This class-default-q is a by-default created class in a user-defined policy-map.
Displaying Policy-Map Configuration
(config-if)#do show policy-map in xe11.1
Interface xe11.1
Type Queuing policy-map : configPolicy1
Class-map (queuing): class-default-q
shape 1000000 kbps (inherited)
wfq-queue weight 1
queue-limit 1253376 bytes/10 ms (default)
match queue 2
Class-map (queuing): data
shape 1000000 kbps (inherited)
wfq-queue weight 1
queue-limit 1253376 bytes/10 ms (default)
match queue 0
Class-map (queuing): signal
shape 1000000 kbps (inherited)
wfq-queue weight 1
queue-limit 1253376 bytes/10 ms (default)
match queue 3
Class-map (queuing): voice
shape 1000000 kbps (inherited)
wfq-queue weight 1
queue-limit 1253376 bytes/10 ms (default)
match queue 1
Output
Total : 2321147 packets, 157909736 bytes
Green : 2337514 packets, 158952312 bytes
Yellow : 0 packets, 0 bytes
Rate : 773130.375 kbps
Displaying Policy-Map Rate Statistics
#show policy-map statistics type queuing rate mbps
+--------------------------------+--------------------+
| Class-map | Rate (in mbps) |
+--------------------------------+--------------------+
xe11.1
voice (q1) 773.104
#show policy-map statistics type queuing rate kbps
+--------------------------------+--------------------+
| Class-map | Rate (in kbps) |
+--------------------------------+--------------------+
xe11.1
voice (q1) 772400.062
#show policy-map statistics type queuing rate gbps
+--------------------------------+--------------------+
| Class-map | Rate (in gbps) |
+--------------------------------+--------------------+
xe11.1
voice (q1) 0.774
Displaying Interface Queue Counters
#show interface xe11.1 counters queue-stats
E - Egress, I - Ingress, Q-Size is in bytes
+-----------------+--------+----------+-----------+-----------------+--------------+
| Queue/Class-map | Q-Size | Tx pkts | Tx bytes | Dropped pkts | Dropped bytes|
+-----------------+--------+----------+-----------+-----------------+--------------+
q0 (E) 1253376 0 0 0 0
q1 (E) 1253376 1402466359 95367712820 0 0
q2 (E) 1253376 0 0 0 0
q3 (E) 1253376 0 0 0 0
Configuration Considerations
• Max 1 level of user defined hierarchy is supported on subinterface.
• Only match queue is allowed in the class in user-define queuing policy-map.
• In user-defined policy-map, all the classes will be in wfq scheduling manner.
• Class-default-q is a self-created class map as part a policy map. It cannot be created nor be destroyed. It will be displayed only when user access it. Executing command "no class-default-q", will un-configure all the configurations of class-default-q.
• User can configure all queuing parameters like weight, priority, queue-limit, wred and shape in a class inside policy.
• Valid priority range is 0-3 and match queue will be 0-3 in case of profile1 and 0-7 in case of profile2.
• Update is possible in the policy-map except the update of match criteria. Once the class with some match criteria is used in a policy-map, it cannot be updated.
• Subinterface queuing can be achieved via vlan-shaping (match interface) as well as via default queues.
• User-defined policy with match subinterface can only be attached on parent interface if subinterface is not attached to user-defined policy-map.
• If user-defined policy with match subinterface is attached on parent interface, sub-interface's default policy-map and port shaper will be removed implicitly from subinterface.
• If the user-defined-policy is applied on parent interface matching subinterface, traffic will go to the queues created via user-defined-service-policy and the queue stats for subinterface will only be displayed via service-policy. The subinterfaces not matched in the user-defined-service policy will go to their own queues only and not to class-default as happens in case of vlan shaping.
• On encap delete from subinterface, all the qos configuration will be removed implicitly from the subinterafce.
• If the port shaper is applied on parent port and on subinterface as well, minimum shape rate will take effect.
• Queue shape percent for subinterface queues, will be calculated as in following manner:
• Percentage will be calculated from the Effective Max speed, which will be calculated as follows:
max_speed = parent_ifp->speed.
If shaper is applied on parent port:
max_speed = parent_port_shaper
If shaper is applied on subinterface:
max_speed = subinterface_shaper
• When only subinterfaces are created with default or no queuing policy-map (when qos is disabled), max supported number of services in case of 4-queue profiles and 8-queue profile are as follows:
QMX : With 4 queues 8K services can be supported but total number of services will be half of the limit supported in case of 8 queues i.e. 4K services approx.
QAX : With 4 queues 4K services can be supported but total number of services will be half of the limit supported in case of 8 queues i.e. 2K services approx.
QUX : With 4 queues 2K services can be supported but total number of services will be half of the limit supported in case of 8 queues i.e. 1K services approx.
• In the case of user-defined queuing, each class represents 1 scheduler each, so it needs to be taken into consideration while configuring max number of services that can be supported with user-defined policy.
• Max number of scheduler and connectors are as follows:
QMX: BCM88370_B0
MAX_NUM_CL_SCHD_QMX 16384
MAX_NUM_FQ_SCHD_QMX 16128
QAX: BCM88470
MAX_NUM_CL_SCHD_QAX 7936
NUM_FQ_SCHD_QAX 7936
QUX: BCM88270
MAX_NUM_CL_SCHD_QUX 4096
MAX_NUM_FQ_SCHD_QUX 3840
Max number of Voqs that can be created will be derived from below formula:
MAX_NUM_VOQ_CONN_QMX (((64*1024)/NUM_CUSTOM_QUEUE)/2)
MAX_NUM_VOQ_CONN_QAX (((32*1024)/NUM_CUSTOM_QUEUE)/2)
MAX_NUM_VOQ_CONN_QUX (((16*1024)/NUM_CUSTOM_QUEUE)/2)
Where NUM_CUSTOM_QUEUE will be based upon service-queue profile set. i.e. 4 for profile1 and 8 for profile2.
Scheduler and queues used for physical interfaces are included in these.
• Subinterface queuing is not supported for lag subinterface and L2VPN/ELINE services on Q1 devices (QMX/QAX/QUX).
• When multiple traffic class is mapped to single service queue i.e tc 1,2,3 are mapped to queue1, traffic load shared between the traffic class inside the particular queue randomly.