08-11-2012 12:25 AM
Hi,
I just want to clarify that I've read snmp is a low priority process. So does this means in case of high cpu any other process is going to take cpu utilization and snmp polling is going to stop? If not then what's gonna happen to polling and does polling in high cpu scenario is going to crash the device?
what is normal cpu utilization and above what % it should be considered high cpu?
Solved! Go to Solution.
08-11-2012 10:45 AM
Hi,
Yes, you are correct, SNMP runs with a low priority. So, during times of high CPU load, SNMP queries may get dropped or time out.
The Network Management station queries routers for their entire route table to learn about other networks. It uses this information to find other routers and query them about their knowledge of networks around them. In this fashion, the management station can learn the topology of the entire network.
The router stores the route table in a hashed format, more conducive to quick route searches. However, SNMP responses for the route are required to be returned in lexicographical order per RFC1213. Therefore, for each SNMP request the router receives, the hash table must be sorted lexicographically before a SNMP response PDU can be built. The larger the route table, the more CPU intensive the sort.
SNMP is a low priority process as far as the CPU scheduler is concerned, so another process requiring CPU resources takes priority. Therefore, while CPU spikes occur in this scenario, they should not affect performance.
If curious about current SNMP usage:
show process cpu
You can also see the OIDs being referenced with
debug snmp
Take care if using debugs as they may overwhelm your device.
If you are running into %SNMP-3-CPUHOG: messages then there are two probable causes in relation to SNMP:
Large route and/or ARP tables being polled by the NMS station
Polling certain MIBs
For case #1
To avoid performance issues, force the router to prematurely end queries for the route table from the network management system server. Configure the router to respond with a complete message as soon as it receives the start of a request for the route table, as follows:
snmp-server view cutdown iso included
!--- ISO is used as a starting point as it is the snmp 'root'.
snmp-server view cutdown 1.3.6.1.2.1.4.21 excluded
snmp-server view cutdown 1.3.6.1.2.1.4.22 excluded
snmp-server view cutdown 1.3.6.1.2.1.3 excluded
snmp-server view cutdown 1.3.6.1.6.3.15 excluded
!--- The additional object snmpUsmMIB is excluded.
snmp-server view cutdown 1.3.6.1.6.3.16 excluded
!--- The additional object snmpVacmMIB is excluded.
snmp-server view cutdown 1.3.6.1.6.3.18 excluded
!--- The additional object snmpCommunityMIB is excluded.
snmp-server community public view cutdown RO
snmp-server community private view cutdown RW
For #2
Network Management Applications frequently retrieve information from devices using SNMP. One example would be Resource Manager Essentials (RME), an applications within the CiscoWorks 2000 suite of products. RME can retrieve flash information defined in the CISCO-FLASH-MIB. If the device has an ATA flash disk, it can cause CPU utilization to jump.
Follow the bug ID link below and see detailed bug information.
CSCdt97325 (registered customers only)
To verify and apply the workaround, follow these steps:
Verify if the device has an ATA Flash Card in one of its slots:
Router#show disk1:
******** ATA Flash Card Geometry/Format Info ********
ATA CARD GEOMETRY
Number of Heads: 12
Number of Cylinders 906
Sectors per Cylinder 63
Sector Size 512
Total Sectors 684936
ATA CARD FORMAT
Number of FAT Sectors 84
Sectors Per Cluster 32
Number of Clusters 21372
Number of Data Sectors 684117
Base Root Sector 169
Base FAT Sector 1
Base Data Sector 201
Router#
If you're not sure or if you do not get output for the show diskX command, run the show tech command and do a search for disk.
Once you know you have an ATA Flash Disk, you can apply the following workaround to prevent the SNMP queries on the FLASH-MIB:
Router(config)#snmp-server view
!--- ISO is used as a starting point as it is the snmp 'root'.
Router(config)#snmp-server view
!--- The additional object snmpUsmMIB is excluded.
Router(config)#snmp-server view
!--- The additional object snmpVacmMIB is excluded.
Router(config)#snmp-server view
!--- The additional object snmpCommunityMIB is excluded.
Router(config)#snmp-server view
Router(config)#snmp-server community
Router(config)#snmp-server community
Router(config)#exit
Note: Choose the same word on every line for the
Caution: In the above example, snmpUsmMIB is excluded, snmpVacmMIB is excluded, and snmpCommunityMIB is excluded. Together these objects can be used to get information about configured users and community strings to gain administrative access to the device. It is recommended that these objects be exlcluded from view on any device which can be accessed by public users.
Other bugs related to polling MIBs:
Follow the Cisco bug ID links below and see detailed bug information.
CSCdm67427 (registered customers only) - Polling the ATM sub interface returns CPU HOG message from the device.
CSCdu63734 (registered customers only) - Flash MIB makes too many calls to ifs.
CSCdu48652 (registered customers only) - Flash MIB query hangs voice calls on 7200.
CSCds53368 (registered customers only) - Problems with ciscoFlashPartitionEntry object in CISCO-FLASH-MIB.
CSCdu55091 (registered customers only) - 2500 snmpgetnext for certain SNMP objects causes trace back.
CSCdx54836 (registered customers only) - SNMP polling on Flash MIB causes high cpu utilization on the switch.
You can find most of the above here.
08-11-2012 10:45 AM
Hi,
Yes, you are correct, SNMP runs with a low priority. So, during times of high CPU load, SNMP queries may get dropped or time out.
The Network Management station queries routers for their entire route table to learn about other networks. It uses this information to find other routers and query them about their knowledge of networks around them. In this fashion, the management station can learn the topology of the entire network.
The router stores the route table in a hashed format, more conducive to quick route searches. However, SNMP responses for the route are required to be returned in lexicographical order per RFC1213. Therefore, for each SNMP request the router receives, the hash table must be sorted lexicographically before a SNMP response PDU can be built. The larger the route table, the more CPU intensive the sort.
SNMP is a low priority process as far as the CPU scheduler is concerned, so another process requiring CPU resources takes priority. Therefore, while CPU spikes occur in this scenario, they should not affect performance.
If curious about current SNMP usage:
show process cpu
You can also see the OIDs being referenced with
debug snmp
Take care if using debugs as they may overwhelm your device.
If you are running into %SNMP-3-CPUHOG: messages then there are two probable causes in relation to SNMP:
Large route and/or ARP tables being polled by the NMS station
Polling certain MIBs
For case #1
To avoid performance issues, force the router to prematurely end queries for the route table from the network management system server. Configure the router to respond with a complete message as soon as it receives the start of a request for the route table, as follows:
snmp-server view cutdown iso included
!--- ISO is used as a starting point as it is the snmp 'root'.
snmp-server view cutdown 1.3.6.1.2.1.4.21 excluded
snmp-server view cutdown 1.3.6.1.2.1.4.22 excluded
snmp-server view cutdown 1.3.6.1.2.1.3 excluded
snmp-server view cutdown 1.3.6.1.6.3.15 excluded
!--- The additional object snmpUsmMIB is excluded.
snmp-server view cutdown 1.3.6.1.6.3.16 excluded
!--- The additional object snmpVacmMIB is excluded.
snmp-server view cutdown 1.3.6.1.6.3.18 excluded
!--- The additional object snmpCommunityMIB is excluded.
snmp-server community public view cutdown RO
snmp-server community private view cutdown RW
For #2
Network Management Applications frequently retrieve information from devices using SNMP. One example would be Resource Manager Essentials (RME), an applications within the CiscoWorks 2000 suite of products. RME can retrieve flash information defined in the CISCO-FLASH-MIB. If the device has an ATA flash disk, it can cause CPU utilization to jump.
Follow the bug ID link below and see detailed bug information.
CSCdt97325 (registered customers only)
To verify and apply the workaround, follow these steps:
Verify if the device has an ATA Flash Card in one of its slots:
Router#show disk1:
******** ATA Flash Card Geometry/Format Info ********
ATA CARD GEOMETRY
Number of Heads: 12
Number of Cylinders 906
Sectors per Cylinder 63
Sector Size 512
Total Sectors 684936
ATA CARD FORMAT
Number of FAT Sectors 84
Sectors Per Cluster 32
Number of Clusters 21372
Number of Data Sectors 684117
Base Root Sector 169
Base FAT Sector 1
Base Data Sector 201
Router#
If you're not sure or if you do not get output for the show diskX command, run the show tech command and do a search for disk.
Once you know you have an ATA Flash Disk, you can apply the following workaround to prevent the SNMP queries on the FLASH-MIB:
Router(config)#snmp-server view
!--- ISO is used as a starting point as it is the snmp 'root'.
Router(config)#snmp-server view
!--- The additional object snmpUsmMIB is excluded.
Router(config)#snmp-server view
!--- The additional object snmpVacmMIB is excluded.
Router(config)#snmp-server view
!--- The additional object snmpCommunityMIB is excluded.
Router(config)#snmp-server view
Router(config)#snmp-server community
Router(config)#snmp-server community
Router(config)#exit
Note: Choose the same word on every line for the
Caution: In the above example, snmpUsmMIB is excluded, snmpVacmMIB is excluded, and snmpCommunityMIB is excluded. Together these objects can be used to get information about configured users and community strings to gain administrative access to the device. It is recommended that these objects be exlcluded from view on any device which can be accessed by public users.
Other bugs related to polling MIBs:
Follow the Cisco bug ID links below and see detailed bug information.
CSCdm67427 (registered customers only) - Polling the ATM sub interface returns CPU HOG message from the device.
CSCdu63734 (registered customers only) - Flash MIB makes too many calls to ifs.
CSCdu48652 (registered customers only) - Flash MIB query hangs voice calls on 7200.
CSCds53368 (registered customers only) - Problems with ciscoFlashPartitionEntry object in CISCO-FLASH-MIB.
CSCdu55091 (registered customers only) - 2500 snmpgetnext for certain SNMP objects causes trace back.
CSCdx54836 (registered customers only) - SNMP polling on Flash MIB causes high cpu utilization on the switch.
You can find most of the above here.
08-12-2012 01:44 AM
Thanks very helpful and detailed answer.
Also what is considered as normal cpu utilization? and above what % it is critical?
08-20-2012 01:25 AM
it is not possible to define a normal CPU utilization value generally; This value depends on several factors mainly the platform, device configuration (function in the network design), typical network load and so on;
you can do baselining (monitor the value over a period of time for your devices and define what is typicall) or - what is not accurate but possible (and sometimes enough) - you can define "your" threshold (like 60 %) and see if any of the devices are constantly above or if some are above at cetain times (e.g. when server backups are done). Then you can define individual values for these devices.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide