Re: 3650 COS/DSCP to queue mapping

interface FastEthernet0/1
des port toward source
switchport tr en dot1q
switchport mode trunk
mls qos trust cos

interface FastEthernet0/2
des port toward destination
switchport tr en dot1q
switchport mode trunk

mls qos
mls qos map cos-dscp 0 8 16 24 32 46 48 56
mls qos map dscp-cos 24 to 5

source send packet with cos 3

regards,
gp

On Tue, Sep 4, 2012 at 5: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
Received on Tue Sep 04 2012 - 17:43:41 ART