Cisco SNMP trap for Realtime Change Detection

It should denote the change in the trap details variable bindings.

From NCM Admin Guide:

Click SNMPv2-MIB:snmpTrapOID, and then browse to the MIB that contains the trap message. For example, browse to CISCO-CONFIG-MAN-MIB:ccmHistoryEventConfigDestination (1.3.6.1.4.1.9.9.43.1.1.6.1.5).

Click the asterisk, and then type the message pattern to match. For example, when a change is made to the running config the HistoryEventMedium is 3. Changes to the startup config are designated by the integer 4.

If you're having issues getting Traps to work, you can try Syslog instead.

That's the problem though. The SNMP trap is denoting a "running-config" change and it's firing that trap when I type "config t" on a switch. It doesn't fire a trap if I change something or when I exit config mode. It's as if the point of it is to get the config BEFORE a change is made. Seems very backwards.

As I mentioned, it does log the change event AFTER I exit config mode via syslog, but no SNMP trap is sent. I tested this on various cisco switches (2924's, 2960's, 4507's) and they all behave the same. I'd like to avoid using Syslog and just use SNMP traps if I can. Is this expected behaviour or do I have a config issue?

Actually, it shouldn't matter if it sends a trap when users enter into config t mode and don't change anything.   NCM's realtime change detection doesn't rely on the trap event alone to tell you something has changed.   As noted in the Admin Guide, you'll need to configure an alert action in the Trap Viewer that executes the following commands:

Management\ConfigAutoDownload.exe ${IP} ${Message}

If you've enabled Realtime Change Detection in NCM settings (File > Settings > Realtime Change Detection), it will download the config, compare to previously downloaded versions, and then send you an email only if the configs have changed.

HTH,

Consider this, as this is exactly what I am seeing:

- I login to SwitchA and issue the "config t" command.
- This is when the switch sends the SNMP trap to NCM.
- The rule setup for RTCD is fired which kicks off ConfigAutoDownload.exe
- The config is downloaded and compared, but nothing is changed because I haven't actually typed any change commands yet, so NCM will not send any email.
- I change port gi0/30 to vlan 50. Exit config mode.
- No SNMP trap trap is sent when I issue either the VLAN change or when i exit config mode. 

I have now successfully made a change to the running-config of a switch, but NCM has not notified me of the change and won't recognize the change until the next backup which could be several hours away. That's hardly "realtime" since it's unknown when the next backup will occur. So either I have a switch configuration issue where it's not sending the trap AFTER I make a change, or you can't use SNMP traps for RTCD on cisco switches.

Thanks.  Sorry for my earlier rambling, I get it now.   You might need to chase this down with Cisco TAC and see if they have any recommendations for how to configure traps on those devices.  

In my experience, this should work:

snmp-server enable traps config

And, as I noted before, as a last resort there's always Syslog ;-)

I played with the same thing for quite a while and ended up having to use syslog to get it to work correctly.  There was another trap I was getting but its value was never consistent and if I remember correctly it was like it was being sent multiple times.  (Which was almost worse.)

In the end we had a few other devices that had better config change alerts sent by syslog so I made the decision to use it instead of traps and it has worked well. 

Note: I never opened up a TAC case with Cisco on the issue.

Hi would you mind sharing what you did to setup the RTCD via syslog?

Right now I am using:

PARSER-5-CFGLOG_LOGGEDCMD paired with logged command:!exec: enable

But again it only tells me if someone has gotten enable on the device and not that any changes were made.

Your help would be appreciated.

I use "SYS-5-CONFIG*" under message pattern. 

We found the same issue with snmp traps occurring prior to a configuration change.  With the added benefit that "show run" is a config event type as well, which can cause a fun loop if your snmp alert definition is overly broad...

One alternative to keep snmp would be an EEM applet which watches for the console message and then generates a trap.  This works well enough, but requires that your IOS supports EEM.

You might also try "snmp-server enable traps syslog" if you don't mind all your syslog messages also going out as traps...

We went with syslog.

problem i have with syslog is that we require a very high level (or low) amount of logging to our security team.  we log to more than one location and it overwhelms my cirrus server.  right now i can't even keep syslog running cause it crashes due to the logging levels.