Re: LLQ- help (with elephants)

I am using 12.4(15)T13

On Thu, Dec 20, 2012 at 7:25 AM, Carlos G Mendioroz <tron_at_huapi.ba.ar>wrote:

> Well, I tried a 12.4(15)T and I get your output:
>
> RouterA#sh policy-map int
> Serial0/0/0
>
>
> Service-policy output: tst
>
> Class-map: ef (match-all)
> 0 packets, 0 bytes
> 5 minute offered rate 0 bps, drop rate 0 bps
> Match: precedence 5
> Queueing
> Strict Priority
> Output Queue: Conversation 40
> Bandwidth 30 (%)
> Bandwidth 30 (kbps) Burst 750 (Bytes)
> (pkts matched/bytes matched) 0/0
> (total drops/bytes drops) 0/0
>
> which leds me to believe that this is pre HQF ( 12.4(20)T ) behaviour.
> -Carlos
>
> Carlos G Mendioroz @ 20/12/2012 09:14 -0300 dixit:
>
> Narbik,
>> Would you mind sharing which IOS version those tests were made on ?
>> Trying to reproduce it and I get burst at 1500 instead of your 750 value
>> on the serial interface with the tst policy.
>> Also, I'm curious about your show policy map showing "conversations"
>> wich is a gadget from CBWFQ which is not present on HQF.
>> On 15.1(1)T :
>>
>> HQ-1#sh run int s 0/1/1
>> Building configuration...
>>
>> Current configuration : 204 bytes
>> !
>> interface Serial0/1/1
>> bandwidth 100
>> ip address 10.1.7.101 255.255.255.0
>> ip access-group drop in
>> loopback
>> no keepalive
>> clock rate 2000000
>> max-reserved-bandwidth 80
>> service-policy output tst
>> end
>> HQ-1#sh policy-map int
>> Serial0/1/1
>>
>> Service-policy output: tst
>>
>> queue stats for all priority classes:
>>
>> queue limit 64 packets
>> (queue depth/total drops/no-buffer drops) 0/0/0
>> (pkts output/bytes output) 0/0
>>
>> Class-map: ef (match-all)
>> 0 packets, 0 bytes
>> 5 minute offered rate 0 bps, drop rate 0 bps
>> Match: precedence 5
>> Priority: 30% (30 kbps), burst bytes 1500, b/w exceed drops: 0
>>
>>
>> ...
>>
>> For sake of comparizon, your R1 output:
>> R1#Show policy-map interface
>> Serial0/1
>> Service-policy output: tst
>> Class-map: ef (match-all)
>> 0 packets, 0 bytes
>> 5 minute offered rate 0 bps, drop rate 0 bps
>> Match: precedence 5
>> Queueing
>> Strict Priority
>> Output Queue: Conversation 40
>> Bandwidth 30 (%)
>> Bandwidth 30 (kbps) Burst 750 (Bytes)
>> (pkts matched/bytes matched) 0/0
>> (total drops/bytes drops) 0/0
>>
>> Tks,
>> -Carlos
>>
>> P.S.
>> Why on earth trying to understand this stuff is childish ?
>>
>> Narbik Kocharians @ 19/12/2012 21:18 -0300 dixit:
>>
>>> To all,
>>>
>>>
>>> Please go to micronics.nl and download the LLQ-LAB and I think I have
>>> done
>>> my best to show how the "burst" in LLQ works just like the Bc in single
>>> rate two color marker, by the way there are no Be in two color marker
>>> with
>>> single rate. BUT I do not have time to go over that and prove it, even
>>> though I can.
>>>
>>>
>>> BTW, this is my last post, i am conducting a class and have no time for
>>> this kind of childish stuff , It is embarrassing (Double
>>> dare??)sharing which
>>> wow.........
>>>
>>> Have fun.
>>>
>>>
>>> On Wed, Dec 19, 2012 at 4:01 PM, Marko Milivojevic
>>> <markom_at_ipexpert.com>wrote:
>>>
>>> On Wed, Dec 19, 2012 at 3:43 PM, Paul Negron <negron.paul_at_gmail.com>
>>>> wrote:
>>>>
>>>>> Therefore, when I placed 4 calls that tootled approx 112K of the Pipe.
>>>>>
>>>> All
>>>>
>>>>> worked well. The 5th call went through fine cause it was not enough to
>>>>> congest the link. The 6th call had to have had congested the link which
>>>>> kicked in the BURST parameter set in the Priority Queue and traffic
>>>>>
>>>> dropped
>>>>
>>>>> traffic out of the VOICE CLASS.
>>>>>
>>>>> [...]
>>>>
>>>>> I also have in my notes that the POLICE action worked very similar to a
>>>>>
>>>> Single Rate 2 Color Policer. '
>>>>
>>>>>
>>>>> The conclusion was that the Priority Class Burst Parameter will drop
>>>>>
>>>> traffic only when the link is congested, even if it's by a little
>>>> depending
>>>> on the traffic.
>>>>
>>>> Dear Lord, I don't even know where to begin with this...
>>>>
>>>> #1 You are aware that 5th call may have gone through because the
>>>> timing on it was such that packets were arriving in such a way to
>>>> never trigger a congestion, even though you exceeded the bandwidth by
>>>> calculation, but not in reality? See example from Carlos about
>>>> elephants (brilliant!)
>>>>
>>>> #6 6th call of course overwhelmed the link, as the statistical timing
>>>> offset was astronomical at that point for different flows to
>>>> interleave without triggering the congestion. When this happens, *of
>>>> course* policer kicks in and all traffic, regardless of the flow gets
>>>> policed at the specified rate.
>>>>
>>>> #3 "Kicked out of VOICE CLASS" - how *on Earth* does traffic gets
>>>> kicked out of the class once it's classified there?
>>>>
>>>> #4 Higher burst parameter causes more draps? What's this about? If
>>>> anything, higher burst means longer measurement interval (in what you
>>>> claim it does), or higher calculated rate that can exceed without
>>>> causing drops. Are you now claiming that BURST parameter in the
>>>> priority command does something entirely different? If yes, pray
>>>> explain, as I have lost you completely at this point.
>>>>
>>>> Last but not the least...
>>>>
>>>>
>>>>> This is how the BURST parameter works.
>>>>>
>>>>
>>>> HOW? I never saw an explanation, just a mass confusion as some
>>>> authority-referencing (Wendell), which is not a valid argument.
>>>>
>>>> --
>>>> Marko Milivojevic - CCIE #18427 (SP R&S)
>>>>
>>>>
>>>
>>>
>>>
>>
> --
> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>

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