Hi Carlos,
My initial tests were also done with a 3560 running 12.2(35)SE and I saw the
same behavior, input policy cleared the trust. After I have upgraded to
12.2(53)SE, the latest IOS version for 3560 I think, the behavior changed
and it was like I described to you in the other emails.
Best regards,
Adrian
On Sat, Apr 10, 2010 at 8:50 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar>wrote:
> I did a couple of tests and it behaves like I would expect, i.e.:
>
> -phone tags PC with COS 0 (does not touch DSCP)
> -trust defines initial internal DSCP value
> -policy can change DSCP on incoming (and internal DSCP value)
> -DSCP rewritten at output by default
>
> What I did not expect is that defining an input policy clears the qos
> trust, and vice versa. This is on a 3560 running 12.2(35)SE.
>
> Your Q on COStoDSCP and DSCPtoCOS is not valid, cause they are used
> at different places. COStoDSCP defines internal DSCP based on COS whan
> COS is trusted. DSCPtoCOS, on the other hand, defines COS at sending
> time depending on internal DSCP.
>
> -Carlos
>
> Lazar Adrian @ 9/04/2010 14:39 -0300 dixit:
> > Carlos,
> >
> > "-You are, I bet, not keeping the incoming DSCP marks, but remarking on
> > exit according to internal DSCP."
> > This should be the default behavior. I am marking DSCP on the incoming
> > interface so the outgoing interface (uplink) should put the corresponding
> > COS value on the frame based on the DSCP that I mark.
> >
> > "The 3560 is not changing the internal DSCP because of the policy, and
> > remarking on exit translates COS 5 to DSCP EF (mls qos rewrite ip dscp)."
> > So, if I understood it right, my policy is remarking DSCP 0 on voice
> packets
> > and then, on exit, because of the COStoDSCP mapping, DSCP EF is put right
> > back on the packet. This could be the explanation but I have also seen
> DSCP
> > AF21 packets on the uplink when capturing (I generated some traffic that
> > would get marked AF21 by the policy). This kind of contradicts the first
> > theory because those packets came with COS 0 from the PC (but got DSCP
> AF21
> > from the policy) and should have got rewritten to DSCP 0 based on the
> > COStoDSCP mapping.
> > Now, the question that arises is: How the COStoDSCP and DSCPtoCOS
> mappings
> > work and which has precedence over the other.
> > From the two behaviors above I can guess that if DSCP is 0 and COS is
> > different than 0 then re-mark DSCP based on internal COStoDSCP mapping
> but
> > if DSCP is not 0 then leave it how it is and add the COS value on exit
> based
> > on DSCPtoCOS mapping.
> >
> > I will post a "sh mls qos " on Monday.
> >
> > Best Regards,
> >
> > Adrian
> >
> >
> >
> > On Fri, Apr 9, 2010 at 8:19 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar>
> wrote:
> >
> >> Hmm,
> >> first, to "post the policy" you also need to post the classes, or
> >> else it is difficult to see what is that you are remarking.
> >> In any case you are remarking everything.
> >>
> >> There are a couple of things though:
> >> -you are trusting COS, not DSCP. The PC has no way of generating a COS
> >> marking, so you are either getting COS 5 or COS 0. (Or 3 for phone
> >> signaling).
> >> -You are, I bet, not keeping the incoming DSCP marks, but remarking on
> >> exit according to internal DSCP.
> >>
> >> The 3560 is not changing the internal DSCP because of the policy, and
> >> remarking on exit translates COS 5 to DSCP EF (mls qos rewrite ip dscp).
> >>
> >> That is how I suspect it is happening. Do you see ANY DSCP 26 or 18
> >> on the uplink ? Can you post a "sh mls qos" ?
> >>
> >> -Carlos
> >>
> >>
> >> Lazar Adrian @ 9/04/2010 12:43 -0300 dixit:
> >>> Carlos,
> >>>
> >>> Below is the policy-map I used :
> >>>
> >>> policy-map QoS_Marking
> >>> class Critical_Traffic
> >>> set ip dscp 26
> >>> exit
> >>> class DC_Traffic
> >>> set ip dscp 18
> >>> exit
> >>> class class-default
> >>> set ip dscp 0
> >>>
> >>> I applied this inbound on an user/phone interface which looks like this
> :
> >>> switchport access vlan YY
> >>> switchport voice vlan XX
> >>> mls qos trust cos
> >>> mls qos trust device cisco-phone
> >>> service-policy input QoS_Marking
> >>>
> >>> Capturing the traffic on the uplink port I saw that voice packets from
> >> the
> >>> port configured like above were marked DSCP EF so the trust device
> >>> cisco-phone command has priority over the policy-map or it certainly
> >> looks
> >>> like it has :)
> >>>
> >>> Best Regards,
> >>>
> >>> Adrian
> >>>
> >>> On Fri, Apr 9, 2010 at 4:46 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar>
> >> wrote:
> >>>> Adrian,
> >>>> to better understand your example, you should post the policy too.
> >>>>
> >>>> You say "the phone DSCP EF marking is not overwritten by the
> policy-map"
> >>>> but I would expect it to, given that the policy actually calls for
> >>>> a remark.
> >>>>
> >>>> I don't ubderstand your last paragraph. The PC marking, if any, will
> >>>> be cleared (reset to 0) by the phone AFAIK. Remember that there's
> always
> >>>> a mark at L3, there's no way to tell apart a "marked as 0" or
> >>>> unmarked, if that term is ever used.
> >>>>
> >>>> -Carlos
> >>>> Firm believer that confusion is the beginning of wisdom :)
> >>>>
> >>>>
> >>>> Lazar Adrian @ 9/04/2010 9:10 -0300 dixit:
> >>>>> Hi Carlos,
> >>>>>
> >>>>> Thanks for your prompt answer.
> >>>>> As I really needed to know what is the exact behavior in this case I
> >> have
> >>>>> tested it using a 3560 switch and a cisco phone.
> >>>>> The original IOS on the switch (1-2 years old) didn't even permit the
> >>>>> service-policy input command on the interface at the same time with
> >> "mls
> >>>> qos
> >>>>> trust device cisco-phone".After I upgraded to the latest 3560 IOS,
> >>>>> 12.2(53)SE, the behavior changed dramatically. Now I was permitted to
> >> put
> >>>>> the two commands on the same interface and after capturing some
> traffic
> >>>> it
> >>>>> seems the phone DSCP EF marking is not overwritten by the policy-map
> I
> >>>>> defined (which was not marking the voice packets with DSCP EF).
> >>>>> To summarize, below are the commands I used to configure the
> interface:
> >>>>>
> >>>>> mls qos trust cos
> >>>>> mls qos trust device cisco-phone
> >>>>> service-policy input QoS_Marking
> >>>>>
> >>>>> As this was a user/phone port those commands had the effect of
> letting
> >>>> the
> >>>>> DSCP EF mark of the phone to go through untouched by the policy and
> >> mark
> >>>> the
> >>>>> user traffic according to the policy (seemed that "mls qos trust cos
> "
> >>>>> command didn't apply to user traffic ).
> >>>>>
> >>>>> Best Regards,
> >>>>>
> >>>>> Adrian
> >>>>>
> >>>>> On Thu, Apr 8, 2010 at 12:52 PM, Carlos G Mendioroz <
> tron_at_huapi.ba.ar
> >>>>> wrote:
> >>>>>
> >>>>>> Adrian,
> >>>>>> ip traffic is always marked with some code, that should give you a
> >> clue.
> >>>>>> But if it does not, then it depends on the logic of the policy, but
> >>>>>> you can remark if you will. In your terms, the policy has
> precedence.
> >>>>>>
> >>>>>> "mls qos trust device" only disables the wiping of the incoming
> mark.
> >>>>>>
> >>>>>> It's a litle more complicated than that in fact. You need to have
> >>>>>> "mls qos trust dscp" in place, and that initializes the internal QoS
> >>>>>> marking to that of the incoming IP dscp. Then if "trust device" is
> >>>>>> added, the initialization is replaced with 0 if the connected device
> >>>>>> is not a cisco phone. Then comes your policy to change whatever, and
> >>>>>> last and option to leave the initial marking alone when sending.
> >>>>>> To top it, this is architecture dependent.
> >>>>>>
> >>>>>> HTH,
> >>>>>> -Carlos
> >>>>>>
> >>>>>> Lazar Adrian @ 8/04/2010 6:29 -0300 dixit:
> >>>>>>> Hi guys,
> >>>>>>>
> >>>>>>> I have a simple QoS implementation with one policy-map marking the
> >>>>>> traffic
> >>>>>>> inbound coming from a user or IP phone (I have a general port
> config,
> >>>> so
> >>>>>>> same port config no matter if a PC or phone connects to it).
> >>>>>>> Now, my question is related to the precedence of "mls qos trust
> >> device
> >>>>>>> cisco-phone" and "service-policy QoS_Marking inbound" commands.
> What
> >> I
> >>>>>> want
> >>>>>>> to know and I haven't found this information anywhere is, if my
> phone
> >>>>>> sends
> >>>>>>> DSCP EF marked traffic will the policy-map mark it down ? So the
> >> matter
> >>>>>>> resumes to what command has precedence over the other.
> >>>>>>>
> >>>>>>> Thank you,
> >>>>>>>
> >>>>>>> Adrian
> >>>>>>>
> >>>>>>> PS: Disregard the previous mail, I accidentally hit the send button
> >> too
> >>>>>>> early :)
> >>>>>>>
> >>>>>>>
> >>>>>>> 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
> >>>>>
> >>>>>
> _______________________________________________________________________
> >>>>> 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
> >>>
> >>> _______________________________________________________________________
> >>> 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
> >
> > _______________________________________________________________________
> > 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
Received on Sun Apr 11 2010 - 09:19:44 ART
This archive was generated by hypermail 2.2.0 : Sat May 01 2010 - 09:49:57 ART