Re: WRED thresholds and queue-limit

Yeah. The interface hold-queue defines the max amount of packets that can
be held in the software queue, and thus available to your classes. I
believe this is the same for HQF and Pre-HQF?

On Thu, Jan 26, 2012 at 3:14 PM, Tom Kacprzynski <tom.kac_at_gmail.com> wrote:

> Yuri,
> Thank you for your response, this is very good information. This looks
> like a well hidden detail that Cisco changed when they implemented HQF.
> Basically HQF (any IOS higher than 12.4(22), WRED has an additional check,
> which is the queue-limit of each class. If the queue's current size, not
> the average queue depth, is above the queue-limit it will tail drop all
> packets exceeding that class' queue-limit. This is independent of what
> value wred max-threshold value you have.
>
> One thing that I'm still little confused it the hold-queue and
> queue-limit. Based on the document you provided:
>
> "Class-Based shaping policy applied to physical interface in HQF code:
> 1000 packets, tunable with a combination of interface CLI hold-queue out
> and child policy queue-limit where child policy queue-limit has an upper
> bound of interface hold-queue out."
>
> ...does this mean that each child's class-map's queue-limit has to be add
> up to the hold-queue of the physical interface?
>
> Regard,
>
> Tom Kacprzynski
>
>
>
>
>
>
> On Thu, Jan 26, 2012 at 12:32 AM, Yuri Bank <yuribank_at_gmail.com> wrote:
>
>> It depends on the version of IOS. Pre-HQF, queue-limit is ignored if
>> random-detect is configured under a class. In HQF, queue-limit WILL take
>> affect when configured with random-detect, but it simply sets a hard limit
>> and must be higher than Max Threshold.
>>
>> Unfortunately I wasn't able to test this since I only had 12.4(15) in
>> Dynamips, but according to Cisco this is the case:
>>
>>
>> http://www.cisco.com/en/US/products/hw/routers/ps341/products_tech_note09186a0080af893d.shtml
>>
>> -Yuri
>>
>>
>>
>>
>>
>>
>> On Tue, Jan 24, 2012 at 1:10 PM, Tom Kacprzynski <tom.kac_at_gmail.com>wrote:
>>
>>> Hello,
>>> Is this a valid configuration of WRED, where the queue-limit is set to 64
>>> packets by default, the WRED Min Threshold is 100 (packets) and Max
>>> threshold is 400 (packets)? Would this configuration defeat the whole
>>> purpose of using WRED, as the average queue depth will never reach 100
>>> packets (min threshold)? Am I understanding this correctly?
>>>
>>>
>>> <sample output>
>>> R1#sh policy-map int gi0/0 out
>>> GigabitEthernet0/0
>>>
>>> Service-policy output: test-pmap
>>>
>>> Class-map: test1 (match-all)
>>> 0 packets, 0 bytes
>>> 5 minute offered rate 0 bps, drop rate 0 bps
>>> Match: none
>>> Queueing
>>> queue limit 64 packets
>>> (queue depth/total drops/no-buffer drops) 0/0/0
>>> (pkts output/bytes output) 0/0
>>> bandwidth 30000 kbps
>>> Exp-weight-constant: 9 (1/512)
>>> Mean queue depth: 0 packets
>>> dscp Transmitted Random drop Tail drop
>>> Minimum Maximum Mark
>>> pkts/bytes pkts/bytes pkts/bytes
>>> thresh thresh prob
>>>
>>> cs3 0/0 0/0
>>> 0/0 100 400 1/10
>>>
>>>
>>> <sample config of wred>
>>> policy-map test-pmap
>>> class test1
>>> bandwidth 30000
>>> random-detect dscp-based
>>> random-detect dscp 24 100 400
>>>
>>>
>>> Thank you,
>>>
>>> Tom Kacprzynski
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Sat Jan 28 2012 - 13:01:39 ART