Hi
You may want to try checking "sh controllers serial <port>" on both sides
Example(OK) output is:
---
router#sh controllers serial 0/0/0
Serial0/0/0 -
Mx T3(1) HW Revision 0x3, FW Revision 2.56
Framing is m13, Clock Source is Internal
Bandwidth limit is 44210, DSU mode 0, Cable length is 450
Data in current interval (750 seconds elapsed):
0 Line Code Violations, 0 P-bit Coding Violation
0 C-bit Coding Violation
0 P-bit Err Secs, 0 P-bit Sev Err Secs
0 Sev Err Framing Secs, 0 Unavailable Secs
0 Line Errored Secs, 0 C-bit Errored Secs, 0 C-bit Sev Err Secs
Total Data (last 24 hours)
0 Line Code Violations, 0 P-bit Coding Violation,
0 C-bit Coding Violation,
0 P-bit Err Secs, 0 P-bit Sev Err Secs,
0 Sev Err Framing Secs, 3 Unavailable Secs,
0 Line Errored Secs, 0 C-bit Errored Secs, 0 C-bit Sev Err Secs
No alarms detected.
On Sat, 6 Jan 2001, Deepak Jain wrote:
>
> Here is a strange problem, or at least one I haven't seen before. :)
>
> I have a point-to-point DS3 that is brand new, on new PA-2T3+ boards.
>
>
> reno <--> denver
>
> Traffic pushed from reno to denver works great, and there is no
> detectable packet loss.
>
> However, (and the symptom that caused this investigation) is FTP
> transactions going from the equipment connected to denver back to
> equipment connected to reno stops or stalls at around 20KB/s. The reverse
> (as to all downloads/web transactions/etc) are fine. Browsing the servers
> with FTP is also fine. The strange thing is that the direction of the DS3
> that should be congested (reno -> denver) is the fast/working FTP path,
> the other is unusable.
>
> Looking for hardware causes, on denver, the DS3 facing Reno picks up a
> small number of errors every 10-20 minutes.
>
> denver>sh in s6/1
> Serial6/1 is up, line protocol is up
> Hardware is M2T-T3+ pa
> Internet address is 205.134.160.26/30
> MTU 4470 bytes, BW 44210 Kbit, DLY 200 usec,
> reliability 255/255, txload 1/255, rxload 249/255
> Encapsulation HDLC, crc 16, loopback not set
> Keepalive set (10 sec)
> Last input 00:00:00, output 00:00:01, output hang never
> Last clearing of "show interface" counters 20:49:50
> Queueing strategy: fifo
> Output queue 0/40, 0 drops; input queue 0/75, 0 drops
> 30 second input rate 43189000 bits/sec, 10064 packets/sec
> 30 second output rate 1000 bits/sec, 1 packets/sec
> 567522756 packets input, 620657675 bytes, 0 no buffer
> Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
> 0 parity
> 733 input errors, 12 CRC, 0 frame, 0 overrun, 0 ignored, 721 abort
> 254394920 packets output, 2731517129 bytes, 0 underruns
> 0 output errors, 0 applique, 0 interface resets
> 0 output buffer failures, 0 output buffers swapped out
> 0 carrier transitions
> rxLOS inactive, rxLOF inactive, rxAIS inactive
> txAIS inactive, rxRAI inactive, txRAI inactive
>
>
> On reno, there are no errors shown:
>
> reno#sh in s1/0/1
> Serial1/0/1 is up, line protocol is up
> Hardware is cyBus PODS3+ Serial
> Internet address is 205.134.160.25/30
> MTU 4470 bytes, BW 44210 Kbit, DLY 200 usec, rely 255/255, load 247/255
> Encapsulation HDLC, loopback not set, keepalive set (10 sec)
> Last input 00:00:01, output 00:00:00, output hang never
> Last clearing of "show interface" counters 00:11:17
> Queueing strategy: fifo
> Output queue 0/512, 416138 drops; input queue 0/512, 0 drops
> 5 minute input rate 18000 bits/sec, 0 packets/sec
> 5 minute output rate 42961000 bits/sec, 9839 packets/sec
> 7584 packets input, 7166182 bytes, 0 no buffer
> Received 0 broadcasts, 0 runts, 0 giants
> 0 parity
> 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
> 6732180 packets output, 3704026139 bytes, 35 underruns
> 0 output errors, 0 applique, 0 interface resets
> 0 output buffers copied, 0 interrupts, 0 failures
> 0 carrier transitions
> rxLOS inactive, rxLOF inactive, rxAIS inactive
> txAIS inactive, rxRAI inactive, txRAI inactive
>
> --
>
> Symmetrical traceroutes confirm the traffic is actually going over the DS3
> in question and not over some crazy internet path.
>
> Any help would be very appreciated, I'd like to figure out what's going on
> as opposed to replacing everything until the problem goes away. :)
>
> Thanks,
>
> Deepak
>
>
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:24 EDT