1841 serial port which is showing an unexisting loopback condition

[maghisi-2007]

I've a cisco 1841 IOS c1841-spservicesk9-mz.124-5b.bin whose serial ports are connected to a couple of leased lines.

One connection (it's the same if I connect it to s0/0/0 or to s0/0/1) after minutes or hours of good work can drop with the router serial port that starts showing a loopback condition (but local PTT never detected any loop). Ptt has already replaced many equipments and we already replaced our Wic-2t module.

Can I change something in the serial port router config that could help to fix the problem? Or can be an IOS bug?

Pls note that this router has been working fine for years with this IOS installed

interface Serial0/0/0

bandwidth 256

no ip address

encapsulation frame-relay MFR10671

ip route-cache flow

tx-ring-limit 2

tx-queue-limit 2

no arp frame-relay

!

interface Serial0/0/1

bandwidth 256

no ip address

encapsulation frame-relay MFR10671

ip route-cache flow

tx-ring-limit 2

tx-queue-limit 2

no arp frame-relay

[paolo bevilacqua]

Can you send "show interface".

Does a shut/no shut put the interface back in service ?

[maghisi-2007]

Shut no shut can restart the connection but it didn't always work and it never completely fixed the trouble. After having replaced the csu/dsu at A-end and B-end, now PTT has rerouted the link to a new path and it's about 1 hour it's working fine, but only if tomorrow morning the connection will be still up, I can think this action fixed the problem

sh int s0/0/1

Serial0/0/1 is up, line protocol is down (looped)<<<<<<<<<<<<<<<<<<<<<<<

Hardware is GT96K Serial

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

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

Encapsulation FRAME-RELAY, loopback not set

Bundle Link of bundle MFR10671

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

Last clearing of "show interface" counters 00:38:08

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

Queueing strategy: fifo

Output queue: 0/40 (size/max)

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

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

22869 packets input, 10434890 bytes, 0 no buffer

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

16 input errors, 16 CRC, 15 frame, 0 overrun, 0 ignored, 1 abort

30975 packets output, 3680020 bytes, 0 underruns

0 output errors, 0 collisions, 51 interface resets

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

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

[paolo bevilacqua]

Likely a circuit issue, from the router everything appears normal.

[Leo Laohoo]

Sounds like the provider has erroneously put your lease line into loop. Is there a modem there you can check? Maybe someone needs to manually turn off the loop or look at the indicators if "loop" is on.

[maghisi-2007]

After that yesterday PTT rerouted the link to a new path between A-end and B-end, circuit came up and it has been perfectly working till yesterday evening. So, it was a line issue. Very strange problem as csu/dsu never showed any loop condition but the router was detecting a loop somewhere, even if PTT always told me that a loopback couldn't automatically start.

Excuse me for the question but now must I close this conversation as fixed or this is not needed?

[paolo bevilacqua · Accepted solution]

Loops can actually be started remotely as there are certain line codes to do that. Generally, few people within telco do have a complete know-how.

There is no threde closure in netpro. You can mark and rate posts and that's it.

[Leo Laohoo]

I doubt if a PTT loop can be started automatically. In my experience it always starts when someone misread the circuit ID.

Thanks for the ratings.