Switching QoS
The following considerations are based on the Cisco 3560 platform.
Enabling QoS
By default, QoS is disabled on a switch. You can enable it with:
Once QoS is enabled, all incoming packets are assigned a QoS label for internal processing. This QoS label is used for Classification and is actually a DSCP value. The QoS label can be derived from the incoming QoS marking or it can be overridden when the packet enters the switch. Based on this classification (QoS label), the packet will be treated throughout the switching process and when it is sent out, it will be marked with the DSCP value of QoS label.
QoS Label
A QoS marking can reside at Layer 2 or at Layer 3. Basic Ethernet Frames don’t have a field in the header for a QoS marking, but such a field can be found in the 802.1q or ISL header. This field is a 3-bit field called CoS – Class of Service (available classes: 0-7). In the IP header, there is a field called the ToS Byte (Type of Service) which had different interpretations over time. First, only the first 3 bits were used for a QoS marking – IP Precedence (Available values: 0-7), but then the first 6 bits were used for another QoS marking called DSCP – Differentiated Services Code Point (Available values: 0-63). For more info about IP Precedence and DSCP, see http://nyquist.eu/classification-and-marking/#2_Marking.
While QoS is disabled, the switch doesn’t change the QoS markings of the packets, but once QoS is enabled, it will mark outgoing packets with the DSCP value of the internal QoS label. By default, this label is set to the port DSCP value, which is 0. So once QoS is enabled, without any other configuration changes, the packets are assigned a QoS label of 0, so when they are sent out they will be marked with a DSCP value of 0, regardless of the markings they previously had. The default QoS label can be changed by modifying the default CoS value of the port, by trusting the incoming QoS markings or by assigning QoS labels via MQC policies.
Classification
On a Cisco 3750 switch, there are 3 ways that can be used to classify packets.
mls qos trust and map. In this mode, a port can be configured to trust or override incoming QoS markings, and to apply QoS label based on predefined QoS maps: cos-to-dscp, ip-prec-to-dscp, dscp-mutation
port-based MQC. In this mode, a port can use MQC policies to classify incoming frames
VLAN-based MQC. In this mode, ports in a VLAN can share a single MQC policy to classify incoming frames
At one time, a port can use only one of the methods above to perform classification of incoming frames.
Trust and Map
Trust
Usually, a packet is classified when it enters a QoS domain. From there on, its QoS classification can be changed or trusted. To enable trusting of QoS settings, use:
Since the CoS field can only be found on frames entering the switch on a trunk port (ISL or dot1q encapsulation), you can have several situations where incoming frames don’t have a Cos marking:
frames entering the switch on access ports
frames of the native VLAN entering on a 802.1q trunk
data traffic received from an IP Phone (data traffic is sent by the phone untagged, while voice traffic is tagged with the voice VLAN)
All IP Traffic has a ToS field so DSCP/IP-Precedence markings exist even if they are set to all zeros, but non-IP traffic doesn’t have such markings. For all of the above situations,the switch uses the port-default CoS value as the incoming QoS Marking. This value is 0 unless you specifically configure it with:
If you use the override keyword, you can override the trust setting and force the switch to apply the port CoS value to all incoming packets.
You can verify the qos settings of a port with the command:
Statistics regarding the markings received on each port can be seen with:
It would help to clear these statistics from time to time with:
Mapping
A packet that is coming on a trusted interface will get its QoS label based on its marking. The markings can be different (CoS, IP-Precedence, DSCP), but the QoS label assigned must be from the same space. This is achieved by mapping the incoming QoS marking to a DSCP value representing the local QoS label, using one of the following maps:
As a best practice, the Voice Traffic should be mapped with CoS 5 and DSCP EF (DSCP 46). With the default CoS to DSCP mappings CoS 5 traffic will be mapped to DSCP 40, so you should change the default settings with:
The incoming DSCP values can also be mapped to new DSCP values, but this map is null by default. To change it, first define a DSCP mutation map:
and then use it on an interface:
There is also a DSCP to CoS map that can be used to mark outgoing traffic in QoS Policies:
To see the QoS maps, use:
Trust Boundary
Some devices (Cisco Phone, IP Camera, Telepresence Devices) send traffic encapsulated with 802.1q and mark the traffic with different CoS values. For example, a Cisco Phone marks voice traffic with CoS 5 (DSCP EF) and data traffic with CoS 0. You can force the switch to only trust traffic that comes from a certain type of device identified via CDP, by using the following commands:
If the device is not found, then the port-default CoS value is used. Additionally, you can instruct an IP Phone, via CDP, to trust or to overwrite the CoS markings of the frames it receives on its Data port, from a PC, thus moving the trust boundary on the IP Phone. To enable this, use:
MQC-based port policy
See MQC Policies.
MQC-based VLAN policy
See MQC Policies.
Marking
The default behavior of a switch is that once mls qos is enabled it will send the packets marked with the DSCP value of the QoS label. However this can be changed if you enable DSCP Transparency feature:
DSCP Transparency
You can disable the rewriting of QoS markings with the DSCP value of the QoS label and send a packet with the same marking as it was received, using:
MQC-based marking
See MQC policies.
MQC Policies
Classification
Define a Class Map:
Marking
Setting new QoS marking or trusting existing ones can be configured in a policy map:
Traffic not matched by any class goes into the class-default class, which by default, doesn’t trust QoS markings and uses a QoS label equal to 0.
Policing
Policing can be configured inside a policy map:
The default action for policing is to drop the traffic that is exceeding the configured RATE. As an option, you can transmit the packet, but mark it according to the policed-DSCP map that can be configured with:
You can apply a policing policy on a port or on a SVI (if using VLAN-based mode – see below), but in the last case, you have to use a two-level policy to make the policing work.
Aggregate Policers
An aggregate policer can be configured to share the same policing profile to multiple classes of traffic. First, you will have to define the policing profile:
Then use it in a policy:
Applying QoS Policies
Port-based
By default, QoS policies can only be configured on each individual physical interface. To do this, simply apply the policy with:
Assigning a QoS policy will remove all other QoS settings on the port except the default CoS value of the port.
VLAN-based
You can enable a port to work in the vlan-based mode, by changing the mls qos mode of operation on the port, with:
Now, in order to apply QoS policies on such a port, you will have to configure the policy on the SVI interface:
The policy will be applied to all ports that are part of this VLAN and that work in the VLAN-based mode. To verify if VLAN-Based is enabled on an interface, use:
If you want to set a VLAN-Based QoS policy that will police traffic, you are required to use a 2-layer policy, like this: Individual policies for each port can be configure with a two-level policy.
Queuing and Weighted Tail Drop
Because the total bandwidth of all incoming ports is greater than the bandwidth of the internal ring, 2 ingress queues are placed after classification, marking and policing takes place and before the switch fabric. These 2 queues service all incoming ports.
Additionally, 4 egress queues exist for each outgoing interface and are placed after the switch fabric and before the packet is sent out
Both ingress and egress queues are serviced by the same algorithm – SRR (Shaped/Shared Round Robin). SRR can work in 2 modes
Shaped mode (available for both Ingress and Egress Queues) – in Shaped mode, each Egress Queue is guaranteed a percentage of the available bandwidth and is rate-limited to that value.
Shared Mode (available only for egress Queues)- in Shared mode, the queues share the remaining bandwidth.
Both incoming and outgoing queues use buffers to store packets. The number of the buffers assigned to each queue is configured. Normally, when the buffers are full, tail drop occurs. You can use Weighted Tail Drop to prevent a tail drop that would drop important traffic. With WTD, each queue has 3 thresholds – 2 configurable thresholds and 1 non-configurable (=100%). Traffic is assigned to a queue and to one of the queue’s thresholds based on CoS/DSCP. When threshold 1 is reached, other traffic that would be assigned to threshold 1 is dropped (we have no more space for such traffic in the queue). The same happens for threshold 2. Threshold 3 is always 100% so it generates a tail drop.
Ingress Queues
After a packet is received, classified, marked and policed on the ingress direction, it will go in one of the ingress queues before entering the Shared Ring. All ports send their packets to these 2 incoming queues.
Traffic is assigned to the queues based on DSCP/CoS (trust settings on the incoming interface). The default maps used to assign traffic to one queue or the other can be seen with:
The default maps can be changed with:
Packets from each queue are placed on the Shared Ring using the Shared Round Robin algorithm. Both queues are serviced proportionally to the configured weights:
One of the queues can also be configured to be a priority queue. This way, it will be serviced first, but it will be limited to a percentage of the available bandwidth. The remaining bandwidth will be shared between the other queue and the remaining traffic of the priority queue. To configure one of the queues as priority queue, use:
Both queues share the same buffer space. You can change default configuration using:
To prevent tail drop, you can configure Weighted Tail Drop on the incoming queues. See above for a description of how WTD works. To configure threshold levels for each queue, use:
Packets are assigned by default to Threshold 1. See the default maps above. You can change this using:
To see configuration of the input queues, use:
Egress Queues
Each port supports 4 egress queues. These queues can be service by SRR in Shaped or Shared mode. Two sets of weights are defined, one for Shaped mode and one for Shared mode:
Queues that have a non-zero Shape Weight, work in Shaped mode, while the others work in Shared Mode. First, queues that work in Shape mode will be reserved and rate-limited to a bandwidth equal to:
Where SPEED is the interface speed (10/100/1000). Therefore, the sum of all Shaped Weights cannot be more than 100. All shared queues will share the remaining bandwidth proportionally to the Shared Weights. The Weights for the Shaped Queues are ignored in this calculation. The Shared Weights cannot be set to zero.
Queue 1 can be configured as a priority queue and will be served before any other queue. It is not rate-limited so it can produce queue starvation. When Queue 1 is configured as a priority queue, its Weight is ignored when calculating the bandwidth assigned in Shaped and Shared mode for the other queues.
You can rate-limit the entire output of a port with:
Each physical port has a number of buffers that can be assigned to the outgoing queues. Additionally, threshold are configured for WTD. But you cannot set completely different configurations on each port. Instead, you can only use one of the 2 global templates, called Queue Sets. To configure the buffer allocation for a Queue Set, use:
Next, we should configure the thresholds for WTD, with:
Out of the available buffers you have assigned a percentage P for each outgoing Queue. From these Buffers (P*BUFF), only a part will be used by the Queue (RESERVED*P*BUFF). The remaining Buffers (BUFF-RESERVED*P*BUFF), will be allocated to a shared pool of Buffers. When queueing packets, when the RESERVED Threshold is reached, the queue will start using Buffers from the Shared Pool. How much it can use, depends on the MAX value. This value is the Maximum size that the queue can have before traffic will be tail dropped. TH1 and TH2 are the threshold values used by WTD. The defaults are:
To apply the template on the outgoing interface, use:
The last step si to assign traffic to the outgoing Queues and to each Threshold:
Auto QoS
Auto QoS is a feature that automatically generates QoS configuration in your switch. To enable autoqos use the following command on an port:
When the command is run for the first time, it enables mls qos and configures QoS maps and Queueing profiles. To see the commands used by auto qos, use:
Last updated
