This document describes how to troubleshoot high CPU utilization caused by different processes.
We recommend that you read Troubleshooting High CPU Utilization on Cisco Routers before proceeding with this document.
This document is not restricted to specific software and hardware versions.
The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.
For more information on document conventions, see the Cisco Technical Tips Conventions.
High CPU utilization in the Address Resolution Protocol (ARP) Input process occurs if the router has to originate an excessive number of ARP requests. The router uses ARP for all hosts, not just those on the local subnet, and ARP requests are sent out as broadcasts, which causes more CPU utilization on every host in the network. ARP requests for the same IP address are rate-limited to one request every two seconds, so an excessive number of ARP requests would have to originate for different IP addresses. This can happen if an IP route has been configured pointing to a broadcast interface. A most obvious example is a default route such as:
ip route 0.0.0.0 0.0.0.0 Fastethernet0/0
In this case, the router generates an ARP request for each IP address that is not reachable through more specific routes, which practically means that the router generates an ARP request for almost every address on the Internet. For more information about configuring next hop address for static routing, see Specifying a Next Hop IP Address for Static Routes.
Alternatively, an excessive amount of ARP requests can be caused by a malicious traffic stream which scans through locally attached subnets. An indication of such a stream would be the presence of a very high number of incomplete ARP entries in the ARP table. Since incoming IP packets that would trigger ARP requests would have to be processed, troubleshooting this problem would essentially be the same as troubleshooting high CPU utilization in the IP Input process.
The IPX Input process is similar to the IP Input process in the sense that it takes care of process switching, except that the IPX Input process switches IPX packets. Nearly all IPX packets are at process level looked at by IPX Input before getting queued to other IPX processes such as IPX SAP In, IPX RIP In, and so on. Unlike IP, IPX supports only one interrupt switching mode, and that is IPX fast-switching which is enabled by default. IPX fast-switching is enabled using the ipx route-cache interface command .
If you see high CPU utilization during the IPX Input process, verify the following:
IPX fast-switching is disabled. Use the show ipx interface command if IPX fast-switching is disabled.
Some IPX traffic cannot be IPX fast-switched:
IPX broadcasts - Check if the router is overwhelmed with IPX broadcasts using the show ipx traffic command.
IPX routing updates - If there are a lot of instabilities in the network, routing update processing increases.
Note: Instead of IPX RIP, use IPX EIGRP (incremental) to reduce the amount of updates, especially over slow speed serial links (see Routing Novell IPX Over Slow Serial Lines and SAP Management for details).
Note: More IPX-related documents can be found at the Novell IPX Technology Support Page.
When the Transmission Control Protocol (TCP) timer process uses a lot of CPU resources, this indicates that there are too many TCP connection endpoints. This can happen in data-link switching (DLSw) environments with many peers, or in other environments where many TCP sessions are simultaneously opened on the router.
The FIB control timer initializes and starts the FIB statistics collection-timer for per-VLAN statistics and global statistics; initializes and starts the FIB/ADJ request/exception timer; maintains the FIB-related registry functions; and initializes BGP accounting timer. These processes get started when EARL is initialized.
The TTY Background process is a generic process used by all terminal lines (console, aux, async, and so on). Normally there should not be any impact on the performance of the router since this process has a lower priority compared to the other processes that need to be scheduled by the Cisco IOS software.
If this process takes high CPU utilization, check whether "logging synchronous" is configured under "line con 0." The possible cause could be Cisco bug ID CSCed16920 (registered customers only) Cisco bug ID or CSCdy01705 (registered customers only) .
The CPU utilization seen for the "TAG Stats Background" process is expected, and it does not affect traffic forwarding.
The TAG Stats Background is a low priority process. This process collects statistics for tags and forwards them to the RP. It is not a function of the amount of traffic, but of the amount of work that the MPLS/LDP control plane does. This is an expected behavior, and it does not impact traffic forwarding. This issue is documented in the bug CSCdz32988 (registered customers only) .
A virtual template (vtemplate) has to be cloned for each new virtual access interface whenever a new user gets connected to the router or access server. The CPU utilization in the Vtemplate Backgr process can get extremely high if the number of users is large. This can be avoided by configuring pre-cloning of the virtual template. For further information, see Session Scalability Enhancements.
The Net Background process runs whenever a buffer is required but is not available to the process or interface. It creates the desired buffers from the main pool based on the request. Net background also manages the memory used by each process and cleans up the freed-up memory. This process is mainly associated with the interfaces and can consume significant CPU resources. The symptoms of high CPU are increase in throttles, ignores, overruns, and resets on an interface.
The IP Background process involves these procedures: the periodic aging of the ICMP redirect cache every minute; an encapsulation type change of an interface; the move of an interface to a new state, UP and/or DOWN; a change in the IP address of the interface; the expiration of a new dxi map; and the expiration of dialer timers.
The IP Background process modifies the routing table in accordance with the status of the interfaces, while the IP Background process assumes that there is a link-state change when it receives link-state change messages. It then notifies all routing protocols to check the affected interface. If more interfaces run routing protocols, a higher CPU utilization is caused by the IP Background process.
ARP background processes handle mulitple jobs and can consume high CPU utilization.
This list provides some example jobs:
ARP flush due to interface up/down events
Clearing the ARP table through the clear arp command
ARP input packets
If any other process is consuming a lot of CPU resources, and there is no indication of any problem in the logged messages, then the problem could possibly be caused by a bug in the Cisco IOS® software. Using the Bug Toolkit (registered customers only) , run a search for the specified process to see if any bugs have been reported.
|If you still need assistance after following the troubleshooting steps above and want to create a service request with the Cisco TAC, be sure to include the following information:|
The Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers.
Refer to Cisco Technical Tips Conventions for information on conventions used in this document.