Re: 3650 COS/DSCP to queue mapping

That's what I would call a gotcha!
Now I would assume that the dscp-to-cos is only used when you trust dscp
on ingress ?

To be honest, what Joe was expecting is what I would have expected.
I'm still inclined to believe that this is what happens on a 6k,
although I would test it before being assertive about it ;-)

-Carlos

Joe Astorino @ 05/09/2012 04:08 -0300 dixit:
> In an effort to make sure I am not completely losing my mind I set out
> to figure out where I had gotten this notion. I believe it is
> something I learned back in the day about the catalyst 3550 and NOT
> the 3560. Check this out from the 3550 software configuration guide
> here: http://www.cisco.com/en/US/docs/switches/lan/catalyst3550/software/release/12.1_19_ea1/configuration/guide/swqos.html#wp1023211
>
> "Before the traffic reaches the scheduling stage, QoS uses the
> configurable DSCP-to-CoS map to derive a CoS value from the internal
> DSCP value. Through the CoS-to-egress-queue map, the CoS values select
> one of the four egress queues for output processing."
>
> In the same section (look for "mapping tables") in the 3560 guide,
> this has been changed to read:
>
> "Before the traffic reaches the scheduling stage, QoS stores the
> packet in an ingress and an egress queue according to the QoS label.
> The QoS label is based on the DSCP or the CoS value in the packet and
> selects the queue through the DSCP input and output queue threshold
> maps or through the CoS input and output queue threshold maps"
>
> NOW...since I just so happen to have some 3550's here in my home lab I
> re-ran the same test and received the same results we did with the
> 3560 as far as MARKING is concerned. But I believe what the 3550
> guide here is saying is that the output queue was based on the
> internal mapping. So, on the 3550 I believe we had the CoS mapped to
> internal DSCP then internal DSCP mapped to CoS and CoS mapped to
> output queue. Seems the output queue was effected by the internal
> mappings, but not the marking itself
>
> So in summary -- It looks like based on testing and documentation that
> the 3550 did something like I was saying at least for outbound
> queueing but that the 3560 has a different approach
>
>
> On Wed, Sep 5, 2012 at 1:36 AM, ccie99999 <ccie99999_at_gmail.com> wrote:
>> sorry.. Joe.. just reloaded everything and I cannot use those switches now.
>>
>> anyway.. nothing special:
>>
>> pc1 side: cos3 + cos override.. as explained in the test
>> pc2 side: nothing.. no trust, no override.. nothing..
>>
>>
>>
>> On Wed, Sep 5, 2012 at 5:25 AM, Joe Astorino <joeastorino1982_at_gmail.com>wrote:
>>
>>> 99999,
>>>
>>> Can you post your configurations? I would like to see on both
>>> interfaces what you have configured for trust and other things.
>>>
>>> On Tue, Sep 4, 2012 at 1:46 PM, marc edwards <renorider_at_gmail.com> wrote:
>>>>
>>> http://www.cisco.com/en/US/docs/switches/lan/catalyst3750x_3560x/software/release/12.2_58_se/configuration/guide/swqos.html#wp1023954
>>>>
>>>>
>>>> Chart really says it all. What I find interested and (supporting your
>>> view)
>>>> is the fact that DSCP-to-CoS is never used....
>>>>
>>>> On Tue, Sep 4, 2012 at 9:04 AM, marc edwards <renorider_at_gmail.com>
>>> wrote:
>>>>
>>>>> So on those thoughts.... We need to trust dscp. trusting cos throughout
>>>>> will bypass switch from looking at dscp markings. trusting dscp will
>>> make
>>>>> switch look into packet to see dscp markings and use mappings to
>>> convert a
>>>>> cos value. This should hit the dscp-cos map and reference values from
>>>>> altered config.
>>>>>
>>>>> Marc
>>>>>
>>>>>
>>>>> On Tue, Sep 4, 2012 at 8:55 AM, marc edwards <renorider_at_gmail.com>
>>> wrote:
>>>>>
>>>>>> So... looks like you are tagging frames on PC NIC? Where is vlan 1
>>> vlan 2
>>>>>> config or are these PC's in same VLAN/subnet? Where is 'mls qos trust
>>> cos'
>>>>>> on fa 0/2?
>>>>>>
>>>>>> Marc
>>>>>>
>>>>>>
>>>>>> On Tue, Sep 4, 2012 at 8:46 AM, ccie99999 <ccie99999_at_gmail.com> wrote:
>>>>>>
>>>>>>> Command was like: MLS qos map dscp-cos 24 to 5
>>>>>>>
>>>>>>> Show mls QoS dscp-cos shows it's mapped correctly
>>>>>>> Il giorno 04/set/2012 17:35, "marc edwards" <renorider_at_gmail.com> ha
>>>>>>> scritto:
>>>>>>>
>>>>>>>> can you please provide command entered for dscp-cos map config?
>>>>>>>>
>>>>>>>> On Tue, Sep 4, 2012 at 8:31 AM, ccie99999 <ccie99999_at_gmail.com>
>>> wrote:
>>>>>>>>
>>>>>>>>> I did cos 3 + cos override on pc1 side and trust dscp on pc2 side.
>>>>>>>>> I can't do a show mls qos maps now but I set up a dscp24 to cos5
>>>>>>> mapping.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Sep 4, 2012 at 3:30 PM, marc edwards <renorider_at_gmail.com>
>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Can either of you do a sh mls qos maps? Also, please show access
>>>>>>>>>> interfaces config. My hunch is that the dscp-cos map hasn't been
>>>>>>>>> changed to
>>>>>>>>>> refelect dscp 24 as cos 05. I am also curious to see if you have
>>>>>>> trusted
>>>>>>>>>> cos or dscp on access. That will change things.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Marc
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Sep 4, 2012 at 8:23 AM, ccie99999 <ccie99999_at_gmail.com>
>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> I've labbed this (cos3->dscp24->cos5) and I see I receive cos3
>>> on
>>>>>>> the
>>>>>>>>>>> second pc as well as dscp24.
>>>>>>>>>>>
>>>>>>>>>>> pc1(vlan1) - sw - pc2(vlan2)
>>>>>>>>>>>
>>>>>>>>>>> (I do trust cos on pc2 interface side).
>>>>>>>>>>>
>>>>>>>>>>> I guess it's fine I see dscp24.. don't understand why I see
>>> cos3.
>>>>>>>>>>>
>>>>>>>>>>> thanks
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Sep 4, 2012 at 12:33 PM, gp <gs4me2me_at_gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Joe,
>>>>>>>>>>>>
>>>>>>>>>>>> I tried lab what you wrote, and not have result that I
>>> expected.
>>>>>>> So I
>>>>>>>>>>> have
>>>>>>>>>>>> one question; in your opinion what cos value will have frame
>>> when
>>>>>>>>> leave
>>>>>>>>>>>> switch: cos 3 or cos 5?
>>>>>>>>>>>>
>>>>>>>>>>>> I had cos 3, that confuse me.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On
>>>>>>>>> Behalf Of
>>>>>>>>>>>> Joe
>>>>>>>>>>>> Astorino
>>>>>>>>>>>> Sent: Thursday, August 30, 2012 6:34 PM
>>>>>>>>>>>> To: Anthony Sequeira
>>>>>>>>>>>> Cc: Matt Eason; Cisco certification
>>>>>>>>>>>> Subject: Re: 3650 COS/DSCP to queue mapping
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Matt,
>>>>>>>>>>>>
>>>>>>>>>>>> Anthony answered your question simply and correctly, but I
>>> just
>>>>>>>>> wanted
>>>>>>>>>>> to
>>>>>>>>>>>> add some things that helped me understand this. Like Anthony
>>>>>>> said,
>>>>>>>>>>>> whatever
>>>>>>>>>>>> you trust is basically how the switch determines the queue at
>>> a
>>>>>>> high
>>>>>>>>>>> level,
>>>>>>>>>>>> but at a deeper level there are a few different mappings going
>>>>>>> on.
>>>>>>>>>>> Let's
>>>>>>>>>>>> assume you trust CoS. You would have:
>>>>>>>>>>>>
>>>>>>>>>>>> - CoS to DSCP mapping INTERNAL to the switch
>>>>>>>>>>>> - DSCP to CoS mapping INTERNAL to the switch
>>>>>>>>>>>> - CoS to output queue mapping
>>>>>>>>>>>>
>>>>>>>>>>>> The point I am making is that even though a frame comes in
>>> with a
>>>>>>>>>>>> particular
>>>>>>>>>>>> CoS value, that value COULD change internally based on the
>>>>>>> internal
>>>>>>>>>>>> COS-DSCP
>>>>>>>>>>>> and DSCP-COS, and the frame COULD be queued based on the value
>>>>>>>>> derived
>>>>>>>>>>> from
>>>>>>>>>>>> the internal mappings and not on the original value. Let's
>>> look
>>>>>>> at
>>>>>>>>> some
>>>>>>>>>>>> example output for a second
>>>>>>>>>>>>
>>>>>>>>>>>> Here are some mapping tables for cos-dscp, dscp-cos and
>>>>>>> cos-output-q
>>>>>>>>> on
>>>>>>>>>>> a
>>>>>>>>>>>> 3750 switch. Note these are probably not default values
>>> because
>>>>>>> this
>>>>>>>>> is
>>>>>>>>>>> a
>>>>>>>>>>>> production switch.
>>>>>>>>>>>>
>>>>>>>>>>>> Here is the COS to DSCP mapping:
>>>>>>>>>>>>
>>>>>>>>>>>> switch#sh mls qos maps cos-dscp
>>>>>>>>>>>> Cos-dscp map:
>>>>>>>>>>>> cos: 0 1 2 3 4 5 6 7
>>>>>>>>>>>> --------------------------------
>>>>>>>>>>>> dscp: 0 8 16 24 32 40 48 56
>>>>>>>>>>>>
>>>>>>>>>>>> Here is the DSCP to CoS mapping
>>>>>>>>>>>>
>>>>>>>>>>>> switch#sh mls qos map dscp-cos
>>>>>>>>>>>> Dscp-cos map:
>>>>>>>>>>>> d1 : d2 0 1 2 3 4 5 6 7 8 9
>>>>>>>>>>>> ---------------------------------------
>>>>>>>>>>>> 0 : 00 00 00 00 00 00 00 00 01 01
>>>>>>>>>>>> 1 : 01 01 01 01 01 01 02 02 02 02
>>>>>>>>>>>> 2 : 02 02 02 02 03 03 03 03 03 03
>>>>>>>>>>>> 3 : 03 03 04 04 04 04 04 04 04 04
>>>>>>>>>>>> 4 : 05 05 05 05 05 05 05 05 06 06
>>>>>>>>>>>> 5 : 06 06 06 06 06 06 07 07 07 07
>>>>>>>>>>>> 6 : 07 07 07 07
>>>>>>>>>>>>
>>>>>>>>>>>> Finally, here is the CoS to output queue mapping
>>>>>>>>>>>>
>>>>>>>>>>>> switch#sh mls qos map cos-output-q
>>>>>>>>>>>> Cos-outputq-threshold map:
>>>>>>>>>>>> cos: 0 1 2 3 4 5 6 7
>>>>>>>>>>>> ------------------------------------
>>>>>>>>>>>> queue-threshold: 2-1 2-1 3-1 3-1 4-1 1-1 4-1 4-1
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Let's just look at CoS 3 for example. We see that CoS 3 is
>>>>>>> mapped to
>>>>>>>>>>> DSCP
>>>>>>>>>>>> 24. In turn DSCP 24 is mapped right back to CoS 3 in the DSCP
>>>>>>> to COS
>>>>>>>>>>>> mapping. In turn, CoS 3 is put into output queue 3,
>>> threshold 1.
>>>>>>>>>>>> Fine. So in this case, it comes in as CoS 3 and is queued
>>> based
>>>>>>> on
>>>>>>>>> CoS
>>>>>>>>>>> 3
>>>>>>>>>>>> because we trust CoS and because the DSCP-COS mapping is sort
>>> of
>>>>>>>>>>> "synced".
>>>>>>>>>>>> But...what if you went in and mucked with the DSCP-COS mapping
>>>>>>>>>>> internally
>>>>>>>>>>>> such that DSCP 24 was no longer mapped back to CoS 3? What if
>>>>>>> it was
>>>>>>>>>>>> re-mapped to CoS 5 ?
>>>>>>>>>>>>
>>>>>>>>>>>> So you COULD have the frame come in as CoS 3 ...internally we
>>> go
>>>>>>> CoS
>>>>>>>>> 3
>>>>>>>>>>>> --> DSCP 24, then DSCP 24 to CoS 5 then queued based on CoS 5
>>>>>>>>>>>>
>>>>>>>>>>>> These are intricate details, but when you are studying for the
>>>>>>> lab, I
>>>>>>>>>>> think
>>>>>>>>>>>> it is important to get to the dirty details! Best of luck
>>> and I
>>>>>>> hope
>>>>>>>>>>> this
>>>>>>>>>>>> helps you out.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Aug 30, 2012 at 10:45 AM, Anthony Sequeira
>>>>>>>>>>>> <terry.francona_at_gmail.com> wrote:
>>>>>>>>>>>>> Hi Matt!
>>>>>>>>>>>>>
>>>>>>>>>>>>> What an AWESOME question. While the documentation does not
>>>>>>> make it
>>>>>>>>>>>>> clear, the value that you trust on ingress, in your example,
>>>>>>> CoS,
>>>>>>>>> is
>>>>>>>>>>>>> the marking that is used in the appropriate default queue
>>>>>>> mapping
>>>>>>>>>>>>> table on the egress port.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Anthony Sequeira, CCIE, CCSI, VCP
>>>>>>>>>>>>> http://www.stormwind.com
>>>>>>>>>>>>> Twitter: @compsolv
>>>>>>>>>>>>> Facebook: http://www.facebook.com/compsolv
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 8/29/12 9:11 PM, "Matt Eason" <matt.d.eason_at_gmail.com>
>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Guys,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Can you help clarify the following. If I have a switchport
>>>>>>>>> configured
>>>>>>>>>>>>>> on a
>>>>>>>>>>>>>> 3560 to trust CoS inbound, that cos value is then mapped to
>>> an
>>>>>>>>>>>>>> internal DSCP value via the COS>DSCP map. That s fine.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Does this switch then determine the output queue from the
>>>>>>> original
>>>>>>>>> CoS
>>>>>>>>>>>>>> value or the internal DSCP value which was assigned by the
>>>>>>> switch?
>>>>>>>>> I
>>>>>>>>>>>>>> see both a DSCP>Output queue map and a COS>Output queue map
>>>>>>>>> exists.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Matt
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Joe Astorino
>>>>>>>>>>>> CCIE #24347
>>>>>>>>>>>> http://astorinonetworks.com
>>>>>>>>>>>>
>>>>>>>>>>>> "He not busy being born is busy dying" - Dylan
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>>
>>> Joe Astorino
>>> CCIE #24347
>>> http://astorinonetworks.com
>>>
>>> "He not busy being born is busy dying" - Dylan
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> 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