Point-2-Point Connection Speed

[kisdonkey3]

Hello,

We are using a point-2-point connection, 2611 and 1760. Connection speed has been unbelievable slow, ran a "show int" and noticed quiet of few drops. I am a newbie and would like someone to point me in the right direction on where to start the troubleshooting prodcedures, would appreciate it. The e0/0 is are redundancy connection. Here is my show int post.

Serial1/0 is up, line protocol is up

Hardware is PQUICC with Fractional T1 CSU/DSU

Description: Cox point-to-point to Parkwest

Internet address is 192.168.23.10/30

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

reliability 255/255, txload 7/255, rxload 26/255

Encapsulation HDLC, 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/0/0 (size/max/drops/flushes); Total output drops: 852

Queueing strategy: weighted fair

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

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

Reserved Conversations 0/0 (allocated/max allocated)

Available Bandwidth 1158 kilobits/sec

5 minute input rate 179000 bits/sec, 26 packets/sec

5 minute output rate 47000 bits/sec, 24 packets/sec

140277729 packets input, 246331714 bytes, 0 no buffer

Received 1453268 broadcasts, 0 runts, 12 giants, 0 throttles

322261272 input errors, 10815 CRC, 72091 frame, 0 overrun, 3 ignored, 322178358 abort

128315056 packets output, 3481037074 bytes, 3 underruns

3 output errors, 0 collisions, 1939 interface resets

0 output buffer failures, 0 output buffers swapped out

43 carrier transitions

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

Ethernet0/0 is up, line protocol is up

Hardware is PQUICC Ethernet, address is 000d.28dc.7f6f (bia 000d.28dc.7f6f)

Description: Cont. Wireless connection to Parkwest

Internet address is 10.1.35.5/29

MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,

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

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Half-duplex, 10BaseT

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:19:17, output 00:00:05, output hang never

Last clearing of "show interface" counters never

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

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

104661829 packets input, 3244614507 bytes, 0 no buffer

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

2569 input errors, 0 CRC, 2245 frame, 8 overrun, 316 ignored

0 input packets with dribble condition detected

92195243 packets output, 3499224551 bytes, 2 underruns

316 output errors, 854809 collisions, 1 interface resets

0 babbles, 0 late collision, 1808906 deferred

314 lost carrier, 0 no carrier

0 output buffer failures, 0 output buffers swapped out

[Georg Pauwen]

Hello,

you might have a problem with your CSU/DSU, or with the serial cable. If you are in a position to swap either one of them, you might want to give that a try.

Can you post the configurations of both sides ?

It also might be a good idea to contact your provider, possibly the problem is related to their side.

I have run your output through the Output Interpreter, see the attachment for the results...

Regards,

GP

[kisdonkey3]

gpauwen,

Thanks for the fast reply. I am definitely going to get our ISP information to call them. I was misinformed about the connection type, both of the interfaces I displayed are suppose to be load balanced. Gpauwen, what did you notice that was able to point out an issue with the serial connection overall. Like I mentioned, I am a newbie and the only thing I noticed was the total output drops to be kinda big. Again, thanks

[Georg Pauwen]

Hello,

since the interface counters have never been cleared, it is kind of hard to tell how fast these errors are actually increasing, but the number of input and crc errors, as well as the amount of interface resets points to some problem with either the hardware, or the provider side of the circuit.

The output drops would actually tell you that you are trying to send too much data over the line, and the traffic is being dropped, which would not necessarily mean a problem with the equipment...

Regards,

GP

[atieo]

Hi There,

As someone mentioned earlier, you need to clear the counters of the two interfaces, this will help to determine the current status of your links.

Importantly the encapsulations on both sides should mirror itself and the speed you are using.

Make the queuing strategy the same as well on both sides.

Hope it helps.