Re: MLS QOS

From: marc edwards <renorider_at_gmail.com>
Date: Sat, 26 May 2012 08:36:52 -0700

*This is the whole point of the previous question! If you use "trust DSCP"
then the switch will indeed use DSCP and not COS.*
*
*
Carlos, if trusting DSCP, the switch will use it's mappings to correlate
the packet's DSCP value to the frame's COS value. Switches deal with
frames, hense the use of COS. Please show me evidence that supports
otherwise.

Marc

On Sat, May 26, 2012 at 8:25 AM, Carlos G Mendioroz <tron_at_huapi.ba.ar>wrote:

> marc edwards @ 26/05/2012 11:55 -0300 dixit:
>
> 1) doesn't matter because the switch will use it's mappings to take dscp
>> value and convert to associated cos more importantly the mappings have
>> to be adjusted. either command is good but I would also add a 'switchpot
>> voice vlan XX' putting the phone into another network and 'mls qos trust
>> device cisco-phone'. These commands will put cisco phones on another
>> vlan and use macros to ensure .1p is set up properly.
>>
>
> It does matter.
> It is how you tell the switch to decide which marking is for good, and
> ignore the other. cos-to-dscp is only used if you decide to trust COS,
> otherwise the DSCP goes straight into internal DSCP. dscp-to-cos is used on
> output to create the L2 marking if needed.
>
> But you also can use trust extend, which instructs the phone (switch) to
> remark PC's packets (or should I say frames) with a given COS. That is the
> remarking that I was referring to.
>
>
> 2) The Cisco phones will most likely mark both but switch will only use
>> CoS. The DSCP values are adjusted based on the internal switch mappings.
>> This mapping is not ideal left to default values and is typically fixed
>> manually. I don't know why cisco just didn't make it default. ... This
>> command : 'mls qos map cos-dscp 0 8 16 24 32 46 48 56' is used in global
>> config to map EF (IP precedence 5) to the dscp value 46.
>>
>
> What do you mean by "switch will only use COS" ?? This is the whole point
> of the previous question! If you use "trust DSCP" then the switch will
> indeed use DSCP and not COS.
>
> The mapping is older than DSCP, at least older than any DSCP usage
> standarization, I would guess.
>
> -Carlos
>
>>
>> You are taking the right steps for Catalyst QoS good luck!
>>
>> HTH
>>
>> Marc
>>
>> On Sat, May 26, 2012 at 5:04 AM, Carlos Mendioroz <tron_at_huapi.ba.ar
>> <mailto:tron_at_huapi.ba.ar>> wrote:
>>
>> COS fpr sure.
>> Phones mark COS & DSCP but only remark COS, so if you want tp extend
>> the
>> trust border, you have tp trust COS.
>> -Carlos
>>
>> --
>> Carlos Mendioroz <tron_at_acm.org <mailto:tron_at_acm.org>>
>>
>>
>> -----Original message-----
>> From: Vincent Tay <vtay.75_at_gmail.com <mailto:vtay.75_at_gmail.com>>
>> To: "Ccielab_at_groupstudy.com <mailto:Ccielab_at_groupstudy.com**>"
>> <ccielab_at_groupstudy.com <mailto:ccielab_at_groupstudy.com**>>
>> Sent: Sat, 26 May 2012, 05:36:38 GMT+00:00
>> Subject: MLS QOS
>>
>> Hi all,
>>
>> I got the below questions to clarify.
>>
>> 1) When a cisco VoIP phone is connected to a switchport, which is
>> better?
>> mls qos trust dscp or mls qos trust cos?
>>
>> 2) The cisco phone will mark cos or dscp value or both? If mls qos
>> trust
>> cos is use, must i map the cos 5 to dscp 46 manually?
>>
>> Regards
>> Vincent Tay
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> ______________________________**______________________________**
>> ___________
>> Subscription information may be found at:
>> http://www.groupstudy.com/**list/CCIELab.html<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<http://www.groupstudy.com/list/CCIELab.html>
>>
>>
>>
>>
>>
>>
>>
>>
>>
> --
> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina

Blogs and organic groups at http://www.ccie.net
Received on Sat May 26 2012 - 08:36:52 ART

This archive was generated by hypermail 2.2.0 : Sun Jun 17 2012 - 09:04:20 ART