Re: LLQ- help

Yes, there are policy drops:

HQ-1#sh policy-map interface
  Serial0/1/0

   Service-policy output: prioUDP

     queue stats for all priority classes:

       queue limit 64 packets
       (queue depth/total drops/no-buffer drops) 0/0/0
       (pkts output/bytes output) 297/292842

     Class-map: udp (match-all)
       460 packets, 453560 bytes
       5 minute offered rate 10000 bps, drop rate 6000 bps
       Match: access-group name udp
       Priority: 100 kbps, burst bytes 2500, b/w exceed drops: 163

Without the service policy, all traffic flies...

-Carlos

Marko Milivojevic @ 18/12/2012 13:33 -0300 dixit:
> Can you post the output of "show frame pvc" when you tested the FR? I
> would be very careful jumping to any conclusions (which you did not),
> as something other than the policer could be dropping those packets.
> Did you see the hit counter increase on the drops in the class?
>
> --
> Marko Milivojevic - CCIE #18427 (SP R&S)
> Senior CCIE Instructor - IPexpert
>
> On Tue, Dec 18, 2012 at 7:26 AM, Carlos G Mendioroz <tron_at_huapi.ba.ar> wrote:
>> Just tested this under 15.1.1T @ 2811.
>>
>> Incoming interface fastEthernet, outgoing serial.
>> Monitoring TX on serial via snmp, generating with a script udp traffic
>> at a constant rate.
>>
>> Baseline: 100K and 200K both are seen at TX on serial.
>> Check1:
>> class-map match-all udp
>> match access-group name udp
>> policy-map prioUDP
>> class udp
>> priority 100
>> interface Serial0/1/1
>> service-policy output prioUDP
>> ip access-list extended udp
>> permit udp any any
>>
>> Both 100K and 200K seen on TX on serial.
>>
>> That was my understanding. (no congestion, no policing).
>>
>> But... same code, same config on an interface that has frame relay, does
>> drop packets even when not congested.
>>
>>
>> To play with this, all you need is one router (real one, no dynamips to test
>> QoS please :), and some time.
>> I can provide a perl script that generates udp traffic. Also copy of a small
>> SNMP interface traffic graphing tool which is handy.
>> (Interface Traffic Indicator, InfTraf.exe
>> Version 1.1.0; April 2004
>> Software by Carsten Schmidt)
>>
>>
>> -Carlos
>>
>>
>>
>>
>> Carlos G Mendioroz @ 18/12/2012 06:56 -0300 dixit:
>>
>>> May I ? :)
>>>
>>> It might be that the whole issue is that:
>>> -the behaviour changed in some point in time
>>> -the behaviour is different in some architecture
>>> -some test was done with some issue that drove a false idea on someone
>>>
>>> I have not tested this latelly, but it used to be the case that the
>>> policer would not be there when not congested. Fact, tested by many.
>>>
>>> I will retest this ASAP to (again ?) be ascertive about it. I respect
>>> Paul and it may be that with some code (an some arch) this has changed.
>>> After all, it would make sense for cisco to impose a policer on a
>>> priority queue always, because that's how most people believe it would
>>> behave.
>>>
>>> The burst size may just be a measurement parameter. After all, instant
>>> rate is always input interface speed, right ? You for any throughput
>>> metering, you need some time slots, which might not be aligned, and some
>>> bursting slack.
>>>
>>> As to whether there is or not a queue, it would be very hard to be
>>> conclusive, because the TX ring will always behave as one. But what
>>> difference would it make, or if it would be needed at all given that
>>> it is priority and should be below the output if rate, I don't know nor
>>> care :)
>>>
>>> I would like this NOT to be taken offline. We all can learn. I would
>>> also like to everyone to agree to a self imposed rate limit, may be
>>> exponential, to filter any impulse driven answer. It's an important
>>> subject, IMHO.
>>>
>>> -Carlos
>>>
>>>
>>>
>>> Marko Milivojevic @ 18/12/2012 02:14 -0300 dixit:
>>>>
>>>> Oh, I understand it very well... This has *nothing* to do with burst,
>>>> as I said hours ago... :-) It has something to do when a strict
>>>> scheduler is in effect. It's in effect when software queueing is in
>>>> effect and is in effect when lower layer (for the lack of better term
>>>> - TX, parent shaper) signal they are congested (TX) or they exist
>>>> (shaper).
>>>>
>>>> Now, your message I'm responding to clearly shows you really
>>>> misunderstand how CBWFQ works. There is no policer there. Conditional
>>>> policer exists only in the LLQ. Unfortunately, I'm off to watch The
>>>> Hobbit now, so I'll have to explain better in couple of hours.
>>>>
>>>> PRIORITY keyword does not create a "PRIORITY QUEUE". It creates LLQ,
>>>> which I downright * refuse* call by the term used in IOS for something
>>>> else.
>>>>
>>>> If you're curious. Create LLQ with 2 Mb/s priority. Send 10 Mb/s of
>>>> the traffic that matches, but *no* other traffic. Ensure that you're
>>>> not oversubscribing the outgoing interface. What will happen?
>>>>
>>>> --
>>>> Marko Milivojevic - CCIE #18427 (SP R&S)
>>>> Senior CCIE Instructor - IPexpert
>>>>
>>>>
>>>> On Mon, Dec 17, 2012 at 9:03 PM, Paul Negron <negron.paul_at_gmail.com>
>>>> wrote:
>>>>>
>>>>> Marko,
>>>>>
>>>>> There are 2 distinct things in play for LLQ.
>>>>>
>>>>> 1) CBWFQ scheduler- This operates exactly the way you have been
>>>>> stating the entire time. Congestion must be in effect for this
>>>>> scheduler to be operating effectively.
>>>>>
>>>>> 2) The priority Class- I think you are very mistaken about this part
>>>>> of LLQ. The fact that you did not understand the "Burst" proves this.
>>>>> Not that this is a bad thing. SO what if you did not know. Does not
>>>>> mean I think less of you.;-)
>>>>>
>>>>> You keep speaking about LLQ from only one of the above perspectives.
>>>>>
>>>>> I understand the multiple input interfaces deal. I was not testing
>>>>> the Queuing, that is very straight forward.
>>>>>
>>>>> I was testing the Policer in the Priority Class. Ya know the part
>>>>> that makes LLQ different from CBWFQ. You are speaking as if they
>>>>> behave the same when they don't.
>>>>>
>>>>> I think I see where we MAY be speaking past each other but let me
>>>>> clarify. I was making a point so EVERYONE would understand how the
>>>>> Priority Q works which is very different then what MOST people think.
>>>>> The statement from the point I was referencing was about the
>>>>> "PRIORITY" keyword, which means it is participating as a Priority Queue.
>>>>>
>>>>> Paul
>>>>>
>>>>> Paul Negron
>>>>> CCIE# 14856
>>>>> negron.paul_at_gmail.com
>>>>> 303-725-8162
>>>>>
>>>>>
>>>>>
>>>>> On Dec 17, 2012, at 11:33 PM, Marko Milivojevic <markom_at_ipexpert.com>
>>>>> wrote:
>>>>>
>>>>>> And mind you :-). I was not the one who talked about flows. I talked
>>>>>> about different interfaces or classes in the same policies. Two flows
>>>>>> in the same queue coming from the same input interface be it 1 or 19
>>>>>> phones is still 1 input 1 output. To see the queueing, you need
>>>>>> multiple input interfaces. Think of a Y.
>>>>>>
>>>>>> --
>>>>>> Marko Milivojevic - CCIE #18427 (SP R&S)
>>>>>> Senior CCIE Instructor - IPexpert
>>>>>>
>>>>>> On Mon, Dec 17, 2012 at 8:31 PM, Marko Milivojevic
>>>>>> <markom_at_ipexpert.com> wrote:
>>>>>>>
>>>>>>> Paul,
>>>>>>>
>>>>>>> If there was no congestion on the TX ring, there was no LLQ. TX ring
>>>>>>> congestion is what signals to IOS that software queueing needs to be
>>>>>>> engaged. Your test was flawed, sorry to say.
>>>>>>>
>>>>>>> --
>>>>>>> Marko Milivojevic - CCIE #18427 (SP R&S)
>>>>>>> Senior CCIE Instructor - IPexpert
>>>>>>>
>>>>>>> On Mon, Dec 17, 2012 at 8:25 PM, Paul Negron
>>>>>>> <negron.paul_at_gmail.com> wrote:
>>>>>>>>
>>>>>>>> I have tested it precisely!
>>>>>>>>
>>>>>>>> I put Voice traffic into the Priority Class and left the burst to
>>>>>>>> default.
>>>>>>>>
>>>>>>>> I placed enough voice calls to equal the amount of traffic I used
>>>>>>>> with the
>>>>>>>> "priority" command (4 calls at 32K each/NO VAD enabled). ALL
>>>>>>>> traffic passed
>>>>>>>> and was not rejected. I placed a 5th call and it also went through
>>>>>>>> with no
>>>>>>>> problem because it did not exceed the burst rate parameter (Voice
>>>>>>>> is not
>>>>>>>> bursty). The second I placed another call, ALL of the Voice flows
>>>>>>>> were
>>>>>>>> negatively impacted. The priority class began dropping traffic! It
>>>>>>>> reacted
>>>>>>>> as if it was receiving burst traffic that exceeded what it would
>>>>>>>> allow.
>>>>>>>>
>>>>>>>> When I extended the Burst parameter, ALL of the Voice call issues
>>>>>>>> cleared
>>>>>>>> up.
>>>>>>>>
>>>>>>>> There was NO congestion on the transmit ring at ANY time during
>>>>>>>> this test.
>>>>>>>>
>>>>>>>>
>>>>>>>> I also performed the same test with Live Video but the results were
>>>>>>>> devastating due to the extreme Bursty nature of the traffic I was
>>>>>>>> using. I
>>>>>>>> needed to extend the "BURST" parameter extensively due to it's
>>>>>>>> extreme
>>>>>>>> restrictive default.
>>>>>>>>
>>>>>>>> This is why some people misspeak and say that the Priority class is a
>>>>>>>> maximum value. It's true in that it binds the high end bandwidth
>>>>>>>> but it does
>>>>>>>> ALLOW you to burst and squeeze a little bit more by default. It's
>>>>>>>> just
>>>>>>>> REALLY restrictive. It does not enforce the 1 to 2 second
>>>>>>>> recommendation.
>>>>>>>>
>>>>>>>> I still disagree with your example of where you " MAY SEE"
>>>>>>>> queueing of
>>>>>>>> packets since I have NOT been able to prove it to this point. I
>>>>>>>> did not ask
>>>>>>>> you to show me the packets to be confrontational or argumentative. I
>>>>>>>> actually thought I was going to learn something in this
>>>>>>>> conversation about
>>>>>>>> how the Priority Queue actually buffers packets. I don't know what
>>>>>>>> command
>>>>>>>> you used to verify this.
>>>>>>>>
>>>>>>>> This is why I am NOT confused about how LLQ works. I understood
>>>>>>>> what the
>>>>>>>> BURST parameter actually does. I am NOT guessing.
>>>>>>>>
>>>>>>>> Policing will impose its constraint weather you are congested on
>>>>>>>> the TX ring
>>>>>>>> or NOT. Same goes for Shaping!
>>>>>>>>
>>>>>>>> Paul
>>>>>>>>
>>>>>>>> Paul Negron
>>>>>>>> CCIE# 14856
>>>>>>>> negron.paul_at_gmail.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Dec 17, 2012, at 10:19 PM, Marko Milivojevic
>>>>>>>> <markom_at_ipexpert.com> wrote:
>>>>>>>>
>>>>>>>> On Mon, Dec 17, 2012 at 7:11 PM, Marko Milivojevic
>>>>>>>> <markom_at_ipexpert.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Yeah, I've seen that in the command reference as well. It's not
>>>>>>>> exactly well documented what it does.
>>>>>>>>
>>>>>>>>
>>>>>>>> What I suspect though (and this is purely speculation) is that it
>>>>>>>> allows the traffic to burst for the specified time when the LLQ is
>>>>>>>> engaged, which means when TX ring (or other choke point, i.e. shaper
>>>>>>>> in the parent class) trigger a congestion. Since there's no LLQ when
>>>>>>>> there's no congestion, I don't see how this parameter is at all
>>>>>>>> relevant when LLQ is not active. That's the thing with your statement
>>>>>>>> about 30 seconds that I mostly disagree with.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Marko Milivojevic - CCIE #18427 (SP R&S)
>>>>>>>> Senior CCIE Instructor - IPexpert
>>>>>>>>
>>>>>>>>
>>>>>
>>>
>>
>> --
>> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina

-- 
Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
Blogs and organic groups at http://www.ccie.net