From: Darby Weaver (ccie.weaver@gmail.com)
Date: Tue Jan 20 2009 - 05:59:38 ARST
Global command that is disabled by default. If DSCP transparency is enabled
by using the no mls qos rewrite ip dscp command, the switch does not modify
the DSCP field in the incoming packet, and the DSCP field in the outgoing
packet is the same as that in the incoming packet.
I think what is being conveyed here is that if you turn off mls qos rewrite,
then your packets will NOT get rewritten as they transit "that switch" and
that switch only. Therefore the DSCP field in the outgoing packet would
remain as it was when it entered the switch either from another switch or
from a trusted port/interface.
On 1/20/09, Pavel Bykov <slidersv@gmail.com> wrote:
>
> I agree with what you posted now, but i still do not see the context you
> are talking about here in your previous post.
>
> E.G.: from the following lines I understood that you talk about turning
> off (disabling) DSCP transparency with "mls qos rewrite ip dscp" command.
----------------------------
> Cat3560(config)# mls qos rewrite ip dscp
>
> disable DSCP transparency to allow switch to modify DSCP values based on
> trust or ACL
> ----------------------------
>
> And from the following lines I understood that the other option to work
> with transparency is to set trust... Which is also not true as you have
> posted in your second post as well, because even if you do trust DSCP, and
> DSCP rewrite is on, DSCP premutation will rewrite the output DSCP...
True enough and agreed.
----------------------------
> -OR-
>
> Cat3560(config)# no mls qos rewrite ip dscp
>
> Cat3560(config-if)# mls qos trust [cos | dscp ] does the same thing per
> interface
> ----------------------------
>
> And in fact when you do type in the "no mls qos rewrite ip dscp" command,
> any trust is irrelevant to output DSCP, since it will not be changed.
>
> Basically, after commands:
> Cat3560(config)# mls qos
> Cat3560(config)# no mls qos rewrite ip dscp
>
> Trust is irrelevant to output DSCP. And to me that seemed to contradict
> your statements after "-OR-"
I think this is where communications are breaking down.
1. If we do nothing and leave qos off - we effectively have transparency by
the very fact that DSCP is unchanged - HOWEVER: We are not able to priortize
our traffic. Note: the difference between classify and prioritze.
2. If turn one mls qos and if we also turn off mls qos rewrite, then we have
can now prioritze the trusted traffic as we see fit - and we now get the
benefit of "no remarking" and we can also prioritize our traffic.
I think the guys teaching the QoS classes tend to favor soltions akin to
this given the amount of emphasis my co-workers have conveyed to me on
simply using trust as almost a panacea for a solution - one size fits all.
At least that's how I'm interpretting it. Someone might need to bail me
ouit here if I'm not saying this or conveying my thoughts properly.
But this is how I interpretted the usage of the command and its intended
usage.
So basically it is saying: I want to use mls qos and I want to trust the
values (from the input interface) - I may want to change the queueing (for
instance) of packets marked with a certain DSCP value as they enter or leave
the switch, but I do NOT want to rewrite the DSCP values.
Now the next switch inline may or may not feel the same way about its
policies towards the marked packets.
Always nice to have the same or complementary policies on switches that are
maintained by the same person.
On Tue, Jan 20, 2009 at 7:22 AM, Darby Weaver <ccie.weaver@gmail.com>wrote:
>
>> I think you misunderstood the context of the post.
>>
>> 1. If you do not turn on mls qos then a switch will not re-write the DSCP
>> values - it simply passes them on. This is simple but allows no "special
>> treatment" of packets that require a little tender loving care.
>>
>> 2. If you turn on mls qos and do not configure the interfaces then you
>> effectively will have re-written the DSCP values to "0". Such that a packet
>> marked with DSCP 46 would be remarked to DSCP 0. Not Kewl... So...
>>
>> 3. If you trust the DSCP/COS Marking as per the reference you called me
>> on.... and if you simply configure this simply command throughout your
>> network - you will have achieved "DSCP transparency" effectually given that
>> your markings will be maintained throughout your network.
>>
>> - Now I'm not speaking theoretically here. I am speaking authoritatively
>> and practically. In fact, I've recently had to contend with a Video
>> Conferencing Solution that was in a "DSCP Transparency State" such that the
>> marking were trusted on a per-interface basis and they were carried
>> throughout the network as such. This was verified first simply by using
>> interface commands, second by matching the DSCP values with ACLs, and
>> finally end to end using Wireshark as the Sniffer and looking for explicitly
>> for the DSCP values in the packet as a final verification.
>>
>>
>> No the command itself does not guarantee transparency in a literal
>> context. However, if the DSCP value is being carried throughout the network
>> and "not being re-written" then it is "effectually transparent" in that it
>> did not change or get re-marked or re-written with another value.
>>
>>
>> Now where do we use this is our day-to-day lives?
>> -----------------------------------------------------------------------
>>
>> 1. VoIP comes to mind as the most prominent application where we like DSCP
>> 46.
>>
>> 2. Video Conferencing also is quite prominent.
>>
>> 3. Campus Networks and Enterprise Networks.
>>
>> 4. Savoir Faire is Everywhere!!!!
>>
>> 5. Basically we can use this as a technique to classify and manage any
>> type of traffic either preferentially or not preferentially from anywhere in
>> our networks based on these DSCP Code Points or CoS values.
>>
>>
>>
>>
>>
>>
>>
>>
>> On 1/19/09, Pavel Bykov <slidersv@gmail.com> wrote:
>>>
>>> Darby:
>>> *Cat3560(config-if)# mls qos trust [cos | dscp ] does the same thing per
>>> interface*
>>>
>>> No, I don't think it does. This command sets the trust mode. Here is my
>>> understanding of it with quick example with trust CoS and DSCP rewrite
>>> (without complicating thing too much).
>>>
>>> 1.
>>> Trust setting: Trust CoS
>>> DSCP rewrite setting: OFF
>>> Incoming Packet: Cos = 0, DSCP = 46
>>>
>>> Packet comes in, CoS > DSCP map is 0 > 0. Internally, CoS is 0, DSCP is
>>> also 0. Queue is selected based on that. Packet is placed into a Queue with
>>> CoS 0, but since rewrite was off, DSCP was left the same at 46.
>>> Output Packet: CoS = 0, DSCP = 46
>>>
>>> 2.
>>> Trust setting: Trust CoS
>>> DSCP rewrite setting: ON
>>> Incoming Packet: Cos = 0, DSCP = 46
>>>
>>> Packet comes in, CoS > DSCP map is 0 > 0. Internally, CoS is 0, DSCP is
>>> also 0. Queue is selected based on that. Packet is placed into a Queue with
>>> CoS 0.
>>> Since rewrite is on, DSCP is set to calculated value, i.e. 0
>>> Output Packet: CoS = 0, DSCP = 0
>>>
>>> 3.
>>> Trust setting: Trust DSCP
>>> DSCP rewrite setting: OFF
>>> Incoming Packet: Cos = 0, DSCP = 40
>>>
>>> Packet comes in, DSCP > Internal DSCP map is used, where 40 maps to 46.
>>> Queue is selected based on that. Packet is placed into a Queue with CoS,
>>> that is calculated from DSCP > CoS map, where 46 maps to 5. Notice, 46 is
>>> used for calculation.
>>> But since rewrite is off, 40 is left in the header. DSCP is not set to
>>> calculated value.
>>> Output Packet: CoS = 0, DSCP = 40
>>>
>>> 4.
>>> Trust setting: NO TRUST (default)
>>> DSCP rewrite setting: OFF
>>> Incoming Packet: Cos = 0, DSCP = 46
>>>
>>> Packet comes in, CoS > DSCP map is 0 > 0. Internally, CoS is 0, DSCP is
>>> also 0. Queue is selected based on that. Packet is placed into a Queue with
>>> CoS 0.
>>> Since rewrite was off, DSCP was left the same at 46.
>>> Output Packet: CoS = 0, DSCP = 46
>>>
>>>
>>>
>>> On Tue, Jan 20, 2009 at 12:33 AM, Darby Weaver <ccie.weaver@gmail.com>wrote:
>>>
>>>> *DSCP Transparency *
>>>>
>>>> *DSCP Transparency is a Cat3560 feature.*
>>>>
>>>> Global command that is disabled by default. If DSCP transparency is
>>>> enabled
>>>> by using the no mls qos rewrite ip dscp command, the switch does not
>>>> modify
>>>> the DSCP field in the incoming packet, and the DSCP field in the
>>>> outgoing
>>>> packet is the same as that in the incoming packet.
>>>>
>>>> Cat3560(config)# mls qos rewrite ip dscp
>>>>
>>>> disable DSCP transparency to allow switch to modify DSCP values based on
>>>> trust or ACL
>>>>
>>>> -OR-
>>>>
>>>> Cat3560(config)# no mls qos rewrite ip dscp
>>>>
>>>> Cat3560(config-if)# mls qos trust [cos | dscp ] does the same thing per
>>>> interface
>>>>
>>>> *Passthrough Option is a 3550 Feature:*
>>>>
>>>> Cat3550(config-if)# mls qos trust [cos | dscp] pass-through [ dscp |
>>>> cos]
>>>>
>>>> Forces Cat to treat CoS and DSCP independently. So, it trusts one and
>>>> doesn't change the other marked as pass-through.
>>>>
>>>>
>>>>
>>>> On 1/19/09, Raghav Bhargava <raghavbhargava12@gmail.com> wrote:
>>>> >
>>>> > HI experts,
>>>> >
>>>> > I am not able to understand to the DSCP Transparency Mode in QOS. Can
>>>> > anyone shed some light on it.
>>>> > I am studying it from the Configuration Guide of Catalyst 3560.
>>>> >
>>>> > --
>>>> > Warm Regards
>>>> > Raghav
>>>> >
>>>> >
>>>> > Blogs and organic groups at http://www.ccie.net
>>>> >
>>>> >
>>>> _______________________________________________________________________
>>>> > Subscription information may be found at:
>>>> > http://www.groupstudy.com/list/CCIELab.html
>>>>
>>>>
>>>> Blogs and organic groups at http://www.ccie.net
>>>>
>>>> _______________________________________________________________________
>>>> Subscription information may be found at:
>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Pavel Bykov
>>> ----------------
>>> Don't forget to help stopping the braindumps, use of which reduces value
>>> of your certifications. Sign the petition at
>>> http://www.stopbraindumps.com/
>>>
>>
>>
>>
>
>
>
> --
> Pavel Bykov
> ----------------
> Don't forget to help stopping the braindumps, use of which reduces value of
> your certifications. Sign the petition at http://www.stopbraindumps.com/
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:43:39 ARST