From: Pavel Bykov (slidersv@gmail.com)
Date: Sun Dec 07 2008 - 02:53:56 ARST
Hi Paul, Rick.
I didn't misread any documentation. The documentation is just NOT VALID in
this case. In my tests, I have not only proved this, but funnily enough IOS
also supported my claim. (but that is at the end of Part 4 of tests)
I think what happened was that you test setup was flawed, because it wasn't
really apparent what were you measuring.
I have spent most of the evening testing this set up, and came up with
correct results. The reason I came up with the results in the first place
was very measurable traffic generation. It is also obvoius how could your
set up be so much different in the first place.
I have uploaded all the results to my server. Please read the following
document, it may seem a bit long, but most of it are output.
http://www.boxoid.org/cisco/MAX-RESERVED-BANDWIDTH-AND-CBWFQ.pdf
Document could be used as a lab guide as well.
Tests really shed light on internal logic, and why max-reserved-bandwidth is
basically useless.
Also, I do point make the case for "old logic" of cisco, with the new logic
working differently.
Tests also point to major differences that are in the new 12.4.20T IOS,
since I am able to demonstrate class-default starvation only in the old IOS.
On Sat, Dec 6, 2008 at 10:02 PM, paul cosgrove <paul.cosgrove@gmail.com>wrote:
> Hi Ricky,
>
> I think Pavel may have misread some of the documentation. He said that
> class-default is supposed to get exclusive use of all bandwidth unassigned
> by max-reserved-bandwidth. He described this as the "old logic' but it is
> not true and I don't recall seeing it before. Lets hope he will contact the
> author or whoever told him this so it can be corrected.
>
> Pavel said that class-default does not by default get any bandwidth
> reservation, and went on to describe how it would receive effectively no
> bandwidth in a case where 95% of the max-reserve-bandwidth is unallocated to
> any specific class. If you try out the example configuration he gave it
> actually shows this is incorrect, and class default is not starved as he
> predicted it would be. I think Pavel is going to check his tests, and
> perhaps share the configurations and results, which may help clear up the
> inconsistencies.
>
>
> Another point Pavel made earlier was:
> "So best practice is to use max-reserved-bandwidth 100 (which is default
> new IOSes I believe) ".
> This is not consistent which the cisco docs I have seen, which explicitly
> warn against it.
>
>
> http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/congstion_mgmt_oview_ps6350_TSD_Products_Configuration_Guide_Chapter.html
> "The sum of all bandwidth allocation on an interface cannot exceed 75
> percent of the total available interface bandwidth. The remaining 25 percent
> is used for other overhead, including Layer 2 overhead, routing traffic, and
> best-effort traffic. Bandwidth for the CBWFQ class-default class, for
> instance, is taken from the remaining 25 percent."
>
> Note that this does not say that all of the 25% is allocated to
> class-default, class-default is given as an instance of something which can
> use a portion of this 25%. So if you increase max-reserved-bandwidth to
> 100% (which seems to be against the recommendations of cisco), even if you
> explicitly put a bandwidth statement under class-default, the docs suggest
> you may be starving control traffic and not leaving sufficient bandwidth for
> L2 headers.
>
> The same link also includes the following in relation to ip rtp priroty:
> "The sum of all bandwidth allocation for voice and data flows on the
> interface cannot exceed 75 percent of the total available bandwidth.
> Bandwidth allocation for voice packets takes into account the payload plus
> the IP, RTP, and UDP headers, but again, not the Layer 2 header. Allowing 25
> percent bandwidth for other overhead is conservative and safe. On a PPP
> link, for instance, overhead for Layer 2 headers assumes 4 kbps. The amount
> of configurable bandwidth for IP RTP Priority can be changed using the *
> max-reserved-bandwidth* command on the interface."
>
> Cisco ATM docs expand on this further by saying that the Layer 2 headers of
> all classes, not just class-default or priority voice traffic, are taken
> from this 25%.
>
> http://www.cisco.com/en/US/tech/tk39/tk48/technologies_tech_note09186a00800fe2c1.shtml
>
> If also strikes me that if your allocation does result in disruption to
> keepalives and other control packets such as routing protocols, then you may
> see a rather sudden decrease in transit traffic.
>
> Paul.
>
> On Sat, Dec 6, 2008 at 6:15 PM, ricky ong <longwaydown@live.com> wrote:
>
>> I think the point Pavel pionted out is valid:
>>
>> -- class-default does not really get the "remaining bandwidth", which is
>> 100%-"what u have assigned using bandwidth in MQC", assuming the interface
>> has been configured with "maximum-reserve-bandwidth 100%".
>>
>> But customers like to give requirements like "i want my CRITICAL to have
>> 50%, BUSINESS to have 25%, and all the remaining to have 25%". That really
>> lead us to configure something like
>>
>> Interface xx
>> Maximum-reserve-bandwidth 100
>> class CRITICAL
>> band per 50
>> class BUSINESS
>> band per 25
>> class class-default
>>
>> But this really screw up the requirement since class-default(without any
>> hard bandwidth guarantee) in fact get far less than 100-(50+25)= 25%. Some
>> will say to put bandwidth per 25 under class class-default.. but that could,
>> although i did not experience it yet, cause control traffic to starve. So
>> my take is to define extra class to catch the "all the remainings" from
>> customer's perspective, and assign bandwidth to that class, say 23%, and use
>> bandwidth 2% for the "class-default" for the control traffic.
>>
>> My assumption is, when using maximum-reserve-bandwidth 100, as long as the
>> total assigned bandwidth configured in MQC does not exceed 100%, no
>> over-subscription will occure and whatever minimum bandwidth guarantee
>> configured for the class will be fufiled. Is this correct?
>>
>> -Ricky
>>
>>
>>
>>
>>
>>
>>
>
-- 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