10-26-2013 06:34 PM - edited 03-04-2019 09:25 PM
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
10-27-2013 10:56 AM
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
10-28-2013 05:56 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide