Re: LLQ- help

Since when do we have a Be in single rate two color policer?

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

> Well, let's talk about the burst parameter, because I believe we
> reached a conclusion it does not work like Bc (i.e. to determine the
> Tc). Rather it works more closely to Be, but not even that... :-)
>
> I'm not confused about it - I just can't seem to find the information
> what it does. I can *believe* what it does, but that doesn't explain
> it to me ;-)
>
> --
> Marko Milivojevic - CCIE #18427 (SP R&S)
> Senior CCIE Instructor - IPexpert
>
> On Tue, Dec 18, 2012 at 3:30 PM, Narbik Kocharians <narbikk_at_gmail.com>
> wrote:
> > 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
> > 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