[c-nsp] RSP-6-TXSTUCK - software or hardware?

Fri Aug 11 09:07:51 EDT 2006

David,

What those messages were designed for was to help
identify if there was tx accumulator leaks on a 75xx before
it started affecting traffic.
It was one of the code areas we had some bugs so we put
that in to try and help. However it caused some false positives
so we removed it for E1's and below from what I remember.

Pretty unilikely your load is high enough to get to the DS3 rate
as long as it's really clocking at a T3.

Can you provide:
sh int se 6/0/0 stat

and sh contr cbus

from the box.

See what the value/limit is for that serial 6/0/0 interface.

There is a remote remote remote chance it could be bad hadware
causing buffer header corruption which results in txacc leaks.
I've only seen that 3 times every in 8 years but it is a chance.
Almost always it's a software bug.

Rodney

On Thu, Aug 10, 2006 at 01:15:06PM +0100, David Freedman wrote:
> 
> Hardware: 75xx(dual RSP4) with VIP2-50 populated with PA-T3+ and PA-FE-TX
> 
> What would cause the following messages to occur?
> 
> 
> Aug  9 21:13:29 BST: %RSP-6-TXSTUCK: Txacc of Interface Serial6/0/0 is 
> at 2% of its txlimit
> 
> Aug 10 10:08:48 BST: %RSP-6-TXSTUCK: Txacc of Interface Serial6/0/0 is 
> at 3% of its txlimit
> 
> Aug 10 12:02:00 BST: %RSP-6-TXSTUCK: Txacc of Interface Serial6/0/0 is 
> at 2% of its txlimit
> 
> 
> Traffic on this interface is miniscule (i.e around 8/10Mbps) and on the 
> FE interface around 16/20Mbps, both with appropriate packet rates.
> 
> Checking the graphs for the times that these events were reported , 
> nothing untoward was occuring at the time.
> 
> We also graph the CPU of the VIPs and the VIP didn't rise about 10% CPU 
> at these times.
> 
> The box is a legacy piece of kit which has been beefed up somewhat to 
> run 12.3 (as it has IPv6 requirements) , its currently running 12.3(10)d
> but I can't find any known bugs that refer directly to this.
> 
> The T3 has been experiencing Input errors for around a week before these 
> messages were appearing:
> 
> Serial6/0/0 is up, line protocol is up
>    Hardware is cyBus PODS3+ Serial
>    Description: Protection T path DS3 over 100239/450845-0/2308
>    MTU 4470 bytes, BW 44210 Kbit, DLY 200 usec,
>       reliability 255/255, txload 5/255, rxload 39/255
>    Encapsulation HDLC, crc 16, loopback not set
>    Keepalive set (10 sec)
>    Restart-Delay is 0 secs
>    Last input 00:00:00, output 00:00:00, output hang never
>    Last clearing of "show interface" counters 1d19h
>    Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 
> 9714
>    Queueing strategy: fifo
>    Output queue: 0/40 (size/max)
>    30 second input rate 6825000 bits/sec, 1325 packets/sec
>    30 second output rate 914000 bits/sec, 320 packets/sec
>       610766319 packets input, 3114706794 bytes, 0 no buffer
>       Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
>                0 parity
>       158422 input errors, 137421 CRC, 0 frame, 18741 overrun, 16 
> ignored, 2260 abort
>       34167551 packets output, 1658107765 bytes, 0 underruns
>       0 output errors, 0 applique, 0 interface resets
>       0 output buffer failures, 0 output buffers swapped out
>       236 carrier transitions
>     rxLOS inactive, rxLOF inactive, rxAIS inactive
>     txAIS inactive, rxRAI inactive, txRAI inactive
> 
> 
> I've been blaming the transmission people for the past week , but they 
> are as mystified as me, is it possible the TXSTUCK messages are a result 
> of some kind of events occuring on the transmission network?
> 
> For reference, its configured as a point-to-point DS3, as so:
> 
> interface Serial6/0/0
>   description Protection T path DS3 over 100239/450845-0/2308
>   load-interval 30
>   dsu bandwidth 44210
>   scramble
>   framing c-bit
>   cablelength 50
>   serial restart-delay 0
>   no clns route-cache
>   hold-queue 2000 in
> end
> 
> 
> 
> If we look at the PA-FE:
> 
> 
> FastEthernet6/1/0 is up, line protocol is up
>    Hardware is cyBus FastEthernet Interface, address is 0001.9700.78c8 
> (bia 0001.9700.78c8)
>    Description: Worker ET Path 100239/450845-0/2307
>    MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
>       reliability 255/255, txload 39/255, rxload 13/255
>    Encapsulation 802.1Q Virtual LAN, Vlan ID  1., loopback not set
>    Keepalive set (10 sec)
>    Full-duplex, 100Mb/s, 100BaseTX/FX
>    ARP type: ARPA, ARP Timeout 04:00:00
>    Last input 00:00:00, output 00:00:06, output hang never
>    Last clearing of "show interface" counters never
>    Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
>    Queueing strategy: fifo
>    Output queue: 0/40 (size/max)
>    5 minute input rate 5381000 bits/sec, 2258 packets/sec
>    5 minute output rate 15681000 bits/sec, 2623 packets/sec
>       1271168625 packets input, 2747320900 bytes, 0 no buffer
>       Received 14588 broadcasts, 0 runts, 0 giants, 0 throttles
>       36 input errors, 0 CRC, 0 frame, 0 overrun, 36 ignored
>       0 watchdog
>       0 input packets with dribble condition detected
>       1476558580 packets output, 3223841169 bytes, 0 underruns
>       0 output errors, 0 collisions, 0 interface resets
>       0 babbles, 0 late collision, 0 deferred
>       0 lost carrier, 0 no carrier
>       0 output buffer failures, 0 output buffers swapped out
> 
> 
> Nothing out of the ordinary.
> 
> 
> Not quite sure how to proceed, I'm considering replacing the PA and/or 
> the VIP but if anybody can suggest this as being a s/w oddity I'm 
> willing to replace/upgrade as needed (bugtool is not turning up anything 
> of interest here)
> 
> 
> Any help/advice on this muchly appreciated.
> 
> 
> Thanks,
> 
> Dave.
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/