Table Of Contents
show license call-home
To display the stock keeping unit (SKU) list and features available in a product authorization key (PAK), use the show license call-home command in privileged EXEC mode.
Cisco 860, 880, and 890 Series Routers, and Cisco 1900, 2900, and 3900 Series Integrated Services Router Platforms
show license call-home pak pak-id
Cisco uBR10012 Universal Broadband Router
show license [call-home pak pak-id]
Cisco Catalyst 3560-E and Cisco Catalyst 3750-E Switch Platforms
show license call-home pak pak-id
Syntax Description
pak
Shows the product authorization key.
pak-id
The product authorization key sent through e-mail or through regular mail by manufacturing to authorize software upgrades.
Command Modes
Privileged EXEC (#)
Command History
Usage Guidelines
The Cisco License Call Home feature allows a Cisco router to communicate with the Cisco licensing infrastructure through the Internet and retrieve licensing information. This command requires that the router be connected to the Internet.
This command requires the following:
•
The router or switch must have an Internet connection and use HTTPS to connect to the Cisco licensing infrastructure. To set up a secure HTTP connection, see the HTTP 1.1 Web Server and Client module in the Network Management Configuration Guide: http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_http_web.html.
•
•
•
Issuing the show license call-home command causes these actions to occur:
•
•
Cisco uBR10012 Universal Broadband Router
In the Cisco uBR10012 universal broadband router, the call-home keyword is optional in the show license command syntax.
Examples
The following example shows the PAKs and SKUs associated with a software license:
Router# show license call-home pak 3XPXR9E7D30CCO User name : User1CCO password : *******Pak Number : 3XPXR9E7D30Pak Fulfillment type: SINGLE1. SKU Name : GatekeeperSKU Type : ProductDescription : GatekeeperOrdered Qty : 1Available Qty : 1Feature List :Feature name: gatekeeper Count: UncountedPlatform Supported : 5400535028003800Table 5 describes the significant fields shown in the display.
Related Commands
show license statistics
To display license statistics information, use the show license statistics command in privileged EXEC mode.
Cisco 860, 880, and 890 Series Routers, and Cisco 1900, 2900, and 3900 Series Integrated Services Router Platforms
show license statistics
Cisco Catalyst 3560-E Switch Platforms
show license statistics
Cisco Catalyst 3750-E Switch and Switch Stack Platforms
show license statistics [switch switch-num]
Cisco Catalyst 3750-E Switch Mixed Stack Platforms
show license statistics switch switch-num
Cisco uBR10012 Universal Broadband Routers
show license [statistics subslot slot/subslot]
Cisco uBR7225VXR and Cisco uBR7246VXR Universal Broadband Routers
show license [statistics slot slot]
Syntax Description
Command Modes
Privileged EXEC (#)
Command History
Usage Guidelines
Cisco uBR10012 Universal Broadband Routers
The command displays statistics information of the line card in the specified slot/subslot. The keyword subslot and slot/subslot arguments were added for Cisco uBR10012 universal broadband routers.
Examples
The following is sample output from the show license statistics command:
Router# show license statisticsAdministrative statisticsInstall success count: 4Install failure count: 1Install duplicate count: 12Comment add count: 2Comment delete count: 0Clear count: 10Save count: 1Save cred count: 6Client statisticsRequest success count 0Request failure count 0Release count 0Global Notify count 21SWIFT url statusSwift value changed by userCurrent Value : https://cisco.com/SWIFT/LicensingDefault Value : https://cisco.com/SWIFT/LicensingCisco uBR10012 Universal Broadband Routers: Example
The following is sample output from the show license statistics subslot 8/1 command executed on the Cisco uBR10012 router:
Router# show license statistics subslot 8/1Administrative statisticsInstall success count: 0Install failure count: 0Install duplicate count: 0Comment add count: 0Comment delete count: 0Clear count: 0Save count: 0Save cred count: 0Client statisticsRequest success count: 1Request failure count: 1Release count: 0Global Notify count: 1Table 6 describes the significant fields shown in the display.
Cisco uBR7225VXR and Cisco uBR7246VXR Universal Broadband Routers: Example
The following is sample output from the show license statistics slot 5 command executed on the Cisco uBR7246VXR router:
Router# show license statistics slot 5Administrative statisticsInstall success count: 0Install failure count: 0Install duplicate count: 0Comment add count: 0Comment delete count: 0Clear count: 0Save count: 0Save cred count: 0Client statisticsRequest success count: 2Request failure count: 0Release count: 0Global Notify count: 0Table 7 describes the significant fields shown in the display.
Related Commands
debug license
Enables controlled debugging options in the Cisco software licensing module.
show license status
Displays license information to troubleshoot licensing issues.
show subsys
To display the subsystem information, use the show subsys command in privileged EXEC mode.
show subsys [class class | name name]
Syntax Description
Command Modes
Privileged EXEC (#)
Command History
Usage Guidelines
Use the show subsys command to confirm that all required features are in the running image.
Examples
The following is sample output from the show subsys command:
Router# show subsysName Class Versionstatic_map Kernel 1.000.001arp Kernel 1.000.001ether Kernel 1.000.001compress Kernel 1.000.001alignment Kernel 1.000.002monvar Kernel 1.000.001slot Kernel 1.000.001oir Kernel 1.000.001atm Kernel 1.000.001ip_addrpool_sys Library 1.000.001chat Library 1.000.001dialer Library 1.000.001flash_services Library 1.000.001ip_localpool_sys Library 1.000.001nvram_common Driver 1.000.001ASP Driver 1.000.001sonict Driver 1.000.001oc3suni Driver 1.000.001oc12suni Driver 1.000.001ds3suni Driver 1.000.001The following is sample output from the show subsys command that includes the license class:
Router# show subsys name licenseName Class Versionlicense_mgmt_local Management 1.000.001license_admin_local Management 1.000.001license_debug_core Management 1.000.001license_test_ui Management 1.000.001test_license_parser Management 1.000.001license_ui Management 1.000.001license_parser Management 1.000.001license_registry Registry 1.000.001license_client License 1.000.001Table 8 describes the fields shown in the display.
show subsys license
To display the subsystem running for a feature set, use the show subsys license command in either user EXEC or privileged EXEC mode.
show subsys license subsystem
Syntax Description
Command Default
Subsystem information is not displayed.
Command Modes
User EXEC (>)
Privileged EXEC (#)Command History
12.2(35)SE2
This command was introduced.
12.4(20)T
This command was integrated into Cisco IOS Release 12.4(20)T.
Usage Guidelines
Use this command to display license information and to help with troubleshooting issues related to Cisco IOS software licenses.
Examples
The following is sample output that shows the subsystem running the IP base feature set:
Router# show subsys license ipbaseLicense level: ipbaseName Class Versionobfl_env_app Kernel 1.000.001exception Kernel 1.000.001xml_proxy_client Kernel 1.000.000proto_counter Kernel 1.000.001sched_ui Kernel 1.000.001policy_manager Kernel 1.000.001fib_table_trace Kernel 1.000.001ifmibapi_access Kernel 1.000.000xml_engine Kernel 1.000.000fddi_mtu Kernel 1.000.001fib_trace Kernel 1.000.001...qos_set Protocol 1.000.001rip Protocol 1.000.001ipdiag Protocol 1.000.001aaa_peruser Protocol 1.000.001identity_cli Management 1.000.001notification_log_mib Management 1.000.000pagpmib Management 1.000.000ifmib Management 1.000.000rtty_chain Management 1.000.001cdpmib Management 1.000.000vlmem Management 1.000.000...psecure_registry Registry 1.000.001ip_ios_registry Registry 1.000.001sys_name_registry Registry 1.000.001INIT SystemInit 2.000.001parser EHSA 1.000.001tmpsys_ifs EHSA 1.000.001hulc_fib_rf_ehsa EHSA 1.000.001regexp_ui EHSA 1.000.001system_ifs EHSA 1.000.001chunk_ui EHSA 1.000.001rbcp EHSA 1.000.000gdb_ui EHSA 1.000.001ifs_image_elf EHSA 1.000.001nvram_common EHSA 1.000.001ifs_image_ascii EHSA 1.000.001clock_ui EHSA 1.000.001nv_ifs EHSA 1.000.001sff8472 Pre-Driver 1.000.001aggmgr Pre-Driver 1.000.000ifindex_pers Pre-Driver 1.000.001sff8472_fixed Pre-Driver 1.000.000fib_rp_predriver Pre-Driver 1.000.001system_capability Pre-Driver 1.000.001fib_lc_predriver Pre-Driver 1.000.001fib_ios_chain Pre-Driver 1.000.001transceiver Pre-Driver 1.000.002fib_ios_predriver Pre-Driver 1.000.001license_client License 1.000.001hulc_flash License 1.000.001ios_licensing_image_application License 1.000.001ifs License 1.000.001sdb License 1.000.001boot_upgrade License 1.000.001hulc_universal_only License 1.000.001Table 8 describes the fields shown in the display.
snmp-server enable traps
To enable all Simple Network Management Protocol (SNMP) notification types that are available on your system, use the snmp-server enable traps command in global configuration mode. To disable all available SNMP notifications, use the no form of this command.
snmp-server enable traps [notification-type] [vrrp]
no snmp-server enable traps [notification-type] [vrrp]
Syntax Description
notification-type
(Optional) Type of notification (trap or inform) to enable or disable. If no type is specified, all notifications available on your device are enabled or disabled (if the no form is used). The notification type can be one of the following keywords:
alarms—Enables alarm filtering to limit the number of syslog messages generated. Alarms are generated for the severity configured as well as for the higher severity values.
•
–
–
–
–
•
•
•
Catalyst 6500 Series Switches
The following keywords are available under the dot1x keyword:
–
–
–
–
•
•
•
•
•
•
•
–
–
–
–
•
•
•
•
–
–
–
–
•
•
•
•
•
•
Note
vrrp
(Optional) Specifies the Virtual Router Redundancy Protocol (VRRP).
1 Supported on the Catalyst 6500 series switches.
Command Default
No notifications controlled by this command are sent.
Command Modes
Global configuration (config)
Command History
Usage Guidelines
For additional notification types, see the Related Commands table for this command.
SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform requests for the specified notification types. To specify whether the notifications should be sent as traps or informs, use the snmp-server host [traps | informs] command.
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. To enable multiple types of notifications, you must issue a separate snmp-server enable traps command for each notification type and notification option.
Most notification types are disabled by default but some cannot be controlled with the snmp-server enable traps command.
The snmp-server enable traps 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 notifications, you must configure at least one snmp-server host command.
Catalyst 6500 Series Switches
The following MIBs were enhanced or supported in Cisco IOS Release 12.2(33)SXI and later releases on the Catalyst 6500 series switch:
•
•
•
•
•
Examples
The following example shows how to enable the router to send all traps to the host specified by the name myhost.cisco.com, using the community string defined as public:
Router(config)# snmp-server enable trapsRouter(config)# snmp-server host myhost.cisco.com publicThe following example shows how to configure an alarm severity threshold of 3:
Router# snmp-server enable traps alarms 3The following example shows how to enable the generation of a DSP operational state notification from from the command-line interface (CLI):
Router(config)# snmp-server enable traps dsp oper-stateThe following example shows how to enable the generation of a DSP operational state notification from a network management device:
setany -v2c 1.4.198.75 test cdspEnableOperStateNotification.0 -i 1cdspEnableOperStateNotification.0=true(1)The following example shows how to send no traps to any host. The Border Gateway Protocol (BGP) traps are enabled for all hosts, but the only traps enabled to be sent to a host are ISDN traps (which are not enabled in this example).
Router(config)# snmp-server enable traps bgpRouter(config)# snmp-server host user1 public isdnThe following example shows how to enable the router to send all inform requests to the host at the address myhost.cisco.com, using the community string defined as public:
Router(config)# snmp-server enable trapsRouter(config)# snmp-server host myhost.cisco.com informs version 2c publicThe following example shows how to send HSRP MIB traps to the host myhost.cisco.com using the community string public:
Router(config)# snmp-server enable traps hsrpRouter(config)# snmp-server host myhost.cisco.com traps version 2c public hsrpThe following example shows that VRRP will be used as the protocol to enable the traps:
Router(config)# snmp-server enable traps vrrpRouter(config)# snmp-server host myhost.cisco.com traps version 2c vrrpThe following example shows how to send IEEE 802.1X MIB traps to the host "myhost.example.com" using the community string defined as public:
Router(config)# snmp-server enable traps dot1xRouter(config)# snmp-server host myhost.example.com traps publicRelated Commands
snmp-server host
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]
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]
Command Syntax on Cisco ME 3400, ME 3400E, and Catalyst 3750 Metro Switches
snmp-server host ip-address {community-string | {informs | traps} {community-string |
version {1 | 2c | 3 {auth | noauth}}}} community-string | version {1 | 2c | 3 {auth | noauth}} community-string | vrf vrf-name {informs | traps} {community-string | version {1 | 2c | 3 {auth | noauth}} community-string}} [notification-type]no snmp-server host ip-address {community-string | {informs | traps} {community-string |
version {1 | 2c | 3 {auth | noauth}} community-string | version {1 | 2c | 3 {auth | noauth}} community-string | vrf vrf-name {informs | traps} {community-string | version {1 | 2c | 3 {auth | noauth}} community-string}} [notification-type]Command Syntax on Cisco 7600 Series Router
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]Syntax Description
hostname
Name of the host. The SNMP notification host is typically a network management station (NMS) or SNMP manager. This host is the recipient of the SNMP traps or informs.
ip-address
IPv4 address or IPv6 address of the SNMP notification host.
vrf
(Optional) Specifies that a Virtual Private Network (VPN) routing and forwarding (VRF) instance should be used to send SNMP notifications.
•
vrf-name
(Optional) VPN VRF instance used to send SNMP notifications.
•
informs
(Optional) Specifies that notifications should be sent as informs.
•
traps
(Optional) Specifies that notifications should be sent as traps. This is the default.
•
version
(Optional) Specifies the version of the SNMP that is used to send the traps or informs. The default is 1.
•
If you use the version keyword, one of the following keywords must be specified:
•
•
•
One of the following three optional security level keywords can follow the 3 keyword:
–
–
–
community-string
Password-like community string sent with the notification operation.
Note
Note
udp-port
(Optional) Specifies that SNMP traps or informs are to be sent to an NMS host.
•
port
(Optional) User Datagram Protocol (UDP) port number of the NMS host. The default is 162.
•
notification-type
(Optional) Type of notification to be sent to the host. If no type is specified, all available notifications are sent. See the "Notification-Type Keywords" section for more information about the keywords available.
Command Default
This command behavior is disabled by default. A recipient is not specified to receive notifications.
Command Modes
Global configuration (config)
Command History
10.0
This command was introduced.
12.0(3)T
•
•
•
12.1(3)T
The calltracker notification-type keyword was added for the Cisco AS5300 and AS5800 platforms.
12.2(2)T
•
•
•
12.2(4)T
•
•
12.2(8)T
•
•
12.2(13)T
•
•
12.3(2)T
•
•
12.3(4)T
•
•
•
12.3(8)T
The iplocalpool notification-type keyword was added for the Cisco 7200 and 7301 series routers.
12.3(11)T
The vrrp keyword was added.
12.3(14)T
•
•
12.4(20)T
The license notification-type keyword was added.
15.0(1)M
•
•
12.0(17)ST
The mpls-traffic-eng notification-type keyword was added.
12.0(21)ST
The mpls-ldp notification-type keyword was added.
12.0(22)S
•
•
12.0(23)S
The l2tun-session notification-type keyword was added.
12.0(26)S
The memory notification-type keyword was added.
12.0(27)S
•
•
12.0(31)S
The l2tun-pseudowire-status notification-type keyword was added.
12.2(18)S
This command was integrated into Cisco IOS Release 12.2(18)S.
12.2(25)S
•
•
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
•
•
12.2(54)SE
This command was modified. See the "Command Syntax on Cisco ME 3400, ME 3400E, and Catalyst 3750 Metro Switches" section for the command syntax for these switches.
15.0(1)S
This command was integrated into Cisco IOS Release 15.0(1)S. The flowmon notification-type keyword was added.
Cisco IOS XE Release 2.1
This command was integrated into Cisco IOS XE Release 2.1.
Usage Guidelines
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
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 than traps to reach their intended destination.
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 a 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 Virtual Routing and Forwarding (VRF) VPN. The VRF defines a VPN membership of a user so data is stored using the VPN.
In the case of the NMS sending the query having a correct SNMP community but that does not have 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
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Note
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
SNMP-Related Notification-Type Keywords
The notification-type keywords 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 keyword 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 command-line interface (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. Table 10 maps some examples of snmp-server enable traps commands to the keywords used in the snmp-server host command.
Table 10 SNMP-server enable traps Commands and Corresponding Notification Keywords
snmp-server enable traps l2tun session
l2tun-session
snmp-server enable traps mpls ldp
mpls-ldp
snmp-server enable traps mpls traffic-eng1
mpls-traffic-eng
snmp-server enable traps mpls vpn
mpls-vpn
1 See the Cisco IOS Multiprotocol Label Switching Command Reference for documentation of this command.
Examples
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 10Router(config)# snmp-server host 192.20.2.160 comaccessRouter(config)# access-list 10 deny any
Note
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 trapsRouter(config)# snmp-server host myhost.cisco.com comaccess snmpThe following example shows how to send the SNMP and Cisco environmental monitor enterprise-specific traps to address 192.30.2.160 using the community string public:
Router(config)# snmp-server enable traps snmpRouter(config)# snmp-server enable traps envmonRouter(config)# snmp-server host 192.30.2.160 public snmp envmonThe 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 trapsRouter(config)# snmp-server host myhost.cisco.com publicThe 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 bgpRouter(config)# snmp-server host myhost.cisco.com public isdnThe 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 trapsRouter(config)# snmp-server host myhost.cisco.com informs version 2c publicThe 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 hsrpRouter(config)# snmp-server host myhost.cisco.com informs version 2c public hsrpThe 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 publicThe 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 2012The following example shows how to specify VRRP as the protocol using the community string public:
Router(config)# snmp-server enable traps vrrpRouter(config)# snmp-server host myhost.cisco.com traps version 2c public vrrpThe following example shows how to send all Cisco Express Forwarding informs to the notification receiver with the IP address 192.40.3.130 using the community string public:
Router(config)# snmp-server enable traps cefRouter(config)# snmp-server host 192.40.3.130 informs version 2c public cefThe following example shows how to enable all NHRP traps, and how to send all NHRP traps to the notification receiver with the IP address 192.40.3.130 using the community string public:
Router(config)# snmp-server enable traps nhrpRouter(config)# snmp-server host 192.40.3.130 traps version 2c public nhrpRelated Commands
