From: paul cosgrove (paul.cosgrove@gmail.com)
Date: Fri Dec 05 2008 - 17:02:06 ARST
Hi Pavel,
Perhaps the behaviour is different with FRTS, but otherwise I'm unclear why
your own results are so different. If you include some of your
configurations and results it may help to clarify where the differences are.
Note that 'show queueing' gives no output for the MQC configuration I'm
using on fast ethernet interface. Shaping must be applied to a class, which
is not how you have used it. Applying shaping also means that the
maximum-reserve-bandwidth command is ignored. Shaping in a parent policy
reduces the total bandwidth available to the classes; I do not think it
changes how the bandwidth is shared by those classes or make results more
precise.
Increasing the packet sizes to be the same (which seems a little
artificial), produces an output rate approximately double that of the output
interface, 20 times the shaping rate, yet class-default is still not starved
- in fact in this example it receives considerably more bandwidth than the
defined class.
Router2(config-if)#do sh policy-map int fa0/0
*Dec 5 18:21:13.113: %CLEAR-5-COUNTERS: Clear counter on all interfaces by
console
FastEthernet0/0
Service-policy output: TEST
Class-map: class-default (match-any)
5337 packets, 8080218 bytes
30 second offered rate 20699000 bps, drop rate 19921000 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 89/5119/0
(pkts output/bytes output) 218/330052
shape (average) cir 1000000, bc 4000, be 4000
target shape rate 1000000
Service-policy : BANDWIDTH
Class-map: FROM-SW2 (match-all)
2288 packets, 3464032 bytes
30 second offered rate 10221000 bps, drop rate 10018000 bps
Match: access-group 40
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 64/2238/0
(pkts output/bytes output) 50/75700
bandwidth 5% (50 kbps)
Class-map: class-default (match-any)
3049 packets, 4616186 bytes
30 second offered rate 10474000 bps, drop rate 9899000 bps
Match: any
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 23/2881/0
(pkts output/bytes output) 168/254352
Router2(config-if)#
Paul
On Fri, Dec 5, 2008 at 6:20 PM, Pavel Bykov <slidersv@gmail.com> wrote:
> 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