I have a Cisco 10000 series router with multiple OC3 connections as well as Gigabit Ethernet connections. When NPM polls the device I get CPU spikes usually around 100% for a few minutes.
I'm curious if there is a way to just poll interface stats and not poll route tables and ARP tables. Since this device has lots of ARP entries and routes i think that might be the issue as to why its spiking the CPU.
Very common issue in Cisco routers. Even more so on a Core router that will be doing BGP and have larger routing tables, and large ARP tables in Enterprise LANs. Here is some stuff you can do or look at. Remember SNMP is low priority on a routers CPU stack, so in theory you will start to drop the SNMP packets and request not traffic.
Using SNMP to poll large routing tables and Address Resolution Protocol (ARP) tables can cause performance problems on the Cisco routers. This section provides background information about the issue and how to avoid the problem.
An SNMP network management station can query a router to learn about other networks. The management station uses this routing information to find other routers and query them about the networks around them. This allows the management station to learn the topology of the entire network.
The router stores the routing table in hash format, which allows the router to quickly and efficiently search the table. However, RFC 1213 requires that SNMP return the routes in lexicographical order, which means they are listed by their OIDs, in the order in which they occur in the OID tree.
This means that for each SNMP request for routing information, the router must sort entries into the OID order before it builds the response protocol data unit (PDU). As the size of the routing table increases, the router must take a proportionately longer time, along with higher CPU processing levels, to sort the table entries.
Note 
The number of CPU cycles needed to respond to a request for the entire routing table depends on the size of the table (more routes require more CPU cycles). Therefore, even if your router does not currently exhibit CPU spikes, it might begin to do so as the size of the routing table increases.
To the CPU scheduler, SNMP is a low-priority process. This means that the CPU processes non-SNMP requests before it processes SNMP requests. Therefore, any CPU spikes that might occur during SNMP route polling should not affect router performance.
To avoid the performance problems that can occur when SNMP is used to retrieve the routing table or the ARP table, configure the router as described in either of the following sections:
•Enabling CEF Fast Switching on the Router
•Using snmp-server view Commands
For additional information about controlling SNMP traffic, see the application note, IP Simple Network Management Protocol (SNMP) Causes High CPU Utilization, at the following URL:
http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a00800948e6.shtml
For information about other causes of high CPU usage, see the Cisco Technical Support document at the following URL:
http://www.cisco.com/en/US/products/hw/routers/ps133/products_tech_note09186a00800a70f2.shtml
To avoid the performance problems that can occur when SNMP GET-NEXT requests are used to retrieve the routing table or the ARP table, enable Cisco Express Forwarding (CEF) fast switching on the router. This is because the router processes SNMP requests differently, depending on whether fast switching is enabled:
•When fast switching is not enabled, the router uses information in the Routing Information Base (RIB) to respond to SNMP requests for the routing table or the ARP table. Entries in the RIB are not sorted by their OID, so the router must first sort these tables by their OID values, resulting in higher CPU usage.
•When fast switching is enabled, the router uses information in the Forwarding Information Base (FIB) to respond to SNMP requests for the routing table or the ARP table. FIB entries are stored in lexicographical order, listed by the router OID. Therefore, the router does not have to sort the routing tables before replying to SNMP requests, improving response time and reducing CPU usage.
Another way to avoid performance issues is to use SNMPv3 views to force the router to prematurely end queries for the route table and to respond instead with a complete message. This blocks requests to retrieve the route table (ipRouteTable) and the ARP table (ipNetToMediaTable), but allows all other requests.
The following command example creates a view named cutdown that blocks requests for the route table and the ARP table, but allows all other requests. Note that you need to substitute your own view name and community strings when you enter these commands on your router.
snmp-server view cutdown internet included
snmp-server view cutdown ipRouteTable excluded
snmp-server view cutdown ipNetToMediaTable excluded
snmp-server view cutdown at excluded
snmp-server community public view cutdown RO
snmp-server community private view cutdown RW
This configuration prevents the router from returning the IP route table or the ARP table as part of an SNMP request. This prevents SNMP network discoveries from creating CPU spikes on the router, but it also removes a degree of manageability from the router.
Hope this can give you some insight and help with what you need!!!
-Richard
