12-22-2004 12:28 PM - edited 03-05-2019 11:22 AM
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
12-22-2004 12:43 PM
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
12-22-2004 01:09 PM
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
12-22-2004 01:34 PM
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
12-23-2004 03:02 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide