From: Carlos G Mendioroz (tron@xxxxxxxxxxx)
Date: Sun Jun 30 2002 - 10:38:12 GMT-3
Keith,
minCIR is the minimum rate your shapping will agree to go down to.
If you set it to 768, then you will be doing no shapping at all
when your hub becomes congested!
Also, your setting of CIR at 1.5M will make you try to send at that
rate for as long as you don't get BECNs... that is only good if your
provider don't drop these packets right away. You'll have to check
your provider's contract...
As for the DE's, I think the problem lies on the other side (your hub)
because these are being set most probably by the network because of
your hub transmitting above your contract rates.
At the ingress of your provider network, the ingress switch is marking
them
so that is congestion is seen anywhere in the path, your over the
contract
packets are the first to go /dev/null :-)
HTH,
Keith Steller wrote:
>
> Thanks for the info Dan. I was on the line with a guy from TAC the other day
> and he said to use port speed to calc the Bc. I will definitely check that
> out though. I may also throttle back the CIR and MIN CIR to 768k as
> suggested on the list. Also, I exchanged an email with someone that said
> they found this particular Frame-relay provider was known to mark all
> traffic above the CIR DE, but not drop it. More to come... Thanks again for
> the info!
>
> Keith
>
> -----Original Message-----
> From: Dan Lockwood [mailto:dlockwood@shastalink.k12.ca.us]
> Sent: Sunday, June 30, 2002 12:21 AM
> 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
> 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