From: Darby Weaver (ccie.weaver@gmail.com)
Date: Tue Jan 20 2009 - 04:22:46 ARST
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/
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