Ciscoworks causing Config traps

Answered Question

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.

I have this problem too.
0 votes
Correct Answer by Joe Clarke about 8 years 6 months ago

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Loading.
Joe Clarke Tue, 05/27/2008 - 11:04

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?

Joe Clarke Tue, 05/27/2008 - 11:23

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.

Correct Answer
Joe Clarke Tue, 05/27/2008 - 12:04

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.

Martin Ermel Tue, 05/27/2008 - 21:27

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.

Actions

This Discussion