I'm very interested in this as well. I'm trying to come up with a baseline SNMP config per topology layer / device role (core, distribution, access, edge router, etc).
I'd also be really interested to hear any one else's take on sending syslog over snmp (snmp-server enable traps syslog). My sense is we get too many traps as it is, and we have a syslog server specifically for this. However the CA Spectrum document titled, “Cisco Device Management Guide” suggest that Cisco syslog messages can be mapped to Spectrum events (page 20), but out of the box it appears they are just generic events with severity specified by the sending device. I do not know how this feeds into fault isolation and root cause analysis. I remember asking support about syslog support a few years back (r8.1), and the response was that Spectrum was not designed to handle syslog, and it since syslog is unstructured, the messages could not be parsed for alarming or root cause. Perhaps this is a new feature? I’m still not convinced I want syslog sent to Spectrum, though. You can set the logging level, but even so, syslog can be very chatty, and we have a Splunk server for it. I believe the configuration which includes syslog as an snmp trap predates our implementation of Spectrum and Splunk.
As far as the rest of the traps listed, my two cents would be it depends on the role and environment what traps you need to see. What features are enabled? What are the critical functions of the device? As I understand it, if you enable traps for features / capabilities that are not present or in use, the only added overhead is in the size and complexity of the config; the traps do nothing. However I am inclined to prefer the simplest config which will provide adequate alerting and notification. The first sentence of the section titled “Requirements” in Cisco’s
Document ID 13506 “Cisco IOS SNMP Traps Supported and How to Configure Them” states, “You do not want a Cisco device to send all of the SNMP traps that the device knows how to send.” If you merely issue the snmp-server [host] global command without specifying traps, all traps are sent. If you only issue one snmp-server enable traps command for say, envmon, ONLY envmon traps will be sent. So if you specify any trap types you want, you must specify all trap types that you want.
For my network, I'm probably most concerned with SNMP, envmon, and config, though I'm not sure about authentication traps. The reason is that auth failures don't indicate a network fault, and even if an attack is seen as a potential fault (as it could lead to a loss of data or outage), Spectrum does not provide rate / threshold alarming.