From: Tommy C (tkc9789@xxxxxxxxxxx)
Date: Sun Aug 11 2002 - 15:47:46 GMT-3
This is becaus CAR uses token bucket mechanism where the size of the bucket
is limited by "normal burst". If your bucket size is too small, you will
not be able to achieve the long term committed rate you desired. There're
several links on CCO which explained the relationship between CIR, normal
burst and excess bursts.
HTH
Tommy
>From: "Michael Snyder" <msnyder@ldd.net>
>Reply-To: "Michael Snyder" <msnyder@ldd.net>
>To: "'Glenn Johnson'" <glennjohnson@attbi.com>
>CC: <ccielab@groupstudy.com>
>Subject: RE: QOS Question, Why inflate burst and max burst values?
>Date: Sun, 11 Aug 2002 13:23:48 -0500
>
>Part of the thread I started was if could you use GTS "Traffic-shape
>group" vs. "rate-limit output access-group" to police these
>requirements? Which I believe we answered as we could do so.
>
>If you substitute the traffic-shape group where you have rate-limit
>output access-group, keeping the same access lists and bit values, I
>believe it will also work.
>
>In other words, going by it's parameters, the GTS command, seems to be
>the grandfather of the rate-limit command.
>
>I have a question about your bit values.
>
>You have:
>
>Bit Rate = x
>
>Burst Size = 3x/16 ; 1.5/8=3/16=.1875
>
>Maximum Burst Size = 3x/8 ; 2(1.5/8)=3/8=.375
>
>Where Burst size is 1.5 times bit rate over 8 and Maximum Burst Size is
>twice that value. I understand that 8 comes from the timer interval.
>
>Here's my question. Why (3/16)x for the burst and (3/8)x for the max
>burst?
>
>Doesn't that undermine the limiting you are trying to do?
>
>Is it the convention to use 3/16's and 3/8's? If so I'll start using
>3/16's and 3/8's, they are easily to remember.
>
>Personally, if I was trying to limit a bit rate, I would use:
>
>Bit rate = x
>
>Burst Size= x/8 (time interval)
>
>Max Burst = 0 (no extra bits on my watch)
>
>
>Could someone enlighten me, if we are trying to limit something, why
>would we inflate the burst and max burst sizes?
>
>
>
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
>Glenn Johnson
>Sent: Sunday, August 11, 2002 11:44 AM
>To: ccielab@groupstudy.com
>Subject: RE: QOS Question from Routopia LAB 3
>
>Quoting original problem --
>
>; Configure the serial interface on R6 so that Ping
>; traffic can only
>; utilize 10% of available bandwidth. Allow BGP to
>; utilize no more
>; than 20% of available bandwidth. Allow all other
>; traffic to utilize up
>; to 70% of available link capacity.
>
>I'm _far_ from a QoS expert, but wouldn't three separate rate-limit
>statements work? (you could add three more if 'input' control was an
>issue as well -- something you can't do with CBWFQ, which seems limited
>to output control [at least on my equip])
>
>Assuming a 256k link for purposes of calc.
>
>10% is 25600
>20% is 51200
>70% is 179200
>
>The burst values below were calculated using the target limit/8 and then
>multiplying by 1.5, and finally multiplying that number by 2.
>
>Originally entered as:
>(Conf-if)
> 101 25600 4800 9600 conform-action
>transmit exceed-action drop
>rate-limit output access-group 102 51200 9600 19200 conform-action
>transmit exceed-action drop
>rate-limit output access-group 103 179200 33600 67200 conform-action
>transmit exceed-action drop
>
>Then from sh run int fa0/0 (things get rounded)
>
>Interface FastEthernet0/0
>ip address 10.1.1.1 255.255.255.0
>rate-limit output access-group 101 24000 4800 9600 conform-action
>transmit exceed-action drop
>rate-limit output access-group 102 48000 9600 19200 conform-action
>transmit exceed-action drop
>rate-limit output access-group 103 176000 33600 67200 conform-action
>transmit exceed-action drop
>
>
>access-list 101 permit icmp any any
>access-list 102 permit tcp any any eq bgp
>Access-list 103 permit ip any any
>
>(following some intense icmp traffic)
>
>Router#sh int fa0/0 rate-limit
>FastEthernet0/0
> Output
> matches: access-group 101
> params: 24000 bps, 4800 limit, 9600 extended limit
> conformed 31 packets, 27334 bytes; action: transmit
> exceeded 3 packets, 4542 bytes; action: drop
> last packet: 14692ms ago, current burst: 6068 bytes
> last cleared 00:01:10 ago, conformed 3000 bps, exceeded 0 bps
> matches: access-group 102
> params: 48000 bps, 9600 limit, 19200 extended limit
> conformed 0 packets, 0 bytes; action: transmit
> exceeded 0 packets, 0 bytes; action: drop
> last packet: 3233872ms ago, current burst: 0 bytes
> last cleared 00:01:10 ago, conformed 0 bps, exceeded 0 bps
> matches: access-group 103
> params: 176000 bps, 33600 limit, 67200 extended limit
> conformed 0 packets, 0 bytes; action: transmit
> exceeded 0 packets, 0 bytes; action: drop
> last packet: 3233876ms ago, current burst: 0 bytes
> last cleared 00:01:10 ago, conformed 0 bps, exceeded 0 bps
>
>This seems to work. My question is should we go back and adjust the
>burst values based on the IOS rounding of our initial numbers?
>
>Thanks
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:48:23 GMT-3