Try enabling T3 scrambling on each end. If this works, there may be an
Alcatel mux in the circuit that has not been strapped for clear channel
and is interpreting an alternating ones and zeros pattern in your data
as a blue alarm signal. You can run with scrambling on or educate your
carrier on the issue and get the mux(es) re-strapped.
-Bert
>
> 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