Cisco Support Community
Community Member

Traffic shaping on FR connection, 140ms packet delay? normal?

How much delay should I expect when using traffic shaping on a Frame Relay connection, FIFO queuing?

This is a 3640, IP only, 12.2(5a) 32MB dram. The router is not busy.

The connection is a simple serial connection, 1,280Kbps to a DCE device, Cisco IAD interface emulating FR. Testing showed a ping between the 3640 and the IAD DCE(not going over the Wan) takes 2-3ms without Traffic shaping but 140+ms with traffic shaping. The serial port is not very busy with 4 other sites, and monitoring TS (show Traffic Stat) showed it not active at the time of testing.

The remote sites and out testing shows a dramatic increase in delay when we increase the packet size from 100 to 1,000 Bytes.

The router was power cycled and the results did not change.

Is a 140ms delay normal with traffic shaping?

Should I deploy a different queuing methond? (now default method FIFO)

Is there known bugs at this level? (I could not find any hits on this)


Re: Traffic shaping on FR connection, 140ms packet delay? normal

Hi - the delay with FRTS is going to be more than without FRTS. However, there are a couple of things to look at:

- what is the configured Bc on the map class

- do you see the pkts delayed / bytes delayed counter incrementing in sh frame pvc xx

The queuing method should be fine - also take a look at the link below for more info on FRTS:

Community Member

Re: Traffic shaping on FR connection, 140ms packet delay? normal

Here is relative config info for the line, PVC and map class used.

interface Serial0/1

description CID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

bandwidth 1280

no ip address

no ip proxy-arp

encapsulation frame-relay

load-interval 30

no fair-queue

frame-relay traffic-shaping

frame-relay lmi-type ansi



interface Serial0/1.100 point-to-point

description xxx diag access

ip address

frame-relay class 256Kcir

frame-relay interface-dlci 100 IETF


map-class frame-relay 256Kcir

no frame-relay adaptive-shaping

frame-relay cir 256000

frame-relay mincir 256000

When we were testing the traffic shaping stats and PVC stats did not show packets delayed. The circuit s0/1 was around 100k total usage on a 30 second avg.

When using a ping length of 100 the avg delay was 2ms.

When using a ping length of 1,000 the avg delay was 140ms.

I found that when I used a map class with a "mincir=192000" and put the frame class statement on the line S0/1 the delay for a 1,000 byte ping was reduced to 35ms or so. I believe this is related to the total number of PVC on the line had a mincir that >= total line speed.

When I removed the "Frame traffic-shaping" statement from the line S0/1 the respone of a 1,000 byte ping averaged 16ms, or so.

The carrier want us to use traffic shaping, to avoid FR to ATM overload but we find, for now it works without TS. They may insist that we use TS as the traffic increases.

Your opinion please.

CreatePlease to create content