From: paul cosgrove (paul.cosgrove@gmail.com)
Date: Thu Dec 18 2008 - 17:08:57 ARST
Hi Pavel,
I think there are two different questions here:-
a) Does cisco intend class-default to receive the full 25% which is not
allocated by max-reserve-bandwidth?
b) Does class default actually receive the share it is supposed to have?
My understanding of the cisco docs is that class default is not supposed to
receive the full 25%. Cisco docs we have discussed already mention that the
Layer 2 headers, control traffic etc. are also taken from this 25%. The
second link I mentioned in my last email (from which there is another
extract below) also indicates that class-default should not be expected to
receive the full 25%.
http://www.cisco.com/en/US/technologies/tk543/tk545/technologies_white_paper0900aecd8012032d.html
"Allocation of Bandwidth to Class Default
Old Behavior
The default class can use up to 25 percent of total available bandwidth;
however, the entire 25 percent is not guaranteed. Rather, it is
proportionately shared between different flows in the default class and
excess traffic from other bandwidth classes. Thus, the amount of bandwidth
that the default class will receive depends on a number of factors,
including the total number of flows currently in the router, the bandwidth
guarantees (or weights) made to the other user-defined classes, and the
number of hash queues in the router. To make minimum bandwidth guarantees
to the default class, the bandwidth command needs to be explicitly
configured under the class in the policy.
New Behavior
The class default has a default minimum guarantee that equals the
difference between the total available bandwidth (for example, link rate,
shaped rate) and the amount of bandwidth guaranteed to the other classes.
For example, if 90 percent of bandwidth is allocated to other classes, then
the class default is guaranteed the remaining 10 percent. If there is no
traffic in the class default, then the other classes share that 10 percent
proportionally. Alternatively, the user can explicitly configure the amount
of bandwidth that should be available to default class using the bandwidth
<x> command. This will lower the guarantee that is given to the class
default and allow 10 minus "x" to always be available for the other classes"
So the second question then, is whether class-default receives the share
which the cisco documents suggest it should get? Judging from the test you
performed using the old T release, it looks like it does not always receive
it's due share. We can determine whether the behaviour seen with that
particular release of IOS, is shared by others by carrying out further
testing. If we are trying to determine what the behaviour is will be in the
lab then perhaps we should look at 12.2 and 12.4 releases first.
Paul.
On Tue, Dec 16, 2008 at 4:52 PM, Pavel Bykov <slidersv@gmail.com> wrote:
> Paul, thanks for the links.
> But as I mentioned before: the "max-reserved-bandwidth" command never
> worked.
> If you look at part 6 of my testing, I used a quite old T release (2 years
> old at least) and still the result points out, that class-default didn't get
> promised 25%.
>
>
>
> On Tue, Dec 16, 2008 at 10:25 AM, paul cosgrove <paul.cosgrove@gmail.com>wrote:
>
>> Hi Pavel,
>>
>> Judging from the docs the functionality of max-reserved-bandwidth changed
>> quite a lot in recent releases - as of 12.2(20)T is is no longer supported.
>>
>> http://ciscosystems.com/en/US/docs/ios/qos/command/reference/qos_m1.html#wp1037779
>> This release introduced HFQ and standardised QoS behaviour across the
>> platforms. Incidentaly it also seems to have removed fast switching.
>>
>> There is a good document on the cisco site which explains the recent QoS
>> changes. It was written about the service provider track but references
>> 12.4T where the changes seem to have been introduced a little later.
>>
>> http://www.cisco.com/en/US/technologies/tk543/tk545/technologies_white_paper0900aecd8012032d.html
>>
>> The following is an extract from the doc:-
>>
>> Max-Reserved-Bandwidth
>>
>> Old Behavior
>> The default maximum reserved bandwidth is 75 percent, so the maximum
>> bandwidth that can be guaranteed to any user-defined class is also 75
>> percent. If 75 percent of the bandwidth is allocated only for the LLQ, then
>> no minimum bandwidth can be guaranteed to the other classes, and they will
>> share the remaining 25 percent bandwidth with the class default traffic.
>> If more bandwidth needs to be allocated, use the max-reserved-bandwidthcommand to modify the bandwidth amount that can be reserved for user-defined
>> classes.
>>
>> New Behavior
>> The max-reserved-bandwidth command no longer affects the amount of
>> bandwidth available to a service-policy. 1% must be reserved for the
>> class-default with the rest being available to the users classes. Please
>> also refer to the previous section "Allocation of Bandwidth to Class
>> Default.
>>
>>
>> Paul.
>>
>>
>>
>> On Mon, Dec 8, 2008 at 10:01 AM, Pavel Bykov <slidersv@gmail.com> wrote:
>>
>>> Thanks.
>>> Functionality of max-reserved-bandwidth did change with latest IOS, but
>>> not
>>> by much.
>>> You can see this in part 6 of tests on page 22 where testing was done
>>> with
>>> an old IOS. There R2 and R3 which were in class-default should have
>>> gotten
>>> at least something, because the command was set at
>>> "max-reserved-bandwidth
>>> 75", but they didn't and what they got was below 1%.
>>>
>>>
>>> On Sun, Dec 7, 2008 at 1:05 PM, <mihai.grigore@onlinehome.de> wrote:
>>>
>>> > Pavel,
>>> >
>>> > I started all this from a statement written some time ago. This might
>>> have
>>> > been
>>> > true at the time of writing Doyle's book. In the meantime, Cisco has
>>> > apparently
>>> > changed how class-default works and that statement appears to be no
>>> longer
>>> > valid.
>>> >
>>> > Thank you for your tests and clarifications, you did a great job with
>>> your
>>> > tests!
>>> > I read the pdf that you put on your server. Very thorough testing!!!
>>> > Basically you conclusion is that max-reserved-bandwidth command is kind
>>> of
>>> > useless.
>>> >
>>> > It looks like indeed that Cisco has changed the way how
>>> > max-reserved-bandwidth
>>> > command works and it will take some time to update the documentation,
>>> as
>>> > usual.
>>> >
>>> > Many thanks again for your tests!
>>> >
>>> >
>>> > Blogs and organic groups at http://www.ccie.net
>>> >
>>> > _______________________________________________________________________
>>> > Subscription information may be found at:
>>> > http://www.groupstudy.com/list/CCIELab.html
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
>>>
>>> --
>>> Pavel Bykov
>>> ----------------
>>> Don't forget to help stopping the braindumps, use of which reduces value
>>> of
>>> your certifications. Sign the petition at http://www.stopbraindumps.com/
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
> --
> Pavel Bykov
> ----------------
> Don't forget to help stopping the braindumps, use of which reduces value of
> your certifications. Sign the petition at http://www.stopbraindumps.com/
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Thu Jan 01 2009 - 12:53:09 ARST