High CPU usage on 4500

Hoping someone may be able to help me track down this slight issue. Starting two weeks ago, one of our 4507R went from an average of 45-50% usage to being pegged at 95-98%.

We really hadn't noticed it until we started looking at the graphs. Performance still seems to be ok. There are no packet loss while connected to the system, users aren't complaining, etc...

While troubleshooting this issue, I've implemented some of the recommendation with reguards to "no ip redirects", "no ip unreachables" on all our SVIs. I found the document which describes the basic troubleshooting process on the 4500 but to still no avail.

Thanks for the response, yes I did perform the recommended monitor of the CPU to a span port. What I saw was a bunch of UDP traffic (part our video encoding/decoding). There other packets that have been seen are our STP instances. There are however only 333 STP instances running in PVST+.This number is under the max limit for STP. (unless I'm mistaken)

The processes that are running the highest are the following:

K2CpuMan Review 30.00 63.45 30 45 100 500 76 82 64 77691:40

K2AccelPacketMan: Tx 10.00 25.21 20 1 100 500 27 29 22 14754:05

These 2 make up 88.66% of the Total CPU usage.

I've attached the "show platform cpu stat" and an output of the show platform cpu buff"

I am at the end of what I know. Like I said I just had a simular issue on my 6509's. and the commands I had you check helped me find my issue which was a PC was causing a broadcast storm and the switches CPU spiked when trying to process all that traffic. If you have any type of support you might try and open a TAC case. Also, like an earlier post said it could be a bug. I will keep picking at my brain. Also go over any changes that may have occured in the enviroment even as small as adding a PC, like in my case.

A static route between our two 4507R. If you remember about the UDP traffic I mentioned earlier. It should have clued me in more into the issue. For some reason, there was a static route placed on the First 4507 (high CPU one) to point to the second 4507.

Since the second one didn't have any routing information for the network in question, it was trying to send it back to the first 4507 as it's default gateway.