Re: QoS question

Hi Carlos,

What do you mean by "updating the policy " ? I have not updated the policy
after I applied it but I will do a no service/service just to be sure.

Thanks,

Adrian

On Sun, Apr 11, 2010 at 3:16 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar>wrote:

> Yup, sorry, you did write that and I forgot.
> Now (12.2(52)SE) it works as I had expected, i.e., policy aplies after
> packet is read, with whatever initial internal DSCP based on trust,
> and then copied to DSCP on exit if enabled.
>
> This is not consistent with your observing DSCP EF upstream with that
> policy (and mls qos enabled/mls qos rewrite ip dscp).
>
> One thing though: updating the policy did not reflect on the port
> behaviour without my first reapplying it. So be careful in your test
> and do "no service .../service ..." after changing the policy !
>
> -Carlos
>
>
> Lazar Adrian @ 11/04/2010 3:19 -0300 dixit:
> > 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
> >
> > _______________________________________________________________________
> > 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 - 19:24:26 ART