05-27-2008 10:41 AM
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.
Solved! Go to Solution.
05-27-2008 12:04 PM
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.
05-27-2008 11:04 AM
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?
05-27-2008 11:08 AM
It's using default settings under Transport Settings. Protocols in the following order.
TELNET
TFTP
SSH
RCP
HTTPS
05-27-2008 11:23 AM
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.
05-27-2008 11:58 AM
Is it possible to just use TFTP only for the fetch, and would this prevent the traps?
05-27-2008 12:04 PM
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.
05-27-2008 12:09 PM
Okay. Sounds like we need to get rid of some traps then. Thanks for the help.
05-27-2008 09:27 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide