SNMP config for CVP - turning off the authenticationFailure trap

Unanswered Question

When you configure SNMP on ICM 7.2(4) you can use the Cisco SNMP snap-in and uncheck the box that says "Enable Authentication Traps?".

I have a trap receiver set up for CVP 4.0(2) and get a ton of authenticationFailure traps. I'd like to turn these off.

There doesn't appear to be a way of controlling this at the CVP Ops Consile user interface. My questions would therefore be:

1. Can I install the snap-in on a CVP box?

2. If not, is there a way to disable the authenticationFailure trap through the SNMP properties file?



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Michael Owuor Tue, 06/17/2008 - 06:04
User Badges:
  • Cisco Employee,

Hi Geoff,

If you are receiving many authenticationFailure notifications from a machine, you need to manually import the previously configured community strings from the windows SNMP Service on that machine.

Steps for Importing Previously Configured Windows SNMP V1 Community Strings:

Step 1 - View the list of previously configured Windows SNMP V1 community strings by doing the following:

a. Open the Windows Services viewer.

b. Right-click SNMP Service and select Properties.

c. Select the Security tab. This tab lists the accepted V1 community strings and the access granted for each string, and also lists the hosts from which SNMP packets are accepted.

Note: The accepted hosts apply to all community strings, whereas the Operations Console provides more granularity, allowing you to specify accepted hosts on a per-community string basis.

Step 2 - Configure these community strings using the Operations Console:

a. Open the Operations Console and select SNMP | V1/V2C | Community String.

b. For each community string discovered above that has not already been configured in the Operations Console, add it by clicking Add New.

Do the following:

• Enter the community string exactly as it appeared in step 1 above.

• Select V1 as the version.

• For Windows community strings with permission other than "Read Only," select Read Write in the Operations Console.

• Be sure to select the device(s) on which this community string was seen in step 1.

See also page 45 of

Hope this helps.




Thanks for your reply. I had noticed that section of the guide and wondered about it. This system was a new install so all that Windows SNMP has is "public" read only and "private" read create with unrestricted host access.

I don't really want to enable these community strings in the new system. I guess I should have configured Windows SNMP before installing CVP when Cisco installed their own SNMP agent and removed these strings.

I'll try what you said, and see if I can work through this without enabling access under those communities.

I feel that there is something missing from the story here. When the Cisco SNMP agent was installed by CVP, does it try to import the community strings? If so, the install guide should tell you to trash those before you start.



Mmm, that's not doing what I want.

I stopped the Cisco SNMP service on each Call Server after adding the two comunity strings as I had seen in the Windows SNMP agent, and then restarted them. My trap receiver shows the cold start, and link up - and then a slew of authenticationFailures traps. Just as it was previously.

In the Windows SNMP agent on the Security tab you can tell the agent to not send authentication traps. I want to do that with the Cisco SNMP agent.

The registry for Cisco\CVP\SNMP does not contain any obvious keys I can change, and neither does the service.

There has to be a way to turn these off.



I was able to turn this off remotely by changing one of my community strings from read-only to read-write, save and deploy, and then a restart of the Cisco SNMP Service.

From a remote box I issued an SNMP set on snmpEnableAuthenTraps to the value of (integer32) 2. This is not what we really want, since it will go back to the default when SNMP restarts.

I looked further on CVP and found that this can be controlled through CVP\conf\SNMPD.CNF - so I edited the file and changed the value to 2 and restarted SNMP.

So that's working. But you have to be careful. If you go to the Ops Console and change something in SNMP it will rewrite this file on a "save and deploy" and you will lose the setting that disables these traps.

Let me check on the Ops Console for the template. This can't be too hard.



So SNMPD.CNF does exist on the Ops Console in the same directory of CVP\conf and it appears to be a template for distribution to the clients. But obviously it gets merged with some real data, since it does not have my community strings etc inside it.

Does anyone know how this stuff really works? ;-)




This Discussion