The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes how to configure supported Cisco IOS® SNMP Traps.
Cisco recommends that you have knowledge of these topics:
You do not want a Cisco device to send all of the SNMP traps that the device knows how to send. For instance, if you enable all traps in a Remote Access Server with 64 dial-in lines, you get a trap whenever a user dials in and whenever a user terminates the connection. This creates too many traps. Cisco IOS Software defines groups of traps that you can enable or disable. There are two global configuration commands that you use to configure SNMP traps into a Cisco IOS Software device:
snmp-server host host-addr [traps | informs] [version ]
community-string [udp-port port] [notification-type]
snmp-server enable traps [notification-type] [notification-option]
The types of traps can be specified in both commands. You must issue the snmp-server host command in order to define the Network Management Systems where traps are to be sent. You must specify the trap types if you do not want all traps to be sent. Issue multiple snmp-server enable traps commands, one for each of the trap types that you used in the snmp host command.
Note: Not all [notification-type] options are supported on both of these commands. For example, [notification-type] x25 and teletype (tty) are not used for snmp-server enable trap x25, and tty traps are enabled by default.
For example, issue these commands to make a Cisco IOS Software device report only configuration, Border Gateway Protocol (BGP), and tty traps to Network Management System 10.10.10.10:
snmp-server host 10.10.10.10 public config bgp tty snmp-server enable traps config snmp-server enable traps bgp
This document is not restricted to specific software and hardware versions.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
Refer to the Cisco Technical Tips Conventions for more information on document conventions.
Note: Cisco IOS Software Release 12.1(3)T was used to prepare this document. When you use an earlier Cisco IOS Software Release, not all options are supported. When you use a Cisco IOS Software release later than 12.1(3)T, additional [notification-type] options can be supported. You can find a current list of all supported Cisco IOS Software Simple Network Management Protocol (SNMP) trap Object Identifiers (OIDs) in this document.
Cisco devices that run the standard Cisco IOS Software (routers, Asynchronous Transfer Mode (ATM) switches and Remote Access Servers) can generate many SNMP traps.
Issue the snmp-server host global configuration command to specify the recipient of an SNMP notification operation. Issue the no form of this command to remove the specified host.
snmp-server host host-addr [traps | informs] [version ] community-string [udp-port port] [notification-type] no snmp-server host host [traps | informs]
The snmp-server host command is disabled by default. No notifications are sent.
If you enter this command with no keywords, the default is to send all trap types to the host.
No informs are sent to this host. If no version keyword is present, the default is version 1. The no snmp-server host command with no keywords disables traps, but not informs, to the host. Issue the no snmp-server host informs command to disable informs.
Note: If the community-string is not defined with the snmp-server community command before you use this command, the default form of the snmp-server community command is automatically inserted into the configuration. The password (community-string) used for this automatic configuration of the snmp-server community is the same as specified in the snmp-server host command. This is the default behavior for Cisco IOS Software Release 12.0(3) and later.
SNMP notifications can be sent as traps or inform requests. Traps are unreliable because the receiver does not send acknowledgments when this device receives traps. The sender cannot determine if the traps were received. However, an SNMP entity that receives an inform request acknowledges the message with an SNMP response protocol data unit (PDU). If the sender never receives the response, the inform request can be sent again. Therefore, informs are more likely to reach their intended destination.
However, informs consume more resources in the agent and in the network. Unlike a trap, which is discarded as soon as it is sent, an inform request must be held in memory until a response is received, or the request times out. Traps are sent only once, while an inform can be retried several times. The retries increase traffic and contribute to a higher overhead on the network.
If you do not enter an snmp-server host command, no notifications are sent. In order to configure the router to send SNMP notifications, you must enter at least one snmp-server host command. If you enter the command with no keywords, all trap types are enabled for the host.
In order to enable multiple hosts, you must issue a separate snmp-server host command for each host. You can specify multiple notification types in the command for each host.
When multiple snmp-server host commands are given for the same host and kind of notification (trap or inform), each command overwrites the previous command. Only the last snmp-server host command is taken into account. For example, if you enter an snmp-server host inform command for a host and then enter another snmp-server host inform command for the same host, the second command replaces the first.
The snmp-server host command is used in conjunction with the snmp-server enable command. Issue the snmp-server enable command in order to specify which SNMP notifications are sent globally. In order for a host to receive most notifications, at least one snmp-server enable command and the snmp-server host command for that host must be enabled.
However, some notification types cannot be controlled with the snmp-server enable command. For example, some notification types are always enabled. Other notification types are enabled by a different command. For example, the linkUpDown notifications are controlled by the snmp trap link-status command. These notification types do not require an snmp-server enable command.
The availability of a notification-type option depends on the router type and Cisco IOS software features supported on the router. For example, the envmon notification-type is available only if the environmental monitor is part of the system.
Complete these steps to be able to send an inform:
If you want to configure a unique SNMP community string for traps, but you want to prevent SNMP polling access with this string, the configuration must include an access-list. In this example, the community string is named comaccess, and the access list is numbered 10:
snmp-server community comaccess ro 10 snmp-server host 172.20.2.160 comaccess access-list 10 deny any
This example sends the SNMP traps to the host specified by the name myhost.cisco.com. The community string is defined as comaccess:
snmp-server enable traps snmp-server host myhost.cisco.com comaccess snmp
This example sends the SNMP and Cisco environmental monitor enterprise-specific traps to address 172.30.2.160:
snmp-server enable traps snmp-server host 172.30.2.160 public snmp envmon
This example enables the router to send all traps to the host myhost.cisco.com with the community string public:
snmp-server enable traps snmp-server host myhost.cisco.com public
This example does not send traps to any host. The BGP traps are enabled for all hosts, but only the ISDN traps are enabled to be sent to a host.
snmp-server enable traps bgp snmp-server host bob public isdn
This example enables the router to send all inform requests to the host myhost.cisco.com with the community string public:
snmp-server enable traps snmp-server host myhost.cisco.com informs version
This example sends HSRP SNMPv2c traps to the host specified by the name myhost.cisco.com. The community string is defined as public.
snmp-server enable traps snmp-server host myhost.cisco.com traps version 2c public hsrp
Use the snmp-server enable traps global configuration command to enable the router to send SNMP traps. Use the no form of this command to disable SNMP notifications.
snmp-server enable traps [notification-type] [notification-option] no snmp-server enable traps [notification-type] [notification-option]
(Optional) The type of notification to enable. If no type is specified, all notifications are sent (that includes the envmon and repeater notifications). The notification type can be one of these keywords:
SNMP notifications are disabled.
If you enter this command with no notification-type keywords, the default is to enable all notification types controlled by this command.
The snmp-server enable traps snmp [ linkup] [linkdown] form of this command replaces the snmp trap link-status interface configuration mode command.
The no form of the snmp-server enable traps command is useful in order to disable notifications that generate a large amount of unneeded noise on your network.
SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform requests for the specified notification types.
If you do not enter an snmp-server enable traps command, no notifications controlled by this command are sent. In order to configure the router to send these SNMP notifications, you must enter at least one snmp-server enable traps command. If you enter the command with no keywords, all notification types are enabled. If you enter the command with a keyword, only the notification type related to that keyword is enabled. In order to enable multiple types of notifications, you must issue a separate snmp-server enable traps command for each notification type and notification option.
The snmp-server enable traps command is used in conjunction with the snmp-server host command. Issue the snmp-server host command to specify which host or hosts receive SNMP notifications. In order to send notifications, you must configure at least one snmp-server host command.
In order for a host to receive a notification controlled by this command, both the snmp-server enable traps command and the snmp-server host command for that host must be enabled. If the notification type is not controlled by this command, only the appropriate snmp-server host command must be enabled.
The notification types used in this command all have an associated MIB object that allows them to be enabled or disabled (for example, HSRP traps are defined with the HSRP MIB, repeater traps are defined with the Repeater Hub MIB, and so on). Not all of the notification types available in the snmp-server host command have notificationEnable MIB objects, so some of these cannot be controlled with the snmp-server enable command.