Re: LLQ- help

I have not, why would you say that? I am not going to participate in you
said he said stuff. The burst in LLQ works the way I explained it, and I
still say that, when did I say the burst does not work the way i mentioned?

The burst in LLQ works just like the Bc in a single rate 2 color policer.
NOW...whether it's behavior is that way during congestion or not it needs
to be tested, I believe it works that way during congestion, but i do not
have the testing gear to provide results, the tests shown in some of the
examples are ridiculous to test the complete package, things like burst and
playing with the burst value.

It was you that was confused about the burst parameter and not me. Go back
and read what you wrote.

On Tue, Dec 18, 2012 at 3:15 PM, Marko Milivojevic <markom_at_ipexpert.com>wrote:

> Thank you for agreeing with what I was saying all along (even though
> it kind-of contradicts your previous burst statement) ;-)
>
> Now, testing LLQ is tricky and making calls is not exactly the best
> way to test it, should you intend to use it for something other than
> voice. Any throughput, queueing, performance testing is best left to
> the professional tools designed for that purpose. Human ears are not a
> good tool :-).
>
> For anyone with (serious) production concerns about the LLQ and a
> (serious) testing budget, I can only highly recommend Spirent
> SmartBits or TestCenter products. They are *unparalleled* to what
> you'll be able to learn about your routers and switches and their
> (lack of) performance... :-)
>
> --
> Marko Milivojevic - CCIE #18427 (SP R&S)
> Senior CCIE Instructor - IPexpert
>
> On Tue, Dec 18, 2012 at 3:09 PM, Narbik Kocharians <narbikk_at_gmail.com>
> wrote:
> > 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
> > Sr. Technical Instructor
> > YES! We take Cisco Learning Credits!
> > A Cisco Learning Partner
> >
>

-- 
*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