6509 -sup720 problem

Question

We are having a problem where the CPU is being driven to over 90% at times and we can't even get at this box , high input on the CPU is "ip input" . This box has all DFC3 cards in it . Under what circumstances does ip traffic get forwarded to the CPU when you have DFC cards installed ? Anyone have any ideas on how to track something like this down? Have checked all links for errors , everything clean . Looked at spanning tree , don't see an issue there . Hard to get any info off the box when this is happening . You look at any of the interfaces and the traffic is not that high , these are gig links down to access layer boxes that are trunked . Frankly I am running out of ideas on what to do with this , any ideas appreciated .

Answer 1

There are quite a bit of reasons traffic may be punted to the MSFC for process switching. Some include unsupported features in hardware, IP options, ttl = 1, and ICMP unreachables/redirects. Here is a link with a more complete list:
http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a00804916e0.shtml
The best way to determine what is causing the process switching is to dump the packet buffers on the interface(s) that is seeing the large volumes of process level traffic. You can do this one of two ways:
1. "show interface switching" and look for the interfaces with increasing IP Process counter.
or
2. "show interfaces" this is probably easier. You can look at the Input Queue for drops or packets actually in the queue.
Vlan10 is up, line protocol is up
Hardware is EtherSVI, address is 00d0.0061.040a (bia 00d0.0061.040a)
Description: VLAN10: Uplink
Internet address is xxx.xxx.xxx.xxx/xx
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
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 never
Input queue: 33/75/3385/3367 (size/max/drops/flushes); Total output drops: 0
In this case we have 33 packets in the queue and we are seeing drops and flushes due to the amount of process level traffic. So once I have this information I can dump those packets by entering "show buffer input-interface vlan10 dump". This will dump those packets from the queue so you can take a look at whats in there. Should look like this:
Router# show buffers input-interface vlan10 dump
Buffer information for Small buffer at 0x437874D4
data_area 0x8060F04, refcount 1, next 0x5006D400, flags 0x280
linktype 7 (IP), enctype 1 (ARPA), encsize 14, rxtype 1
if_input 0x505BC20C (GigabitEthernet4/1), if_output 0x0 (None)
inputtime 00:00:00.000 (elapsed never)
outputtime 00:00:00.000 (elapsed never), oqnumber 65535
datagramstart 0x8060F7A, datagramsize 60, maximum size 308
mac_start 0x8060F7A, addr_start 0x8060F7A, info_start 0x0
network_start 0x8060F88, transport_start 0x8060F9C, caller_pc 0x403519B4
source: xxx.xxx.xxx.xxx, destination: xxx.xxx.xxx.xxx, id: 0x0000, ttl: 63,
TOS: 0 prot: 17, source port 63, destination port 63
08060F70: 000A 42D17580 ..BQu.
08060F80: 00000000 11110800 4500002E 00000000 ........E.......
08060F90: 3F11EAF3 64646401 64646402 003F003F ?.jsddd.ddd..?.?
08060FA0: 001A261F 00010203 04050607 08090A0B ..&.............
08060FB0: 0C0D0E0F 101164 ......d
I would suggest sending this output to me as well so I can take a look at it as well. Other useful commands are:
1. show ip traffic
This command is useful to see if things like bad hop count, fragments, unreachables, redirects, and other various common traffic that can cause IP Input.
2. show cef not
3. show cef drop.
Please email me with the buffer output when you get a chance. Sup720 has some good hw rate-limiters that we can use if we can not correct the situation.
Warm Regards
Anthony
[email protected]