From: Pavel Bykov (slidersv@gmail.com)
Date: Fri Dec 05 2008 - 16:20:59 ARST
Yes, what I meant was that basically if you do not put "bandwidth" command
on a class, it is not treated preferentially.
There is no special mechanism in IOS to guarantee that 25% for class
default, as can be seen from "show queueing" during load.
I was saying in previous email that measuring in the example you gave should
have more precision, because of burstiness with such a short queue. That is
why I proposed to create a parent shaper to 1 Mbps speed, to make the
measurement more precise. Max-reserved-bandwidth is a configuration
limitation only in my view, but to stick to your point we will have to do
without shaper. I will post tests results as soon as I can get to the lab. I
carried out mentioned testing using back to back serial links with clock
rate at 512K or 1M, therefore the "max-res" was present.
In the mean time, to make burstiness to not play such a major role in your
set up, can you please:
1. Increase traffic throughput to at least 15Mbps
2. Increase "queue-limit" in the FROM-SW2 map to something like 1800
packets? This is to simply reduce possibility of "window" opening up for
class-default due to unloaded interface at microsecond levels.
i.e.
policy-map BANDWIDTH
class FROM-SW2
queue-limit 1800
On Fri, Dec 5, 2008 at 4:42 PM, paul cosgrove <paul.cosgrove@gmail.com>wrote:
> Hi Pavel,
> Perhaps I misunderstood, but I thought you mentioned that the 25% which is
> usually excluded by the maximum reserve bandwidth is not available to
> class-default? The output I gave is just an example of where class-default
> is able to utilise this bandwidth, using the configuration you provided
> (without otherwise changing QoS settings).
>
> Further restricting the output using shaping to 1Mb would mean that the
> maximum reserve bandwidth you referred to in your first email would no
> longer be a factor, which seems to be a different scenario.
>
> Paul.
>
>
> On Fri, Dec 5, 2008 at 3:13 PM, Pavel Bykov <slidersv@gmail.com> wrote:
>
>> That last command of course should have been without "no"
>>
>> As a side note: to check how IOS actually behaves towards these packets,
>> type command "show queueing" multiple times during your tests. It will
>> display actual queue information. You can see there weight, which translates
>> into Sequence Numbers (aka Finish Time) using the standard WFQ formula.
>>
>>
>> On Fri, Dec 5, 2008 at 3:53 PM, Pavel Bykov <slidersv@gmail.com> wrote:
>>
>>> Hello Paul.
>>> Behavior is same throughout 12.4 and 12.4T. I have tested platforms 800,
>>> 1800, 2800 and 7200, all with the same result
>>> .
>>> In your case there are a couple of reasons that are standing in the way
>>> of packets being dropped.
>>> 1. Primary one is that link is really not fully utilized. Remember, the
>>> drops occur when buffers for that queue are full. But if there is a
>>> millisecond of time, when the buffers are not full - algorithm will send
>>> packets from class-default. You really need to generate constant bit rate.
>>> To make the results of your test precise, please use parent shaper to reduce
>>> speed to 1 Mbps. This way you will be sure that there are enough packets in
>>> the queue as to not to create any "windows" for class-default.
>>> Alternatively, you can generate about twice the amount of traffic, that
>>> should do the job. Measuring sometimes can be hard - to constantly overfill
>>> the buffers, you'd need either near real-time operating system or generate
>>> traffic much faster than the output.
>>> 2. Packets in class-default are small. Also, do you have "no fair-queue"
>>> in class-default? I'm not sure about output in this particular version, if
>>> it is displayed or not.
>>>
>>> CBWFQ modifies WFQ algorithm such that it assigns Weight to packets
>>> inversely based on bandwidth reserved on the class.
>>> LLQ is also a modifies WFQ algorithm, but additionally to CBWFQ inverse
>>> bandwidth formula, it also assigns Sequence Number of "0" to packets in
>>> class with "priority" command, meaning "send this packet first", and all
>>> else has to wait. I'm not sure about the exact science behind policing (it
>>> seems that it assigns very bad weight to all the packets that are over the
>>> limit <- this can be why packets are still sent if bandwidth is available).
>>> I still have the Excel sheet from a couple years back, where you can type in
>>> the parameters, and see what is the probability of the packet being sent.
>>>
>>> Please try the following (with traffic generators set up in the same
>>> way):
>>>
>>> policy-map PARENT
>>> shape average 1024000
>>> service-policy BANDWIDTH
>>>
>>> interface FastEthernet0/0
>>> no service-policy output BANDWIDTH
>>> no service-policy output PARENT
>>>
>>> If that will not help, please post how exaclty are you generating the
>>> traffic.
>>>
>>>
>>>
>>> On Fri, Dec 5, 2008 at 2:33 PM, paul cosgrove <paul.cosgrove@gmail.com>wrote:
>>>
>>>> Hi Pavel,
>>>>
>>>> I think some documentation might say that class-default had to be
>>>> specifically defined and allocated bandwidth in order for it to use any.
>>>> Whether or not this was the case previously it is not the behaviour in 12.4
>>>> (13r) which I have on my lab kit. With this class-default does not need to
>>>> be defined in order to receive bandwidth.
>>>>
>>>> In the example below I have a 100Mbps input port receiving >10Mbps ICMP
>>>> from SW2, and some other ICMP from another device a hop away from SW2. The
>>>> combined traffic is contending to get out a 10Mbps interface on this router
>>>> (fa0/0), but none of the class-default traffic is dropped. I'm using
>>>> smaller packets here for the class-default traffic just to illustrate the
>>>> point.
>>>>
>>>> interface FastEthernet0/0
>>>> ip address 192.168.100.2 255.255.255.0
>>>> load-interval 30
>>>> duplex auto
>>>> speed 10
>>>> service-policy output BANDWIDTH
>>>> end
>>>>
>>>> Router2(config-pmap-c)#do sh policy-map int fa0/0
>>>> FastEthernet0/0
>>>>
>>>> Service-policy output: BANDWIDTH
>>>>
>>>> Class-map: FROM-SW2 (match-all)
>>>> 801601 packets, 928837110 bytes
>>>> 30 second offered rate 10266000 bps, drop rate 3520000 bps
>>>> Match: access-group 40
>>>> Queueing
>>>> queue limit 64 packets
>>>> (queue depth/total drops/no-buffer drops) 64/211287/0
>>>> (pkts output/bytes output) 590316/608962024
>>>> bandwidth 5% (500 kbps)
>>>>
>>>> Class-map: class-default (match-any)
>>>> 2675 packets, 2579856 bytes
>>>> 30 second offered rate 227000 bps, drop rate 0 bps
>>>> Match: any
>>>>
>>>> queue limit 64 packets
>>>> (queue depth/total drops/no-buffer drops) 0/0/0
>>>> (pkts output/bytes output) 2742/2475487
>>>> Router2(config-pmap-c)#
>>>>
>>>> The bandwidth command gives minimum reservations used during congestion,
>>>> it does not police traffic at the configured rate. During congestion both
>>>> traffic types will contend for the unreserved bandwidth.
>>>>
>>>> The docs indicate that the 25% of interface bandwidth which is not
>>>> available by default, is reserved for best effort, control and layer 2
>>>> overheads. By allocating 100% of the interface bandwidth to other classes
>>>> you may run into problems.
>>>>
>>>> Paul.
>>>>
>>>> On Fri, Dec 5, 2008 at 12:49 AM, Pavel Bykov <slidersv@gmail.com>wrote:
>>>>
>>>>> It's not like that, really.
>>>>> by default, class-default will not get any reservation whatsoever.
>>>>>
>>>>> Great test to proove this is create the following policy map:
>>>>>
>>>>> policy-map TEST
>>>>> class SOMECLASS
>>>>> bandwidth percent 5
>>>>>
>>>>> now apply this service policy on output, and flood the interface with
>>>>> traffic that belongs to this class map (really flood - reduce the
>>>>> interface
>>>>> speed if you need to, e.g. slow traffic generator)
>>>>> By "old logic" or what was said before about all that
>>>>> "max-reserved-bandwidth", class-default should have gotten 95% of the
>>>>> bandwidth, or "the rest".
>>>>> But in reality? In reality it will get... ZERO, ZILCH, NADA, NOTHING.
>>>>> If you
>>>>> try to ping now in class default, you will have drop rate of something
>>>>> like
>>>>> 99.9% (so it's almost nothing) It of course has to do with the logic of
>>>>> CBWFQ algorithm which is not published but was tested to the point that
>>>>> the
>>>>> algorithm is well understood.
>>>>>
>>>>>
>>>>> That led to very unpleasant starvations in practice. So best practice
>>>>> is to
>>>>> use max-reserved-bandwidth 100 (which is default new IOSes I believe)
>>>>> and if
>>>>> you need to "reserve" then do reserve using bandwidth/priority.
>>>>>
>>>>> On Thu, Dec 4, 2008 at 11:21 PM, <mihai.grigore@onlinehome.de> wrote:
>>>>>
>>>>> > Dear fellow experts,
>>>>> >
>>>>> > I am now reading Wendel Odom's great QOS - Exam Certification Guide
>>>>> book
>>>>> > where
>>>>> > he wrote:
>>>>> >
>>>>> > "class-default automatically gets 25 percent of the bandwidth" on
>>>>> page 302.
>>>>> >
>>>>> > Is this (still) true ?
>>>>> > Is this the explanation for the default max-reserved-bandwidth of 75%
>>>>> ?
>>>>> > If so, what happens with the class-default when I configure
>>>>> > "max-reserved-bandwidth 100" ?
>>>>> >
>>>>> > TIA, MIhai
>>>>> >
>>>>> >
>>>>> > 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/
>>>
>>
>>
>>
>> --
>> 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/
>>
>
>
-- 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:07 ARST