Re: LLQ- help

Carlos,

I would like to check out your perl script to generate udp traffic. I just
started to read this thread, so forgive me if you have sent it already.

On Tue, Dec 18, 2012 at 10: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
>
> ______________________________**______________________________**
> ___________
> Subscription information may be found at: http://www.groupstudy.com/**
> list/CCIELab.html <http://www.groupstudy.com/list/CCIELab.html>

Blogs and organic groups at http://www.ccie.net
Received on Tue Dec 18 2012 - 23:04:53 ART