frame-relay traffic-rate command, does it work?

[rbradfield]

I use the traffic rate command in the frame relay calss maps to control traffic.

in the example below the access at the site is 1024k

and the CIR 640K

map-class frame-relay Jam

frame-relay traffic-rate 640000 1024000

no frame-relay adaptive-shaping

frame-relay mincir 640000

service-policy output 206toJF

the customer started complaining of slow responses and said the link did not go above 640K, he uses MRTG tool to monitor the Bandwidth usage of his frame relay pvcs.

so I changed the command to

frame-relay traffic-rate 896000 1024000

then he saw the traffic then peak at 896k

so why does the traffic-rate command not work.

note: the other end of the link has a 2048k access

and is setup in the same way.

In Australia Telstra allow bursting up to 2 X CIR when over 512K

do any other commands in the class map stop the bursting?

anybody got any ideas?

[bstremp]

It could be an IOS-specific bug. The config lines look good. Give TAC a call.

[s.fathinia]

When you use the command:

frame-relay traffic-rate 640000 1024000

the router implements its own values for bc, be and tc etc.

Effectively your mincir becomes 640000 (divided by the number of intervals per second) and the router will set up a value for be. It will actually send out bc + be worth of data in the first time interval. From that point onwards it will not send out any be (excess burst) until it has built up credits.

Credits are built up only when the router actually sends out data at less than bc. If you constantly have data that requires to be sent out, you will never build up credits and therefore never go past 640000 over an extended period of time.

Since Telsta is always generous try using the following values (after getting rid of the frame-relay traffic-rate 640000 1024000 command)

map-class frame-relay Jam

cir 1024000

mincir 640000

bc 128000

be 0

frame-relay adaptive-shaping becn

This will set up the line with an average rate of 1024K and will throttle back on receiving BECNs back to a minimum of 640000. If you find you are getting too many BECNs try reducing CIR and bc a little e.g 960000 and 120000 and increasing be to 64000. This will try to average 960000 and burst up to 1024000.

There are a few URLs on CCO with regards to tc, bc and be and how they are used.

http://www.cisco.com/warp/customer/125/traffic_shaping_6151.html

http://www.cisco.com/warp/customer/788/voip/fr_traffic.html