Re: 3650 COS/DSCP to queue mapping

Based on the tests I just ran, it appears that I was incorrect on this
one guys. Sorry for the confusion and here are my findings

R1 ---- Cat1 ---- R2

Cat 1 is a 3560 and both interfaces are configured as trunks. R1 and
R2 each have fa0/0.10 setup as dot1q subinterfaces. R1 is configured
to tall all packets with a CoS of 3. Cat1 fa0/1 connected to R1 and
Cat1 Fa0/2 connected to R2 trust CoS. R2 has an inbound policy
configured that matches CoS 3. The default DSCP-COS map on Cat1 was
modified such that DSCP 24 is mapped to CoS 5. Here are the relevant
configurations

R1

---
policy-map R1-MARK
 class class-default
  set cos 3
!
interface FastEthernet0/0
 no ip address
 duplex auto
 speed auto
!
interface FastEthernet0/0.10
 encapsulation dot1Q 10
 ip address 10.10.10.1 255.255.255.0
 service-policy output R1-MARK
R2
----
class-map match-all foo
 match cos  3
!
policy-map R2-IN
 class foo
 class class-default
!
interface FastEthernet0/0
 no ip address
 duplex full
 speed 100
!
interface FastEthernet0/0.10
 encapsulation dot1Q 10
 ip address 10.10.10.2 255.255.255.0
 service-policy input R2-IN
Cat1
-------
mls qos
mls qos map dscp-cos  24 to 5
!
interface FastEthernet0/1
 switchport trunk encapsulation dot1q
 switchport mode trunk
 mls qos trust cos
!
interface FastEthernet0/2
 switchport trunk encapsulation dot1q
 switchport mode trunk
 mls qos trust cos
Now, let's get started with the test:
First, here are the cos-dscp and dscp-cos maps on Cat1: We see CoS 3
is mapped to DSCP 24 and that DSCP 24 is mapped to CoS 5
Cat1#show 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
Cat1#sh mls qos maps 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 05 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
Now, let's make sure our counters are all reset to 0 before we try
anything on R1 and R2
R1#sh policy-map int fa0/0.10
 FastEthernet0/0.10
  Service-policy output: R1-MARK
    Class-map: class-default (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
      QoS Set
        cos 3
          Packets marked 0
R2#sh policy-map int fa0/0.10
 FastEthernet0/0.10
  Service-policy input: R2-IN
    Class-map: foo (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps
      Match: cos  3
Good, nothing has happened yet.  Now, we will ping R2 from R1.  When
this happens, since R1 is marking the frame as CoS 3 it will arrive at
Cat1 Fa0/1 as CoS 3.  The switch trust's the marking.  If it does
indeed map CoS 3 to DSCP 24 then consult an internal mapping that maps
DSCP 24 back to CoS 5 we should see the frame arrive at R2 with a CoS
marking of 5.  But...we don't.
R1#ping 10.10.10.2 re 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 1/2/4 ms
R1#show policy-map int fa0/0.10
 FastEthernet0/0.10
  Service-policy output: R1-MARK
    Class-map: class-default (match-any)
      10 packets, 1000 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
      QoS Set
        cos 3
          Packets marked 10
Notice that R1 says it did indeed mark all the frames as CoS 3 ...
What happened on R2?
R2#show policy-map int fa0/0.10
 FastEthernet0/0.10
  Service-policy input: R2-IN
    Class-map: foo (match-all)
      10 packets, 1180 bytes
      5 minute offered rate 0 bps
      Match: cos  3
Note that R2 caught all the frames marked as CoS 3 and not CoS 5 ...so
no internal mapping took place here.  Also, we can validate on the
switch.
Cat1#show mls qos maps 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
Cat1#show mls qos int fa0/2 statistics | b output queues enqueued
  output queues enqueued:
queue: threshold1 threshold2 threshold3
-----------------------------------------
 queue 0:           2           0           0
 queue 1:         168           0        7144
 queue 2:          40           0           0
 queue 3:           0           0          16
At this stage we can see that CoS 3 gets mapped to output queue 3,
threshold 1, but CoS 5 is mapped to queue 1 threshold 1.  Since the
"sh mls qos interface statistics" command unfortunately starts with
queue 0, we can see that queue 2 in that command is actually the real
queue 3.  Now...let's ping again
Cat1#show mls qos int fa0/2 statistics | b output queues enqueued
  output queues enqueued:
queue: threshold1 threshold2 threshold3
-----------------------------------------
 queue 0:           2           0           0
 queue 1:         178           0        7517
 queue 2:          50           0           0
 queue 3:           0           0          16
We can see that the queue 3 threshold 1 incremented by exactly 10
packets...the same amount we just sent across the interface. Had the
CoS been mapped to DSCP 24 and then BACK to CoS 5 we would have seen
the packet get queued into queue 1 threshold 1 but we didn't
I would say based on this test, it is pretty conclusive that I made a
mistake.  But hey...we all learned something and that's what it's all
about guys : )
On Wed, Sep 5, 2012 at 1:07 AM, ccie99999 <ccie99999_at_gmail.com> wrote:
> Hi Marc..
>
> thanks a lot for the link.. it clarifies indeed!
>
> btw.. I did some other tests:
>
> *** TEST1 ***
>
> pc1(vlan1) - sw1 - pc2(vlan2)
>
> pc1 side
> cos 3
> cos overr
>
> mls qos map dscp-cos 24 to 5
>
> I see:
>
> cos3 incoming on pc1 side
> cos3 outgoing on pc2 side
> dscp24 incoming on pc2 side
> dscp24 outogoing on pc2 side
>
> **** TEST2 ***
>
> instead of doing a cos 3 + override I just trusted dscp and sent ping with
> ToS 96 from PC1
>
> mls qos map dscp-cos 24 to 5
>
> I see:
>
> dscp24 incoming on pc1 side
> dscp24 incoming on pc2 side
> dscp24 outogoing on pc2 side
> cos instead is always 0.. that makes sense
>
>
> **** TEST3 ****
>
> I put a sw2 on pc2 side in trunk with sw1
> I setup a cos3 + cos override on pc1 side and did some test
>
> mls qos map dscp-cos 24 to 5
>
> I see:
> same results than TEST1
>
>
> therefore.. what I don't see it when cos to dscp to cos it could be
> actually used.. as the schema implicitily says it should be never used.
>
> Joe.. could please add your comment? when your scenario could apply?
>
> thanks in advance
>
>
>
> On Tue, Sep 4, 2012 at 5: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