Solved: Ciscoworks causing Config traps

wil6707 · ‎05-27-2008

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.

Joe Clarke · ‎05-27-2008

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.

View solution in original post

Joe Clarke · ‎05-27-2008

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?

wil6707 · ‎05-27-2008

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

TELNET

TFTP

SSH

RCP

HTTPS

Joe Clarke · ‎05-27-2008

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.

wil6707 · ‎05-27-2008

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

Joe Clarke · ‎05-27-2008

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.

wil6707 · ‎05-27-2008

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

Martin Ermel · ‎05-27-2008

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.