White Papers

Enabling Strict-Priority Queueing
In strict-priority queuing, the system de-queues all packets from the assigned queue before servicing any other queues. You can
assign strict-priority to one unicast queue, using the strict-priority command.
● Policy-based per-queue rate shaping is not supported on the queue configured for strict-priority queuing. To use queue-
based rate-shaping as well as strict-priority queuing at the same time on a queue, use the Scheduler Strict feature as
described in Scheduler Strict .
● The strict-priority supersedes bandwidth-percentage configuration.
● A queue with strict priority can starve other queues in the same port-pipe.
●
Assign strict priority to one unicast queue.
INTERFACE mode
service-policy output policy-map-name
Enter the name for the policy map in character format (32 characters maximum).
Queue Classification Requirements for PFC
Functionality
Queue classification requirements for PFC functionality are mentioned below:
● On untagged ports, Queue classification must be based on DSCP.
● On tagged ports, Queue classification must be based on Dot1p. Layer 3 classification configurations should not be present on
the port.
● On hybrid ports, Queue classification can be based on either Dot1p (for tagged packets) or DSCP (for untagged packets) but
not both.
Example Case:
PFC does not work for tagged traffic, when DSCP based class map is applied on a hybrid port or on a tagged port. Assume two
switches A and B are connected back to back.
Consider the case where untagged packets arrive on switch A, if you want to generate PFC for priority 2 for DSCP range 0-7,
then you have to match the interested traffic. You must use the class map and associate to queue 1 using the policy map. The
same class map needs to be applied in switch B as well and when queue 1 gets congested, PFC would be generated for priority
2. Switch A on receiving PFC frames with priority 2 would stop scheduling queue 1.
If a tagged packet with VLAN dot1p as 5 ingresses on switch A. Consider that tagged packet also has DSCP in range of
0-7.These packets will match the class map and get queued on queue 1 on both the switches.
But when queue 1 gets congested on switch B, PFC frames for tagged packets will not be generated as PFC is not enabled on
dot1p priority 5.
Support for marking dot1p value in L3 Input Qos
Policy
In case the incoming packet is untagged and the packet which goes out to the peer is tagged, then the dot1p should be marked
appropriately using L3 Input Qos Policy. This is required because in the peer switch PFC will be generated based on the dot1p
value. Currently if the ingress is untagged and egress is tagged, then dot1p priority 0(default) will be added as part of the tag
header and from the next hop PFC will be based on that dot1p priority. Support is added to mark the dot1p value in the L3 Input
Qos Policy in this feature. Hence it is possible to mark both DSCP and Dot1p simultaneously in the L3 Input Qos Policy. You are
expected to mark the Dot1p priority when the ingress packets are untagged but go out to the peer as tagged
NOTE:
L2 qos-policy behavior will be retained and would not be changed, that is we would not allow to set both DSCP and
Dot1p in the L2 Input Qos Policy.
Example case:
Quality of Service (QoS)
709