I actually used two 3560 physical switches that I have. I didnt do this on GNS3. Can you tell me what I can do to get it working? Thanks!
Hello Martha
Hm, still not sure why itâs doing that. If you have the ability, check it out on another device. Also, make sure that the port itself is connected to something and is up, as this may change the indicators. You can also check to see if override is indeed being applied to the packets/frames or not using wireshark⌠Some of these troubleshooting steps should shed more light on the issue.
I hope this has been (somewhat) helpful!
Laz
Hello,
Unfortunately my GNS images do not have mls qos.
I have some remarks though (searching for official Cisco doc).
The âswitchport priority extend cosâ command I believe is actually âswitchport priority extend cos <cos_value>â.
For âqos trust dscpâ example there should be a description informing that CoS will be overwritten according to the dscp-to-cos map.
Also some outputs for cos-to-dscp and dscp-to-cos would be useful in this lesson.
I found this on some Cisco documentation (but those values seem to contradict in their doc and I donât know how to check them):
show mls qos maps cos-dscp
CoS 0 1 2 3 4 5 6 7
DSCP 0 8 16 24 32 40 48 56
show mls qos maps dscp-cos
DSCP 0-7 8-15 16-23 24-31 32-39 40-47 48-55 56-63
CoS 0 1 2 3 4 5 6 7
Thank you,
Stefanita
Hello Stuat
Yes, those functionalities are difficult to simulate/emulate so even VIRL doesnât support them. Iâm afraid youâll have to use real equipment to use and explore them.
Yes you are correct, there should be a value after the command. Rene does mention this in the text as shown below:
However, it can be made clearer. Iâll let Rene know to clarify.
Concerning the mapping commands that show DSCP to CoS mappings and vise versa, because these values can be changed, the outputs will not always be the same. I will let Rene know of your suggestions however.
Thanks so much for your feedback, as it is invaluable to maintaining the quality and integrity of the site! It is much appreciated!
Laz
1 Like
Hi Lazaros,
Would you please simply these:
1.We can trust packets based on DSCP value, frames on the Cos value or we can trust the IP phone.
2.Why should we set a COS value?
Thanks in advance.
Hello Muhammad
QoS functions at various levels in routers and switches. Specifically, QoS functions at Layer 2 with a Class of Service (CoS) value in the VLAN tag, and at Layer 3 with the DSCP values in the IP header. Each is used in a different scenario.
CoS is used to prioritize frames on any link that carries more than one VLAN. It specifically exists in the VLAN Tag found on trunks. So CoS values are used to ensure that frames with a higher priority are given precedence over a trunk when there is congestion. Now this is also the case on any link using a Voice VLAN. In the example in the lesson, we have FastEthernet0/1 where the voice packets are tagged, and the data packets are untagged. If a CoS value in the tagged (voice) frames is configured, then if there is congestion on the link (due to a user on the connected computer downloading a movie for example), CoS can be used to ensure that voice frames will be given priority over the data frames.
Now Layer 3 switches also have the capability of decapsulating to Layer 3 and examining the info in the IP packet header. This allows a switch to use DSCP values as well to determine priority, and to determine the QoS mechanism that will take place in the event of congestion.
I hope this has been helpful!
Laz
Thanks Laz now it is clear.
1 Like
How switch can trust packets based on the DSCP value. DSCP bits are encoded into IP packet header and switch only does lookup in L2 frame header. how switch will know about any IP DSCP value at layer 2 frame.
Hello Ankit
Yes, you are correct that DSCP values are found in the IP header. However, some L2 switches have the capability of decapsulating packets to the IP level and examining the DSCP values to determine the kind of QoS that they will implement. This is done using the mls qos trust dscp command for example.
I hope this has been helpful!
Laz
I am having an issue on the WS-C3550-24-PWR/ WS-C3560CX-12PC-S switches in FastEthernet interfaces where I see a lot of underruns in output packet and buffer failure in all of the interfaces.
The ports are 100/ Full, I did try Auto-negotiation as well. Now the problem is that itâs causing issues on my voice traffic and I am planning to prioritize voice/ video traffic on the layer 2 edge switch.
In my current setup, we have Avaya phones are connected to the ports and PCâs are connected with the phones.
I want to prioritize my video/ voice traffic any suggestion on the following configurations?
-
Globally
mls qos -
End point ports (Phones, PCâs)
mls qos trust cos -
Uplink ports between two switches on both ends
mls qos trust cos -
mls qos trust dscp on switchport that is facing where my SVIâs.
How can I verify if the traffic passing through the Layer 2 switch is being prioritized?
Thank you,
Hello Khurram
First of all, before you employ QoS for voice, it would be a good idea to determine why you are getting underruns and buffer failures on the interfaces. Remember than an underrun is a state occurring when a buffer is fed with data at a lower speed than the data is being read from it. This causes the switch to pause to wait for the buffer to refill before sending out the data. This is especially harmful to time sensitive data like voice. An underrun occurs when part of the packet is being sent on the wire, but the device is unable to get the remaining part of the packet on the wire when it has finished transmitting the first part. This results in an error and upper level protocols are used to ask for a resend of the info (TCP) or not (UDP). Underruns are usually caused by an inconsistent flow of traffic from other devices due to congestion that occurs in other areas of the network.
My suggestion would be to examine the traffic patterns on your network, and see where the congestion is taking place. Even if you employ QoS on this specific access switch, if the congestion causing the underruns exists elsewhere on the network, you will still face similar problems.
Having said all of this, implementing QoS for voice is vital. The configuration you have above will create a trust boundary that includes both the interfaces as well as the uplinks, and DSCP values will be trusted as well. In order to verify that the traffic passing through the switch is indeed prioritised, you can either use the show mls qos interface command shown in the lesson, or you can use wireshark to examine the voice packets and see what their markings are like, and that they havenât been removed or modified.
I hope this has been helpful!
Laz
MLS QoS is only in inbound ?
Iâve seen on Huawei they call it âtrust upstreamâ but you can configure inbound and outbound
Hello Juan
The mls qos command simply enables QoS on the switch. When it is enabled, all ports on the switch are initially untrusted. The characteristic of being untrusted or trusted is not a concept that has âinboundâ and âoutboundâ associated with it. This characteristic simply defines the trust boundary.
If traffic comes in to a trusted port, we trust the QoS markings and process the traffic based on the markings without changing them. If the port is untrusted, then the markings on incoming traffic are ignored, and are changed.
If you are to assign an âinboundâ or âoutboundâ quality to the trust boundary, then the only thing we can say is that it is applied to all âinboundâ traffic. Trusting or untrusting âoutboundâ traffic on such an interface has no meaning, because this traffic is already trusted, since it is coming from inside our trust boundary. (The diagrams in the lesson illustrate this very well.)
Keep in mind that QoS in general always functions in an outgoing direction, because you can queue and manipulate the priority of outgoing traffic. Incoming traffic is something you cannot control. You must receive whatever is sent to you. You can however classify the traffic (using trusted or untrusted port configurations) so that, downstream, these markings can be used to queue and prioritize it as needed.
I hope this has been helpful!
Laz
Hi,
Iâve been reading the official cert guide from CiscoPress. It mentioned Cos is categorized into 8 different priority. But the book doesnât really get into much details. Would you mind talking about Layer2 marking a little in depth? For instance, different fields in TCI field.
Regarding this article, I have several questions that would want your confirmation:
- what is cos-to-dscp map? Is there a show command to show its setting?
- For me issue âmls qos trust cosâ means if i have a device that tag its Cos to 5, then switch will keep the Cos value to 5 without remarking it to 0, correct? However, if we issue âmls qos cos overrrideâ then regardless whether we trust the incoming cos tag or not, the switch will remark the cos when it receives the packet, is this a correct statement?
- If we issue âmls qos trust cos pass-througâ that basically means we trust and would accept both the incoming cos and dscp value, correct?
- I remember Rene mentioned the Qos configuration on router is different than a switch. The classification and marking is pretty much the same. The difference in configuration is that we need to globally enable Qos and define the trust boundary on switch, which is not necessary on router, correct?
- What about QoS on Cisco Firewall? Is it pretty much the same with router ?
Thank you as always for your help and time.
Helen
Hello Helen.
Do you mean the ToS field? If so you can find info about this lesson:
If you donât mean the ToS field, can you clarify what field you mean?
QoS can take place at layer 3 (when packets are routed) or at layer 2 (on trunk links). The DSCP values are those found in the ToS field of the IP header and are used to implement QoS at Layer 3.
They are contained within a field of 6 bits so they have values from 0 to 63. More about these can be found in the lesson shared above.
The CoS values are those found within the VLAN tag and are used to implement QoS at Layer 2. These CoS values are briefly mentioned under the âClassification and Markingâ section in the following lesson, and are referred to as the "priority field: of the VLAN tag:
These CoS values are important when multiple VLANs are competing for available bandwidth on a trunk port. QoS mechanisms on a switch will prioritize VLAN frames over a trunk based on the CoS values. CoS values are contained within a 3 bit field, so CoS values can be 0 to 7.
CoS to DSCP mappings, and vice versa, are used to allow routers and switches to maintain a common QoS strategy from end to end by translating Layer 2 QoS markings to Layer 3 and vice versa. An example of how you can display these mappings is shown below:
c3750#sh mls qos maps cos-dscp
Cos-dscp map:
cos: 0 1 2 3 4 5 6 7
--------------------------------
dscp: 0 8 16 26 32 46 48 56
c3750#sh mls qos maps dscp-cos
Dscp-cos map:
d1 : d2 0 1 2 3 4 5 6 7 8 9
---------------------------------------
0 : 00 00 00 00 00 00 00 00 01 01
1 : 01 01 01 01 01 01 02 02 02 02
2 : 02 02 02 02 03 03 03 03 03 03
3 : 03 03 04 04 04 04 04 04 04 04
4 : 05 05 05 05 05 05 05 05 06 06
5 : 06 06 06 06 06 06 07 07 07 07
6 : 07 07 07 07
The syntax may be a bit different for different platforms. To understand the output of the dscp-cos mappings, take a look at the lesson mentioned before.
Yes this is correct.
This command actually means that the switch uses the CoS value of the incoming packets without modifying the DSCP value. It passes through the switch with both CoS and DSCP values unchanged. If this command is used without pass-through keyword, then the DSCP value is derived from the CoS to DSCP map. More info here.
Yes, a trust boundary is a Layer 2 concept, which is not present o routers.
The concepts of QoS on an ASA are much the same as those on an IOS router. Some of the commands may have a slight syntax change, but the principles are the same. Some examples of QoS implementation on an ASA can be found in the following Cisco documentation:
I hope this has been helpful!
Laz
Hi Laz,
Itâs very helpful! Thank you so much for the detailed explanation.
In regards to my first question about Layer2 marking, I mean CoS field.
With cos-to-dscp mapping, I still donât think I quite understand the correlation between cos and dscp. Is this map only used for switch overwrite purpose? Say if switch trusts the packet with cos value 1, switch will check its cos-to-dscp mapping and automatically remark the dscp value to 8? Is there any other purpose that we would use the cos-to-dscp mapping? How about dscp-to-cos mapping?
Is the cos and dscp mapping kind of a automatic way for the switch or router to know if this cos is 5, then it should be voice traffic, I will change the dscp to 46 to match the layer 2 marking?
I hope my questions make sense.
Thank you,
Hello Helen
Ah I see. You referred to the Tag Control Information (TCI) field within the 802.1Q tag. Remember that QoS mechanisms at Layer 2 only operate on trunk ports. The CoS values are only found within the tag of an 802.1q, and such tags only exist on trunks, so whenever we speak about QoS on Layer 2, weâre talking about trunks.
The 802.1Q tags are composed of various fields, and these fields have changed their names over time, so it can get confusing. Hereâs the diagram Rene has in the Introduction to QoS lesson.
The TCI field is a 16 bit field that is composed of the Priority Code Point (PCP), Canonical Format Indicator (CFI), and VLAN Identifier sub fields. (The CFI is now called the Drop Eligible Indicator or DEI). The CoS values are found in what is the three bit PCP field, marked as Priority in red in the above diagram. These three bits, as mentioned in my previous post, contain the CoS value from 0 to 7 and are used to prioiritize traffic over trunks.
The purpose of the CoS to DSCP and visa versa mappings are to allow Layer 2 switches to employ Layer 3 QoS markings on packets so that subsequent routers in the path the packet takes know that this traffic should be treated differently. In the same way, it allows switches to interpret the markings placed on packets by routers (Layer 3 devices) so that they can treat them correctly over their trunk links.
Mappings allow a switch to change the DSCP values in layer 3 based on the CoS values in layer 2. Now this can be applied either using the trusted received CoS values or based on new CoS values that the switch applies. In any case, when the packets reach a router, you want that router to treat them with the appropriate priority. Routers will never see CoS values in the frame, but they will prioritize traffic based on the DSCP values.
I hope this has been helpful!
Laz
I have a 10G trunk between two sites that carries 5+ VLANs on it. I have 2 VLANs that must always get through (very low volume, around 4Mb/s) but is constantly being dropped as my other VLANs are trying to push 10G or greater over the pipe. I donât mind problems with the other vlans dropping packets, but I need these two to always get through.
Unfortunately I canât tag specific packets easily as I canât define the traffic that goes over the trunks (note that the trunks are also being passed via multiple 10G radios of three different mfgs so I canât even get consistent methods of dealing with QoS) so rather than fight the radios, I just want the feed in and out at each end of the pipe to always put in traffic from these two VLANs and then prioritize the others howeverâŚ
Hello Marcos
It looks like what you need to do is classify the frames with the specific VLAN IDs as requiring priority. This can be done using Layer 2 QoS which provides priority to frames of a particular VLAN ID sent over a trunk.
Take a look at Unit 2: LAN QoS of the Quality of Service course below:
You can mark the CoS of frames coming into your switch on a particular VLAN, and you can then set the queuing on that particular interface so that the VLANs you want will have priority. The lessons in Unit 2 will help you configure this.
As you proceed, let us know how youâre doing, and if you need any additional help, you know where to find us!
I hope this has been helpful!
Laz
Hi,
For the statement: Trusting the Cos or DSCP value on the interface will set your trust boundary at the switch level.
Am I right in saying that if you only trust Cos OR DSCP, then the trust boundary is still at the switch? However, if you trust both - using the commands below - then the trust boundary is moved to the connected device because it is now accepting BOTH cos and DSCP values.
mls qos trust cos
mls qos trust cos pass-through
Is that statement correct?
Also, for the command:
switchport priority extend trust
Does that mean both DSCP and COS values are trusted from the PC? Also, with regard to COS, does that mean the phone port that connects to the PC is capable of 802.1q trunking?
Thanks.
Sam