7200 Error Please help

[bandit324]

I have tried everyting. We have a 7200 with a fast ethernet connecting to a 3550 g core router. The 7200 is used for the atm wan. This has been an issue forever. The drops and throttles skyrocket and the interface shuts down. This happens everyday. I have done everything but change the interface. Any ideas.

Thanks in advance.

Wayne_BOE_ADM_Bldg#sh int fast 0/1
FastEthernet0/1 is up, line protocol is up
Hardware is i82543 (Livengood), address is 0009.b6f0.a401 (bia 0009.b6f0.a401)
Description: *** Connection to BOE Internal LAN and HP 3000 ***
Internet address is 10.1.6.2/24
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 8/255
Encapsulation ARPA, 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:00, output hang never
Last clearing of "show interface" counters 01:47:07
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 1880 drops
5 minute input rate 3386000 bits/sec, 418 packets/sec
5 minute output rate 431000 bits/sec, 317 packets/sec
2435599 packets input, 2298715144 bytes
Received 0 broadcasts, 0 runts, 0 giants, 4200 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog
0 input packets with dribble condition detected
1881494 packets output, 316012590 bytes, 0 underruns(0/0/0)
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

 

[Zen37]

http://www.cisco.com/en/US/products/hw/modules/ps2033/products_tech_note09186a00800ac5a8.shtml

 

[tecnikall]

Hello there,
This info may help as I could see a big no of throttles:
Throttles - When the Input Q (process switching) fills up on an interface, the CPU assumes that something is misbehaving on that interface (broadcast storm, SNMP storm) since the processor is not able to keep up with the incoming packet rate (hence the Q filling up). The processor throttles the interface to protected itself and the other well-behaved interfaces. This means that it ignores interrupts from that particular interface for one second. When the interface gets a packet and sends an interrupt to have it stored and switched, the processor doesn't answer. Thus the packet is dropped at the hardware level. Throttled means interrupts were disabled for the interface. We do this for any interface when the input queue is filled. Packets in the input queue are processed before interrupts are enabled again, so no traffic will enter the port.

Increase the input queue, but if they still happen, look at the switching path, and see if you can fast switch traffic without causing some other problem. If the Input Q never returns to 0, then you might have packets stuck in the Q. In that case you can do a
'show buffer old' or 'show buffer input-int xx' to find out what packets are stuck. There is no counter that keeps track of how many packets were dropped during the throttle interval.

Also, check the show proc cpu to see if we don't have any high cpu utilisation and if cef is enable in the global config mode. Cheers and good luck

 

[bandit324]

Thanks guys. A few questions.

1. The input queue is dropping but the counter is 0/75. Meaning no packets in queue, so why drops.
2. Cef is enabled both on the int and globally.
3. The cpu shows util of 0 or so, not anything significant.
4. The sh buff old shows nothing
5. A quote from your reply "look at the switching path, and see if you can fast switch traffic without causing some other problem". Could you elaborate on this?

I have very minimal process switched packets. Checked all that yesterday. Something is filling up the input queue too fast. What about priority queueing?

Thanks again

 

[tecnikall]

Hello there, sorry I was off the net for a while.... Can you please let me know if you still have the issue? If so just add the command ip accounting on that interface and after few min do a sh ip accounting, this way we should be able to identify any suspect traffic or which source downstream is causing it. also, a sniffer on the local lan may provide additional clues. Cheers and good luck