help,about serial xx is down and line protocol is down

jeff.lee · ‎09-23-2003

a 3661 with nm-4t and a 2610 with wic-1t,connected via a 256k leased line,I use syslog soft to monitor the 36,recently,the following log must appear 5-10 time per day:

%LINK-3-UPDOWN: Interface Serial1/0, changed state to down

%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0, changed state to down

but,about 30 seconds later,both the serial and its line protocol would be up.there is an application which is a real-time program,even the line is down no moren than 10 seconds,the custmer will complaint us.so how can I resolve it?

thanks!

Serial1/0 is up, line protocol is up

Hardware is M4T

Description: Connecting to 2610 in Yi Len

Internet address is 172.28.127.17/30

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

reliability 255/255, txload 147/255, rxload 91/255

Encapsulation HDLC, crc 16, loopback not set

Keepalive set (10 sec)

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

Last clearing of "show interface" counters never

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

Queueing strategy: weighted fair

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

Conversations 3/69/256 (active/max active/max total)

Reserved Conversations 0/0 (allocated/max allocated)

Available Bandwidth 384 kilobits/sec

5 minute input rate 184000 bits/sec, 177 packets/sec

5 minute output rate 296000 bits/sec, 89 packets/sec

144089272 packets input, 826692251 bytes, 854 no buffer

Received 120505 broadcasts, 0 runts, 526 giants, 0 throttles

570950 input errors, 386802 CRC, 0 frame, 1532 overrun, 0 ignored, 182616 a

bort

27837929 packets output, 881243369 bytes, 0 underruns

0 output errors, 0 collisions, 101 interface resets

CISCO3660_1>sho ver

Cisco Internetwork Operating System Software

IOS (tm) 3600 Software (C3660-IS-M), Version 12.2(4)T, RELEASE SOFTWARE (fc1)

TAC Support: http://www.cisco.com/tac

Compiled Thu 27-Sep-01 21:15 by ccai

Image text-base: 0x600089C0, data-base: 0x614C0000

ROM: System Bootstrap, Version 12.0(6r)T, RELEASE SOFTWARE (fc1)

CISCO3660_1 uptime is 1 week, 5 days, 2 hours, 11 minutes

System returned to ROM by power-on

System image file is "flash:c3660-is-mz.122-4.T.bin"

cisco 3660 (R527x) processor (revision 1.0) with 59392K/6144K bytes of memory.

Processor board ID JAB0428896W

R527x CPU at 225Mhz, Implementation 40, Rev 10.0, 2048KB L2 Cache

Channelized E1, Version 1.0.

Bridging software.

X.25 software, Version 3.0.0.

Primary Rate ISDN software, Version 1.1.

3660 Chassis type: ENTERPRISE

1 FastEthernet/IEEE 802.3 interface(s)

22 Serial network interface(s)

2 Channelized E1/PRI port(s)

DRAM configuration is 64 bits wide with parity disabled.

125K bytes of non-volatile configuration memory.

16384K bytes of processor board System flash (Read/Write)

Configuration register is 0x2102

jolmo · ‎09-24-2003

Hi Jeff

There are some symptoms of your problem:

This interface has received a high number of packets with incorrect CRCs (corrupted data) (> 0.1%).

Problems that may cause this symptom include:

a. Noisy serial line

b. Serial cable is too long or cable from the CSU/DSU to the router is not shielded

c. SCTE mode is not enabled on the DSU

d. The CSU line clock is incorrectly configured

e. A Ones density problem on the link (incorrect framing or coding specification), exists

f. Verify the queuing strategies are the same on both ends of the link.

TRY THIS:

1. Ensure that the line is clean enough for transmission requirements. Shield the cable if necessary.

2. Make sure the cable is within the recommended length (no more than 50 feet [15.24 meters], or 25 feet [7.62 meters] for the link).

3. Ensure that all devices are properly configured for a common line clock. Set serial clock transmit external (SCTE) on the local and remote DSU. If you are attempting serial connections at speeds greater than 64 kbps with a CSU/DSU that does not support (SCTE), you might have to invert the transmit clock on the router. Inverting the transmit clock compensates for phase-shifts between the data and clock signals.

4. Make certain that the local and remote CSU/DSU are configured for the same framing and coding scheme as that used by the leased-line or other carrier service (for example, ESF/B8ZS).

5. Contact your leased-line or other carrier service and have them perform integrity tests on the line.

854 packets have been dropped because there were no free buffers to copy the packet.

526 packets were discarded because they exceed the medium's maximum packet size.

These two last symptoms point to a buffer problem. It can happen when you have a great amount of input traffic (bursty).

I'm manging a 3640 and recently I have some similar problems with buffers. To ckeck this, please do a 'sh buffers' and 'sh memory' (just take 2 first lines of this command output to see Processor and I/O memory statistics , 'used, free, largest, lowest,etc). I solved this problem increasing I/O memory using 'memory-size iomem ' command.

Please, let us know the output of 'sh buffers' and 'sh mem'(only first lines).

Hope this helps

deilert · ‎09-24-2003

aborts are a symptom of a clocking problem on the line , Please check with the provider to find out who is providing clock , If they are then both sides should be configured to clock source network , If you provide clock then one side should be internal and the other side should be network .