cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2095
Views
0
Helpful
8
Replies

Serial Line Bouncing

johnlloyd_13
Level 9
Level 9

all,

our serial wan link has been bouncing up and down for a couple of weeks now. we have reported this incident to our telco several times, but they always tested it "clean." would this be a hardware issue? what should things should i check? i cleared the errors after the telco test.

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

Hardware is GT96K Serial

Description: VzB T1 Circuit ID BCBJP9J10001

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

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation FRAME-RELAY IETF, loopback not set

Keepalive set (10 sec)

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

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

LMI DLCI 0 LMI type is ANSI Annex D 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:10

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

Queueing strategy: Class-based queueing

Output queue: 0/1000/64/0 (size/max total/threshold/drops)

Conversations 0/37/256 (active/max active/max total)

Reserved Conversations 1/1 (allocated/max allocated)

Available Bandwidth 512 kilobits/sec

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

5 minute output rate 2000 bits/sec, 6 packets/sec

62 packets input, 3330 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

66 packets output, 5919 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

Timeslot(s) Used:1-24, SCC: 0, Transmitter delay is 0 flags

1 Accepted Solution

Accepted Solutions

John

I had noticed this in your previous post:

Queueing strategy: Class-based queueing

which indicates that you are using Class Based Queuing and wondered if it might be part of this issue. While I can not absolutely rule it out, I do not believe that Class Based Queuing is part of the issue. I believe this mainly because that queuing probably affects the traffic that you send out (if you post the config we would know for sure) and the problem is requests that you send to the telco for which you get no response. I do not see your queuing causing that.

The way that Frame Relay works is that you periodically send a request to the Frame Relay switch for status information. The switch should send a response and in the response is information about any PVCs associated with your link and their status. When the switch sees requests from you it knows that you are available to receive traffic and will send to you. When you receive responses you know that the switch is available and you will send traffic. When you send several requests and do not get responses to several consecutive requests then you assume that the switch is not available. The Num Status Enq. Sent is requests that you have sent and Num Status msgs Rcvd are the responses that you have received. These numbers should be fairly close (a small difference does not matter much). But a large difference idicates a problem. I believe that this number of timeouts Num Status Timeouts 1143 represents a problem.

The difference between Last Full Status Req and Last Full Status Recvd is not a significant issue. When you send the status request the switch will normally send a "short" response and every sixth response will be a "full" response which has more data (and is a bigger packet). As long as there do not get over a couple of minutes you are well within the range of normal.

[edit] I would point to this as additional evidence that there are problems between you and the Frame Relay switch:

16362694 input errors, 16362694 CRC, 6988501 frame, 3909883 overrun, 0 ignored, 12297155 abort

HTH

Rick

HTH

Rick

View solution in original post

8 Replies 8

Richard Burts
Hall of Fame
Hall of Fame

John

There are several things that might cause this symptom. I have seen a pair of routers with the keepalive timer set for different values on each router where it caused this flapping symptom. Can you also post the show interface from the other router?

When there is interface flapping on an interface configured as Frame Relay one of the things I look at is in this line:

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

but with only 1 sent and 1 received it is hard to know whether there is some issue between the router and the Frame Relay switch. If you would post the output after the router has been running for a while (and especially after there has been some flapping episode) it would be more helpful.

HTH

Rick

HTH

Rick

hi rick,

thanks for your input. here's another show interface output after 3 hours and 25 minutes after being stable. i checked LMI sent and received, and both are equal values (1235). i will check with telco (their PE router) if keepalive timer is set to a value other than 10 sec (our CE router).

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

Hardware is GT96K Serial

Description: VzB T1 Circuit ID BCBJP9J10001

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

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation FRAME-RELAY IETF, loopback not set

Keepalive set (10 sec)

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

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

LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE

FR SVC disabled, LAPF state down

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

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

Last clearing of "show interface" counters 03:25:50

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

Queueing strategy: Class-based queueing

Output queue: 0/1000/64/0 (size/max total/threshold/drops)

Conversations 0/37/256 (active/max active/max total)

Reserved Conversations 1/1 (allocated/max allocated)

Available Bandwidth 512 kilobits/sec

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

5 minute output rate 1000 bits/sec, 2 packets/sec

21608 packets input, 1644003 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

18891 packets output, 1689207 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

Timeslot(s) Used:1-24, SCC: 0, Transmitter delay is 0 flags

John

Thanks for the update on this issue. LMI sent and received being equal is a good thing. My suggestion at this point is to continue to investigate with the provider any possible configuration differences and to wait for another instance where the interface flaps and to post another show interface (checking the LMI sent and received) at that time.

HTH

Rick

HTH

Rick

got back in the office and found out again that the interface went flapping. telco provided their PE router keepalive setting and it was set to 10 sec. will ask telco for any misconfigurations. i have another show interface that has unequal LMI sent and received.

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

Hardware is GT96K Serial

Description: VzB T1 Circuit ID BCBJP9J10001

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

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation FRAME-RELAY IETF, loopback not set

Keepalive set (10 sec)

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

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

LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE

FR SVC disabled, LAPF state down

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

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

Last clearing of "show interface" counters 18:01:24

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

Queueing strategy: Class-based queueing

Output queue: 0/1000/64/0 (size/max total/threshold/drops)

Conversations 0/37/256 (active/max active/max total)

Reserved Conversations 1/1 (allocated/max allocated)

Available Bandwidth 512 kilobits/sec

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

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

93453 packets input, 7387374 bytes, 0 no buffer

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

16362694 input errors, 16362694 CRC, 6988501 frame, 3909883 overrun, 0 igno

red, 12297155 abort

84700 packets output, 7852652 bytes, 0 underruns

0 output errors, 0 collisions, 2 interface resets

0 output buffer failures, 0 output buffers swapped out

30 carrier transitions

Timeslot(s) Used:1-24, SCC: 0, Transmitter delay is 0 flags

John

The mismatch between LMI enq sent of 6290 (when you sent requests to the Frame Relay switch) and the LMI received of 5161 (when you got responses from the Frame Relay switch) shows numerous instances of when you sent requests to the Frame Relay switch for which you did not receive responses. And missing 3 consecutively will cause the Frame Relay interface to go down (and then come up the next time it sends a request and receives a response.

I would continue to press the tlco for their specific configuration parameters for the link to you.

It might also be helpful if you post the output of show frame-relay lmi.

[note] in reading more closely what you posted I notice this line:

16362694 input errors, 16362694 CRC, 6988501 frame, 3909883 overrun, 0 ignored, 12297155 abort

which I believe demonstrates some mismatch between you and the provider.

HTH

Rick

HTH

Rick

rick,

here's the show frame-relay lmi output. i counter checked this with our other frame-relay circuit, and the differences that i noticed is that the Num Status Enq. Sent and Num Status msgs Rcvd traffic counts are almost the same. does it affect whether you have different Queueing strategy? this circuit is Class-based queueing while the one i've checked with is weighted fair. lastly, the Last Full Status Req and Last Full Status Rcvd are both 00:00:00 on this circuit while there's a count of 00:00:31 on the one that is working.

LMI Statistics for interface Serial0/1/0:0 (Frame Relay DTE) LMI TYPE = ANSI

Invalid Unnumbered info 0 Invalid Prot Disc 0

Invalid dummy Call Ref 0 Invalid Msg Type 0

Invalid Status Message 0 Invalid Lock Shift 0

Invalid Information ID 0 Invalid Report IE Len 0

Invalid Report Request 0 Invalid Keep IE Len 0

Num Status Enq. Sent 9635 Num Status msgs Rcvd 8492

Num Update Status Rcvd 0 Num Status Timeouts 1143

Last Full Status Req 00:00:00 Last Full Status Rcvd 00:00:00

John

I had noticed this in your previous post:

Queueing strategy: Class-based queueing

which indicates that you are using Class Based Queuing and wondered if it might be part of this issue. While I can not absolutely rule it out, I do not believe that Class Based Queuing is part of the issue. I believe this mainly because that queuing probably affects the traffic that you send out (if you post the config we would know for sure) and the problem is requests that you send to the telco for which you get no response. I do not see your queuing causing that.

The way that Frame Relay works is that you periodically send a request to the Frame Relay switch for status information. The switch should send a response and in the response is information about any PVCs associated with your link and their status. When the switch sees requests from you it knows that you are available to receive traffic and will send to you. When you receive responses you know that the switch is available and you will send traffic. When you send several requests and do not get responses to several consecutive requests then you assume that the switch is not available. The Num Status Enq. Sent is requests that you have sent and Num Status msgs Rcvd are the responses that you have received. These numbers should be fairly close (a small difference does not matter much). But a large difference idicates a problem. I believe that this number of timeouts Num Status Timeouts 1143 represents a problem.

The difference between Last Full Status Req and Last Full Status Recvd is not a significant issue. When you send the status request the switch will normally send a "short" response and every sixth response will be a "full" response which has more data (and is a bigger packet). As long as there do not get over a couple of minutes you are well within the range of normal.

[edit] I would point to this as additional evidence that there are problems between you and the Frame Relay switch:

16362694 input errors, 16362694 CRC, 6988501 frame, 3909883 overrun, 0 ignored, 12297155 abort

HTH

Rick

HTH

Rick

hi rick, this T1 has been a nuisance in our network and operations. we demanded telco to re-route this circuit and observe. thanks for your patient inputs!

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: