From: Dan Lockwood (dlockwood@xxxxxxxxxxxxxxxxxxxx)
Date: Sun Jun 30 2002 - 02:20:41 GMT-3
Keith,
I think that your Bc should be 96000. I have included a post from one of the o
ther members. To be honest I did not understand FRTS until I read his post and
now it seems to make sense. He suggests that you determine your Bc by dividin
g minCIR by 8. This results from the 8 time periods in one second or .125ms as
the default for IOS. I wont mix words, he did a much better job of expaining
it.
Cheers,
Dan
Larry Roberts wrote:
Shaping mechanisms, such as Frame Relay Traffic Shaping (FRTS) and Committed
Access Rate (CAR) use a token bucket mechanism. The token bucket basically
regulates the amount of data that can be sent during a time period. Data
can only be sent if there are enough free tokens in the token bucket
equivalent to that amount of data. If there are enough tokens, the data is sent
and
the appropriate amount of tokens are removed from the Token Bucket. If there
is not enough tokens, the router will buffer the data until the Token Bucket
has enough tokens to send the data and then remove the appropriate amount
of tokens. There are many terms and formulas you must understand to grasp
this concept:
CIR (Committed Information Rate) - This is the average amount of data that
either you (or your service provider) wants you to be able to send
Bc - (Committed Burst) - This is the amount of data that can be sent
during
a time interval. There is really no bursting at this point. This is just
the
amount of data that you are allowed to send each time interval to meet
your
CIR.
Be - (Excess Burst) - Here is where bursting happens. This is normally the
difference between your CIR and actual line access rate (or another
pre-defined parameter by your service provider).
Be + CIR = the depth of the token bucket
Bc = the rate at which tokens are added to the bucket
Now, in order to put all of this together we need one more important piece
of data. That piece of data is the time interval or Tc.
Tc = Bc/CIR
This usually comes out to 0.125 or 125ms. This is the default setting on
Cisco routers.
Example - I have a 128k Frame Relay circuit. I have configured the CIR as
64k. By default, the Tc is 125ms. So, 0.125 times 64,000 = 8,000.
Therefore,
my default Bc is 8,000. Therefore, my token bucket fills at this rate and
allows me to send 8k every 125ms. 125ms is one eighth of a second. So,
8,000
times 8 equals 64,000 or 64k per second. Now, my actual line speed is
128k.
I can configure a Be of 64k. This will allow my Token Bucket to fill to a
capacity of 128k. This means that if I don't send any data for a period of
128,000 divided by 8,000 = 16 time intervals, which equals 2 seconds, my
token bucket will fill to capacity and during the next time interval I can
send 128k worth of data or burst to 128k. However, I would then go into a
period of quite time where I couldn't send any data at all until the token
bucket filled back up to CIR, which would be CIR (64,000) divided by Bc
(8,000) = 8 time intervals or one second.
Now, this is probably the perfect example of how to do this right. However,
when you get into higher data rates, the quite time after the burst can get
quite lengthy. Also, a Tc of 125ms works great for data, but this should be
adjusted to 10ms if you are running Voice across the Frame Relay circuit.
HTH,
Larry Roberts
CCIE #7886 (R&S / Security)
-----Original Message-----
From: Keith Steller [mailto:ksteller@attbi.com]
Sent: Saturday, June 29, 2002 4:21 PM
To: Ccielab@Groupstudy. Com
Subject: FRTS and DE packets
I have a customer with the typical hub and spoke frame-relay config. I
implemented FRTS for BECN adapting. The problem with incrementing BECN's
went away. I am still wrestling with packets being marked DE at the remotes
(as seen below). Based on the "DE in packets" I am thinking that there is a
congestion issue at the hub location since several 768k pipes empty into a
t1. Any way to throttle the traffic back further? Should I drop the CIR and
MIN CIR in the FRTS? Any other ideas? Btw, this counter was cleared a day
ago and I already have a ton of DE pkts.
Thanks,
Keith
****************************spoke location**************************
RP#sh frame pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 16, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.16
input pkts 362679 output pkts 333278 in bytes 171925362
out bytes 59043979 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 8010 out DE pkts 0
out bcast pkts 24043 out bcast bytes 1538752
Shaping adapts to BECN
pvc create time 40w0d, last time pvc status changed 9w5d
RiverPoint#sh traffic
Interface Se0.16
Access Target Byte Sustain Excess Interval Increment Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes)
Active
16 1544000 6000 192000 0 31 5983 BECN
RiverPoint#sh config
!
interface Serial0
description xxx Frame Relay (Local DLCI 19)
bandwidth 768
no ip address
encapsulation frame-relay
no fair-queue
frame-relay traffic-shaping
frame-relay lmi-type cisco
!
interface Serial0.16 point-to-point
description Frame Relay connection to xxx
bandwidth 768
ip address 172.17.1.14 255.255.255.252
no arp frame-relay
no cdp enable
frame-relay class 768_CIR
frame-relay interface-dlci 16
!
!
map-class frame-relay 768_CIR
frame-relay adaptive-shaping becn
frame-relay cir 1544000
frame-relay bc 192000
frame-relay mincir 768000
frame-relay priority-group 1
access-list 150 permit tcp any any range 1525 1530
access-list 150 permit tcp any range 1525 1530 any
priority-list 1 protocol ip high list 150
!
This archive was generated by hypermail 2.1.4 : Tue Jul 02 2002 - 08:12:44 GMT-3