Possible problem with RSRack16R4 Serial 0/0/0 connection to FRS
Using rack rentals the other day, I struck this problem when trying to bring up a frame relay connection from R4 S0/0/0 DLCI 402 through to R2 S0/0 DLCI 204.
On the R2 side, the physical link came up, and the DLCI was showing INACTIVE (because the R4 side was down).
On the R4 side, the link didn't come up. No LMI received from the FRS. Here's the config section, along with some show output:
[code]RSRack16R4#sh run int s0/0/0
Building configuration...
Current configuration : 71 bytes
!
interface Serial0/0/0
no ip address
encapsulation frame-relay
end
RSRack16R4#sh frame-relay pvc
RSRack16R4#sh frame-relay lmi
LMI Statistics for interface Serial0/0/0 (Frame Relay DTE) LMI TYPE = CISCO
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 43 Num Status msgs Rcvd 0
Num Update Status Rcvd 0 Num Status Timeouts 42
Last Full Status Req 00:00:04 Last Full Status Rcvd never
RSRack16R4#sh int s0/0/0
Serial0/0/0 is up, line protocol is down
Hardware is GT96K Serial
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation FRAME-RELAY, loopback not set
Keepalive set (10 sec)
CRC checking enabled
LMI enq sent 42, LMI stat recvd 0, LMI upd recvd 0, DTE LMI down
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 never, output 00:00:22, output hang never
Last clearing of "show interface" counters 00:07:02
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/1/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 1158 kilobits/sec
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 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
47 packets output, 617 bytes, 0 underruns
0 output errors, 0 collisions, 13 interface resets
0 unknown protocol drops
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out
28 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up
[/code]
I took a look at BB1 as well - obviously this is with limited access to BB1. It seems to also be saying that the link is down:
[code]
RS.16.16.BB1>sh int Serial4
Serial4 is up, line protocol is down
Hardware is CD2430 in sync mode
Description: Connected to R4
MTU 1500 bytes, BW 115 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation FRAME-RELAY, loopback not set
Keepalive set (10 sec)
LMI enq sent 0, LMI stat recvd 0, LMI upd recvd 0
LMI enq recvd 3904, LMI stat sent 3904, LMI upd sent 0, DCE LMI down
LMI DLCI 1023 LMI type is CISCO frame relay DCE
Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0
Last input 1d10h, output 00:14:40, output hang never
Last clearing of "show interface" counters 2d22h
Input queue: 0/75/156/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/1/32 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 86 kilobits/sec
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
10511 packets input, 985016 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 3 giants, 0 throttles
60 input errors, 5 CRC, 0 frame, 0 overrun, 0 ignored, 55 abort
14965 packets output, 1376828 bytes, 0 underruns
0 output errors, 0 collisions, 7115 interface resets
0 output buffer failures, 0 output buffers swapped out
1978 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up
RS.16.16.BB1>
[/code]
Given that the link won't come up at all, but I know that this is something that has worked in the past, since the R4 frame relay connection is used in most labs, my inclination is that there is a problem at the physical layer. Support couldn't find anything wrong in the logs of the connection test. Is there something simple I'm missing here, or would you also conclude it's a physical problem?
Comments
Hi northlandboy,
looking into your configs, most likely it is physical/cable problem.
Below is a snippet from your show interface se4:
abort
Illegal sequence of one bits on a serial interface. This usually indicates a clocking problem between the serial interface and the data link equipment.
giants
Number of packets that are discarded because they exceed the maximum packet size of the medium.
input errors
Total number of no buffer, runts, giants, CRCs, frame, overrun, ignored, and abort counts. Other input-related errors can also increment the count, so that this sum might not balance with the other counts.
CRC
Cyclic redundancy checksum generated by the originating station or far-end device does not match the checksum calculated from the data received. On a serial link, CRCs usually indicate noise, gain hits, or other transmission problems on the data link.
interface resets
Number of times an interface has been completely reset. This can happen if packets queued for transmission were not sent within several seconds' time. On a serial line, this can be caused by a malfunctioning modem that is not supplying the transmit clock signal or by a cable problem. If the system notices that the carrier detect line of a serial interface is up, but the line protocol is down, it periodically resets the interface in an effort to restart it. Interface resets can also occur when an interface is looped back or shut down.
Have you tried to config an IP Address on R4's Serial0/0/0?
Yes, I had previously tried configuring a P2P subinterface on it. I later defaulted the interface configuration, when I realised that something lower level was going wrong. I wanted the simplest interface config possible (in this case just "encapsulation frame-relay"), to check the basics out. When I saw that there was no LMI being received, this indicated it may be a physical issue. I also tried different LMI types, just in case auto-sense was having a bad day. No joy with any of those settings, which is when I tried logging a case. Support didn't see any problems with the interface tests done during rack setup, and suggested I try asking around here.
Great - just wanted to make sure!
I have to say that if you are not receiving any LMIs from your FRSW and you already tried other LMI types just to make sure it was not an "auto" issue then Support needs to take a look into it. I have seen instances in which the PVC will take a long time to come up, but I believe you have waited more than enough. Looks like a layer-1 issue indeed.
Thanks for the support - you think you've checked out all the obvious things, but it's good to know someone else has run their eye over it. I'll go back to support on the matter.
I should just add that I did wait a reasonable amount of time for LMI status updates to be received, and was watching the debug frame-relay lmi output during this time. Nothing was ever received from the FRS.
I just thought I would provide an insider's view to this situation. I don't recall if we fixed a problem on RSRack16 or not, but I can tell that as of September 5, the cable/interface checks show that the serial ports on R4 are OK.
Here is the report from that diagnostic as of this morning: