Ok, so I'm not a Cisco guru, enough said. That being the case, what is the difference between the "logging trap" and "snmp-server enable traps"? I am assuming they are for two completely different puposes. Can anyone explain.
John,
I don't think Cisco could have made it any more confusing if they tried. In the case of the snmp-server enable traps syslog command, the syslog extension refers to system logging messages (and, as the Cisco documentation states, also called system error messages or syslog messages.) The command is still sending the messages via snmp, not syslog. I don't know if my explanation is any clearer than the Cisco documentation, but here it is, just in case it makes more sense to you hearing it from them!
Hope this helps clear it up for you!
From the Cisco IOS Configuration Fundamentals and Network Management Command Reference, Release 12.3
SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform requests.
This command controls (enables or disables) system logging message notifications. System logging messages (also called system error messages, or syslog messages) are status notification messages that are generated by the routing device during operation. These messages are typically logged to a destination (such as the terminal screen, to a system buffer, or to a remote "syslog" host).
If your software image supports the Cisco Syslog MIB, these messages can also be sent via SNMP to a network management station (NMS). To determine which software images support the Cisco Syslog MIB, used the Cisco MIB Locator tool at http://www.cisco.com/go/mibs/ .(At the time of writing, the Cisco Syslog MIB is only supported in "Enterprise" images.)
Unlike other logging processes on the system, debug messages (enabled using CLI debug commands) are not included with the logging messages sent via SNMP.
To specify the severity level at which notifications should be generated, use the logging history global configuration command. For additional information about the system logging process and severity levels, see the description of the logging commands.
The syslog notification is defined by the clogMessageGenerated NOTIFICATION-TYPE object in the Cisco Syslog MIB (CISCO-SYSLOG-MIB.my). When a syslog message is generated by the device a clogMessageGenerated notification is sent to the designated NMS. The clogMessageGenerated notification includes the following objects: clogHistFacility, clogHistSeverity, clogHistMsgName, clogHistMsgText, clogHistTimestamp.
For a complete description of these objects and additional MIB information, see the text of CISCO-SYSLOG-MIB.my, available on Cisco.com using the SNMP Object Navigator tool at http://www.cisco.com/go/mibs . See also the CISCO-SYSLOG-EXT-MIB and the CISCO-SYSLOG-EVENT-EXT-MIB.
The snmp-server enable traps syslog command is used in conjunction with the snmp-server host command. Use the snmp-server host command to specify which host or hosts receive SNMP notifications. To send SNMP notifications, you must configure at least one snmp-server host command.
The following example enables the router to send system logging messages at severity levels 0 (emergencies) through 2 (critical) to the host at the address myhost.cisco.com using the community string defined as public:
Router(config)# snmp-server enable traps syslog
Router(config)# logging history 2
Router(config)# snmp-server host myhost.cisco.com traps version 2c public
This is kinda general speaking, but Syslog, or logging, is any output that could appear on the Cisco console. Logging on your Cisco equipment can be configured to send at 8 different levels. 0 is the most severe and 7 is least severe. If you set your Cisco device to log at level 4, it will send log messages that are level 4 through 0.
SNMP traps do not appear on the Cisco console and are typically only sent to a trap server. You can configure your device to send a million different types of traps depending on what you want to be notified on. For example, OSPF changes, temperature alerts, interfaces going up and down...etc. Again this, is a very general explanation, but hopefully that helps a bit.
DirtySouth, thanks for that info. I am however specifically looking for the difference between "logging trap" and "snmp-server enable traps" when both are directed to syslog servers. I guess I'll just play with them until I figure it out.
The "logging trap" command enables the sending of syslog messages to syslog servers. The destination syslog server is configured with the "logging" command.
The "snmp-server enable traps" command enables the sending of trap messages. The destination trap server is configured with the "snmp-server host" command.
Sedo,
Thanks, that clears it up somewhat. My confusion still comes from the following extension of the "snmp-server enable traps" command which would be "snmp-server enable traps syslog". If "snmp-server enable traps" sends to a trap server, what does adding the "syslog" parameter do - send it to a syslog server?
Sorry for beating a dead horse, I just want to make sure I fully understand the differences.
John
"SNMP traps do not appear on the Cisco console and are typically only sent to a trap server."
Can I log what traps I sent? Can I see them in syslog? What can I configure so I can check what traps I sent (lets say in the last 24 hours). Consider I dont have access to the server receiving the trap.
Can I log what traps my ASA has sent? Can I see them in syslog? What can I configure so I can check what traps ASA has sent (lets say in the last 24 hours). Consider I dont have access to the server receiving the trap.
Everyone has provided an answer that pretty much gets to the root of your issue. The commands basically allow you to leverage syslog or snmp, and then report those messages via syslog or snmp. If you go the SNMP route, it will package up your syslog messages (that appear on console) like an snmptrap and assign each portion of a syslog message an SNMPOid and plug in the syslog value. Vice versa, if you listen for syslog messages, but want to see the traps, then syslog will package your snmptrap into a syslog message. This is helpful most times from the SNMP perspective. Not all syslog messages have a corresponding snmptrap, but most SNMPtraps will have a corresponding syslog. That way, if you are only listening for SNMPtraps, you can package your syslog messages as SNMPtraps and send them over.
