High Utilization causing Frame-Relay reset?

[f.sorrentino]

Evening all,

Looking for a bit of advice with an issue I am looking into.

I have a frame Relay serial link configured for 1.5Mb which is being heavily utilized pretty consistently.  What I am seeing is some up/down entries in the log.  However the timings between the down and the up are either 20, 30 or 40 seconds which seems strange.  The physical circuit appears to be stable so I am wondering if excessive high usage could cause the FR link to reset.

If so, would disabling the keepalives resolve the issue?  I have tried increasing the hold queue but the drops continue.

Oct 26 19:53:03.720 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/1, changed state to down

Oct 26 19:53:33.721 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/1, changed state to up

Oct 26 20:21:03.755 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/1, changed state to down

Oct 26 20:21:33.755 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/1, changed state to up

Oct 26 21:16:53.829 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/1, changed state to down

Oct 26 21:17:23.830 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/1, changed state to up

Oct 26 21:44:43.869 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/1, changed state to down

Oct 26 21:45:13.869 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/1, changed state to up

Oct 26 22:12:33.901 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/1, changed state to down

Oct 26 22:13:03.901 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/1, changed state to up

Oct 26 22:40:23.973 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/1, changed state to down

Oct 26 22:40:53.974 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/1, changed state to up

Oct 26 23:08:14.006 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/1, changed state to down

Oct 26 23:08:44.007 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/1, changed state to up

Oct 26 23:36:14.039 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/1, changed state to down

Oct 26 23:36:44.039 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/1, changed state to up

Oct 27 00:04:04.072 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/1, changed state to down

Oct 27 00:04:34.072 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/1, changed state to up

Serial0/0/1 is up, line protocol is up

  Hardware is GT96K Serial

  Description: XXXXXXXXXXXXXXXXXXX

  MTU 1500 bytes, BW 1536 Kbit/sec, DLY 20000 usec,

     reliability 255/255, txload 252/255, rxload 236/255

  Encapsulation FRAME-RELAY, loopback not set

  Keepalive set (10 sec)

  Restart-Delay is 0 secs

  CRC checking enabled

  LMI enq sent  0, LMI stat recvd 0, LMI upd recvd 0, DTE LMI up

  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0

  LMI DLCI 1023  LMI type is CISCO  frame relay DTE

  FR SVC disabled, LAPF state down

  Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0

  Last input 00:00:00, output 00:00:00, output hang never

  Last clearing of "show interface" counters 00:00:05 <<<<<<<

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 1404 <<<<<<<<<<

  Queueing strategy: Class-based queueing

  Output queue: 44/2048/64/1404 (size/max total/threshold/drops)

     Conversations  3/51/256 (active/max active/max total)

     Reserved Conversations 5/5 (allocated/max allocated)

     Available Bandwidth 88 kilobits/sec

  30 second input rate 1426000 bits/sec, 151 packets/sec

  30 second output rate 1520000 bits/sec, 370 packets/sec

     786 packets input, 928325 bytes, 0 no buffer

     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

     1973 packets output, 962868 bytes, 0 underruns

     0 output errors, 0 collisions, 0 interface resets

     0 unknown protocol drops

     0 output buffer failures, 0 output buffers swapped out

     0 carrier transitions

     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

[Richard Burts]

The information that you have posted does show that the circuit is overutilized and is experiencing dropped packets. It is reasonable to assume that the keepalive/LMI packets are among what is being dropped and this accounts for the line protocol going down and then back up (in multiples of 10 seconds). Your output show   Queueing strategy: Class-based queueing and I wonder if seeing how the classes are configured would help (especially whether it is possible to put the keepalive traffic in a more favored class).

HTH

Rick

[Joseph W. Doherty]

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

I suspect Rick has put his finger on the issue, the very high utilization with a high drop rate.  We see a 71% egress drop rate in your stats!  If you have egress FQ, perhaps this isn't impacting egress LMIs, but as Rick notes, seeing what's configured would help.

As the ingress utilization is also very high, if LMIs are being lost, they might be being lost there.  I.e. don't forget you need to account for LMIs in both directions.  If there is an issue with ingress, we would also need to know more about your topology and what's on the other side.