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

[David Freedman]

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.