From: OhioHondo (ohiohondo@columbus.rr.com)
Date: Fri Apr 25 2003 - 07:56:57 GMT-3
Brian has a GREAT point here -- and it is the cause of many of the problems
questions. When stating CIR you must know if it is the providers CIR or
Cisco CIR that the question is giving you. They are used in entirely
different manners by the router. If the stated cir is the cisco CIR then....
cir = 64000
mincir= 32000
bc= 8000
be= 8000
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Brian Dennis
Sent: Thursday, April 24, 2003 11:35 PM
To: 'Nguyen Hoang Long'; ccielab@groupstudy.com
Subject: RE: Frame-Relay Traffic Shaping "Be" Value
map-class frame-relay MyFRTSMap
frame-relay cir 128000
This would allow the router to send at 128k all the time. If they wanted
you to throttle back to "CIR" in case of congestion this would be the
answer:
map-class frame-relay MyFRTSMap
frame-relay cir 128000
frame-relay adaptive-shaping becn
Of course this assumes the CIR is the provider's CIR and not the Cisco
CIR ;-)
Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
Director of CCIE Training and Development - IPexpert, Inc.
Mailto: brian@ipexpert.net
Toll Free: 866.225.8064
Outside U.S. & Canada: 312.321.6924
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Nguyen Hoang Long
Sent: Thursday, April 24, 2003 7:29 PM
To: ccielab@groupstudy.com
Subject: Re: Frame-Relay Traffic Shaping "Be" Value
Hi Brian,
hmmm!? what value I should use if the question is somthing like:
CIR=64k
AR=128k
configure the end router so you can have data transmited as maximum as
possible.
I believe the Proctor won't tell me any about configuration specific.
thanks
Long.
----- Original Message -----
From: "Brian Dennis" <brian@labforge.com>
To: <ccielab@groupstudy.com>
Sent: Friday, April 25, 2003 7:00 AM
Subject: Frame-Relay Traffic Shaping "Be" Value
> After testing FRTS I can say that Be can be larger than the previous
> "internal interval" (Tc) and even the previous "interval" (full
second).
> There does not appear to be a limit as to how long Be can continue to
> build up credits (aka tokens). This means that Be can hold credits
from
> a multitude of previous Tc's and even a multitude of full seconds.
I've
> tested FRTS scenarios where Be credits built up over 10 minutes (CIR =
> 16000 and Be = 12000000).
>
> For those interested in understanding FRTS let me explain it from the
> perspective a single "bucket" (i.e. Be = 0) FRST configuration and
then
> from a dual "bucket" (i.e. Be > 0) FRST configuration.
>
> Let's start off the single bucket explanation:
>
> map-class frame-relay SingleBucket
> frame-relay cir 16000
> frame-relay bc 2000
>
> When we first apply FRTS to an interface (or DLCI) we will start out
> with a single bucket full of credits. Every Tc the amount of credits
> equaling Bc is added to this bucket. When a packet needs to be sent
the
> router will check to see if there are enough credits to send the
packet
> (1 credit equals 1 bit). If there are enough credits, the router will
> send the packet and removes the amount of credits equaling the size of
> the packet. If there are not enough credits the packet gets "shaped"
and
> placed in the FRTS hold queue awaiting enough credits to send the
> packet.
>
> Since this is a single bucket configuration we do not store excess
> credits and theoretically can never send more than Bc amount of bits
per
> Tc. If this bucket has credits left over when the next Tc starts these
> left over credits will be lost. This is because at the start of every
Tc
> Bc amount of credits are added to this bucket that can only hold Bc
> amount of credits.
>
> In contrast to CAR FRTS will never borrow credits from future Bc's and
> will theoretically never go into debt. This ensures that with FRTS the
> router is always guaranteed to have credits to send every Tc. As a
side
> note remember that CAR on the other hand does not really guarantee
> bandwidth. CAR only limits bandwidth.
>
> Now the dual bucket explanation:
>
> map-class frame-relay DualBucket
> frame-relay cir 16000
> frame-relay bc 2000
> frame-relay be 62000
>
> When we first apply FRTS to an interface (or DLCI) we will start out
> with two buckets full of credits. Lets call the first bucket the Bc
> bucket and the second bucket the Be bucket. When a packet needs to be
> sent the router will check to see if the Bc bucket has enough credits
to
> send the packet. If it does have enough credits the packet is sent and
> the amount of credits equaling the size of the packet is removed from
> the Bc bucket. If the Bc bucket does not have enough credits the
router
> will check the Be bucket. The packet will be sent if there are enough
> credits in the Be bucket and the amount of credits equaling the size
of
> the packet will be removed from the Be bucket. If there aren't enough
> credits in the Bc or Be buckets the packet is stored in the FRTS hold
> queue till there are enough credits built up to send the packet.
>
> At the start of every Tc Bc amount of credits are added to the Bc
> bucket. If the bucket has credits left over when the next Tc starts
> those credits will cause the Bc bucket to overflow but the overflow
> credits will be caught by the Be bucket. The Be bucket can only hold
Be
> amount of credits. If the Bc and Be buckets are both full the new
> credits added each Tc will be lost.
>
> This is actually my short explanation of FRTS ;-)
>
> Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
> Director of CCIE Training and Development - IPexpert, Inc.
> Mailto: brian@ipexpert.net
> Toll Free: 866.225.8064
> Outside U.S. & Canada: 312.321.6924
This archive was generated by hypermail 2.1.4 : Thu May 01 2003 - 13:36:06 GMT-3