Well QoS labels intend to place the right packets with the right QoS settings using labels. Prior to QoS there was never any differentiation of packets arriving or leaving a switchport. QoS labels simply mark our different classes of traffic with the appropriate label and thus helps distinguish and differentiate on what happens to the packet. These labels are present in two forms one being the tag control field in a frame header as a layer 2 marking and one being present in the ToS byte of an ip packet header as a layer 3 marking. Layer 2 QoS labels are represented using CoS values and Layer 3 QoS labels are represented using Either IP Precedence or DSCP.
By default routers and switches in a network follow the best-effort model and for Cisco devices this is the default. What I plan on explaining in this blog revolves around the Diff-Serv architecture. The Diff-Serv (or Differentiated Services) model introduces a concept wherein a packet is classified or labeled as it enters the network. This in turn reduces the overhead that would plague core switches if they had to label every packet passing by it. The other benefit of this is that all traffic marked entering the network can be subjected to QoS settings from the start.
Layer 2: Class of Service (CoS)
Class of Service
The 802.1q frame headers present in layer 2 frames contain a byte Tag Control Information field that carries the CoS value in the three most significant bits. These three bits are used to represent values in the ranges of 0 to 7. A CoS value of 0 represents the lowest priority and 7 that of the highest priority.
Binary
|
Decimal
|
Use
|
000
|
0
|
Best Effort
|
001
|
1
|
Priority
|
010
|
2
|
Excellent Effort
|
011
|
3
|
Critical Applications
|
100
|
4
|
Video
|
101
|
5
|
Voice
|
110
|
6
|
Internetwork Control
|
111
|
7
|
Network Control
|
Layer 3: IP Precedence and DSCP
IP Precedence
Was the old layer 3 form of marking it took 3 bits from the ToS byte and therefore a representation of 8 values could be used to mark packets. This was the military standard and was initially used to provide QoS labeling for layer 3 ip packets. They too have values ranging from 0 to 7 and are prioritized in the increasing order.
Binary
|
Decimal
|
Use
|
000
|
0
|
Routine or Best Effort
|
001
|
1
|
Priority
|
010
|
2
|
Immediate
|
011
|
3
|
Flash
|
100
|
4
|
Flash Override
|
101
|
5
|
Critical
|
110
|
6
|
Internet
|
111
|
7
|
Network
|
DSCP
Today most modern switches including Cisco’s use DSCP markings for its QoS Labeling. DSCP makes use of 6 bits instead of 3 from the ToS byte. These 6 bits are used to represent DSCP values and range from 0 to 63. The 64 different values that can be represented by DSCP allows it more granularity over the traffic and allows for all traffic in the network to be labeled uniquely. This in turn offers separate QoS policies to be implemented on the uniquely classified traffic. DSCP markings can be classified into many types like the Default PHB, Class selector, Assured Forwarding and Expedited Forwarding.
Default PHB
The Default PHB has a binary value of 000000. It is used to mark traffic as best effort or basically no QoS.
Class selector
DSCP is backward compatible with IP Precedence values. A certain range of values present in the DSCP range are reserved for backwards compatibility with the older method of ip precedence. The first three bits in the case of the DSCP values are the same as that of ip precedence. The next three bits are 0’s just as in the case of ip precedence (these bits are not used). They are of the form ‘XXX000’. Thus if a packet comes in with an IP Precedence value it has a DSCP equivalent. These equivalent DSCP values are called the Class Selector (CS) values. This can be inferred from the table below.
Binary
|
IP Precedence
|
DSCP
|
000000
|
0
|
Default (0)
|
001000
|
1
|
CS1 (8)
|
010000
|
2
|
CS2 (16)
|
011000
|
3
|
CS3 (24)
|
100000
|
4
|
CS4 (32)
|
101000
|
5
|
CS5 (40)
|
110000
|
6
|
CS6 (48)
|
111000
|
7
|
CS7 (56)
|
Assured Forwarding
DSCP also introduces something known as Assured Forwarding (AF). The Assured Forwarding values are represented using two properties, drop probability and Class. The drop probability characteristic of the marked packet indicates the chances of the packet being dropped during a state of congestion as compared to other traffic in the same class. The drop probability characteristic can have one of three values namely Low Drop probability, Medium Drop probability, High Drop probability. The Class characteristic defines that if congestion does occur traffic in the higher classes is given a higher priority than the traffic in lower classes. The classes are divided into four Class 1 to Class 4. Class 4 being the highest priority and class 1 being given the lowest priority.
The AF values can be deciphered using a simple formula.
AFxy where x stands for the class and why stands for the drop probability.
Class 1
|
Class 2
|
Class 3
|
Class 4
| |
Low Drop
|
AF11 (DSCP 10)
|
AF21 (DSCP 18)
|
AF31 (DSCP 26)
|
AF41 (DSCP 34)
|
Medium Drop
|
AF12 (DSCP 12)
|
AF22 (DSCP 20)
|
AF32 (DSCP 28)
|
AF42 (DSCP 36)
|
High Drop
|
AF13 (DSCP 14)
|
AF23 (DSCP 22)
|
AF33 (DSCP 30)
|
AF43 (DSCP 38)
|
Expedited Forwarding
Expedited Forwarding (EF) has a binary value of 101110 or a decimal value of 46. The expedited forwarding PHB is used on traffic that has characteristics like low delay, low loss and low jitter. The EF marking is generally used with voice traffic because of the characteristics just mentioned.
The QoS maps
A Cisco layer 2 or layer 3 switch sees a frame/packet as it is and does not make any change to it by default, the packet is sent out of the egress interface without any markings applied on it. This is because by default QoS is disabled as you can see from the screenshot below.
Even though the output shows QoS ip packet DSCP rewrite is enabled it really doesn’t rewrite anything until and unless QoS is enabled. QoS is enabled using the command mls qos.
The switch only processes packets based on the DSCP value and not the CoS or IP Precedence values. Whether a packet comes in with a CoS value or an IP Precedence value at the end of the day it needs to be converted to an equivalent DSCP value for the switch to process it. Using maps this can be achieved. A map is basically a table used by a switch to convert QoS markings from one form into another (DSCP in our case). There are three maps I would like to discuss in this post and I have listed them below along with their maps to equivalent DSCP values.
CoS-to-DSCP map
IP-Precedence-to-DSCP map
DSCP-to-DSCP-mutation table
If the particular switch is at the boundary of a set of networking devices it may require a conversion of DSCP values to other sets of DSCP values and this can be attained by using the above DSCP mutation table.
The classification process
Traffic entering the switch needs to be trusted based on the CoS/IP Precedence/DSCP values. There are multiple methods to achieve this and they have been listed below:
MLS QoS Trust CoS
This command is used to classify IP or non-IP traffic entering into the switchport. It initially checks if the incoming packet has a CoS label. If the packet has a CoS value attached to it the CoS-toDSCP map is used to generate an equivalent DSCP value. If the packet doesn’t have a CoS value associated with it the default port CoS is applied and the CoS-to-DSCP map is then used to generate an equivalent DSCP value
MLS QoS Trust DSCP
This command is used to trust IP traffic only. If the DSCP-to-DSCP-mutation table has been modified the DSCP value present in the incoming packet will be modified according to the mutation table. If the packet comes in with no predefined DSCP value the packet is checked to see if it has a CoS label assigned. If it does then the CoS from the packet is used to generate a DSCP value using the CoS-to-DSCP map. If the packet does not have a CoS value or a DSCP value assigned to it. The packet is assigned a default CoS value and the CoS-to-DSCP map is used to generate an equivalent DSCP value.
MLS QoS Trust IP Precedence
This command is used to trust IP traffic entering the switchport. An IP-Precedence-to-DSCP map is used to generate an equivalent DSCP value. If the packet comes in with no predefined IP Precedence value the packet is checked to see if it has a CoS label assigned. If it does then the CoS from the packet is used to generate a DSCP value using the CoS-to-DSCP map. If the packet does not have a CoS value or a DSCP value assigned to it. The packet is assigned a default CoS value and the CoS-to-DSCP map is used to generate an equivalent DSCP value.
Alternatively ACLs can also be used to match packets and assign CoS or DSCP values.
Trust device cisco-phone/ cisco-softphone/cts/ip-camera
When a Cisco ip phone sends packets out it sends them with a default CoS value of 5. When this packet enters a switch this CoS value is either accepted or remarked depending on the configuration present on the switch. Any two cisco devices present come to know of each other using cdp. When a Cisco switch is connected to a Cisco ip phone (or similar devices) cdp can be utilized to detect if the device connected is indeed a Cisco ip phone.
Using the command MLS QoS Trust device Cisco phone Utilizes CDP to detect if the device connected is a cisco ip phone or not. If the detected device is a cisco phone the CoS values are trusted. If the device is not a cisco ip phone the packets are remarked to a CoS of 0. This mechanism is used to prevent devices capable of 802.3p tagging from marking its own packets with a higher CoS value, thus prioritizing its own traffic above the others.
The default CoS value can be set on the switchport by using the command MLS QoS cos <value> command and the CoS values of the packet can be overwritten to the default values using the MLS QoS cos override command.
These settings can be verified by issuing the show mls qos interface <type> <port>
As an example I will configure interface fa 1/0/1 of a 3750 switch with the following QoS settings:
- Trust the CoS values entering the switch
- Trust the CoS markings if the device is of type cisco-phone
- Set the default CoS value to 3
- Force all traffic to use the default CoS value
Below are packet captures using wireshark that show the before and after of configuring the above commands
Before
After
If you notice the before image it indicates that the packets were being sent out with a DSCP value of EF. This is because the frame comes in with a CoS value of 5 this is tagged by the phone itself. As it enters the switch it is converted into an equivalent value present using the CoS-DSCP map. However QoS has not been enabled and this conversion does not take place therefore it is left at the value of EF. If QoS was enabled the CoS-DSCP map would equate to a value of CS5 (DSCP 40) as shown in the screenshot below
The after screenshot indicates that the converted value is CS3 (DSCP 24) which can be calculated using the CoS-DSCP mapping table. This proves the override command and the CoS to DSCP translation taking effect.