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:

    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

     


    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.

  • Yes, I had previously tried configuring a P2P subinterface on it.

    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:

    (!!!!!!!!) [[8]  R4:Serial0/1/0 -> R5:Serial0/1                       ok
    (!!!!!!!!) [8] R4:Serial0/0/0-401 -> FR -> R1:Serial0/0-104 ok
    (!!!!!!!!) [8] R4:Serial0/0/0-402 -> FR -> R2:Serial0/0-204 ok
    (!!!!!!!!) [8] R4:Serial0/0/0-403 -> FR -> R3:Serial1/0-304 ok
    (!!!!!!!!) [8] R4:Serial0/0/0-405 -> FR -> R5:Serial0/0-504 ok
    (!!!!!!!!) [8] R4:Serial0/0/0-413 -> FR -> R3:Serial1/1-314 ok




Sign In or Register to comment.