From: Connie Nie (CNie@EPLUS.com)
Date: Fri Apr 25 2003 - 12:15:54 GMT-3
I am a little confused here. Brian's explanation makes a lot of sense. If I
understand it right, during every tc, the bc bucket will be emptied first,
then the be bucket is checked for credit. In that case, if the burst is to a
full E-1, then this "burst" here is the sum of the token taken out of both
bc and be bucket. So shouldn't the be then:
2048000x30 - (256000x30) ???
Am I missing something here?
Connie
-----Original Message-----
From: Danny.Andaluz@triaton-na.com [mailto:Danny.Andaluz@triaton-na.com]
Sent: Friday, April 25, 2003 8:47 AM
To: ccielab@groupstudy.com
Subject: RE: Frame-Relay Traffic Shaping "Be" Value
So an example like this is valid?:
(This is generic traffic shaping, but I think the concept is pretty much the
same.)
An ISP wants to sell a service in which a customer may use all of an E-1
line for 30 seconds in a burst, but on long term average, is limited to
256000.
Bit rate: 256000 output rate is 256000
Burst size: 32000 (the number of bits sent in a 125 msec
Excess burst: 61440000 = 2048000(30 secs.)
Config would look like this:
Interface s1/0
traffic-shape rate 256000 32000 61440000
I got this straight from the cisco web site.
-----Original Message-----
From: Brian Dennis [mailto:brian@labforge.com]
Sent: Thursday, April 24, 2003 11:49 PM
To: 'Connie Nie'; ccielab@groupstudy.com
Subject: RE: Frame-Relay Traffic Shaping "Be" Value
I won't say there is a hard and fast rule of what Be should or shouldn't be
because it's really dependant on the needs of the network. If a network had
voice traffic going across the frame-relay cloud Be should be set to 0 and
CIR should equal the provider's CIR. If there was a lot of traffic that
needs to burst then a Be value could be configured.
In the end it's up to the network administrator to configure a Bc and Be
value that works for their network. But keep in mind when configuring Be the
line rate and the queue sizes (hardware and FRTS). If you configure a very
large Be value on a slow line you could create the possibility of
overrunning the queues and in turn cause the router to drop packets. If you
need to have a large Be value on a slow line I would recommend increasing
the FRTS queue and interface output queue.
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
Connie Nie
Sent: Thursday, April 24, 2003 7:13 PM
To: ccielab@groupstudy.com
Subject: RE: Frame-Relay Traffic Shaping "Be" Value
Dennis: What would be the formula to calculate be then? Does the formula
(be+bc)/tc=AIR still stand?
Connie
-----Original Message-----
From: Brian Dennis [mailto:brian@labforge.com]
Sent: Thursday, April 24, 2003 7:00 PM
To: ccielab@groupstudy.com
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