Re: LLQ- help

Totally agree with what was stated in that link.
We have to remember that PQ, CBWFQ, are all congestion management tool. but
the best way to test LLQ is to actually make calls and test the quality.

On Tue, Dec 18, 2012 at 2:40 PM, Joe Sanchez <marco207p_at_gmail.com> wrote:

> Here is a great view:
>
>
> http://www.cisco.com/en/US/docs/ios/12_0t/12_0t7/feature/guide/pqcbwfq.html#wp5329
>
> JS
>
> On Tue, Dec 18, 2012 at 3:28 PM, Marko Milivojevic <markom_at_ipexpert.com>wrote:
>
>> For fun, I added another source of the traffic and lowered bandwidth
>> on the interface to 768000 (in an attempt to actually create a
>> congestion). This is by no means an exhaustive test of LLQ and the
>> quality, but it shows a conditional policer in action.
>>
>> ------------------------------8<------------------------------
>> !!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!
>> !!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> !.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!
>> !!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!
>> !!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!
>> !!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!
>> !!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!
>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!
>> !!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!
>> !!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!
>> !!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> !.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!
>> !!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!
>> !!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!
>> !!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> !!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!
>> !!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!
>> !!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!
>> !!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!
>> ------------------------------8<------------------------------
>>
>> If you look closely at the pattern of drops above, you will observe
>> the regular intervals at which they appear. This *can* be an indicator
>> of active traffic conditioner. Let's see what our policy says. Keep in
>> mind that the other traffic generator is much more aggressive than the
>> first (timeout 0).
>>
>> ------------------------------8<------------------------------
>> R2#show policy-map interface Serial0/2/0 output class PRIORITY
>>
>> Serial0/2/0
>>
>> Service-policy output: LLQ
>>
>> queue stats for all priority classes:
>>
>> queue limit 64 packets
>> (queue depth/total drops/no-buffer drops) 0/0/0
>> (pkts output/bytes output) 158281/238054624
>>
>> Class-map: PRIORITY (match-all)
>> 344671 packets, 518385060 bytes
>> 30 second offered rate 10173000 bps, drop rate 9649000 bps
>> Match: protocol icmp
>> Priority: 100 kbps, burst bytes 2500, b/w exceed drops: 186359
>> ------------------------------8<------------------------------
>>
>> The problem is that this test is flawed when it comes to reproducing
>> the real congestion, as here we also have to take into account that
>> the traffic is arriving from the same input interface, so we have 1:1
>> input:output mapping (again, something I mentioned very early in this
>> thread as an important factor).
>>
>> I could spend even more time labbing it up for you, but I suppose I've
>> done enough train-the-trainer for one day :-).
>>
>> --
>> Marko Milivojevic - CCIE #18427 (SP R&S)
>> Senior CCIE Instructor - IPexpert
>>
>> On Tue, Dec 18, 2012 at 1:16 PM, Marko Milivojevic <markom_at_ipexpert.com>
>> wrote:
>> > On Tue, Dec 18, 2012 at 1:14 PM, Narbik Kocharians <narbikk_at_gmail.com>
>> wrote:
>> >> How did you prove that LLQ kicks in during congestion? How did you
>> measure
>> >> the quality of these packets?
>> >
>> > Well, that's not at all what I was testing, as the test was built
>> > specifically to avoid congestion to show how there's no policing when
>> > congestion does not occur. Apples and Oranges.
>> >
>> > Testing the quality of these packets would be difficult (not
>> > impossible) to measure using IOS-only and Voice SLA probes as traffic
>> > generators, but as I said... this was not the point here.
>> >
>> > --
>> > Marko Milivojevic - CCIE #18427 (SP R&S)
>> > Senior CCIE Instructor - IPexpert
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>>
>

-- 
*Narbik Kocharians
*CCSI#30832, CCIE# 12410 (R&S, SP, Security)
*www.MicronicsTraining.com* <http://www.micronicstraining.com/>
Sr. Technical Instructor
YES! We take Cisco Learning Credits!
A Cisco Learning Partner
Blogs and organic groups at http://www.ccie.net