Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Ciscoworks causing Config traps

Hi Folks,

Theres a certain job thats running on Ciscoworks that causes the switches and routers to send out loads of the following traps. "<hostname> Configuration Change, command - commandline, source - running, destination - commandSource. I think it may be cause by thhe config fetches or the inventory polling. I'm finding it hard to tell. Has anyone had this trap showing up a lot, or know what is causing it? It's basically flooding our Openview NNM box with too many traps and I need to try to find a way to eliminate it if possible. Any help would be appreciated.

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Re: Ciscoworks causing Config traps

By making TFTP the first protocol, and by making sure you have valid read-write SNMP credentials in DCR, then RME will use TFTP and SNMP on all devices that support it. However, traps will still be sent even using this method. They will just have a different command source.

7 REPLIES
Cisco Employee

Re: Ciscoworks causing Config traps

This could be caused by the config fetch job. It is most definitely not being caused by the inventory collection job. What protocol are you using to fetch your configs?

New Member

Re: Ciscoworks causing Config traps

It's using default settings under Transport Settings. Protocols in the following order.

TELNET

TFTP

SSH

RCP

HTTPS

Cisco Employee

Re: Ciscoworks causing Config traps

If the config is being fetched by telnet, then the device will send a ciscoConfigManEvent notification when the show run command is executed. This will only be sent if you've enabled config traps (e.g. snmp-server host 10.1.1.1 traps public config). If you do not want these traps, then disable config traps.

New Member

Re: Ciscoworks causing Config traps

Is it possible to just use TFTP only for the fetch, and would this prevent the traps?

Cisco Employee

Re: Ciscoworks causing Config traps

By making TFTP the first protocol, and by making sure you have valid read-write SNMP credentials in DCR, then RME will use TFTP and SNMP on all devices that support it. However, traps will still be sent even using this method. They will just have a different command source.

New Member

Re: Ciscoworks causing Config traps

Okay. Sounds like we need to get rid of some traps then. Thanks for the help.

Re: Ciscoworks causing Config traps

another possibiliy should be to set the trap to 'log-only' or 'don't discplay - don't log' in NNM to keep the Alarm Browser clean.

Make a duplicate of the event and define a filter so it will be 'Don't Log - Don't Display' if your LMS server is listed as the source inside the trap. With this you will still see this trap in the Alarm Browser when other sources causes this trap.

148
Views
10
Helpful
7
Replies