Re: LLQ- help

That's exactly my point. We don't (you talked about single-rate
policer, not me, btw.). This is what the description of the command
says:

"(Optional) Burst size in bytes. The burst size configures the network
to accommodate temporary bursts of traffic. The default burst value,
which is computed as 200 milliseconds of traffic at the configured
bandwidth rate, is used when theburst argument is not specified. The
range of the burst is from 32 to 2000000 bytes."

Further down, there's an example:

"Examples

The following example shows how to configure PQ with a guaranteed
bandwidth of 50 kbps and a one-time allowable burst size of 60 bytes
for the policy map named policy1:

Router(config)# policy-map policy1
Router(config-pmap)# class voice
Router(config-pmap-c)# priority 50 60"

Now, look me in the eye and say this sounds like Bc to you? To me,
this sounds more like a Be (which implies two rate policer. This is
not the three color policer, as there seems to be no option to specify
three actions, hence my comment that it sounds like be, but not even
that, as it lacks the functionality I'd expect to see...

Now, there are two possibilites:

1) Cisco documentation is wrong and this indeed specifies Bc for a
single rate, two color policer. It would actually make sense, as it
allows the possibility to adjust metering on transmission side to the
metering on the receiving side (other side of the link), should they
be mismatched. This is not an unlikely scenario and it's what you're
saying.

2) This is indeed a temporary "excess burst", but with the implied
"transmit" action, meaning that it can be used to create a two rate,
two color policer. According to the documentation, this is what it is.

--
Marko Milivojevic - CCIE #18427 (SP R&S)
Senior CCIE Instructor - IPexpert
On Tue, Dec 18, 2012 at 3:39 PM, Narbik Kocharians <narbikk_at_gmail.com> wrote:
> 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
> Sr. Technical Instructor
> YES! We take Cisco Learning Credits!
> A Cisco Learning Partner
Blogs and organic groups at http://www.ccie.net