From: CCIE FUN (ccieexam2002@xxxxxxxxx)
Date: Mon Jul 01 2002 - 01:20:52 GMT-3
Keith
I did notice one thing which is different under your
"show traffic" output.
the time interval shown is 31ms, i guess then the
Bc in your traffic shaping configs should be really
different.
You are going to see a ton of De's because you are
setting up your traffic shaping parameters in that
way.
Like for eg.
the CIR == line access rate.
Bc == line access rate / 8
mincir == CIR assigned by the provider.
Now i believe in terms of the Telco point of view,
any traffic above the CIR ( one which is assigned by
the telco) is DE. However in your case the MINcir is
that value.
To make the long story short, you are assigning the
CIR value which is equals the line access rate.
This means you are allowing traffic to burst about the
CIR assigned by the telco.
I don't think that is the problem, and i think it is
pretty normal practice to do so.
However if you are noticing any traffic issues then i
would definately suggest to change these values to
match the telco provided values. THAT TIME INTERVAL IT
LOOKS DIFFERENT IT SHOULD BE 125MS.
--- yakout esmat <yesmat@iprimus.com.au> wrote:
> Dan,
>
> This is very usefull piece of information.
>
> If we hace a line with 128K access rate and the
> provider is guaranteeing 64K
> rate, is that CIR or minCIR??
> Some docoumentation insist that this is minCIR. If
> that so, then how should
> we calculate the CIR.
>
> TIA
>
> Yak
>
> -----Original Message-----
> From: nobody@groupstudy.com
> [mailto:nobody@groupstudy.com]On Behalf Of
> Dan Lockwood
> Sent: Sunday, June 30, 2002 3:21 PM
> To: Keith Steller; Ccielab@Groupstudy. Com
> Subject: RE: FRTS and DE packets
>
>
> Keith,
>
> I think that your Bc should be 96000. I have
> included a post from one of
> the other 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 dividing 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
>
=== message truncated ===
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:36:16 GMT-3