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.
To specify the recipient of a Simple Network Management Protocol (SNMP) notification operation, use the snmp-server host command in global configuration mode. To remove the specified host from the configuration, use the no form of this command.
snmp-server host { hostname | ip-address } [ vrf vrf-name | informs | traps | version { 1 | 2c | 3 [ auth | noauth | priv ] } ] community-string [ udp-port port [notification-type] | notification-type ]
no snmp-server host { hostname | ip-address } [ vrf vrf-name | informs | traps | version { 1 | 2c | 3 [ auth | noauth | priv ] } ] community-string [ udp-port port [notification-type] | notification-type ]
snmp-server host ip-address { community-string | informs | traps } { community-string | version { 1 | 2c | 3 { auth | noauth } } } { community-string | vrf vrf-name { informs | traps } } [ notification-type ]
no snmp-server host ip-address { community-string | informs | traps } { community-string | version { 1 | 2c | 3 { auth | noauth } } } { community-string | vrf vrf-name { informs | traps } } [ notification-type ]
snmp-server host ip-address { community-string | { informs | traps } { community-string | version { 1 | 2c | 3 { auth | noauth | priv } } community-string | version { 1 | 2c | 3 { auth | noauth | priv } } community-string | vrf vrf-name { informs | traps } { community-string | version { 1 | 2c | 3 { auth | noauth | priv } } community-string } } } [notification-type]
no snmp-server host ip-address { community-string | { informs | traps } { community-string | version { 1 | 2c | 3 { auth | noauth | priv } } community-string | version { 1 | 2c | 3 { auth | noauth | priv } } community-string | vrf vrf-name { informs | traps } { community-string | version { 1 | 2c | 3 { auth | noauth | priv } } community-string } } } [notification-type]
This command behavior is disabled by default. A recipient is not specified to receive notifications.
Global configuration (config)
Release |
Modification |
---|---|
10.0 |
This command was introduced. |
Cisco IOS Release 12 and 15 Mainline/T Train |
|
12.0(3)T |
This command was modified. |
12.1(3)T |
This command was modified. The calltracker notification-type keyword was added for the Cisco AS5300 and AS5800 platforms. |
12.2(2)T |
This command was modified. |
12.2(4)T |
This command was modified. |
12.2(8)T |
This command was modified. |
12.2(13)T |
This command was modified. |
12.3(2)T |
This command was modified. |
12.3(4)T |
This command was modified. |
12.3(8)T |
This command was modified. The iplocalpool notification-type keyword was added for the Cisco 7200 and 7301 series routers. |
12.3(11)T |
This command was modified. The vrrp keyword was added. |
12.3(14)T |
This command was modified. |
12.4(20)T |
This command was modified. The license notification-type keyword was added. |
15.0(1)M |
This command was modified. |
Cisco IOS Release 12.0S |
|
12.0(17)ST |
This command was modified. The mpls-traffic-eng notification-type keyword was added. |
12.0(21)ST |
This command was modified. The mpls-ldp notification-type keyword was added. |
12.0(22)S |
This command was modified. |
12.0(23)S |
This command was modified. The l2tun-session notification-type keyword was added. |
12.0(26)S |
This command was modified. The memory notification-type keyword was added. |
12.0(27)S |
This command was modified. |
12.0(31)S |
This command was modified. The l2tun-pseudowire-status notification-type keyword was added. |
Cisco IOS Release 12.2S |
|
12.2(18)S |
This command was integrated into Cisco IOS Release 12.2(18)S. |
12.2(25)S |
This command was modified. |
12.2(28)SB |
This command was integrated into Cisco IOS Release 12.2(28)SB. |
12.2(33)SRA |
This command was integrated into Cisco IOS Release 12.2(33)SRA. |
12.2(31)SB2 |
The cef notification-type keyword was added. |
12.2(33)SXH |
This command was integrated into Cisco IOS Release 12.2(33)SXH. |
12.2(33)SB |
This command was integrated into Cisco IOS Release 12.2(33)SB. |
12.2(33)SXI5 |
This command was modified. |
12.2(54)SE |
This command was modified. See the snmp-server host for the command syntax for these switches. |
12.2(33)SXJ |
This command was integrated into Cisco IOS Release 12.2(33)SXJ. The public storm-control notification-type keyword was added. |
Cisco IOS Release 15S |
|
15.0(1)S |
This command was modified. The flowmon notification-type keyword was added. |
Cisco IOS XE Releases |
|
Cisco IOS XE Release 2.1 |
This command was integrated into Cisco IOS XE Release 2.1. |
15.2(1)S |
This command was modified. The p2mp-traffic-eng notification-type keyword was added. |
If you enter this command with no optional keywords, the default is to send all notification-type traps to the host. No informs will be sent to the host.
The no snmp-server host command with no keywords disables traps, but not informs, to the host. To disable informs, use the no snmp-server host informs command.
Note |
If a community string is not defined using the snmp-server community command prior to using this command, the default form of the snmp-server community command will automatically be inserted into the configuration. The password (community string) used for this automatic configuration of the snmp-server community command will be the same as that specified in the snmp-server host command. This automatic command insertion and use of passwords is the default behavior for Cisco IOS Release 12.0(3) and later releases. However, in Cisco IOS Release 12.2(33)SRE and later releases, you must manually configure the snmp-server community command. That is, the snmp-server community command will not be seen in the configuration. |
SNMP notifications can be sent as traps or inform requests. Traps are unreliable because the receiver does not send acknowledgments when it 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. Thus, informs are more likely to reach their intended destination than traps.
Compared to traps, 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. Also, traps are sent only once; an inform may be tried 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. 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 optional keywords, all trap types are enabled for the host.
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 succeeding command overwrites the previous command. Only the last snmp-server host command will be in effect. 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 will replace the first.
The snmp-server host command is used in conjunction with the snmp-server enable command. Use the snmp-server enable command to specify which SNMP notifications are sent globally. 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.
Some notification types cannot be controlled with the snmp-server enable command. Some notification types are always enabled, and others 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 notification-type options depends on the router type and the 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. To see what notification types are available on your system, use the command help ? at the end of the snmp-server host command.
The vrf keyword allows you to specify the notifications being sent to a specified IP address over a specific VRF VPN. The VRF defines a VPN membership of a user so that data is stored using the VPN.
In the case of the NMS sending the query having a correct SNMP community but not having a read or a write view, the SNMP agent returns the following error values:
Notification-Type Keywords
The notification type can be one or more of the following keywords.
Note |
The available notification types differ based on the platform and Cisco IOS release. For a complete list of available notification types, use the question mark (?) online help function. |
Note |
To enable RFC-2233-compliant link up/down notifications, you should use the snmp server link trap command. |
SNMP-Related Notification-Type Keywords
The notification-type argument used in the snmp-server host command do not always match the keywords used in the corresponding snmp-server enable traps command. For example, the notification-type argument applicable to Multiprotocol Label Switching Protocol (MPLS) traffic engineering tunnels is specified as mpls-traffic-eng (containing two hyphens and no embedded spaces). The corresponding parameter in the snmp-server enable traps command is specified as mpls traffic-eng (containing an embedded space and a hyphen).
This syntax difference is necessary to ensure that the CLI interprets the notification-type keyword of the snmp-server host command as a unified, single-word construct, which preserves the capability of the snmp-server host command to accept multiple notification-type keywords in the command line. The snmp-server enable traps commands, however, often use two-word constructs to provide hierarchical configuration options and to maintain consistency with the command syntax of related commands. The table below maps some examples of snmp-server enable traps commands to the keywords used in the snmp-server host command.
snmp-server enable traps Command |
snmp-server host Command Keyword |
---|---|
snmp-server enable traps l2tun session |
l2tun-session |
snmp-server enable traps mpls ldp |
mpls-ldp |
snmp-server enable traps mpls traffic-eng 1 |
mpls-traffic-eng |
snmp-server enable traps mpls vpn |
mpls-vpn |
snmp-server host host-address community-string udp-port port p2mp-traffic-eng |
snmp-server enable traps mpls p2mp-traffic-eng [down | up] |
If you want to configure a unique SNMP community string for traps but prevent SNMP polling access with this string, the configuration should include an access list. The following example shows how to name a community string comaccess and number an access list 10:
Router(config)# snmp-server community comaccess ro 10 Router(config)# snmp-server host 10.0.0.0 comaccess Router(config)# access-list 10 deny any
Note |
The “at” sign (@) is used as a delimiter between the community string and the context in which it is used. For example, specific VLAN information in BRIDGE-MIB may be polled using community @VLAN-ID (for example, public@100), where 100 is the VLAN number. |
The following example shows how to send RFC 1157 SNMP traps to a specified host named myhost.cisco.com. Other traps are enabled, but only SNMP traps are sent because only snmp is specified in the snmp-server host command. The community string is defined as comaccess.
Router(config)# snmp-server enable traps Router(config)# snmp-server host myhost.cisco.com comaccess snmp
The following example shows how to send the SNMP and Cisco environmental monitor enterprise-specific traps to address 10.0.0.0 using the community string public:
Router(config)# snmp-server enable traps snmp Router(config)# snmp-server enable traps envmon Router(config)# snmp-server host 10.0.0.0 public snmp envmon
The following example shows how to enable the router to send all traps to the host myhost.cisco.com using the community string public:
Router(config)# snmp-server enable traps Router(config)# snmp-server host myhost.cisco.com public
The following example will 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. The community string is defined as public.
Router(config)# snmp-server enable traps bgp Router(config)# snmp-server host myhost.cisco.com public isdn
The following example shows how to enable the router to send all inform requests to the host myhost.cisco.com using the community string public:
Router(config)# snmp-server enable traps Router(config)# snmp-server host myhost.cisco.com informs version 2c public
The following example shows how to send HSRP MIB informs to the host specified by the name myhost.cisco.com. The community string is defined as public.
Router(config)# snmp-server enable traps hsrp Router(config)# snmp-server host myhost.cisco.com informs version 2c public hsrp
The following example shows how to send all SNMP notifications to example.com over the VRF named trap-vrf using the community string public:
Router(config)# snmp-server host example.com vrf trap-vrf public
The following example shows how to configure an IPv6 SNMP notification server with the IPv6 address 2001:0DB8:0000:ABCD:1 using the community string public:
Router(config)# snmp-server host 2001:0DB8:0000:ABCD:1 version 2c public udp-port 2012
The following example shows how to specify VRRP as the protocol using the community string public:
Router(config)# snmp-server enable traps vrrp Router(config)# snmp-server host myhost.cisco.com traps version 2c public vrrp
The following example shows how to send all Cisco Express Forwarding informs to the notification receiver with the IP address 10.0.1.1 using the community string public:
Router(config)# snmp-server enable traps cef Router(config)# snmp-server host 10.0.1.1 informs version 2c public cef
The following example shows how to enable all NHRP traps, and how to send all NHRP traps to the notification receiver with the IP address 10.0.0.0 using the community string public:
Router(config)# snmp-server enable traps nhrp Router(config)# snmp-server host 10.0.0.0 traps version 2c public nhrp
The following example shows how to enable all P2MP MPLS-TE SNMP traps, and send them to the notification receiver with the IP address 172.20.2.160 using the community string "comp2mppublic":
Router(config)# snmp-server enable traps mpls p2mp-traffic-eng Router(config)# snmp-server host 172.20.2.160 comp2mppublic udp-port 162 p2mp-traffic-eng
Command |
Description |
---|---|
show snmp host |
Displays recipient details configured for SNMP notifications. |
snmp-server enable peer-trap poor qov |
Enables poor quality of voice notifications for applicable calls associated with a specific voice dial peer. |
snmp-server enable traps |
Enables SNMP notifications (traps and informs). |
snmp-server enable traps nhrp |
Enables SNMP notifications (traps) for NHRP. |
snmp-server informs |
Specifies inform request options. |
snmp-server link trap |
Enables linkUp/linkDown SNMP traps that are compliant with RFC 2233. |
snmp-server trap-source |
Specifies the interface from which an SNMP trap should originate. |
snmp-server trap-timeout |
Defines how often to try resending trap messages on the retransmission queue. |
test snmp trap storm-control event-rev1 |
Tests SNMP storm-control traps. |