What's the "show int on the other side look like? I'd suspect that
you're dropping packets on the transmit side and losing tcp ack's
is going to kill thruput worse than losing data packets.
George
> From cisco-nsp-request@puck.nether.net Sat Jan 6 17:34:45 2001
> Resent-Date: Sat, 6 Jan 2001 17:26:38 -0500
> Received-Date: Sat, 6 Jan 2001 17:24:37 -0500
> X-Sender: arousch@mail.bdfrd1.tx.home.com
> Date: Sat, 06 Jan 2001 16:24:49 -0600
> To: Deepak Jain <deepak@ai.net>, cisco-nsp@puck.nether.net
> From: Andrew <arousch@home.com>
> Subject: Re: [nsp] Assymetrical DS3 errors?
> In-Reply-To: <Pine.BSF.4.21.0101061339170.28736-100000@aries.ai.net>
> X-OriginalArrivalTime: 06 Jan 2001 22:27:12.0437 (UTC) FILETIME=[D0918E50:01C0782F]
> Resent-From: cisco-nsp@puck.nether.net
> X-Mailing-List: <cisco-nsp@puck.nether.net> archive/latest/4762
> X-Loop: cisco-nsp@puck.nether.net
> Precedence: list
> Resent-Sender: cisco-nsp-request@puck.nether.net
>
> sounds like a sync error coming back. Phasing in and out of sync like a
> timing slip.
>
> At 01:44 PM 1/6/01 -0500, 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