cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2753
Views
0
Helpful
14
Replies

LAN QoS - How to tell switchport to re-assign CoS value to non-Phone?

Dean Romanelli
Level 4
Level 4

Hi All,

There is a command issued on the switchport that tells a Cisco IP Phone to trust the CoS of a station connected to said phone's access port, but to change the tag to a CoS value of your choosing. Example:

msl qos trust cos

switchport priority extend cos 3

What I have, however, is a station with important data traffic only capable of sending traffic on CoS 0, and no voice/phone.

So, I want to instruct the switchport to assign a CoS value of 3 to the traffic recieved from the stand-alone station PC.

Is there an IOS command that makes this possible without having a Cisco IP Phone between the switch port and the Station PC?

1 Accepted Solution

Accepted Solutions

Hi Dean,

Specifically, if the mls qos cos 3 command is ineffective for IP packets  and the port is configured to trust dscp, then how would an  administrator set the desired DSCP priority level for those packets  he/she wants?

What you request here contradicts itself. Trusting the DSCP means "the DSCP value is good and requires no rewriting" - why would you want to override the DSCP value, then?

Note that even for mls qos trust cos, the mls qos cos command applies only to those frames that have no CoS field present because the 802.1Q VLAN tag is missing. If the frame has a CoS field, the mls qos cos command does not apply. With mls qos trust dscp, a similar mls qos dscp command would have no sense: each IP packet has the DSCP field in its header, and non-IP packets have no DSCP whatsoever.

However, there is a way of actually classifying and possibly rewriting DSCP values in a more granular way using class-maps and policy-maps used in service-policy interface command. This command can be used instead of mls qos trust command and perform more in-depth, more elaborate classifying and DSCP value rewriting. See:

http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/15.0_2_se/command/reference/cli2.html#wp6193114

Best regards,

Peter

View solution in original post

14 Replies 14

Peter Paluch
Cisco Employee
Cisco Employee

Hi Dean,

So, I want to instruct the switchport to assign a CoS value of 3 to the traffic recieved from the stand-alone station PC.

Is there an IOS command that makes this possible without having a Cisco IP Phone between the switch port and the Station PC?

Yes, this can be accomplished using the mls qos cos command, e.g.:

mls qos trust cost

mls qos cos 3

This command causes all untagged frames (i.e. those not carrying any 802.1p CoS marking) to be treated as if they were marked with CoS 3. You can combine this command with switchport priority extend cos to tell the IP Phone to remark the priority in the PC's frames if they are tagged.

Best regards,

Peter

Thanks Peter.

So this will work even if I do not have an IP Phone in between switchport and the PC?

Do I have to issue the mls qos trust dscp command as well? Or would this only be used if my station is sending CoS packets and there is no phone in the path (i.e. force switch to read the DSCP packet as opposed to the layer 2 frame).

Hello Dean,

So this will work even if I do not have an IP Phone in between switchport and the PC?

Yes, that is correct. In fact, the situation with CoS markings is a little convoluted.

The CoS marking is a part of the 802.1Q VLAN tag, so to have an Ethernet frame CoS-marked, it actually has to be 802.1Q-tagged. Now, I have never seen an ordinary PC actually send tagged frames. While technically perfectly possible, drivers (at least under Windows) rarely support this feature for end-user PCs and related NIC cards. Experiments I have done with Windows OS clearly show that while applications are able to set the IP DSCP field to an appropriate value, the frames themselves were never tagged and hence they never carried a CoS marking.

The switchport priority extend cos command, to my best knowledge, causes a Cisco IP phone to overwrite the existing CoS marking in a frame received from PC only if it is already tagged. However, if the frame received from the PC is not tagged, the IP phone will not add an 802.1Q tag itself to the frame, and the frame will remain untagged. The switchport priority extend cos command has therefore no effect on untagged traffic sent from PC through the phone.

This is where the mls qos cos command comes in. This command applies to all untagged (and hence lacking any explicit CoS marking) frames received on a switchport. The presence of this command will cause the switch to treat the frames as if they had the CoS marking set to the particular value specified by this command. The mls qos cos command is relevant to the switch operation itself, and requires no IP phone anywhere between the PC and the switchport.

Do I have to issue the mls qos trust dscp command as well?

The mls qos trust cos and mls qos trust dscp commands are mutually exclusive. You can either trust the CoS marking or the DSCP field but not both. Once you trust one of them, the other value will be "normalized", or overwritten, according to the appropriate rewrite table (the cos-dscp rewrite table in case of trust cos, or dscp-cos rewrite table in case of trust dscp). While I believe you must configure some kind of mls qos trust command on a switchport to make the mls qos cos command effective (not 100% sure about this, though - can you make an experiment here please?), you can not trust both DSCP and CoS.

In general, though, my recommendation is to trust the DSCP instead of CoS. As the CoS marking is a part of 802.1Q VLAN tag, it is lost whenever the tag is removed - and this happens as soon as the frame is sent out another access port, or when the frame is received by a router and the packet is routed further, or thanks to native VLAN, etc... Hence, the scope of the CoS validity is at most within a single broadcast domain. DSCP marking, on the other hand, is maintained end-to-end.

The combination of mls qos trust dscp and mls qos cos commands results in IP packets being classified by their trusted DSCP fields, while non-IP frames will be classified according to the value configured in the mls qos cos command.

Best regards,

Peter

Peter,

Gotcha, very nice response. Just one follow up question:

If I choose to trust the dscp, then I set the qos cos to, say, 3:

mls cos trust dscp

mls qos cos 3

Since the switch is trusting the dscp marking and not the cos, then when traffic gets to the trunk port on the switch (which I believe also has to have trust commands configured), then won't that trunk port see the cos set to 3 on the incoming traffic, then set it to 0, since it was instructed to trust dscp and not cos?

Or does the cos still apply as long as you specify the cos value relevant to the dscp conversion (i.e. cos 3 = dscp 24)?

Hello Dean,

If I choose to trust the dscp, then I set the qos cos to, say, 3:

mls cos trust dscp

mls qos cos 3

The switch will trust DSCP whenever present. The mls qos cos 3 specifies a so-called default CoS value that is used if no other CoS value can be derived from the incoming frame. This means there are following possibilities:

  • The incoming frame carries an IP packet. The DSCP is always present in IP packets, so for IP packets, the mls qos cos 3 command will be ineffective. If the frame is to be forwarded as a tagged frame, the CoS value will be established using the dscp-cos rewrite table
  • The incoming frame does not carry an IP packet but it is tagged. In that case, the CoS marking in the frame will be trusted and used.
  • The incoming frame does not carry an IP packet and is not tagged. In that case, the mls qos cos 3 command will apply as the default CoS.

This behavior is documented here:

http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/15.0_2_se/command/reference/cli1.html#wp11906329

Does this answer your question?

Best regards,

Peter

Hi Peter,

Yes, it is coming together.

The only thing I am still sketchy on is your bullet point 1 - Specifically, if the mls qos cos 3 command is ineffective for IP packets and the port is configured to trust dscp, then how would an administrator set the desired DSCP priority level for those packets he/she wants?

There doesn't appear to be a "mls qos dscp command option.

Hi Dean,

Specifically, if the mls qos cos 3 command is ineffective for IP packets  and the port is configured to trust dscp, then how would an  administrator set the desired DSCP priority level for those packets  he/she wants?

What you request here contradicts itself. Trusting the DSCP means "the DSCP value is good and requires no rewriting" - why would you want to override the DSCP value, then?

Note that even for mls qos trust cos, the mls qos cos command applies only to those frames that have no CoS field present because the 802.1Q VLAN tag is missing. If the frame has a CoS field, the mls qos cos command does not apply. With mls qos trust dscp, a similar mls qos dscp command would have no sense: each IP packet has the DSCP field in its header, and non-IP packets have no DSCP whatsoever.

However, there is a way of actually classifying and possibly rewriting DSCP values in a more granular way using class-maps and policy-maps used in service-policy interface command. This command can be used instead of mls qos trust command and perform more in-depth, more elaborate classifying and DSCP value rewriting. See:

http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/15.0_2_se/command/reference/cli2.html#wp6193114

Best regards,

Peter

Hi Peter,

I see what you're saying now. Basically there is no need to manipulate the dscp value because it is already calculated correctly, if it exists, and if a frame is sent with a cos field, the cos value in the cos field is maintained, regardless of administrator specified cos values on the switchport. The only time the value is applied is if the traffic recieved on the port contains no cos field.

So in that case, if a station/PC that cannot send any 802.1p/QoS info transmits data to a switchport that is configured to trust the dscp field, then how does the DSCP know what level to classify that data as if the station/PC is incapable of performing/mandating any sort of QoS?

Hello Dean,

I suppose that all following discussion is related to mls qos trust dscp

Basically there is no need to manipulate the dscp value because it is already calculated correctly, if it exists

Whether the value is really calculated correctly is a matter of trust - it may or may not be, as there may be an attacker spoofing a high priority DSCP setting for his/her data packets. However, once you say mls qos trust dscp you are stating that you are going to trust the DSCP settings no matter what. It is you who is saying that the DSCP are calculated correctly by trusting them.

and if a frame is sent with a cos field, the cos value in the cos field  is maintained, regardless of administrator specified cos values on the  switchport

This is slightly ambiguous because you may have a frame carrying an IP packet that also has a CoS field, or you may have a non-IP frame carrying a CoS field. In the first case, the DSCP is trusted and CoS will be rewritten according to the dscp-cos table. In the second case, the CoS field will be trusted.

The only time the value is applied is if the traffic recieved on the port contains no cos field.

More precisely, no DSCP (i.e. no IP) and no CoS field.

So in that case, if a station/PC that cannot send any 802.1p/QoS info  transmits data to a switchport that is configured to trust the dscp  field, then how does the DSCP know what level to classify that data as  if the station/PC is incapable of performing/mandating any sort of QoS?

Dean, can you say this in different words? I am afraid I do not understand this question.

Best regards,

Peter

Hi Peter,

Certainly.  If I have the below:

Station PC------------------Switchport on Access Switch

1. The station PC above which is not capable of sending any QoS classification information sends an IP packet.

2. However, I want this traffic to be classified with a higher priority than CoS/DSCP 0 (Default/Best Effort).

2. The switchport on my access switch is configured to trust the dscp value in the dscp field, and recieves the packet.

How can I be assured that the dscp field will assign the priority I desire for this traffic if the recieved IP packet originated from a station that does not assign any DSCP/CoS/Qos priority values?  How do I know the dscp priority in the dscp field will be the priority I desire the traffic to be classified as?

Hi Dean,

I see your point now. Thank you.

How can I be assured that the dscp field will assign the priority I  desire for this traffic if the recieved IP packet originated from a  station that does not assign any DSCP/CoS/Qos priority values?

Please keep in mind that while the station may not be capable of performing L2 QoS marking using 802.1p CoS bits in an Ethernet frame, it should always be able to perform L3 IP DSCP marking because the DSCP field is a mandatory field of an IP header. Even though the application software and/or the TCP/IP driver on the PC may lack the functionality of setting custom DSCP values, the DSCP field will nonetheless be present in all IP packets sent from the PC. Therefore, the mls qos trust dscp command can not be used here because in all received IP packets, the DSCP value (even if set to 0) would be trusted.

Instead, in this case, you would need to perform the classification and potentially DSCP rewriting yourself using class-map and policy-map constructs that would be applied on the switchport using the service-policy command. Are you familiar with this approach?

Best regards,

Peter

Hi Peter,

I see now.  Makes sense, thank you.  So basically if I want to send traffic with QoS classification outside of it's originating broadcast domain, I need to set a service policy on the port for dscp for the traffic (if the station cannot send custom dscp info) to ensure it will be end to end and have the priority I want, but if the destination for the traffic resides within the broadcast domain, I should use CoS instead.

I've heard of service-policies for QoS but I've never implemented them myself.  However, I defintely see what you're saying now.  Thanks for all your help with this. I really appreciate you dealing with all my follow up questions, haha.

Hi Dean,

I think you are trying too much to have a clear delineation when to use CoS and when to use DSCP. I suggest taking one step backwards and see the entire issue from a larger perspective.

Ideally, we should be using DSCP markings for absolutely all traffic, both for communication within a broadcast domain and for traffic going out of its originating broadcast domain. Why? Because DSCP marking does not need any modification to the existing IP header as it is already there, can be relatively easily set by the communicating applications, and regardless of the Layer2 technology in use, it is maintained end-to-end. In fact, with DSCP, it would appear there is absolutely no need for CoS.

And for IP traffic, that would be true. However, not all traffic is IP based, so for non-IP traffic, there is no DSCP marking available. In addition, while Catalyst switches recognize and honor the DSCP marking, the same can not be said about all switches of all vendors in general. Some switches disregard CoS and DSCP altogether, and some other switches understand and honor only CoS markings. Therefore, especially in a mixed vendor environment, you actually want to have your traffic QoS-marked both by DSCP and CoS to make sure every device on the path knows how to treat the traffic. Ideally, the DSCP should dictate the treatment. If the packet is not IP, or the device does not support DSCP-based QoS, the CoS marking can be used instead.

Note that this is actually what Catalyst switches do all the time. You either trust CoS or DSCP, and the other value will be automatically determined using the cos-dscp or dscp-cos maps and possibly rewritten in the forwarded datagram if present. If you accept an IP packet and trust its DSCP, the switch will also determine the CoS value using the dscp-cos map. If the frame is forwarded out another access port, the CoS value will be simply forgotten as there is no further use for it. If the frame is forwarded out a trunk port, the added VLAN tag will have the CoS markings set according to the dscp-cos map.

So ideally, DSCP should be used all the time but it is not always available or understood, therefore we have an option of marking the packets using CoS as well.

Best regards,

Peter

Peter,

Gotcha.  I'm with you now.  Thanks for that extra bit of info.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: