Showing results for 
Search instead for 
Did you mean: 

Frame-Relay Traffic Shaping and Dropped Output PKTs


We are running a dual-carrier frame environment and have noticed that we have a lot of "byte delayed" and out pkts dropped showing up on many PVCS on both ends and both carrier of our frame-network. We have tweaked Frame-Relay Traffic Maps to reflect individual carrier recommendations (ie Carrier selling OK CIR guarenteeing port speed we set MINCIR to 1/2 of a T1).

No FECNS/BECNS...the aggregation links are not oversubscribed and it appears things are dropping before they even go out...the only thing this seems to point to is either the traffic-maps or perhaps the ethernet switch where the routers terminate...but that doesnt appear to be it.

Any ideas on a good way to troubleshoot this? Buffers seem good as well

Example below:

input pkts 219232 output pkts 210021 in bytes 32300516

out bytes 64629859 dropped pkts 231 in pkts dropped 0

out pkts dropped 231 out bytes dropped 73158

late-dropped out pkts 231 late-dropped out bytes 73158

in FECN pkts 0 in BECN pkts 0 out FECN pkts 0

out BECN pkts 0 in DE pkts 0 out DE pkts 0

out bcast pkts 5107 out bcast bytes 669383

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

pvc create time 14w1d, last time pvc status changed 1w0d

cir 384000 bc 384000 be 0 byte limit 6000 interval 125

mincir 128000 byte increment 6000 Adaptive Shaping none

pkts 210021 bytes 44388411 pkts delayed 12361 bytes delayed 10496435

shaping inactive

traffic shaping drops 0

Queueing strategy: fifo

Output queue 0/40, 231 drop, 12361 dequeued



Hello there,

Try to increase the hold-queue per PVC and serial interface also.

The packets are dropped by the router so there is no FECN/BECN indication from the network as long as the traffic is respecting the contracted values.

You can try a:

CCM-EXPRESS#sh traffic-shape statistics

Acc. Queue Packets Bytes Packets Bytes Shaping

I/F List Depth Delayed Delayed Active

Fa0/0 0 54 4175 0 0 no

to see if there are any delayed packets.

Also, if the sent traffic is bursty, you can have peaks which are dropped and thus, increasing the out hold-queues (interface and FR class-map) you can eliminate the problem.

Good luck!

One more,

I mean, you should increase that queue:


Queueing strategy: fifo

Output queue 0/40, 231 drop, 12361 dequeued



Is that the Frame Relay HoldQ?

We have increased the Output and Input queues on the primary interfaces:

hold-queue 150 in

hold-queue 4000 out

Thanks again for your reply!


Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: