RE: class-default is reserved 25% of the configured BW ???

From: ricky ong (longwaydown@live.com)
Date: Sat Dec 06 2008 - 16:15:46 ARST


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
> From: smorris@internetworkexpert.com> To: slidersv@gmail.com; mihai.grigore@onlinehome.de> CC: ccielab@groupstudy.com> Subject: RE: class-default is reserved 25% of the configured BW ???> Date: Fri, 5 Dec 2008 09:43:45 -0500> > You're talking about two different things...> > Bandwidth commands = guarantees in case of congestion.> > 75% rule was designed to give SOME bandwidth (unguaranteed) to the "other> stuff" on a link.> > Now, there's nothing against you making the math work against you. I know> plenty of people who work with over-subscribed lines. And they plan QoS> based on a higher-than-is-really-there bandwidth.> > You can trick the router all you like (your "unpleasant starvations") but> that doesn't make it MQC's fault! Honestly, if your congestion is bad> enough to drop the througput that much (more than 25% of link speed) you> have issues. If you have oversubscribed it to the point where reality> intervenes, you have issues. If you allow 100% reservation, and t!
 ry to> "guarantee" that much, if the transmission speed either actually drops, or> congestion is occurring where packets get dropped, you have accomplished> nothing by "guaranteeing" bandwidth.> > You may see more output drops. The point was never to "guarantee" stuff for> class-default. It was to help prevent people from creating their own bad> scenarios. Unfortunately, when we think we are smarter than the routers, we> often find ways to create the potential for bad stuff no matter how many> safeguards were put in place!> > Just my thoughts...> > > Scott Morris, CCIE4 #4713, JNCIE-M #153, JNCIS-ER, CISSP, et al.> CCSI/JNCI-M/JNCI-ER> Senior CCIE Instructor> > smorris@internetworkexpert.com> > > > Knowledge is power. > Power corrupts. > Study hard and be Eeeeviiiil......> > > -----Original Message-----> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of> Pavel Bykov> Sent: Thursday, December 04, 2008 7:50 PM> To: mihai.grigore@onlinehome.de> Cc: cciela!
 b@groupstudy.com> Subject: Re: class-default is reserved 25% o!
 f the co

nfigured BW ???> > 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 b!
 est 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 t

he 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> > > Blogs and organic groups at http://www.ccie.net> > _______________________________________________________________________> Subscription information may be found at: > http://www.groupstudy.com/list/CCIELab.html> > > > > > >



This archive was generated by hypermail 2.1.4 : Thu Jan 01 2009 - 12:53:07 ARST