-
Cisco IOS Network Management Command Reference
-
Introduction
-
absolute through action snmp-trap
-
action string compare through buffers tune automatic
-
calendar set through clock update-calendar
-
cns aaa authentication through discover (cns)
-
emm through event manager scheduler script
-
event manager scheduler suspend through hw-module logging onboard (Cat 6K)
-
idle-timeout (WSMA) through ip director server weights
-
ip dns server through kron policy-list
-
line-cli through logging userinfo
-
major rising through ntp update-calendar
-
object id (action notification) through rmon queuesize
-
sample (expression) through show ethernet oam status
-
show event manager detector through show event manager session cli username
-
show facility-alarm through show ntp status
-
show odm-format through show rmon topn
-
show snmp through snmp mib event sample
-
snmp mib event trigger owner through snmp-server enable informs
-
snmp-server enable traps through snmp-server enable traps ospf cisco-specific retransmit
-
snmp-server enable traps ospf cisco-specific state-change through snmp-server enable traps voice poor-qov
-
snmp-server engineID local through snmp trap link-status
-
sntp broadcast client through xsm vdm
-
Feedback
Table Of Contents
snmp-server file-transfer access-group
snmp-server manager session-timeout
snmp-server trap authentication unknown-context
snmp-server trap authentication vrf
snmp-server trap link switchover
snmp-server trap-authentication
snmp-server engineID local
To specify the Simple Network Management Protocol (SNMP) engine ID on the local device, use the snmp-server engineID local command in global configuration mode. To remove the configured engine ID, use the no form of this command.
snmp-server engineID local engineid-string
no snmp-server engineID local engineid-string
Syntax Description
Command Default
An SNMP engine ID is generated automatically but is not displayed or stored in the running configuration. You can display the default or configured engine ID by using the show snmp engineID command.
Command Modes
Global configuration
Command History
Usage Guidelines
The SNMP engine ID is a unique string used to identify the device for administration purposes. You do not need to specify an engine ID for the device; a default string is generated using Cisco's enterprise number (1.3.6.1.4.1.9) and the mac address of the first interface on the device. For further details on the SNMP engine ID, see RFC 2571.
If you wish to specify your own ID, note that you need not specify the entire 24-character engine ID if it contains trailing zeros. Specify only the portion of the Engine ID up until the point where only zeros remain in the value. For example, to configure an engine ID of 123400000000000000000000, you can specify snmp-server engineID local 1234.
Changing the value of snmpEngineID has important side-effects. A user's password (entered on the command line) is converted to an MD5 or SHA security digest. This digest is based on both the password and the local engine ID. The command line password is then destroyed, as required by RFC 2274. Because of this deletion, if the local value of engineID changes, the security digests of SNMPv3 users will be invalid, and the users will have to be reconfigured.
Similar restrictions require the reconfiguration of community strings when the engine ID changes. A remote engine ID is required when an SNMPv3 inform is configured. The remote engine ID is used to compute the security digest for authenticating and encrypting packets sent to a user on the remote host.
Related Commands
snmp-server engineID remote
To specify the Simple Network Management Protocol (SNMP) engine ID of a remote SNMP device, use the snmp-server engineID remote command in global configuration mode. To remove a specified SNMP engine ID from the configuration, use the no form of this command.
snmp-server engineID remote {ipv4-ip-address | ipv6 address}[udp-port udp-port-number] [vrf vrf-name] engineid-string
no snmp-server engineID remote {ipv4-ip-address | ipv6 address} [udp-port udp-port-number] [vrf vrf-name] engineid-string
Syntax Description
Command Default
UDP port: 161
Command Modes
Global configuration
Command History
Usage Guidelines
Specifying the entire 24-character engine ID if it contains trailing zeros is not required. Specify only the portion of the engine ID up to where the trailing zeros start. For example, to configure an engine ID of 123400000000000000000000, specify the value 1234 as the engineid-string argument.
A remote engine ID is required when an SNMP version 3 inform is configured. The remote engine ID is used to compute the security digest for authenticating and encrypting packets sent to a user on the remote host.
Examples
The following example specifies the SNMP engine ID and configures the VRF name traps-vrf for SNMP communications with the remote device at 172.16.20.3:
Router(config)# snmp-server engineID remote 172.16.20.3 vrf traps-vrf 80000009030000B064EFE100Related Commands
snmp-server file-transfer access-group
To associate an access list to the transfer protocols TFTP, FTP, Remote Copy Protocol (RCP), Secure Copy Protocol (SCP), and Secured File Transfer Protocol (SFTP), use the snmp-server file-transfer access-group command in global configuration mode. To disassociate an access list, use no form of this command.
snmp-server file-transfer access-group {acl-number | acl-name} [protocol p-name]
no snmp-server file-transfer access-group {acl-number | acl-name}
Syntax Description
Command Default
If a protocol is not specified, all protocols are associated with the access list.
Command Modes
Global configuration
Command History
12.4(12)
This command was introduced.
This command replaces the snmp-server tftp-server-list command.
Usage Guidelines
The snmp-server tftp-server-list command is still supported in Cisco IOS software, but if it is configured as snmp-server tftp-server-list 10, it will be substituted with the snmp-server file-transfer access-group 10 protocol tftp command.
Use the snmp-server file-transfer access-group command to restrict configuration transfers that are initiated via Simple Network Management Protocol (SNMP). You can restrict transfers for specific transfer protocols by associating an access list to the protocol.
Examples
The following example associates access group 10 to the transfer protocols FTP and RCP:
Router(config)# snmp-server file-transfer access-group 10 protocol ftpRouter(config)# snmp-server file-transfer access-group 10 protocol rcpRelated Commands
snmp-server tftp-server-list
Associates TFTP servers used via SNMP controlled TFTP operations to the servers specified in an access list.
snmp-server group
To configure a new Simple Network Management Protocol (SNMP) group, use the snmp-server group command in global configuration mode. To remove a specified SNMP group, use the no form of this command.
snmp-server group group-name {v1 | v2c | v3 {auth | noauth | priv}} [context context-name] [read read-view] [write write-view] [notify notify-view] [access [ipv6 named-access-list] [acl-number | acl-name]]
no snmp-server group group-name {v1 | v2c | v3 {auth | noauth | priv}} [context context-name]
Syntax Description
Command Default
No SNMP server groups are configured.
Command Modes
Global configuration (config)
Command History
Usage Guidelines
When a community string is configured internally, two groups with the name public are autogenerated, one for the v1 security model and the other for the v2c security model. Similarly, deleting a community string will delete a v1 group with the name public and a v2c group with the name public.
No default values exist for authentication or privacy algorithms when you configure the snmp-server group command. Also, no default passwords exist. For information about specifying a Message Digest 5 (MD5) password, see the documentation of the snmp-server user command.
Configuring Notify Views
The notify-view option is available for two reasons:
•
If a group has a notify view that is set using SNMP, you may need to change the notify view.
•
Specifying a notify view when configuring an SNMP group is not recommended, for the following reasons:
•
•
Instead of specifying the notify view for a group as part of the snmp-server group command, use the following commands in the order specified:
1.
2.
3.
SNMP Contexts
SNMP contexts provide VPN users with a secure way of accessing MIB data. When a VPN is associated with a context, that VPN's specific MIB data exists in that context. Associating a VPN with a context enables service providers to manage networks with multiple VPNs. Creating and associating a context with a VPN enables a provider to prevent the users of one VPN from accessing information about users of other VPNs on the same networking device.
Use this command with the context context-name keyword and argument to associate a read, write, or notify SNMP view with an SNMP context.
Examples
Create an SNMP Group
The following example shows how to create the SNMP server group "public," allowing read-only access for all objects to members of the standard named access list "lmnop":
Router(config)# snmp-server group public v2c access lmnopRemove an SNMP Server Group
The following example shows how to remove the SNMP server group "public" from the configuration:
Router(config)# no snmp-server group public v2cAssociate an SNMP Server Group with Specified Views
The following example shows SNMP context "A" associated with the views in SNMPv2c group "GROUP1":
Router(config)# snmp-server context ARouter(config)# snmp mib community commARouter(config)# snmp mib community-map commA context A target-list commAVpnRouter(config)# snmp-server group GROUP1 v2c context A read viewA write viewA notify viewBRelated 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 in the "Usage Guidelines" 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 modified. 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 that 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 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 126 maps some examples of snmp-server enable traps commands to the keywords used in the snmp-server host command.
Table 126 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
snmp-server inform
To specify inform request options, use the snmp-server inform command in global configuration mode. To return settings to their default values, use the no form of this command.
snmp-server inform [pending pending] [retries retries] [timeout seconds]
no snmp-server inform [pending pending] [retries retries] [timeout seconds]
Syntax Description
Command Default
Inform requests are resent three times. Informs are resent after 30 seconds if no response is received. The maximum number of informs waiting for acknowledgment at any one time is 25.
Command Modes
Global configuration (config)
Command History
Examples
The following example shows how to increase the pending queue size when several informs drop:
Router(config)# snmp-server inform pending 50The following example shows how to increase the default timeout when you send informs over slow network links. Because informs will remain in the queue longer than other types of messages, you also may need to increase the pending queue size.
snmp-server inform timeout 60 pending 40The following example shows how to decrease the default timeout when you send informs over very fast links:
Router(config)# snmp-server inform timeout 5The following example shows how to increase the retry count when you send informs over unreliable links. Because informs will remain in the queue longer than other types of messages, you may need to increase the pending queue size.
Router(config)# snmp-server inform retries 10 pending 45Related Commands
snmp-server ip dscp
To set the IP Differentiated Services Code Point (DSCP) value for Simple Network Management Protocol (SNMP) traffic, use the snmp-server ip dscp command in global configuration mode. To disable the configured value, use the no form of this command.
snmp-server ip dscp value
no snmp-server ip dscp value
Syntax Description
value
The IP DSCP value to apply to SNMP traffic. Valid values for IP DSCP are 0 through 63. The default is 0.
Command Default
The IP DSCP default value for SNMP traffic is 0.
Command Modes
Global config
Command History
12.0(26)S
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 specify an IP DSCP value to give SNMP traffic higher or lower priority in your network.
The following example shows how to set the IP DSCP value to 45:
Router(config)# snmp-server ip dscp 45Related Commands
snmp-server ip precedence
To set the IP Precedence value for Simple Network Management Protocol (SNMP) traffic, use the snmp-server ip precedence command in global configuration mode. To disable the configured value, use the no form of this command.
snmp-server ip precedence value
no snmp-server ip precedence value
Syntax Description
value
The IP Precedence value to apply to SNMP traffic. Valid values for IP Precedence are 0 through 7. The default is 0.
Command Default
The IP Precedence default value for SNMP traffic is 0.
Command Modes
Global config.
Command History
12.0(26)S
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 specify an IP Precedence value to give SNMP traffic higher or lower priority in your network.
Examples
The following example shows how to set the IP Precedence value to 7:
Router(config)# snmp-server ip precedence 7Related Commands
snmp-server location
To set the system location string, use the snmp-server location command in global configuration mode. To remove the location string, use the no form of this command.
snmp-server location text
no snmp-server location
Syntax Description
Command Default
No system location string is set.
Command Modes
Global configuration
Command History
Examples
The following example shows how to set a system location string:
Router(config)# snmp-server location Building 3/Room 214Related Commands
show snmp location
Displays the SNMP system location string.
snmp-server contact
Sets the system contact (sysContact) string.
snmp-server manager
To start the Simple Network Management Protocol (SNMP) manager process, use the snmp-server manager command in global configuration mode. To stop the SNMP manager process, use the no form of this command.
snmp-server manager
no snmp-server manager
Syntax Description
This command has no arguments or keywords.
Command Default
Disabled
Command Modes
Global configuration (config)
Command History
Usage Guidelines
The SNMP manager process sends SNMP requests to agents and receives SNMP responses and notifications from agents. When the SNMP manager process is enabled, the router can query other SNMP agents and process incoming SNMP traps.
Most network security policies assume that routers will be accepting SNMP requests, sending SNMP responses, and sending SNMP notifications. With the SNMP manager functionality enabled, the router may also be sending SNMP requests, receiving SNMP responses, and receiving SNMP notifications. The security policy implementation may need to be updated prior to enabling this functionality.
SNMP requests are typically sent to UDP port 161. SNMP responses are typically sent from UDP port 161. SNMP notifications are typically sent to UDP port 162.
Examples
The following example shows how to enable the SNMP manager process:
Router(config)# snmp-server managerRelated Commands
snmp-server manager session-timeout
To set the amount of time before a nonactive session is destroyed, use the snmp-server manager session-timeout command in global configuration mode. To return the value to its default, use the no form of this command.
snmp-server manager session-timeout seconds
no snmp-server manager session-timeout
Syntax Description
Command Default
Idle sessions time out after 600 seconds (10 minutes).
Command Modes
Global configuration (config)
Command History
Usage Guidelines
Sessions are created when the SNMP manager in the router sends SNMP requests, such as inform requests, to a host or receives SNMP notifications from a host. One session is created for each destination host. If there is no further communication between the router and host within the session timeout period, the session will be deleted.
The router tracks statistics, such as the average round-trip time required to reach the host, for each session. Using the statistics for a session, the SNMP manager in the router can set reasonable timeout periods for future requests, such as informs, for that host. If the session is deleted, all statistics are lost. If another session with the same host is later created, the request timeout value for replies will return to the default value.
However, sessions consume memory. A reasonable session timeout value should be large enough such that regularly used sessions are not prematurely deleted, yet small enough such that irregularly used, or one-shot sessions, are purged expeditiously.
Examples
The following example shows how to set the session timeout to a larger value than the default:
Router(config)# snmp-server managerRouter(config)# snmp-server manager session-timeout 1000Related Commands
show snmp pending
Displays the current set of pending SNMP requests.
show snmp sessions
Displays the current SNMP sessions.
snmp-server manager
Starts the SNMP manager process.
snmp-server packetsize
To establish control over the largest Simple Network Management Protocol (SNMP) packet size permitted when the SNMP server is receiving a request or generating a reply, use the snmp-server packetsize command in global configuration mode. To restore the default value, use the no form of this command.
snmp-server packetsize byte-count
no snmp-server packetsize
Syntax Description
Command Default
Packet size is not configured.
Command Modes
Global configuration
Command History
Examples
The following example establishes a packet filtering of a maximum size of 1024 bytes:
Router(config)# snmp-server packetsize 1024Related Commands
snmp-server queue-length
Establishes the message queue length for each trap host.
snmp-server queue-length
To establish the message queue length for each trap host, use the snmp-server queue-length command in global configuration mode.
snmp-server queue-length length
Syntax Description
length
Integer that specifies the number of trap events that can be held before the queue must be emptied. The default is 10.
Command Default
The queue length is set to 10.
Command Modes
Global configuration
Command History
Usage Guidelines
This command defines the length of the message queue for each trap host. When a trap message is successfully transmitted, Cisco IOS software will continue to empty the queue but never faster than at a rate of four trap messages per second.
During device bootup, some traps could be dropped because of trap queue overflow on the device. If you think that traps are being dropped, you can increase the size of the trap queue (for example, to 100) to determine if traps can then be sent during bootup.
Examples
The following example shows how to set the Simple Network Management Protocol (SNMP) notification queue to 50 events:
Router(config)# snmp-server queue-length 50Related Commands
snmp-server packetsize
Establishes control over the largest SNMP packet size permitted when the SNMP server is receiving a request or generating a reply.
snmp-server queue-limit
To establish the message queue size for various queues, use the snmp-server queue-limit command in global configuration mode. To disable the configured settings, use the no form of this command.
snmp-server queue-limit {dispatcher | engine | notification-host} queue-length
no snmp-server queue-limit {dispatcher | engine | notification-host}
Syntax Description
Command Default
By default, message queue size is not set.
Command Modes
Global configuration (config)
Command History
Usage Guidelines
Use the snmp-server queue-limit command to set the message queue size for different queues. Using this command you can resize the queue for dispatcher, engine, and host traps.
Examples
The following example shows how to set the message queue length of each notification host to 50:
Router(config)# snmp-server queue-limit notification-host 50Related Commands
snmp-server queue-length
Establishes the message queue length for each trap host.
snmp-server source-interface
To specify the interface from which a Simple Network Management Protocol (SNMP) trap originates the informs or traps, use the snmp-server source-interface command in global configuration mode. To remove the source designation, use the no form of this command.
snmp-server source-interface {traps | informs} interface
no snmp-server source-interface {traps | informs} [interface]
Syntax Description
traps
Specifies SNMP traps.
informs
Specifies SNMP informs.
interface
The interface type and the module and port number of the source interface.
Command Default
No interface is designated.
Command Modes
Global configuration (config)
Command History
Usage Guidelines
This command replaced the snmp-server trap-source command.
Note
The source interface must have an IP address. Enter the interface argument in the following format: interface-type module/port.
An SNMP trap or inform sent from a Cisco SNMP server has a notification IP address of the interface it went out of at that time. Use this command to monitor notifications from a particular interface.
Examples
The following example shows how to specify that Gigabit Ethernet interface 5/2 is the source for all informs:
snmp-server source-interface informs gigabitethernet5/2The following example shows how to specify that the Gigabit Ethernet interface 5/3 is the source for all traps:
snmp-server source-interface traps gigabitethernet5/3The following example shows how to remove the source designation for all traps for a specific interface:
no snmp-server source-interface traps gigabitethernet5/3Related Commands
snmp-server system-shutdown
To use the Simple Network Management Protocol (SNMP) message reload feature, the router configuration must include the snmp-server system-shutdown command in global configuration mode. To prevent an SNMP system-shutdown request (from an SNMP manager) from resetting the Cisco agent, use the no form of this command.
snmp-server system-shutdown
no snmp-server system-shutdown
Syntax Description
This command has no arguments or keywords.
Command Default
This command is not included in the configuration file.
Command Modes
Global configuration
Command History
Examples
The following example enables the SNMP message reload feature:
Router(config)# snmp-server system-shutdownsnmp-server tftp-server-list
Note
To limit the TFTP servers used via Simple Network Management Protocol (SNMP) controlled TFTP operations (saving and loading configuration files) to the servers specified in an access list, use the snmp-server tftp-server-list command in global configuration mode. To disable this function, use the no form of this command.
snmp-server tftp-server-list {acl-number | acl-name}
no snmp-server tftp-server-list {acl-number | acl-name}
Syntax Description
acl-number
Integer from 1 to 99 that specifies a standard access control list (standard ACL).
acl-name
String (not to exceed 64 characters) that specifies a standard ACL.
Command Default
Disabled
Command Modes
Global configuration
Command History
Examples
The following example shows how to limit the TFTP servers that can be used for saving and loading configuration files via SNMP to the servers specified in the standard named access list lmnop:
Router(config)# snmp-server tftp-server-list lmnopThe following example shows how to limit the TFTP servers that can be used for copying configuration files via SNMP to the servers in access list 44:
Router(config)# snmp-server tftp-server-list 44snmp-server trap authentication unknown-context
To enable the Simple Network Management Protocol (SNMP) authorization failure (authFail) traps during an unknown context error, use the snmp-server trap authentication unknown-context command in global configuration mode. To disable the authFail traps, use the no form of this command.
snmp-server trap authentication unknown-context
no snmp-server trap authentication unknown-context
Syntax Description
This command has no arguments or keywords.
Defaults
No authFail traps are generated.
Command Modes
Global configuration (config)
Command History
Examples
The following example shows how to enable the authorization failure traps during an unknown context error:
Router(config)# snmp-server trap authentication unknown-contextThe following example shows how to disable the authorization failure traps during an unknown context error:
Router(config)# no snmp-server trap authentication unknown-contextsnmp-server trap authentication vrf
To enable virtual private network (VPN) routing and forwarding (VRF) instance context authentication notifications, use the snmp-server trap authentication vrf command in global configuration mode. To suppress authentication notifications for Simple Network Management Protocol (SNMP) packets dropped due specifically to VRF context mismatches while keeping all other SNMP authentication notifications enabled, use the no form of this command.
snmp-server trap authentication vrf
no snmp-server trap authentication vrf
Syntax Description
This command has no arguments or keywords.
Command Default
No VRF-specific authentication notifications are enabled when SNMP authentication notifications are not enabled.
Command Modes
Global configuration (config)
Command History
Usage Guidelines
The snmp-server enable traps snmp authentication command controls SNMP authentication traps and the no form of this command disables all SNMP authentication failure notifications. The snmp-server trap authentication vrf command provides more granular control of these notifications.
With context-based MIB access, SNMP requests on each VRF are tied to a specific context. This context is used for access control. If SNMP contexts are configured for VPNs, any SNMP request not matching the configured context will generate an SNMP authentication failure notification.The no snmp-server trap authentication vrf command allows you to suppress the authentication failure notifications that are specific to these VRF contexts, while keeping all other SNMP authentication failure notifications enabled.
The no snmp-server trap authentication vrf command has no effect if the snmp-server enable traps snmp authentication command has not been configured..
Examples
The following example shows how to enable a router to send SNMP authentication traps to host myhost.cisco.com using the community string public while disabling all VRF authentication traps:
Router(config)# snmp-server enable traps snmp authenticationRouter(config)# no snmp-server trap authentication vrfRouter(config)# snmp-server host myhost.cisco.com publicRelated Commands
snmp-server enable traps snmp
Enables the sending of RFC 1157 SNMP notifications.
snmp-server host
Specifies the recipient of an SNMP notification operation.
snmp-server trap link
To enable linkUp/linkDown Simple Network Management Protocol (SNMP) traps that are compliant with RFC2233, use the snmp-server trap link command in global configuration mode. To disable IETF- compliant functionality and revert to the default Cisco implementation of linkUp/linkDown traps, use the no form of this command.
snmp-server trap link ietf
no snmp-server trap link ietf
Syntax Description
ietf
Notifies the command parser to link functionality of SNMP linkUp/linkDown traps to the Internet Engineering Task Force (IETF) standard (instead of the previous Cisco implementation).
Command Default
This command is disabled by default.
Command Modes
Global configuration
Command History
Usage Guidelines
The snmp-server trap link ietf command is used to configure your router to use the RFC2233 IETF standards-based implementation of linkUp/linkDown traps. This command is disabled by default to allow you to continue using the earlier Cisco implementation of linkUp/linkDown traps if you so choose.
However, please note that when using the default Cisco object definitions, linkUp/linkDown traps are not generated correctly for sub-interfaces. In the default implementation an arbitrary value is used for the locIfReason object in linkUp/linkDown traps for sub-interfaces, which may give you unintended results. This is because the locIfReason object is not defined for sub-interfaces in the current Cisco implementation, which uses OLD-CISCO-INTERFACES-MIB.my.
If you do not enable this functionality, the link trap varbind list will consist of {ifIndex, ifDescr, ifType, locIfReason}. After you enable this functionality with the snmp-server trap link ietf command, the varbind list will consist of {inIndex, ifAdminStatus,ifOperStatus, if Descr, ifType}. The locIfReason object will also be conditionally included in this list depending on whether meaningful information can be retrieved for that object. A configured sub-interface will generate retrievable information. On non-HWIDB interfaces, there will be no defined value for locIfReason, so it will be omitted from the trap message.
Examples
The following example shows the enabling of the RFC 2233 linkUp/linkDown traps, starting in privileged EXEC mode:
Router# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# snmp-server trap link ietfRouter(config)# endRouter# more system:running configuration...!snmp-server engineID local 00000009000000A1616C2056snmp-server community public ROsnmp-server community private RWsnmp-server trap link ietf!...Related Commands
debug snmp packets
Displays information about every SNMP packet sent or received by the router for the purposes of troubleshooting.
snmp-server trap link switchover
To enable sending a linkdown trap followed by a linkup trap for every interface in the switch during a switch failover, use the snmp-server trap link switchover command in global configuration mode. To disable linkdown during a switch failover, use the no form of this command.
snmp-server trap link switchover
no snmp-server trap link switchover
Syntax Description
This command has no arguments or keywords.
Command Default
This command is enabled by default.
Command Modes
Global configuration
Command History
12.2(18)SXF2
This command was introduced on the Supervisor Engine 720 and the Supervisor Engine 32.
Usage Guidelines
By default, no link traps are generated during a switchover.
Examples
This example shows how to enable sending a linkdown trap followed by a linkup trap for every interface in the switch during a switch failover:
snmp-server trap link switchoverThis example shows how to disable linkdown followed by a linkup trap for every interface in the switch during a switch failover:
no snmp-server trap link switchoversnmp-server trap retry
To define the number of times the Simple Network Management Protocol (SNMP) agent on a device tries to find a route before it sends traps, use the snmp-server trap retry command in global configuration mode.
snmp-server trap retry number
Syntax Description
number
Integer from 0 to 10 that sets the number of times the message will be retransmitted. The default is 3.
Command Default
Messages are not retransmitted.
Command Modes
Global configuration
Command History
Usage Guidelines
The SNMP agent looks for a configured route in the system before sending a trap out to a destination. If a route is not present, traps are queued in the trap queue and discarded when the queue becomes full. When the snmp-server trap retry command is configured, the route search retry number tells the agent how many times to look for the route before sending the trap out.
Configuring the snmp-server trap retry command also ensures that policy-based routing traps are sent and not discarded. Policy-based traps must be sent immediately and routes are not needed. The number of retries must be set to 0 so that policy-based traps are sent immediately.
Examples
The following example shows how to set the number of times a SNMP agent on a device tries to find a route to 10:
Router(config)# snmp-server trap retry 10Related Commands
snmp-server trap timeout
Defines an interval of time between retransmissions of traps on a retransmission queue.
snmp-server trap timeout
To define an interval of time between retransmissions of trap messages on a retransmission queue, use the snmp-server trap timeout command in global configuration mode.
snmp-server trap timeout seconds
Syntax Description
seconds
Integer from 1 to 1000 that sets the interval, in seconds, for resending messages. The default is 30.
Command Default
This command is disabled.
Command Modes
Global configuration
Command History
12.2(33)SRA
This command was introduced. This command replaces the snmp-server trap-timeout command in Cisco IOS Release 12.2SR only.
Usage Guidelines
Before a trap is sent, the SNMP agent looks for a route to the destination address. If there is no known route, the trap is saved in a retransmission queue. Issue the snmp-server trap timeout command to configure the number of seconds between retransmission attempts.
Examples
The following example shows how to set an interval of 20 seconds between retransmissions of traps:
Router(config)# snmp-server trap timeout 20Related Commands
snmp-server host
Specifies the recipient of an SNMP notification operation.
snmp-server queue-length
Establishes the message queue length for each trap host.
snmp-server trap-authentication
The snmp-server trap-authentication command has been replaced by the snmp-server enable traps snmp authentication command. See the description of the snmp-server enable traps snmp command in this chapter for more information.
snmp-server trap-source
Note
To specify the interface (and hence the corresponding IP address) from which a Simple Network Management Protocol (SNMP) trap should originate, use the snmp-server trap-source command in global configuration mode. To remove the source designation, use the no form of the command.
snmp-server trap-source interface
no snmp-server trap-source
Syntax Description
interface
Interface from which the SNMP trap originates. Includes the interface type and number in platform-specific syntax (for example, type slot/port).
Command Default
No interface is specified.
Command Modes
Global configuration (config)
Command History
Usage Guidelines
An SNMP trap or inform sent from a Cisco SNMP server has a notification address of the interface it went out of at that time. Use this command to monitor notifications from a particular interface.
Examples
The following example shows how to set the IP address for Ethernet interface 0 as the source for all SNMP notifications:
Router(config)# snmp-server trap-source ethernet 0The following example shows how to set the IP address for the Ethernet interface in slot 2, port 1 as the source for all SNMP notifications:
Router(config)# snmp-server trap-source ethernet 2/1Related Commands
snmp-server enable traps
Enables a router to send SNMP traps and informs.
snmp-server host
Specifies the recipient of a SNMP notification operation.
snmp-server trap-timeout
Note
To define an interval of time before resending trap messages on the retransmission queue, use the snmp-server trap-timeout command in global configuration mode.
snmp-server trap-timeout seconds
Syntax Description
seconds
Integer from 1 to 1000 that sets the interval, in seconds, for resending messages. The default is 30.
Defaults
30 seconds
Command Modes
Global configuration
Command History
10.0
This command was introduced.
12.2(33)SRA
This command was replaced by the snmp-server trap timeout command in Cisco IOS Release 12.2SR.
Usage Guidelines
The snmp-server trap-timeout command remains in Cisco IOS software for compatibility but is written in the configuration as snmp-server trap timeout.
Before the Cisco IOS software tries to send a trap, it looks for a route to the destination address. If there is no known route, the trap is saved in a retransmission queue. The snmp-server trap-timeout command determines the number of seconds between retransmission attempts.
Examples
The following example shows how to set an interval of 20 seconds between resending trap messages on the retransmission queue:
Router(config)# snmp-server trap-timeout 20Related Commands
snmp-server host
Specifies the recipient of an SNMP notification operation.
snmp-server queue-length
Establishes the message queue length for each trap host.
snmp-server user
To configure a new user to a Simple Network Management Protocol (SNMP) group, use the snmp-server user command in global configuration mode. To remove a user from an SNMP group, use the no form of this command.
snmp-server user username group-name [remote host [udp-port port] [vrf vrf-name]] {v1 | v2c | v3 [encrypted] [auth {md5 | sha} auth-password]} [access [ipv6 nacl] [priv {des | 3des | aes {128 | 192 |256}} privpassword] {acl-number | acl-name}]
no snmp-server user username group-name [remote host [udp-port port] [vrf vrf-name]] {v1 | v2c | v3 [encrypted] [auth {md5 | sha} auth-password]} [access [ipv6 nacl] [priv {des | 3des | aes {128 | 192 |256}} privpassword] {acl-number | acl-name}]
Syntax Description
Command Default
See Table 127 in the "Usage Guidelines" section for default behaviors for encryption, passwords, and access lists.
Command Modes
Global configuration (config)
Command History
Usage Guidelines
To configure a remote user, specify the IP address or port number for the remote SNMP agent of the device where the user resides. Also, before you configure remote users for a particular agent, configure the SNMP engine ID, using the snmp-server engineID command with the remote keyword. The remote agent's SNMP engine ID is needed when computing the authentication and privacy digests from the password. If the remote engine ID is not configured first, the configuration command will fail.
For the privpassword and auth-password arguments, the minimum length is one character; the recommended length is at least eight characters, and should include both letters and numbers.
Table 127 describes the default user characteristics for encryption, passwords, and access lists.
SNMP passwords are localized using the SNMP engine ID of the authoritative SNMP engine. For informs, the authoritative SNMP agent is the remote agent. You need to configure the remote agent's SNMP engine ID in the SNMP database before you can send proxy requests or informs to it.
Note
Working with Passwords and Digests
No default values exist for authentication or privacy algorithms when you configure the command. Also, no default passwords exist. The minimum length for a password is one character, although Cisco recommends using at least eight characters for security. If you forget a password, you cannot recover it and will need to reconfigure the user. You can specify either a plain-text password or a localized MD5 digest.
If you have the localized MD5 or Secure Hash Algorithm (SHA) digest, you can specify that string instead of the plain-text password. The digest should be formatted as aa:bb:cc:dd where aa, bb, and cc are hexadecimal values. Also, the digest should be exactly 16 octets long.
Examples
The following example shows how to add the user abcd to the SNMP server group named public. In this example, no access list is specified for the user, so the standard named access list applied to the group applies to the user.
Router(config)# snmp-server user abcd public v2cThe following example shows how to add the user abcd to the SNMP server group named public. In this example, access rules from the standard named access list qrst apply to the user.
Router(config)# snmp-server user abcd public v2c access qrstIn the following example, the plain-text password cisco123 is configured for the user abcd in the SNMP server group named public:
Router(config)# snmp-server user abcd public v3 auth md5 cisco123When you enter a show running-config command, a line for this user will be displayed. To learn if this user has been added to the configuration, use the show snmp user command.
Note
If you have the localized MD5 or SHA digest, you can specify that string instead of the plain-text password. The digest should be formatted as aa:bb:cc:dd where aa, bb, and cc are hexadecimal values. Also, the digest should be exactly 16 octets long.
In the following example, the MD5 digest string is used instead of the plain-text password:
Router(config)# snmp-server user abcd public v3 encrypted auth md5 00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FFIn the following example, the user abcd is removed from the SNMP server group named public:
Router(config)# no snmp-server user abcd public v2cIn the following example, the user abcd from the SNMP server group named public specifies the use of the 168-bit 3DES algorithm for privacy encryption with secure3des as the password.
Router(config)# snmp-server user abcd public priv v2c 3des secure3desRelated Commands
snmp-server view
To create or update a view entry, use the snmp-server view command in global configuration mode. To remove the specified Simple Network Management Protocol (SNMP) server view entry, use the no form of this command.
snmp-server view view-name oid-tree {included | excluded}
no snmp-server view view-name
Syntax Description
Command Default
No view entry exists.
Command Modes
Global configuration
Command History
Usage Guidelines
Other SNMP commands require an SMP view as an argument. You use this command to create a view to be used as arguments for other commands.
Two standard predefined views can be used when a view is required, instead of defining a view. One is everything, which indicates that the user can see all objects. The other is restricted, which indicates that the user can see three groups: system, snmpStats, and snmpParties. The predefined views are described in RFC 1447.
Note
The first snmp-server command that you enter enables SNMP on your routing device.
Examples
The following example creates a view that includes all objects in the MIB-II subtree:
snmp-server view mib2 mib-2 includedThe following example creates a view that includes all objects in the MIB-II system group and all objects in the Cisco enterprise MIB:
snmp-server view root_view system includedsnmp-server view root_view cisco includedThe following example creates a view that includes all objects in the MIB-II system group except for sysServices (System 7) and all objects for interface 1 in the MIB-II interfaces group:
snmp-server view agon system includedsnmp-server view agon system.7 excludedsnmp-server view agon ifEntry.*.1 includedIn the following example, the USM, VACM, and Community MIBs are explicitly included in the view "test" with all other MIBs under the root parent "internet":
! -- include all MIBs under the parent tree "internet"snmp-server view test internet included! -- include snmpUsmMIBsnmp-server view test 1.3.6.1.6.3.15 included! -- include snmpVacmMIBsnmp-server view test 1.3.6.1.6.3.16 included! -- exclude snmpCommunityMIBsnmp-server view test 1.3.6.1.6.3.18 excludedRelated Commands
snmp-server community
Sets up the community access string to permit access to the SNMP protocol.
snmp trap if-monitor
To enable if-monitor traps for a particular interface, use the snmp trap if-monitor command in interface configuration mode. To disable traps on an interface, use the no form of this command.
snmp trap if-monitor
no snmp trap if-monitor
Syntax Description
This command has no arguments or keywords.
Command Default
Traps are not generated.
Command Modes
Interface configuration (config-if)
Command History
Usage Guidelines
Traps are sent for the interface only if they have been enabled globally by issuing the snmp-server enable traps if-monitor command and then explicitly on that interface by issuing the snmp trap if-monitor command.
Examples
The following example shows how to enable if-monitor traps on a specific interface:
Router(config)# snmp-server enable traps if-monitorRouter(config)# interface ethernet 1/1Router(config-if)# snmp trap if-monitorRelated Commands
snmp trap ip verify drop-rate
To configure the router to send a Simple Network Management Protocol (SNMP) notification when the Unicast Reverse Path Forwarding (RPF) drop rate exceeds the configured threshold, use the snmp trap ip verify drop-rate command in interface configuration mode. To disable SNMP notification, use the no form of this command.
snmp trap ip verify drop-rate
no snmp trap ip verify drop-rate
Syntax Description
This command has no arguments or keywords.
Command Default
No SNMP notifications are sent.
Command Modes
Interface configuration (config-if)
Command History
Usage Guidelines
This command enables cipUrpfIfDropRateNotify notification. This notification is sent when the Unicast RPF drop rate exceeds the threshold.
Examples
The following example shows how to configure SNMP notification for the Unicast RPF drop rate on Ethernet interface 3/0:
Router> enableRouter# configure terminalRouter(config)# interface ethernet 3/0
Router(config-if)# snmp trap ip verify drop-rateRelated Commands
snmp trap link-status
To enable Simple Network Management Protocol (SNMP) link trap generation, use the snmp trap link-status command in either interface configuration mode or service instance configuration mode. To disable SNMP link traps, use the no form of this command.
snmp trap link-status [permit duplicates]
no snmp trap link-status [permit duplicates]
Syntax Description
.
Command Default
SNMP link traps are sent when an interface goes up or down.
Command Modes
Interface configuration (config-if)
Service instance configuration (config-if-srv)Command History
Usage Guidelines
By default, SNMP link traps are sent when an interface goes up or down. For interfaces expected to go up and down during normal usage, such as ISDN interfaces, the output generated by these traps may not be useful. The no form of this command disables these traps.
The permit and duplicates keywords are used together and cannot be used individually. Use the permit duplicates keyword pair when an interface is not generating SNMP linkup traps, linkdown traps, or both. When the snmp trap link-status permit duplicates command is configured, more than one trap may be sent for the same linkup or linkdown transition.
The permit duplicates keyword pair does not guarantee that SNMP link traps will be generated nor should configuring these keywords be required to receive traps.
By default, in service instance configuration mode SNMP link traps are not sent. Also, the permit duplicates keyword pair is not available in service instance configuration mode.
Cisco 10000 Series Router Usage Guidelines
In Cisco IOS Release 12.2(33)SB, the virtual-template snmp command has a new default configuration. Instead of being enabled by default, no virtual-template snmp is the default configuration. This setting enhances scaling and prevents large numbers of entries in the MIB ifTable, thereby avoiding CPU Hog messages as SNMP uses the interfaces MIB and other related MIBs.
If you configure the no virtual-template snmp command, the router no longer accepts the snmp trap link-status command under a virtual-template interface. Instead, the router displays a configuration error message such as the following:
Router(config)# interface virtual-template 1Router(config-if)# snmp trap link-status%Unable set link-status enable/disable for interfaceIf your configuration already has the snmp trap link-status command configured under a virtual-template interface and you upgrade to Cisco IOS Release 12.2(33)SB, the configuration error occurs when the router reloads even though the virtual template interface is already registered in the interfaces MIB.
Examples
The following example shows how to disable SNMP link traps related to the ISDN BRI 0 interface:
Router(config)# interface bri 0Router(config-if)# no snmp trap link-statusThe following example shows how to enable SNMP link traps for service instance 50 on Ethernet interface 0/1:
Router(config)# interface ethernet 0/1Router(config-if)# service instance 50 ethernetRouter(config-if-srv)# snmp trap link-statusRouter(config-if-srv)# exit
Related Commands
virtual-template snmp
Allows virtual access interfaces to register with SNMP when they are created or reused.
