From: Chris Lewis (chrlewiscsco@gmail.com)
Date: Mon Mar 06 2006 - 00:48:25 GMT-3
As I said, I have not seen the question wording, but in my opinion, if
anyone looks at the burst parameters as a way of defining a throughput rate,
they are not matching the question wording to the way the technology
operates. The wording would have to be very specific about credit build up
and duration for which the solution would be valid.
The bottom line is that CIR defines the rate that can be sustained
indefinitely, normal burst is there to allow CIR to be achieved if there is
fluctuation in the offered rate of traffic to be policed, meaning if credit
builds up by less than CIR being offered, you can use that credit later if
more than CIR has to be transmitted briefly, but once it is gone, it is not
available again until credit builds up through low utilization again.
Chris
On 3/5/06, CCIE 4 Me <ccie4me@inbox.lv> wrote:
>
> Chris,
>
>
>
> Both solutions are correct depending on one's interpretation. If one
> interprets "limit to maximum of 500kbps" as referring to the nominal
> maximum
> limit that we all deal with everyday, then using CIR of 500kbps will meet
> the requirement, but if one interprets it as a hard maximum limit ie the
> limit of 500kbps is "calved in stone" ie at no time must the rate exceed
> 500kbps, then using CIR of 496kbps will make more sense, because if one
> use
> a CIR of 500kbps, there is the possibility after the accumulation of
> enough
> credit to transmit above 500kbps for a short period of time. But using a
> CIR
> of 496k and Bc of 4k & Be of 4k, the nominal maximum limit will be set at
> 496kbps but there is the possibility of transmitting above 496kbps
> temporary
> if enough credit has been accumulated.
>
>
>
> The Brians stands a better chance of setting the records straight, it is
> either they met a hard limit of 500kbps and intentional provide that
> solution so that their students will think through the process instead of
> using the obvious value of 500kbps for the CIR or they met a nominal
> maximum
> limit and when they type in the value of 500000 into the router, it
> changed
> it to 496000 and they never check it out before posting the solution.
>
>
>
> Whichever way, this is an interesting thread.
>
>
>
> Thanks.
>
> CCIE 4 Me.
>
>
>
> ----- Original Message -----
> From: "Chris Lewis" <chrlewiscsco@gmail.com>
> To: "PANDI MOORTHY" <moorthypandi@gmail.com>
> Cc: "Reinhold Fischer" <Reinhold.Fischer@gmx.net>; "Cisco certification"
> <ccielab@groupstudy.com>
> Sent: Sunday, March 05, 2006 9:58 AM
> Subject: Re: how to choose Rate-limt brust
>
>
> > Guys,
> >
> > I think there are a couple of misrepresentations on this thread.
> >
> > First, the concept of Tc in policing algorithms is different to that in
> > shaping algorithms. Unlike shaping algorithms, which calculate things at
> > regular intervals, policing calculations are driven by packet arrival
> times.
> > Although referring to the two rate policer, the description at
> >
>
>
http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123tcr/123tq
> r
> > /qos_o1gt.htm#wp1084420
> > of
> >
> > tokens being added to the bucket when packets arrive is still valid for
> a
> > one rate system.
> >
> > Talking just about a sungle bucket system (like the rate-limit command),
> the
> > CIR defines the rate that will be achieved over time, one does not
> enable
> > the policer to continually police at a higher rate by defining a Bc
> value.
> > Bc is just the depth of the bucket used for the policing algorithm. It
> is
> > not an extra amount of traffic that can be continually sent. If the
> traffic
> > coming in is much lower than the CIR, the bucket will fill with tokens,
> once
> > the bucket is full, tokens are discarded. The effect this has is to
> allow
> > the policer to temporarily transmit at a rate (key here is temporarily)
> > higher than CIR until the bucket is empty. So one has to build up credit
> > first in order to do this, one cannot transmit indefinitely at a
> > rate greater than CIR. Be in a single bucket system means you can borrow
> > agaainst future allocation of tokens, meaning the token bucket can go
> > negative for a while (negative amount of tokens in the bucket), again
> > thought, it does not imply a continuous rate.
> >
> > The values recommended for Bc in policiing are just general rules of
> thumb
> > and do not relate to round trip times (how could you apply a general
> rule
> > for that, it varies so much!). The 1.5 seconds of burst for the token
> bucket
> > depth is just a typical value, tuning it to another value depends on the
> > profile of hte traffic, a more steady stream needs less, a more uneven
> > stream may require more.
> >
> > I have not seen the question, but from what I see the configuration
> shown
> > would not meet the requirements to limit to 500K, it would limit to
> 496K.
> To
> > limit to 500K would require use of MQC police, which can limit to
> exactly
> > 500K. The classification could use the same ACL, just call that in a
> class
> > map and police to 500000 in a policy-map, as shown in the policy-map
> > interface output below.
> >
> >
> > Router1(config-if)#do sho policy-map int
> > Serial3/0
> >
> > Service-policy output: test
> >
> > Class-map: class-default (match-any)
> > 1 packets, 24 bytes
> > 5 minute offered rate 0 bps, drop rate 0 bps
> > Match: any
> > police:
> > cir 500000 bps, bc 15625 bytes
> > conformed 0 packets, 0 bytes; actions:
> > transmit
> > exceeded 0 packets, 0 bytes; actions:
> > drop
> > conformed 0 bps
> >
> >
> >
> > On 3/4/06, PANDI MOORTHY <moorthypandi@gmail.com> wrote:
> > >
> > > Excellent, thank you.
> > >
> > > Regards.
> > > Pandi
> > >
> > >
> > > On 3/5/06, Reinhold Fischer <Reinhold.Fischer@gmx.net> wrote:
> > > >
> > > > Hi Pandi,
> > > >
> > > > i came across the following statement in the book 'IP Quality of
> > > Service'
> > > > (Ciscopress, Page 38):
> > > >
> > > > <cite>
> > > > - Rate (bps) should be in increments of 8 Kbps, and the lowest value
> > > > allowed for conformed and extended burst size is 8000 bytes.
> > > > - The minimum value of BC size is Rate (bps) divided by 2000. It
> should
> > > be
> > > > at least 8000 bytes.
> > > > - The BE is always equal to or greater than the BC value.
> > > > </cite>
> > > >
> > > > According to the calculation the BC value would be: 500000 / 2000 =
> 250
> > > >
> > > > So i would choose the recommended minimum value of 8000 bytes for BC
> and
> > > > twice the size for BE:
> > > >
> > > > access-list 100 permit tcp any any syn
> > > > access-list 100 deny ip any any
> > > > int e0/0
> > > > rate-limit output access-group 100 496000 8000 16000 conform-action
> > > > transmit exceed-action drop
> > > >
> > > >
> > > > There is another formula on cco on this URL:
> > > >
> > > >
> > > >
> > >
> > >
> >
>
>
http://www.cisco.com/en/US/tech/tk543/tk545/technologies_q_and_a_item09186a0
> 0
> > > 800cdfab.shtml#policing
> > > >
> > > > http://tinyurl.com/ouvcf
> > > >
> > > > which you can use to calculate the BC/BE values. This formula
> assumes
> > > > a typical round-trip-time of 1.5 seconds and therefore the results
> > > > for BC/BE produce higher numbers.
> > > > When using this formula the BC value would be 93750 and the BE value
> > > > would be 187500.
> > > >
> > > >
> > > > hope this helps and is not too confusing :-)
> > > >
> > > > regards
> > > >
> > > > Reinhold
> > > >
> > > >
> > > > On Sun, Mar 05, 2006 at 12:36:02AM +0800, PANDI MOORTHY wrote:
> > > > > Hi
> > > > >
> > > > > The question is to limit the TCP sync traffic to 500kbps which is
> out
> > > > from
> > > > > the Ethernet interface.
> > > > >
> > > > > So I have to use the rate-limit command to achieve this, one thing
> > > still
> > > > I
> > > > > can't figure out is choosing the value for burst-normal and
> burst-max,
> > > > > Anyone please advice me on this?
> > > > >
> > > > > Regards.
> > > > > Pandi
> > >
> > >
> _______________________________________________________________________
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Apr 01 2006 - 10:07:38 GMT-3