How to configure QoS trust boundary on Cisco Switches

gaby.ochoa · June 12, 2019, 10:02pm

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!

lagapidis · June 25, 2019, 9:35am

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

staut_stefanita · June 26, 2019, 9:21pm

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

lagapidis · June 27, 2019, 3:38pm

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

mrayubzada · September 23, 2019, 3:19pm

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.

lagapidis · September 24, 2019, 5:29am

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

mrayubzada · October 1, 2019, 7:55am

Thanks Laz now it is clear.

ankisang · October 7, 2019, 2:58pm

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.

lagapidis · October 8, 2019, 7:05am

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

sherry.safdar · December 17, 2019, 8:02am

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,

lagapidis · December 17, 2019, 12:04pm

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

castrojuanj · March 26, 2020, 10:01pm

MLS QoS is only in inbound ?

I’ve seen on Huawei they call it “trust upstream” but you can configure inbound and outbound

lagapidis · March 27, 2020, 8:13am

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

helen_power · April 22, 2020, 3:59am

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

lagapidis · April 22, 2020, 12:11pm

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

helen_power · April 22, 2020, 2:55pm

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,

lagapidis · April 23, 2020, 1:32pm

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

mdella · December 17, 2020, 7:40pm

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…

lagapidis · December 19, 2020, 11:11am

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

samirkhair · January 11, 2021, 2:52pm

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