From: paul cosgrove (paul.cosgrove@gmail.com)
Date: Sat Dec 06 2008 - 19:02:44 ARST
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
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