Re: [nsp] Assymetrical DS3 errors?

From: Rafi Sadowsky (rafi@meron.openu.ac.il)
Date: Sat Jan 06 2001 - 14:50:33 EST


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