SNMP ENGINE high cpu

Unanswered Question
Nov 12th, 2007
User Badges:

Hi,

There is known NMS polling routers on my network. I have an access-list but the utilization still reaches 99%. What should i do in order to stop the NMS polling my routers?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
David Stanford Mon, 11/12/2007 - 13:21
User Badges:
  • Cisco Employee,

Try temporarily removing the snmp community strings to see if the CPU usage decreases.


You can't stop the NMS from polling unless you know where the NMS stations are an have access to them.


If your ACL is configured correctly it should be dropping all requests to snmp.

v.matiakis Mon, 11/12/2007 - 23:43
User Badges:

Hi,

The NMS station is a known NMS system in the network and building an ACL to drop its packets is not an option. From what i read in Cisco documentation i found that the following command stops the polling :

snmp-server view cutdown 1.3.6.1.2.1.4.21 excluded.

Is this the only thing i have to insert? Can i stop the polling from the NMS? If i do, do i have a problem?

David Stanford Tue, 11/13/2007 - 08:51
User Badges:
  • Cisco Employee,

Your first post mentioned that you were using an access-list so thats why I mentioned it.


The config you mention above is part of an snmp-server view which is used to exclude certain mib objects from being polled. However, you don't know which MIB is causing the CPU to spike, so it will not be useful.


You can enable debugs to determine what is happening (prob not good with 99% CPU) or look through the logs to see if there are any CPUHOG messages.


If you want to bring down the CPU utilization you will need to do one of the following:


1) Disable snmp

2) Add an ACL to block snmp or add an acl to the comm string blocking that NMS from RO access

3) Disable polling on the NMS

v.matiakis Tue, 11/13/2007 - 23:30
User Badges:

Ok i have disabled polling from the NMS. I had another problem again with a CPU load. The CPU went high due to an virtual exec proccess. From i found in Cisco's website, this problem is sourced from a telnet connection. Is that the only case? How can i completely stop it when it happens?

Actions

This Discussion