Re: LLQ- help

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
Blogs and organic groups at http://www.ccie.net