Table Of Contents
show license call-home
show license statistics
show subsys
show subsys license
snmp-server enable traps
snmp-server host
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.
show license call-home pak pak-id
Cisco uBR10012 Universal Broadband Router
show license [call-home {pak pak-id}]
Note 
The Cisco License Call Home feature allows a Cisco router to communicate with the Cisco licensing infrastructure via the Internet and retrieve licensing information. This command requires that the router be connected to the Internet.
Syntax Description
pak
|
The product authorization key.
|
pak-id
|
The pak-id argument is a product authorization key sent via e-mail or regular mail by manufacturing to authorize software upgrades.
|
Command Modes
Privileged EXEC (#)
Command History
Release
|
Modification
|
12.4(15)XZ
|
This command was introduced.
|
12.4(20)T
|
This command was integrated into Cisco IOS Release 12.4(20)T.
|
12.2(33)SCC
|
This command was integrated into Cisco IOS Release 12.2(33)SCC on the Cisco uBR10012 Universal Broadband Router.
|
Usage Guidelines
This command requires the following:
•The router or switch must have an Internet connection and use HTTPS to connect to the Cisco licensing infrastructure. See the "HTTP 1.1 Web Server and Client" chapter in the Cisco IOS Network Management Configuration Guide, Release 12.4T, for the steps to set up a secure HTTP connection.
•Only certain platforms support the Cisco License Call Home feature and those devices must be running a Cisco IOS crypto K9 image.
•You must obtain the device certificate from the Cisco licensing infrastructure.
•You also need a CCO user login account.
Issuing the show license call-home command causes the following actions to occur:
1. The Cisco licensing infrastructure returns parsed XML content to the command line. The parsed content will have information about SKUs and feature names. The content may also contain warning messages.
2. The SKU information and any warning messages are displayed as formatted output on the router command line.
Cisco uBR10012 Universal Broadband Router
In the Cisco uBR10012 universal broadband router, call-home is used as an optional keyword 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 3XPXR9E7D30
Pak Fulfillment type: SINGLE
Feature name: gatekeeper Count: Uncounted
Platform Supported : 5400
Table 15 describes the significant fields shown in the display.
Table 15 show license call-home Field Descriptions
Field
|
Description
|
Pak Number
|
Product Authorization Key number, which is provided to customers when they order and purchase the right to use a feature set for a particular platform. The PAK serves as a receipt and is used as part of the process to obtain a license.
|
SKU Name
|
Stock Keeping Unit name, which maps to one or more Cisco software features.
|
Description
|
Description provided for SKU.
|
Ordered Qty
|
Quantity ordered.
|
Feature List
|
List of features.
|
Platform Supported
|
List of Cisco device platforms supported.
|
Related Commands
Command
|
Description
|
license call-home install
|
Installs a license using the Cisco License Call Home feature.
|
license call-home resend
|
Restores a lost license using the Cisco License Call Home feature.
|
license call-home revoke
|
Revokes and transfers a license using the Cisco License Call Home feature.
|
show license statistics
To display license statistics information, use the show license statistics command in privileged EXEC mode.
show license statistics
Cisco UBR10012 Universal Broadband Router
show license [statistics {subslot slot/subslot}]
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC (#)
Command History
Release
|
Modification
|
12.4(15)XZ
|
This command was introduced.
|
12.4(20)T
|
This command was integrated into Cisco IOS Release 12.4(20)T.
|
12.2(33)SCC
|
This command was integrated into Cisco IOS Release 12.2(33)SCC on the Cisco uBR10012 universal broadband router.
|
Examples
The following example shows a typical report from this command:
Router# show license statistics
Administrative statistics
Install duplicate count: 12
Swift value changed by user
Current Value : https://cisco.com/SWIFT/Licensing
Default Value : https://cisco.com/SWIFT/Licensing
Cisco UBR10012 Universal Broadband Router
The following example shows a sample output of show license statistics subslot 8/1 command executed on the Cisco UBR10012 Router:
Router# show license statistics subslot 8/1
Administrative statistics
Install duplicate count: 0
Table 16 describes the significant fields shown in the display.
Table 16 show license statistics Field Descriptions
Field
|
Description
|
Administrative statistics
|
•Install success count—Number of successful installations
•Install failure count—Number of failed installation attempts
•Install duplicate count—Number of duplicate installations
•Comment add count—Number of added comments
•Comment delete count—Number of deleted comments
•Clear count—Number of License Clear events
•Save count—Number of License Save events
•Save cred count—Number of License Save Credentials
|
Client statistics
|
•Request success count—Number of successful license requests
•Request failure count—Number of failed license requests
•Release count—Number of released licenses
•Global Notify count—Number of global notifications
|
SWIFT url status
|
•Current Value—Current SWIFT URL
•Default Value—Default SWIFT URL
|
Related Commands
Command
|
Description
|
debug license
|
Enables controlled debugging options in the Cisco software licensing module.
|
show license status
|
Displays license information for 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
class class
|
(Optional) Displays the subsystems of the specified class. Valid classes are driver, kernel, library, license, management, protocol, and registry.
|
name name
|
(Optional) Displays the specified subsystem. Use the asterisk character (*) as a wildcard at the end of the name to list all subsystems, starting with the specified characters.
|
Command Modes
Privileged EXEC (#)
Command History
Release
|
Modification
|
11.1
|
This command was introduced.
|
12.2(33)SRA
|
This command was integrated into Cisco IOS Release 12.2(33)SRA.
|
12.2(35)SE2
|
The license class was added, and this command was integrated into Cisco IOS Release 12.2(35)SE1.
|
12.4(20)T
|
This command was integrated into Cisco IOS Release 12.4(20)T.
|
Usage Guidelines
Use the show subsys command to confirm that all required features are in the running image.
Examples
Following is sample output from the show subsys command:
static_map Kernel 1.000.001
compress Kernel 1.000.001
alignment Kernel 1.000.002
ip_addrpool_sys Library 1.000.001
flash_services Library 1.000.001
ip_localpool_sys Library 1.000.001
nvram_common Driver 1.000.001
oc12suni Driver 1.000.001
Following is sample output from the show subsys command that includes the license class:
license_mgmt_local Management 1.000.001
license_admin_local Management 1.000.001
license_debug_core Management 1.000.001
license_test_ui Management 1.000.001
test_license_parser Management 1.000.001
license_ui Management 1.000.001
license_parser Management 1.000.001
license_registry Registry 1.000.001
license_client License 1.000.001
Table 17 describes the fields shown in the display.
Table 17 show subsys Field Descriptions
Field
|
Description
|
Name
|
Name of the subsystem.
|
Class
|
Class of the subsystem. Possible classes include Driver, Kernel, Library, License, Management, Protocol, Registry.
|
Version
|
Version of the subsystem.
|
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
subsystem
|
Name of the subsystem for a specified license.
|
Command Default
Subsystem information is not displayed.
Command Modes
User EXEC (>)
Privileged EXEC (#)
Command History
Release
|
Modification
|
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 for the IP base feature set:
Router# show subsys license ipbase
obfl_env_app Kernel 1.000.001
exception Kernel 1.000.001
xml_proxy_client Kernel 1.000.000
proto_counter Kernel 1.000.001
sched_ui Kernel 1.000.001
policy_manager Kernel 1.000.001
fib_table_trace Kernel 1.000.001
ifmibapi_access Kernel 1.000.000
xml_engine Kernel 1.000.000
fddi_mtu Kernel 1.000.001
fib_trace Kernel 1.000.001
qos_set Protocol 1.000.001
ipdiag Protocol 1.000.001
aaa_peruser Protocol 1.000.001
identity_cli Management 1.000.001
notification_log_mib Management 1.000.000
pagpmib Management 1.000.000
ifmib Management 1.000.000
rtty_chain Management 1.000.001
cdpmib Management 1.000.000
vlmem Management 1.000.000
psecure_registry Registry 1.000.001
ip_ios_registry Registry 1.000.001
sys_name_registry Registry 1.000.001
INIT SystemInit 2.000.001
tmpsys_ifs EHSA 1.000.001
hulc_fib_rf_ehsa EHSA 1.000.001
system_ifs EHSA 1.000.001
ifs_image_elf EHSA 1.000.001
nvram_common EHSA 1.000.001
ifs_image_ascii EHSA 1.000.001
sff8472 Pre-Driver 1.000.001
aggmgr Pre-Driver 1.000.000
ifindex_pers Pre-Driver 1.000.001
sff8472_fixed Pre-Driver 1.000.000
fib_rp_predriver Pre-Driver 1.000.001
system_capability Pre-Driver 1.000.001
fib_lc_predriver Pre-Driver 1.000.001
fib_ios_chain Pre-Driver 1.000.001
transceiver Pre-Driver 1.000.002
fib_ios_predriver Pre-Driver 1.000.001
license_client License 1.000.001
hulc_flash License 1.000.001
ios_licensing_image_application License 1.000.001
boot_upgrade License 1.000.001
hulc_universal_only License 1.000.001
Table 17 describes the fields shown in the display.
Table 18 show subsys license Field Descriptions
Field
|
Description
|
License level
|
Feature set for which the license is issued; for example, Advanced IP services, IP services, or IP base.
|
Name
|
Name of the subsystem.
|
Class
|
Class of the subsystem. Possible classes include Driver, Kernel, Library, License, Management, Protocol, Registry.
|
Version
|
Version of the subsystem.
|
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.
•The severity argument is an integer or string value that identifies the severity of an alarm. Integer values are from 1 to 4. String values are critical, major, minor, and informational. The default is 4, or informational. Severity levels are defined as follows:
–1—Critical. The condition affects service.
–2—Major. Immediate action is needed.
–3—Minor. Minor warning conditions.
–4—Informational. No action is required. This is the default.
•config—Controls configuration notifications, as defined in the CISCO-CONFIG-MAN-MIB (enterprise 1.3.6.1.4.1.9.9.43.2). The notification type is (1) ciscoConfigManEvent.
•dot1x—Enables IEEE 802.1x traps. This notification type is defined in the CISCO PAE MIB.
•ds0-busyout—Sends notification when the busyout of a DS0 interface changes state (Cisco AS5300 platform only). This notification is defined in the CISCO-POP-MGMT-MIB (enterprise 1.3.6.1.4.1.9.10.19.2), and the notification type is (1) cpmDS0BusyoutNotification.
•ds1-loopback—Sends notification when the DS1 interface goes into loopback mode (Cisco AS5300 platform only). This notification type is defined in the CISCO-POP-MGMT-MIB (enterprise 1.3.6.1.4.1.9.10.19.2) as (2) cpmDS1LoopbackNotification.
•dsp—Enables SNMP digital signal processing (DSP) traps. This notification type is defined in the CISCO-DSP-MGMT-MIB.
•dsp oper-state—Sends a DSP notification made up of both a DSP ID that indicates which DSP is affected and an operational state that indicates whether the DSP has failed or recovered.
|
| |
•entity—Controls Entity MIB modification notifications. This notification type is defined in the ENTITY-MIB (enterprise 1.3.6.1.2.1.47.2) as (1) entConfigChange.
|
| |
•hsrp—Controls Hot Standby Routing Protocol (HSRP) notifications, as defined in the CISCO-HSRP-MIB (enterprise 1.3.6.1.4.1.9.9.106.2). The notification type is (1) cHsrpStateChange.
|
| |
•ipmulticast—Controls IP multicast notifications.
|
| |
•license—Enables licensing notifications as traps or informs. The notifications are grouped into 3 categories that may be controlled individually by combining them with the license keyword, or as a group by using the license keyword by itself.
–deploy—Controls notifications generated as a result of install, clear or revoke license events.
–error—Controls notifications generated as a result of a problem with the license itself or usage of the license.
–imagelevel—Controls notifications related to the imagelevel of the license.
–usage—Controls usage notifications, related to the license.
|
| |
•modem-health—Controls modem-health notifications.
|
| |
•rsvp—Controls Resource Reservation Protocol (RSVP) flow change notifications.
|
| |
•tty—Controls TCP connection notifications.
|
| |
•xgcp—Sends External Media Gateway Control Protocol (XGCP) notifications. This notification is from the XGCP-MIB-V1SMI.my, and the notification is enterprise 1.3.6.1.3.90.2 (1) xgcpUpDownNotification.
Note For additional notification types, see the Related Commands table.
|
vrrp
|
(Optional) Specifies the Virtual Router Redundancy Protocol (VRRP).
|
Command Default
No notifications controlled by this command are sent.
Command Modes
Global configuration (config)
Command History
Release
|
Modification
|
10.3
|
This command was introduced.
|
12.0(2)T
|
The rsvp notification type was added in Cisco IOS Release 12.0(2)T.
|
12.0(3)T
|
The hsrp notification type was added in Cisco IOS Release 12.0(3)T.
|
12.0(24)S
|
This command was integrated into Cisco IOS Release 12.0(24)S.
|
12.2(14)SX
|
Support for this command was implemented on the Supervisor Engine 720.
|
12.2(18)S
|
This command was integrated into Cisco IOS Release 12.2(18)S.
|
12.2(17d)SXB
|
Support for this command on the Supervisor Engine 2 was integrated into Cisco IOS Release 12.2(17d)SXB.
|
12.3(11)T
|
The vrrp notification type was added in Cisco IOS Release 12.3(11)T.
|
12.4(4)T
|
Support for the alarms notification type and severity argument was added in Cisco IOS Release 12.4(4)T.
Support for the dsp and dsp oper-state notification types was added in Cisco IOS Release 12.4(4)T.
|
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.4(11)T
|
The dot1x notification type was added in Cisco IOS Release 12.4(11)T.
|
12.2(33)SRB
|
This command was integrated into Cisco IOS Release 12.2(33)SRB.
|
12.2SX
|
This command is supported in the Cisco IOS Release 12.2SX train. Support in a specific 12.2SX release of this train depends on your feature set, platform, and platform hardware.
|
12.2(33)SB
|
This command was integrated into Cisco IOS Release 12.2(33)SB.
|
12.4(20)T
|
Support for the license notification type was added in Cisco IOS Release 12.4(20)T.
|
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.
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 traps
Router(config)# snmp-server host myhost.cisco.com public
The following example shows how to configure an alarm severity threshold of 3:
Router# snmp-server enable traps alarms 3
The 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-state
The 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 1
cdspEnableOperStateNotification.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 bgp
Router(config)# snmp-server host user1 public isdn
The 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 traps
Router(config)# snmp-server host myhost.cisco.com informs version 2c public
The 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 hsrp
Router(config)# snmp-server host myhost.cisco.com traps version 2c public hsrp
The following example shows that VRRP will be used as the protocol to enable the traps:
Router(config)# snmp-server enable traps vrrp
Router(config)# snmp-server host myhost.cisco.com traps version 2c vrrp
The 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 dot1x
Router(config)# snmp-server host myhost.example.com traps public
Related Commands
Command
|
Description
|
snmp-server enable traps atm pvc
|
Enables ATM PVC SNMP notifications.
|
snmp-server enable traps atm pvc extension
|
Enables extended ATM PVC SNMP notifications.
|
snmp-server enable traps bgp
|
Enables BGP server state change SNMP notifications.
|
snmp-server enable traps calltracker
|
Enables Call Tracker callSetup and callTerminate SNMP notifications.
|
snmp-server enable traps envmon
|
Enables environmental monitor SNMP notifications.
|
snmp-server enable traps frame-relay
|
Enables Frame Relay DLCI link status change SNMP notifications.
|
snmp-server enable traps ipsec
|
Enables IPsec SNMP notifications.
|
snmp-server enable traps isakmp
|
Enables IPsec ISAKMP SNMP notifications.
|
snmp-server enable traps isdn
|
Enables ISDN SNMP notifications.
|
snmp-server enable traps memory
|
Enables memory pool and buffer pool SNMP notifications.
|
snmp-server enable traps mpls ldp
|
Enables MPLS LDP SNMP notifications.
|
snmp-server enable traps mpls traffic-eng
|
Enables MPLS TE tunnel state-change SNMP notifications.
|
snmp-server enable traps mpls vpn
|
Enables MPLS VPN specific SNMP notifications.
|
snmp-server enable traps repeater
|
Enables RFC 1516 hub notifications.
|
snmp-server enable traps snmp
|
Enables RFC 1157 SNMP notifications.
|
snmp-server enable traps syslog
|
Enables the sending of system logging messages via SNMP.
|
snmp-server host
|
Specifies whether you want the SNMP notifications sent as traps or informs, the version of SNMP to use, the security level of the notifications (for SNMPv3), and the destination host (recipient) for the notifications.
|
snmp-server informs
|
Specifies inform request options.
|
snmp-server trap-source
|
Specifies the interface (and hence the corresponding IP address) from which an SNMP trap should originate.
|
snmp trap illegal-address
|
Issues an SNMP trap when a MAC address violation is detected on an Ethernet hub port of a Cisco 2505, Cisco 2507, or Cisco 2516 router.
|
vrrp shutdown
|
Disables a VRRP group.
|
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] [traps | informs] [version {1 | 2c | 3
[auth | noauth | priv]} [community-string [udp-port port] [notification-type]]
no snmp-server host {hostname | ip-address} [vrf vrf-name] [traps | informs] [version {1 | 2c | 3
[auth | noauth | priv]} [community-string [udp-port port] [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
|
IP 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.
|
traps
|
(Optional) Specifies that notifications should be sent as traps. This is the default.
|
informs
|
(Optional) Specifies that notifications should be sent as informs.
|
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:
•1—SNMPv1.
•2c—SNMPv2C.
•3—SNMPv3. The most secure model because it allows packet encryption with the priv keyword. The default is noauth.
One of the following three optional security level keywords can follow the 3 keyword:
–auth—Enables Message Digest 5 (MD5) and Secure Hash Algorithm (SHA) packet authentication.
–noauth—Specifies that the noAuthNoPriv security level applies to this host. This is the default security level for SNMPv3.
–priv—Enables Data Encryption Standard (DES) packet encryption (also called "privacy").
|
community-string
|
Password-like community string is sent with the notification operation.
Note You can set this string using the snmp-server host command by itself, but Cisco recommends that you define the string using the snmp-server community command prior to using the snmp-server host command.
Note The "at" sign (@) is used for delimiting the context information.
|
udp-port
|
(Optional) Specifies that SNMP traps or informs are to be sent to an NMS host.
|
port
|
(Optional) 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. The notification type can be one or more of the following keywords:
•bgp—Sends Border Gateway Protocol (BGP) state change notifications.
•calltracker—Sends Call Tracker call-start/call-end notifications.
•cef — Sends notifications related to Cisco Express Forwarding.
•config—Sends configuration change notifications.
•cpu—Sends CPU-related notifications.
•director—Sends notifications related to DistributedDirector.
•dspu—Sends downstream physical unit (DSPU) notifications.
•eigrp—Sends Enhanced Interior Gateway Routing Protocol (EIGRP) stuck-in-active (SIA) and neighbor authentication failure notifications.
•entity—Sends Entity MIB modification notifications.
•envmon—Sends Cisco enterprise-specific environmental monitor notifications when an environmental threshold is exceeded.
•flash—Sends flash media insertion and removal notifications.
•frame-relay—Sends Frame Relay notifications.
•hsrp—Sends Hot Standby Routing Protocol (HSRP) notifications.
•iplocalpool—Sends IP local pool notifications.
•ipmobile—Sends Mobile IP notifications.
•ipsec—Sends IP Security (IPsec) notifications.
•isdn—Sends ISDN notifications.
•l2tun-pseudowire-status—Sends pseudowire state change notifications.
•l2tun-session—Sends Layer 2 tunneling session notifications.
•license—Sends licensing notifications as traps or informs.
•llc2—Sends Logical Link Control, type 2 (LLC2) notifications.
•memory—Sends memory pool and memory buffer pool notifications.
•mpls-ldp—Sends Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) notifications indicating status changes in LDP sessions.
|
| |
•mpls-traffic-eng—Sends MPLS traffic engineering notifications indicating changes in the status of MPLS traffic engineering tunnels.
•mpls-vpn—Sends MPLS VPN notifications.
•nhrp—Sends Next Hop Resolution Protocol (NHRP) notifications.
•ospf—Sends Open Shortest Path First (OSPF) sham-link notifications.
•pim—Sends Protocol Independent Multicast (PIM) notifications.
•repeater—Sends standard repeater (hub) notifications.
•rsrb—Sends remote source-route bridging (RSRB) notifications.
•rsvp—Sends Resource Reservation Protocol (RSVP) notifications.
•rtr—Sends Response Time Reporter (RTR) notifications.
•sdlc—Sends Synchronous Data Link Control (SDLC) notifications.
•sdllc—Sends SDLC Logical Link Control (SDLLC) notifications.
•snmp—Sends any enabled RFC 1157 SNMP linkUp, linkDown, authenticationFailure, warmStart, and coldStart notifications.
Note To enable RFC 2233 compliant link up/down notifications, you should use the snmp server link trap command.
•srp—Sends Spatial Reuse Protocol (SRP) notifications.
•stun—Sends serial tunnel (STUN) notifications.
•syslog—Sends error message notifications (Cisco Syslog MIB). Use the logging history level command to specify the level of messages to be sent.
•tty—Sends Cisco enterprise-specific notifications when a TCP connection closes.
•voice—Sends SNMP poor quality of voice traps, when used with the snmp enable peer-trap poor qov command.
•vrrp—Sends Virtual Router Redundancy Protocol (VRRP) notifications.
•vsimaster—Sends Virtual Switch Interface (VSI) Master notifications.
•x25—Sends X.25 event notifications.
|
Command Default
This command is disabled by default. A recipient is not specified to receive notifications.
Command Modes
Global configuration (config)
Command History
Release
|
Modification
|
10.0
|
This command was introduced.
|
Cisco IOS Release 12 Mainline/T Train
|
12.0(3)T
|
•The version 3 [auth | noauth | priv] syntax was added as part of the SNMPv3 Support feature.
•The hsrp notification-type keyword was added.
•The voice notification-type keyword was added.
|
12.1(3)T
|
The calltracker notification-type keyword was added for the Cisco AS5300 and AS5800 platforms.
|
12.2(2)T
|
•The vrf vrf-name keyword/argument combination was added.
•The ipmobile notification-type keyword was added.
•Support for the vsimaster notification-type keyword was added for the Cisco 7200 and Cisco 7500 series.
|
12.2(4)T
|
•The pim notification-type keyword was added.
•The ipsec notification-type keyword was added.
|
12.2(8)T
|
•The mpls-traffic-eng notification-type keyword was added.
•The director notification-type keyword was added.
|
12.2(13)T
|
•The srp notification-type keyword was added.
•The mpls-ldp notification-type keyword was added.
|
12.3(2)T
|
•The flash notification-type keyword was added.
•The l2tun-session notification-type keyword was added.
|
12.3(4)T
|
•The cpu notification-type keyword was added.
•The memory notification-type keyword was added.
•The ospf notification-type keyword was added.
|
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
|
•Support for SNMP over IPv6 transport was integrated into Cisco IOS Release 12.3(14)T. Either an IP or IPv6 Internet address can be specified as the hostname argument.
•The eigrp notification-type keyword was added.
|
12.4(20)T
|
The license notification-type keyword was added.
|
15.0(1)M
|
This command was modified. The nhrp notification-type keyword was added.
|
Cisco IOS Release 12.0S
|
12.0(17)ST
|
The mpls-traffic-eng notification-type keyword was integrated into Cisco IOS Release 12.0(17)ST.
|
12.0(21)ST
|
The mpls-ldp notification-type keyword was integrated into Cisco IOS Release 12.0(21)ST.
|
12.0(22)S
|
•All features in the Cisco IOS Release 12.0ST train were integrated into Cisco IOS Release 12.0(22)S.
•The mpls-vpn notification-type keyword was added.
|
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
|
•Support for SNMP over IPv6 transport was added. Either an IP or IPv6 Internet address can be specified as the hostname argument.
•The vrf vrf-name keyword argument pair was integrated into Cisco IOS Release 12.0(27)S to support multiple Lightweight Directory Protocol (LDP) contexts for VPNs.
|
12.0(31)S
|
The l2tun-pseudowire-status notification-type keyword was added.
|
Release 12.2S
|
|
12.2(18)S
|
This command was integrated into Cisco IOS Release 12.2(18)S.
|
12.2(25)S
|
•The cpu notification-type keyword was added.
•The memory notification-type keyword was added.
|
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.
|
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 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 will be the same as 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.
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 a 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 a 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 VRF. The VRF defines a VPN membership of a user so data is stored using the VPN.
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 19 maps some examples of snmp-server enable traps commands to the keywords used in the snmp-server host command.
Table 19 SNMP-server enable traps Commands and Corresponding Notification Keywords
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-eng1
|
mpls-traffic-eng
|
snmp-server enable traps mpls vpn
|
mpls-vpn
|
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 10
Router(config)# snmp-server host 192.20.2.160 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 192.30.2.160 using the community string public:
Router(config)# snmp-server enable traps snmp
Router(config)# snmp-server enable traps envmon
Router(config)# snmp-server host 192.30.2.160 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 company.com over the VRF named trap-vrf using the community string public:
Router(config)# snmp-server host company.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 192.40.3.130 using the community string public:
Router(config)# snmp-server enable traps cef
Router(config)# snmp-server host 192.40.3.130 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 192.40.3.130 using the community string public:
Router(config)# snmp-server enable traps nhrp
Router(config)# snmp-server host 192.40.3.130 traps version 2c public nhrp
Related Commands
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 trap 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.
|
