Re: LLQ- help

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

Blogs and organic groups at http://www.ccie.net
Received on Mon Dec 17 2012 - 23:25:51 ART