04-11-2011 08:28 AM - edited 03-06-2019 04:33 PM
"mls qos trust cos " ,How to trust?What's different betweeuse trust cos and trust DSCP parameter .or ask with another way : what to do the Switch when use "trust cos". what to do not trust by default?My understanding that it's effect is put classified traffic flow to specific queue, isn't it?
thanks a lot. Who knows????
04-11-2011 08:59 AM
Have a look at the command reference guide below. It goes over all the
options
04-13-2011 11:11 AM
hi,friend upstairs.i see the link.but I don`t understand still it.I am sorry.Can you help me ? Tell me Why? I am very confused .
I Want know How does switch do when default (no mls qos trust cos).
and My understand is that mls qos trust cos command according to CoS of frame put it into corresponding queue and mutate CoS to DSCP according to CoS-dscp map. packets are switchedas as best effort without any policing when qos trust state is not trust by default .Is my understand correct?
04-13-2011 11:23 AM
Switches always use an internal DSCP marking to make QOS decisions. This internal DSCP marking in not written into the packet.
If the port has "mls qos trust cos" then the switch will use the CoS marking in the packet. But because switches always use an internal DSCP marking the switch needs to derive a DSCP value from the CoS value. This is what the CoS-to-DSCP map is for.
The DSCP-to-CoS map would be used when the packet is being queued on the egress interface and the queue mappings were done using CoS values.
packets are switchedas as best effort without any policing when qos trust state is not trust by default .Is my understand correct?
Not sure what you mean by the above. If QOS is not enabled on the switch then all packets are treated the same.
Jon
09-15-2013 01:47 AM
Ports have 3 states :
- untrusted : all frames/packets incoming will leave the switch with 802.1p=0 and DSCP=0
- trust cos : switch will use cos-to-dscp and cos-to-queue (ingress and ingress) according to the incoming 802.1p value
- trust dscp : switch will use dscp-to-cos and dscp-to-queue (ingress and ingress) according to the incoming dscp value
There is a 4th state : conditionnal trust/marking with MQC but I will exclude the case
Then according to the model you use (cos-based or dscp-based) on each input port; you can define the marking of the output traffic (resp. DSCP value or 802.1p value you trust cos or DSCP).
If you issue the "mls trust cos" command on a port, the 802.1p-based QOS is selected for all incoming traffic on this port; then if you want to know which queue will be used and which DSCP value will be marked at egress; use "show mls qos maps cos-dscp" and "show mls qos maps cos-output-q"
Unlike what jon.marshall says, internal DSCP is marked to the packet at then end of the process when leaving the switch (in fact there is no "internal dscp"; the switch really uses a "QOS label"; internal DSCP is an unclear concept and should not be considered - of course if you want to do QOS on non-IP traffic, DSCP is a useless concept - think pure L2 protocols like ARP or Q-in-Q); the only exception is the application of the global command "no mls qos rewrite ip dscp" and it's called DSCP transparency - see slide 48 of the attached file; or use a 3750 with a wireshark at egress
There are a lot of good networkers sildes around Campus QOS (from 2960 to 6500) available from 2011 to 2013 :
BRKCRS-2501
BRKCRS-2500
BRKRST-2501
BRKRST-2500
There is no real "best effort" concept in the 3750; as soon as you enter the "mls qos" command in the config, a lot of underlying mechanisms are deployed (they don't appear as the switch use default value); for example; buffers on each interface are allocated at 25% for each queue at egress; the queue 1 is shape (rate limit+ BW guaranteed) at 25%; queue 2, 3 and 4use smooth round robin at 1/3 of the remaining bandwidth when queue 1 is full; otherwise if queue 1 is empty, queue 2, 3, 4 will share 1/3 (not limited) of the available bandwidth (so; all the link if q1 is empty)
09-15-2013 05:46 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
internal DSCP is an unclear concept and should not be considered
I respectively disagree. If the switch supports "internal marking" like DSCP's 6 bits, why not consider it? Of course not all switches offer DSCP like internal markings, 6500s internal COS (3 bits) comes to mind, but on other switches you can consider it.
There is a 4th state : conditionnal trust/marking with MQC but I will exclude the case
of course if you want to do QOS on non-IP traffic, DSCP is a useless concept - think pure L2 protocols like ARP or Q-in-Q);
You're correct concerning using IP ToS for the actual packet. But here's where the "internal" marking might come into use.
Consider if we you an explicit ingress policy, the "internal" QoS marking (hopefully DSCP like) might be used for QoS processing such a received packet.
There is no real "best effort" concept in the 3750; as soon as you enter the "mls qos" command in the config, a lot of underlying mechanisms are deployed (they don't appear as the switch use default value); for example; buffers on each interface are allocated at 25% for each queue at egress; the queue 1 is shape (rate limit+ BW guaranteed) at 25%; queue 2, 3 and 4use smooth round robin at 1/3 of the remaining bandwidth when queue 1 is full; otherwise if queue 1 is empty, queue 2, 3, 4 will share 1/3 (not limited) of the available bandwidth (so; all the link if q1 is empty)
Unclear what you mean with "There is no real 'best effort' concept in the 3750". What do you understand the "best effort" concept to be?
By default, you're correct when the 3750 QoS is enabled, 4 egress queues are enabled with default settings. However, part of the default QoS configuration is ingress markings are not trusted and are even erased. Effectively, all ingress traffic is treated alike, i.e. "best effort", although with the default buffer settings, the single "default marking" egress queue for all non-trusted traffic doesn't have the buffer resources the only egress queue has with QoS disabled.
BTW the 3750's default SRR share configuration of 25 0 0 0 is 1/25 (4%) of the bandwidth, it's not 25%. Although also by default a 3750's 4 egress queues are assigned 25% of the buffer space, the remaining default parameters usually don't reserve all this space for each egress queue and the unreserved buffer space may be acquired by other egress queues. I.e. (much) more than 25% might be actually actively (dynamically) allocated to an egress buffer. Lastly, with default shaping for queue 1, the queue doesn't have to be full to impact bandwidth sharing between Q1 and the other queues. With the usual default configuration, all 4 egress queues will share bandwidth equally except when Q1 traffic is being held due to shaping, then the other remaining queues will continue to share the bandwidth equally.
09-15-2013 06:50 AM
ooops, you're right about the shape mode in egress scheduling; it's 1/25 and not 25% (it's a bad idea to reply on a sunday morning)
I don't like the "internal dscp" concept because it doesn't apply to non IP traffic - it creates confusion to me; in fact the "internal QOS label" seems to be more accurate; also the "qos label" is used on newer platform (nexus 5k, also the cat4500 supports a "set qos-group" option)
also in the 3560/3750 platform; the management of the buffering system is quite cryptic (between the reserved pool; common pool for extra buffers...)
09-15-2013 11:32 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
also in the 3560/3750 platform; the management of the buffering system is quite cryptic (between the reserved pool; common pool for extra buffers...)
Yea, I found that true too until I can across: https://supportforums.cisco.com/docs/DOC-8093 See if that help explain.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide