Spikes of high utilization:

     7774444477777444449999944444777774444466666444441111133333
100
90
80
70
60
50
40
30
20
10  ***     *****     *****     *****     *****     *****
    0....5....1....1....2....2....3....3....4....4....5....5....
              0    5    0    5    0    5    0    5    0    5

               CPU% per second (last 60 seconds)

     15  1 55  2521 41  7512 144211519 2237115212311  612114111
     1698080198271195498513183406312809798515943783399506213283
100
90                                  *
80                     *            *    *
70                     *            *    *           *
60   *         *       *            *    *  *        *
50   *    **   *   *   **         * *    *  *        *
40   *    **   *   *   **    **   * *   **  *   *    *    *
30   *    **   *   *   **    ***  * * ****  *  **    * *  *
20   *    **  ***  *   ** *  ***  **# **** *** **    # *  * *
10  ##########################################################
    0....5....1....1....2....2....3....3....4....4....5....5....
              0    5    0    5    0    5    0    5    0    5

               CPU% per minute (last 60 minutes)
              * = maximum CPU%   # = average CPU%

     9785964585664955577366568954458585448555595558557544555655959556585788
     0323456168398275646991278506805234883844704883023276413871404654719398
100                           *
90  *   *   *    *          **    *          *                * *       **
80  * * *   *    *    *     **    * *   *    *   *            * *    *  **
70  *** **  *  * *   ** *  ***    * *   *    *   *  *      *  * *    * ***
60  *** **  **** ****** ** ***    * *   **  ** ***  *      ** * **********
50  ******************* **************************************************
40  **********************************************************************
30  **********************************************************************
20  **********************************************************************
10  ######################################################################
    0....5....1....1....2....2....3....3....4....4....5....5....6....6....7.
              0    5    0    5    0    5    0    5    0    5    0    5    0

                   CPU% per hour (last 72 hours)
                  * = maximum CPU%   # = average CPU%

Any suggestions on how to find the traffic causing this?

Hello Randy,

because sh proc cpu history does not provide details about processes or interrupts using cpu you can use:

sh proc cpu sorted in case there are processes loading the cpu

if the high spikes are caused by peaks of traffic that is process switched = sent to main cpu you can follow the following link:

http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a00804916e0.shtml

refer to the section about tools for finding traffic sent to main cpu

and

http://www.cisco.com/en/US/products/hw/routers/ps133/products_tech_note09186a00800a70f2.shtml#high_cpu

Hope to help

Giuseppe

What show proc cpu hist does show you is an over view of the utilisation from the last 60 seconds, 60 minutes and 72 hours.

As you can see there are high peaks (peak noted by the * sign), but nothing sustained (average noted by the # sign). Your polling/alerting must be set as such to catch this high peak event.

I would at first glace say that this is nothing too much to worry about as the CPU is not underload for very long, but it may well be worth getting to the bottom of it if it is a frequent and/or regular occurance.

The problem you have is that the show proc cpu sorted command only gives you at max the last 5 mins of processes utilising the cpu. You either need to logon immediatley when you recieve the alarm to see what process spiked (this depends on whether you monitoring alerts straight away or not) or set up some other method in understanding what is hitting the CPU at that time. In the past I have set SPAN sessions up to monitor the control plane to see what is being sent to the cpu at specific times.

It may just be that there is a network event, the requirement for STP or other mechanisms to re-compute at these times so it would be worth looking around the network to see if anything else has a similar spike or event that may have caused some topology change. If not, then it is something specific to this 6500. A little assumption here that you are using this 6500 as the root bridge or some central point of control.

SNMP is a fairly common cuase of these kind of spikes. Usually a good place to start to ensure these strings are secured.

HTH

Andy