Hello David
I’ve created a NetworkLessons note on the topic of CBWFQ. You can take a look at it here for more info. If you have further questions, feel free to ask!
I hope this has been helpful!
Laz
1 Like
This is a particularly confusing section.
<0-63> Differentiated services codepoint value
- I thought the sixth DSCP bit always had to be 0? How could there be 63 possible values if this is the case?
- What do the DSCP values outside of AF, EF, and CS represent? ie: 111110 (62)? AF only includes 12 values, CS only 8, and EF only 1.
- The CoS & IPP to DSCP mappings are awfully confusing. If the first three bits of DSCP map to CoS & IPP, why are the last three bits always 0? If you had a value of say, 011 010, would this still map to IPP Flash & CoS Critical Applications, or would the DSCP value need to be 011 000 for it to actually map?
Hello CJ
Let me try to address each of your questions:
-
The DSCP is a field in the IP header for providing different levels of service for network traffic. It uses the first 6 bits of the 8-bit differentiated services field. Theoretically, this gives you 2^6 or 64 possible values (0-63). However, in practice, not all these values are used. The sixth bit is not always 0. It is set to 0 for compatibility with network devices that only recognize the older Type of Service (ToS) field. But, it can be set to 1 for newer applications that recognize the DSCP field. Take a look at this for more information.
-
The DSCP values outside of AF, EF, and CS represent different levels of service that might be defined by a specific network administration. They are not standardized and can be used for custom traffic classes. For example, a DSCP value of 62 (111110) could be used for a custom traffic class that requires a very high level of service. Remember, AF, EF, and CS are all recommendations that are often implemented by default in certain network equipment. A network administrator can choose to override these, redefine these, or use other values as they see fit for their network.
-
The CoS and IPP values are older methods of providing QoS and are mapped to the first three bits of the DSCP field for backward compatibility. The last three bits of the DSCP field are used for Drop Probability in the Assured Forwarding (AF) class. If the DSCP value is 011 010, it would still map to the same CoS and IPP values as 011 000. The last three bits would just indicate a different Drop Probability. However, if you want to ensure that your network traffic is treated as Critical Applications by devices that only recognize CoS or IPP, you would want to use a DSCP value of 011 000.
For more info, take a look at:
- QoS - CoS to DSCP and DSCP to CoS mapping
- Diffserv recommended configuration
- QoS Marking
- CoS vs DSCP
I hope this has been helpful!
Laz
Hi Laz,
Thanks for explaining. So in short, the 0-63 option allows for up to 64 custom DSCP values. Any idea how often that’s used in the real world? How often do network admins use custom values vs. AF, EF, and CS?
Hello CJ
Hmm, not quite 64 custom DSCP values. Some of those values are predefined. The full range of DSCP values is 0-63 since we are using 6 bits to represent them. Some of those 64 values are predefined using some of the AF, EF, and CS notations. The following context sensitive help gives this indication:
R2(config-pmap-c)#set dscp ?
<0-63> Differentiated services codepoint value
af11 Match packets with AF11 dscp (001010)
af12 Match packets with AF12 dscp (001100)
af13 Match packets with AF13 dscp (001110)
af21 Match packets with AF21 dscp (010010)
af22 Match packets with AF22 dscp (010100)
af23 Match packets with AF23 dscp (010110)
af31 Match packets with AF31 dscp (011010)
af32 Match packets with AF32 dscp (011100)
af33 Match packets with AF33 dscp (011110)
af41 Match packets with AF41 dscp (100010)
af42 Match packets with AF42 dscp (100100)
af43 Match packets with AF43 dscp (100110)
cos Set packet DSCP from L2 COS
cs1 Match packets with CS1(precedence 1) dscp (001000)
cs2 Match packets with CS2(precedence 2) dscp (010000)
cs3 Match packets with CS3(precedence 3) dscp (011000)
cs4 Match packets with CS4(precedence 4) dscp (100000)
cs5 Match packets with CS5(precedence 5) dscp (101000)
cs6 Match packets with CS6(precedence 6) dscp (110000)
cs7 Match packets with CS7(precedence 7) dscp (111000)
default Match packets with default dscp (000000)
ef Match packets with EF dscp (101110)
qos-group Set packet dscp from QoS Group.
As you can see, AF42 for example corresponds to 100010 which in binary is 34, and CS3 is 011000 which in binary is 24. So out of the full range of values, some are predefined, and those predefinitions are typically dealt with in a particular way by default by network equipment. How each predefined value is determined and interpreted, depends upon the type of Differentiated Services being used. Is it Class selector PHB,Assured forwarding PHB, or Exedited Forwarding? More about this can be found in the Differentiated Services section of the IP Precedence DSCP values lesson.
Now other than those predefined values, you as a network admin can use your own custom values, (such as a decimal value of 1, 7 or 15 which are not predefined by any of the above mechanisms) and then configure your network devices to respond and behave accordingly to those.
The truth is that in the majority of networks, one of the predefined mechanisms is typically used. They are well-designed and are appropriate for most cases. The only time you would see a custom approach is if you have a specialized network with many different types of traffic, with much congestion, and you need to very precisely fine-tune your priorities. In other words, only in situations where you require a very high level of granularity, would you use custom values.
So to answer your question, it is quite rare to see custom values of DSCP used.
I hope this has been helpful!
Laz
Remember, AF, EF, and CS are all recommendations that are often implemented by default in certain network equipment. A network administrator can choose to override these, redefine these, or use other values as they see fit for their network.
I got confused by the above and was under the impression based on what you said that the AF, EF, and CS values could be overrode by custom DSCP values. The first option in the set dscp command allows you to choose a value between 0-63; are you saying that if I were to enter set dscp 10, it would be the same as entering set dscp af11 since the values match?
Thanks for the detailed explanation here. QoS is one of the chunkiest and finnicky topics in CCNA. No doubt questions from this section are going to be a total nightmare on the exam.
Hello CJ
Yes, that’s exactly correct. The lesson I linked to in my previous post shows the various ways that the six bits found in the DSCP codepoint field can be interpreted in different ways. Some of those are predefined values (within the 0-63 range in decimal) while some are undefined, but you can define them as you like. And yes, setting a DSCP value of 10 is the same thing setting af11 because the result is the same in the DSCP field.
QoS is indeed a large part of CCNA, and I have found that when you end up understanding particular part of it, a whole series of new questions pop up in my mind, making it truly one of the more challenging topics to grasp. The good thing however is that the scope of QoS on the CCNA exam is somewhat limited. In the exam blueprint, it is only found in sections 2.9 and 4.7. Although it is an integral part of the exam, its impact on your mark will be small.
I hope this has been helpful!
Laz
Hello, everyone.
I have this simple topology:
Say that I have a class called TELNET.
When it comes to applying a policy-map in this case, in terms of internal processing, does it matter whether I do it inbound (G2) or outbound (G1) on R1?
Because either way, before the traffic makes it to the output queue, it will be eventually classified as TELNET, correct?
Also, any clue about why my Telnet responses are being marked with CS6? I’ve configured my marking to be AF21 which the Telnet requests are, but not the replies from the device.
Thank you.
David
Hello David
It depends on what you want to achieve. If you’re using a policy map to mark telnet messages, then there will be little or no difference whether you mark them incoming on G2 or outgoing on G1. The purpose is to have them marked for transmission throughout the whole network. The direction (inbound or outbound) mainly affects the order of operations for other features like routing, NAT, etc, but for classification, it doesn’t really matter. The only time it would matter is if you have configured R1 to process these telnet packets with a particular QoS priority, thus, when the packets are being processed within R1, if you apply it in an inbound direction on G2, those priorities would be applied for the packets as they egress the device.
The marking of CS6 is likely due to the default behavior of Telnet. The Telnet responses (from the Telnet server to the client) are typically marked as CS6, which is the default ToS value for network control traffic. This is because Telnet replies are considered as network control traffic, thus they are marked with a higher priority value (CS6) than regular traffic. The reasoning behind this is the same as that seen on OSPF messages.
I hope this has been helpful!
Laz
Hello Laz.
Thank you, I have one more question.
I understand what QoS groups are. The idea is that you can classify something in your input policy map and then apply a qos group to that packet so that when it gets routed out of the egress interface the egress policy map applies its own policy to that qos group.
Although I don’t quite understand when would I use this. Why would you apply a QoS group to something when you can just classify it again using the relevant CLASS-MAP and have the policy applied that way?
Do you please have a practical example or configuration for this?
Because if you consider one of my examples
class-map match-all PING
match protocol ping
policy-map GROUP
class PING
set qos-group 1
interface GigabitEthernet1
service-policy input GROUP
class-map match-all PING-EF
match qos-group 1
policy-map GROUP-EF
class PING-EF
set ip dscp ef
interface GigabitEthernet2
service-policy output GROUP-EF
I could just match based off the PING class-map again in my output policy map without a QoS group. So where do these groups become useful?
David
Hello David
Hello David,
You’re right, in many cases you could just reclassify packets using class-maps in your output policy-map. However, QoS groups can be very useful in more complex scenarios with multiple interfaces, policies, and handling of different types of traffic, where you might need to handle traffic differently based on its ingress interface or other criteria. QoS groups can be helpful in such situations especially to ensure scalability, and to make configurations a little more efficient.
Consider a scenario where you have multiple ingress interfaces with different classification criteria, but you want to apply the same treatment to certain types of traffic once they’re inside the router. You could use QoS groups to accomplish this.
For example, let’s say you have two ingress interfaces, Gi0/1 and Gi0/2, and you want to classify ICMP traffic on Gi0/1 and HTTP traffic on Gi0/2, but treat both types of traffic the same way once they’re inside the router. You could do this with QoS groups like this:
class-map match-all ICMP
match protocol icmp
class-map match-all HTTP
match protocol http
policy-map INGRESS1
class ICMP
set qos-group 1
policy-map INGRESS2
class HTTP
set qos-group 1
interface GigabitEthernet0/1
service-policy input INGRESS1
interface GigabitEthernet0/2
service-policy input INGRESS2
class-map match-all QOS1
match qos-group 1
policy-map EGRESS
class QOS1
set ip dscp ef
interface GigabitEthernet0/3
service-policy output EGRESS
In this configuration, the ICMP traffic on Gi0/1 and HTTP traffic on Gi0/2 are both assigned to QoS group 1, and then the same treatment is applied to both types of traffic in the EGRESS policy-map on Gi0/3.
I hope this has been helpful!
Laz