Frame relay traffic shaping - late output drops

[karthikvish2000]

I have a branch site having issues with frame-relay.

The branch is configured with FRTS. Traffic is shaped to 64k/64k(cir/mincir) and adapts to BECN. EEK has been configured for the PVC.

Lately the site is experiencing intermittent frame-relay flaps about 5 - 10 time a day. Router log shows %FR_EEK-FAILED: messages.

show frame relay pvc xxx command shows a lot of output drops and all the output drops are late drops.

I thought that the late output drops were due to high output traffic causing FRTS to shape traffic which makes outout queue overflow and hence packet getting dropped. But when I checked the link utilisation on NetQos it indicates that everytime an EEK failure happened there was a spike in the input traffic (nearly 64K). The output traffic has never been more than 10K at the most.

This phenomenon totally confuses me. Why should output drops/late drops occur when output datarate is much less than the mincir?

Are the late output drops in anyway related to the spike in the input traffic?

And also I dont see any input drops at all.

[Jerry Ye]

Hi,

I see your serial interface is taking some errors. Just curious, does the error counter increasing or not? Before and after the EEK_FAILED message.

I am suspecting there is problem on the telco side.

HTH,

jerry

[karthikvish2000]

The errors on the interface is an ongoing issue but I have confirmed that those errors are not causing the EEK timouts. Mulitple EEK timeouts occur even when the errors don't increment.

[Giuseppe Larosa]

Hello Khartik,

you are using end-to-end keepalives so the state of the PVC is conditioned to correct reception of these end-to-end keepalives.

When you have a peak of input traffic there are chances that some frames are dropped including the EEK frames.

When the router complains of missing EEK frames what is the state of the pvc:

for the me the key lines are :

DLCI = 226, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE (>>EEK UP), INTERFACE = Serial

0/0/0.226

pvc create time 1w6d, last time pvc status changed >> 00:20:49

if the pvc changes state ACTIVE-inactive packets holded for trasmission are dropped and so you see output drops.

Then as soon as EEK are seen again the PVC changes state again to ACTIVE

I would suggest you to try to see what happens without EEK if you can change configuration at both sites.

Hope to help

Giuseppe

[karthikvish2000]

Hi Giuseppe,

Thanks for your response. This explanation seems to fit in place but I have another doubt reg the same issue. For the time being lets assume that your theory is 100% correct and the spike in input traffic causes the packet drops(including EEKs) which in turn brings the PVC down.

The site under question is a branch site attached to a core site. From the core router's perspective input traffic for the branch would be its output traffic. When the output traffic at the core end spikes(say over 64K) would'nt the core router explicitly traffic-shape and drop some output packets?

And if it does so would'nt the "traffic-shapping drops" counter increment?

But that does'nt seem to be the case here. The counter is always zero. So, can you please explain as to what exactly traffic-shapping does here and how(things like does it just shape the traffic or polices the traffic etc. and what counters indicate what)? Things area a bit fuzzy for me at the momment with FRTS. Cisco doco is not very helpful as well.

I have attached the output for "sh frame pvc xxx" from the core router.

thanks,

[Giuseppe Larosa]

Hello Khartik,

for me this second attachment file is equal to the first one.

However, it is not a problem.

FRTS performs output shaping so normally packets are hold in a software queue waiting to be transmitted.

You can see that FRTS has worked by the lines:

delayed packets ... delayed bytes ...

this is the action of shaping

frames shouldn't be dropped unless some event happens that makes the DLCI temporary unusable, or traffic is so higher than the shaping rate that the dedicated buffers for holding frames to be shaped are full.

When I mean some frames can be dropped when input rate is near or somewhat higher then input CIR, I mean that can be dropped inside the FR cloud if it experiences congestion it provides just CIR nothing more.

if this is the case using FRTS adaptive shaping allows the DTEs to react to FECN or better to BECN by slowing down the rate.

the command should be in frame-relay map-class mode:

frame-relay adaptive shaping

This can provide some benefits if the issue is caused by these peaks that can cause some drops in the wan cloud.

Edit:

I see that you have already configured adapting to BECN. so this cannot solve.

Hope to help

Giuseppe

[karthikvish2000]

Hi Giuseppe,

Thanks for your response. For the moment I think the only permanent solution is BW upgrade. Will try that.