Document ID: 43842
Contents
Introduction
Before You Begin
Conventions
Prerequisites
Components Used
Troubleshooting
Symptoms
Solution
Information to Collect if You Open a TAC Case
Related Information
Introduction
This document explains the causes of high CPU utilization in the LC Adjacency Updater process on a Cisco 12000 Series Internet Router. It also explains the troubleshooting steps that need to be followed to solve this issue.
Before You Begin
Conventions
For more information on document conventions, see the Cisco Technical Tips Conventions.
Prerequisites
We recommend that you read Troubleshooting High CPU Utilization on Cisco Routers before proceeding with this document.
Components Used
The information in this document is based on the software and hardware versions below.
-
Cisco 12000 Series Internet Router
-
Cisco IOS Software Releases 12.0(18)S01, 12.0(19)ST, 12.0(17)S02, 12.0(17)ST02, and 12.0(19)S
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.
Troubleshooting
Symptoms
You are experiencing high CPU utilization on a Cisco 12000 Series Internet Router, and you can see from the show proc cpu command on the Gigabit Route Processor (GRP) that the process which is using the most CPU is LC adj updater.
Router#show proc cpu CPU utilization for five seconds: 87%/17%; one minute: 86%; five minutes: 86% ... 55 15395220681690031711 910 57.22% 55.57% 57.11% 0 LC adj updater ...
These symptoms may appear after a line card crash or during normal operation of the router, even if the adjacencies are stable.
You may see the following debug messages if you enable debug gsr encaps on the Cisco 12000 router:
*Oct 11 06:25:18.995 CET: %GRP-3-ADJ_UPDATER: spinning delete for adj(0x1)->oi(0x0) *Oct 11 06:25:47.600 CET: GigabitEthernet2/0 new: 30, old: 30, platform: 0x6211330C *Oct 11 06:25:47.604 CET: GigabitEthernet1/0 new: 30, old: 30, platform: 0x6824EB58 *Oct 11 06:25:47.604 CET: GigabitEthernet2/0 new: 30, old: 30, platform: 0x6211330C *Oct 11 06:25:48.996 CET: %GRP-3-ADJ_UPDATER: spinning delete for adj(0x1)->oi(0x0) *Oct 11 06:26:15.600 CET: GigabitEthernet1/0 new: 30, old: 30, platform: 0x62E2FB44 *Oct 11 06:26:16.376 CET: GigabitEthernet1/0 new: 30, old: 30, platform: 0x62E2FB44 *Oct 11 06:26:18.996 CET: %GRP-3-ADJ_UPDATER: spinning delete for adj(0x1)->oi(0x0)
Note: Before enabling this command, you should read the note in the Solution section below.
Solution
The LC adj updater process runs frequently, but will surrender the CPU to other processes if they require it. So, even if the CPU is running high due to this process, it is usually not an issue.
Of course, there is always a possibility that something has gone wrong, and hopefully it will be easy to determine if this is the case. If you enable debug gsr encap and you don't see any error messages, it means the CPU usage for the LC adj updater process is normal and desirable.
However, if you see debug messages (such as spinning adj or spinning midb), there might be an issue which needs further troubleshooting.
Use the debug gsr encap command to troubleshoot encap failures.
Note
Before enabling this debug command, you need to enable service internal in the main configuration mode. This debug command should not give too much output (if the router is stable: no flaps, no routing changes, and so on). However, as always with debug commands, you should take the normal precautions:
-
No logging to the console port (only to buffer)
-
(Recommendation): Use this command during a maintenance window or a period of time that will not affect too many customers if something should go wrong
When a line card with many encaps strings allocated is rebooted or crashes, the Gigabit Route Processor (GRP) could repeatedly try to send the encaps strings to the line card. This might cause the LC adjacency process to run high. This problem has been fixed as part of bugID CSCdu50927 (registered customers only) - %GRP-3-ENCAP: Failure to allocate encap table entry, exceeded max number. Be sure to run a Cisco IOS software release which integrates the fix for this bug: 12.0(18)S01, 12.0(19)ST, 12.0(17)S02, 12.0(17)ST02, and 12.0(19)S.
The show gsr encap command gives details on the encaps strings allocated. In normal conditions, the output of this command looks similar to this:
Router#show gsr encap-info
Statistics:
Fail Send Count: SND_ENC :0 REP_ENC :0
: MIDB_UPD:0 ADJ_UPD:0
Fail Try Count: REP_ENC:0 MIDB_UPD:0 AD_UP:0
Fail Try LastOI: REP_ENC:0x0 MIDB_UPD:0x0 AD_UP:0x0
Missng OI Count: FRE_ENC:0 FR_EN_CL:0 FR_QD:0
Missing OI Val : FRE_ENC:0x0 FR_EN_CL:0x0 FR_QD:0x0
Missng OI Slot : FRE_ENC:0 FR_EN_CL:0 FR_QD:0
Msg Counts in Queues:
SEND 0, REP 0, MIDB 0, ADJ 0
OutputInfo Info:
Information to Collect if You Open a TAC Case
|
If the router is configured with a Cisco IOS software release later than the releases mentioned above which integrate a fix for CSCdu50927 (registered customers only) , and if you still see high CPU utilization, capture the output of the following commands and open a case (registered customers only) with the Cisco TAC to report this issue: |
|---|
The most important command output is that of the debug gsr encap command. This gives us enough information to determine the reason for the high CPU utilization. You can attach information to your case by uploading it using the Case Query tool (registered customers only) . If you cannot access the Case Query tool, you can send the information in an email attachment to attach@cisco.com with your case number in the subject line of your message to attach the relevant information to your case. |
Once you have captured all the required information, you can manually reload the corresponding line card using the hw-module slot <slot #> reload command. This should bring the CPU utilization down to a more acceptable value. If not, perform a warm reload of the router.
Related Information
| Updated: Jul 07, 2005 | Document ID: 43842 |