Usage Guidelines

The SNMP engine ID is a unique string used to identify the device for administrative 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 specify your own ID, note that the entire 24-character engine ID is not needed 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 .

The value for the engine ID is displayed in hexadecimal value pairs. If the length of the input is an odd number, the last digit will be prepended with a zero ("0"). For example, if the engine ID is 12345, the ID is treated as 12:34:05 internally. Hence, the engine ID is displayed as 123405 in the show running configuration command output.

Changing the value of the SNMP engine ID has significant effects. A user's password (entered on the command line) is converted to a message digest5 algorithm (MD5) or Secure Hash Algorithm (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 the engineID changes, the security digests of SNMPv3 users will become 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.

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.

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.

• The snmp-server host command may have been configured before the snmp-server group command. In this case, you must either reconfigure the snmp-server host command, or specify the appropriate notify view.

Specifying a notify view when configuring an SNMP group is not recommended, for the following reasons:

• The snmp-server host command autogenerates a notify view for the user, and then adds it to the group associated with that user.

• Modifying the group’s notify view will affect all users associated with that group.

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. snmp-server user --Configures an SNMP user.

2. snmp-server group --Configures an SNMP group, without adding a notify view .

3. snmp-server host --Autogenerates the notify view by specifying the recipient of a trap operation.

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.

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 command will be the same as that specified in the snmp-server host command. This automatic command insertion and use of passwords is the default behavior for Cisco IOS Release 12.0(3) and later releases. However, in Cisco IOS Release 12.2(33)SRE and later releases, you must manually configure the snmp-server community command. That is, the snmp-server community command will not be seen in the configuration.

SNMP notifications can be sent as traps or inform requests. Traps are unreliable because the receiver does not send acknowledgments when it receives traps. The sender cannot determine if the traps were received. However, an SNMP entity that receives an inform request acknowledges the message with an SNMP response protocol data unit (PDU). If the sender never receives the response, the inform request can be sent again. Thus, informs are more likely to reach their intended destination than traps.

Compared to traps, informs consume more resources in the agent and in the network. Unlike a trap, which is discarded as soon as it is sent, an inform request must be held in memory until a response is received or the request times out. Also, traps are sent only once; an inform may be tried several times. The retries increase traffic and contribute to a higher overhead on the network.

If you do not enter an snmp-server host command, no notifications are sent. To configure the router to send SNMP notifications, you must enter at least one snmp-server host command. If you enter the command with no optional keywords, all trap types are enabled for the host.

To enable multiple hosts, you must issue a separate snmp-server host command for each host. You can specify multiple notification types in the command for each host.

When multiple snmp-server host commands are given for the same host and kind of notification (trap or inform), each succeeding command overwrites the previous command. Only the last snmp-server host command will be in effect. For example, if you enter an snmp-server host inform command for a host and then enter another snmp-server host inform command for the same host, the second command will replace the first.

The snmp-server host command is used in conjunction with the snmp-server enable command. Use the snmp-server enable command to specify which SNMP notifications are sent globally. For a host to receive most notifications, at least one snmp-server enable command and the snmp-server host command for that host must be enabled.

Some notification types cannot be controlled with the snmp-server enable command. Some notification types are always enabled, and others are enabled by a different command. For example, the linkUpDown notifications are controlled by the snmp trap link-status command. These notification types do not require an snmp-server enable command.

The availability of notification-type options depends on the router type and the Cisco IOS software features supported on the router. For example, the envmon notification type is available only if the environmental monitor is part of the system. To see what notification types are available on your system, use the command help ? at the end of the snmp-server host command.

The vrf keyword allows you to specify the notifications being sent to a specified IP address over a specific VRF VPN. The VRF defines a VPN membership of a user so that data is stored using the VPN.

In the case of the NMS sending the query having a correct SNMP community but not having a read or a write view, the SNMP agent returns the following error values:

• For a get or a getnext query, returns GEN_ERROR for SNMPv1 and AUTHORIZATION_ERROR for SNMPv2C.

• For a set query, returns NO_ACCESS_ERROR.

Notification-Type Keywords

The notification type can be one or more of the following keywords.

Note	The available notification types differ based on the platform and Cisco IOS release. For a complete list of available notification types, use the question mark (?) online help function.

• aaa server --Sends SNMP authentication, authorization, and accounting (AAA) traps.

• adslline --Sends Asymmetric Digital Subscriber Line (ADSL) LINE-MIB traps.

• atm --Sends ATM notifications.

• authenticate-fail --Sends an SNMP 802.11 Authentication Fail trap.

• auth-framework --Sends SNMP CISCO-AUTH-FRAMEWORK-MIB notifications.

• bgp --Sends Border Gateway Protocol (BGP) state change notifications.

• bridge --Sends SNMP STP Bridge MIB notifications.

• bstun --Sends Block Serial Tunneling (BSTUN) event notifications.

• bulkstat --Sends Data-Collection-MIB notifications.

• c6kxbar --Sends SNMP crossbar notifications.

• callhome --Sends Call Home MIB notifications.

• calltracker -- Sends Call Tracker call-start/call-end notifications.

• casa --Sends Cisco Appliances Services Architecture (CASA) event notifications.

• ccme --Sends SNMP Cisco netManager Event (CCME) traps.

• cef --Sends notifications related to Cisco Express Forwarding.

• chassis --Sends SNMP chassis notifications.

• cnpd --Sends Cisco Network-based Application Recognition (NBAR) Protocol Discovery (CNPD) traps.

• config --Sends configuration change notifications.

• config-copy --Sends SNMP config-copy notifications.

• config-ctid --Sends SNMP config-ctid notifications.

• cpu --Sends CPU-related notifications.

• csg --Sends SNMP Content Services Gateway (CSG) notifications.

• deauthenticate --Sends an SNMP 802.11 Deauthentication trap.

• dhcp-snooping --Sends DHCP snooping MIB notifications.

• director --Sends notifications related to DistributedDirector.

• disassociate --Sends an SNMP 802.11 Disassociation trap.

• dlsw --Sends data-link switching (DLSW) notifications.

• dnis --Sends SNMP Dialed Number Identification Service (DNIS) traps.

• dot1x --Sends 802.1X notifications.

• dot11-mibs --Sends dot11 traps.

• dot11-qos --Sends SNMP 802.11 QoS Change trap.

• ds1 --Sends SNMP digital signaling 1 (DS1) notifications.

• ds1-loopback --Sends ds1-loopback traps.

• dspu --Sends downstream physical unit (DSPU) notifications.

• eigrp --Sends Enhanced Interior Gateway Routing Protocol (EIGRP) stuck-in-active (SIA) and neighbor authentication failure notifications.

• energywise --Sends SNMP energywise notifications.

• entity --Sends Entity MIB modification notifications.

• entity-diag --Sends SNMP entity diagnostic MIB notifications.

• envmon --Sends Cisco enterprise-specific environmental monitor notifications when an environmental threshold is exceeded.

• errdisable --Sends error disable notifications.

• ethernet-cfm --Sends SNMP Ethernet Connectivity Fault Management (CFM) notifications.

• event-manager --Sends SNMP Embedded Event Manager notifications.

• firewall --Sends SNMP Firewall traps.

• flash --Sends flash media insertion and removal notifications.

• flexlinks --Sends FLEX links notifications.

• flowmon --Sends flow monitoring notifications.

• frame-relay --Sends Frame Relay notifications.

• fru-ctrl --Sends entity field-replaceable unit (FRU) control notifications.

• hsrp --Sends Hot Standby Routing Protocol (HSRP) notifications.

• icsudsu --Sends SNMP ICSUDSU traps.

• iplocalpool --Sends IP local pool notifications.

• ipmobile --Sends Mobile IP notifications.

• ipmulticast --Sends IP multicast notifications.

• ipsec --Sends IP Security (IPsec) notifications.

• isakmp --Sends SNMP ISAKMP notifications.

• isdn --Sends ISDN notifications.

• l2tc --Sends SNMP L2 tunnel configuration 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.

• mac-notification --Sends SNMP MAC notifications.

• memory --Sends memory pool and memory buffer pool notifications.

• module --Sends SNMP module notifications.

• module-auto-shutdown --Sends SNMP module autoshutdown MIB notifications.

• mpls-fast-reroute --Sends SNMP Multiprotocol Label Switching (MPLS) traffic engineering fast reroute notifications.

• mpls-ldp --Sends 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.

• msdp --Sends SNMP Multicast Source Discovery Protocol (MSDP) notifications.

• mvpn --Sends multicast 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.

• port-security --Sends SNMP port-security notifications.

• power-ethernet --Sends SNMP power Ethernet notifications.

• public storm-control --Sends SNMP public storm-control notifications.

• pw-vc --Sends SNMP pseudowire virtual circuit (VC) notifications.

• p2mp-traffic-eng --Sends SNMP MPLS Point to Multi-Point MPLS-TE notifications.

• repeater --Sends standard repeater (hub) notifications.

• resource-policy --Sends CISCO-ERM-MIB notifications.

• rf --Sends SNMP RF MIB notifications.

• rogue-ap --Sends an SNMP 802.11 Rogue AP trap.

• 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.

• slb --Sends SNMP server load balancer (SLB) 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.

• sonet --Sends SNMP SONET notifications.

• srp --Sends Spatial Reuse Protocol (SRP) notifications.

• stpx --Sends SNMP STPX MIB notifications.

• srst --Sends SNMP Survivable Remote Site Telephony (SRST) traps.

• stun --Sends serial tunnel (STUN) notifications.

• switch-over --Sends an SNMP 802.11 Standby Switchover trap.

• syslog --Sends error message notifications (Cisco Syslog MIB). Use the logging history level command to specify the level of messages to be sent.

• 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.

• udp-port --Sends the notification host’s UDP port number.

• vlan-mac-limit --Sends SNMP L2 control VLAN MAC limit notifications.

• vlancreate --Sends SNMP VLAN created notifications.

• vlandelete --Sends SNMP VLAN deleted notifications.

• voice --Sends SNMP voice traps.

• vrrp --Sends Virtual Router Redundancy Protocol (VRRP) notifications.

• vsimaster --Sends Virtual Switch Interface (VSI) notifications.

• vswitch --Sends SNMP virtual switch notifications.

• vtp --Sends SNMP VLAN Trunking Protocol (VTP) notifications.

• wlan-wep --Sends an SNMP 802.11 Wireless LAN (WLAN) Wired Equivalent Privacy (WEP) trap.

• x25 --Sends X.25 event notifications.

• xgcp --Sends External Media Gateway Control Protocol (XGCP) traps.

SNMP-Related Notification-Type Keywords

The notification-type argument used in the snmp-server host command do not always match the keywords used in the corresponding snmp-server enable traps command. For example, the notification-type argument applicable to Multiprotocol Label Switching Protocol (MPLS) traffic engineering tunnels is specified as mpls-traffic-eng (containing two hyphens and no embedded spaces). The corresponding parameter in the snmp-server enable traps command is specified as mpls traffic-eng (containing an embedded space and a hyphen).

This syntax difference is necessary to ensure that the CLI interprets the notification-type keyword of the snmp-server host command as a unified, single-word construct, which preserves the capability of the snmp-server host command to accept multiple notification-type keywords in the command line. The snmp-server enable traps commands, however, often use two-word constructs to provide hierarchical configuration options and to maintain consistency with the command syntax of related commands. The table below maps some examples of snmp-server enable traps commands to the keywords used in the snmp-server host command.

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 45

Usage Guidelines

Use this command to specify an IP Precedence value to give SNMP traffic higher or lower priority in your network.

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.

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.

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.

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.

Usage Guidelines

This command replaced the snmp-server trap-source command.

Note	The snmp-server trap-source command is available in other versions of Cisco IOS software for backward compatibility.

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.

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..

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.

Usage Guidelines

By default, no link traps are generated during a switchover.

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.

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.

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.

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.

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 privacypassword and authpassword arguments, the minimum length is one character; the recommended length is at least eight characters, and should include both letters and numbers. The recommended maximum length is 64 characters.

The table below 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	Changing the engine ID after configuring the SNMP user, does not allow to remove the user. To remove the user, you need to first reconfigure the SNMP user.

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. The recommended maximum length of a password is 64 characters. 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.

From Cisco IOS XE Release 17.10.1a, the SHA-2 algorithm is implemented as an additional authentication protocol to create an SNMPv3 user and associate a security level to each user, extending the authentication level from the existing MD5 and SHA protocols.

This feature provides HMAC-SHA-2 authentication protocols for USM using a Hashed Message Authentication Code (HMAC) based on the SHA-2 family of hash functions. The resulting message digest (output of HMAC) is truncated as follows:

• 192 bits (24 octets) for SHA-256 protocol.

• 256 bits (32 octets) for SHA-384 protocol.

• 384 bits (48 octets) for SHA-512 protocol.

Usage Guidelines

The RFC 3414-compliant error messages are descriptive and can lead to misuse of information by malicious users. Use the snmp-server usm cisco command to enable Cisco-specific messages that help to hide the exact error condition. Enabling Cisco-specific messages for SNMPv3 is a deviation from RFC 3414.

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	Beginning in Release 12.0(26)S and 12.2(2)T, the USM, VACM, and Community MIBs are excluded from any parent OIDs in a configured view by default. If you wish to include these MIBs in a view, you must now explicitly include them.

The first snmp-server command that you enter enables SNMP on your routing device.

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.

Usage Guidelines

By default, SNMP link traps are sent when an interface goes up or down. For interfaces such as ISDN interfaces, expected to go up and down during normal usage, 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.

The snmp trap link-status command must be used in conjunction with the snmp-server enable traps atm subif command in order to enable SNMP trap notifications on ATM subinterfaces. The snmp-server enable traps atm subif command must be configured in global configuration mode, and then the snmp trap link-status command must be configured on each ATM subinterface for which you want to enable SNMP trap notifications.

Cisco 10000 Series Router

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 device no longer accepts the snmp trap link-status command under a virtual-template interface. Instead, the device displays a configuration error message such as the following:

Device(config)# interface virtual-template 1
Device(config-if)# snmp trap link-status
%Unable set link-status enable/disable for interface

If 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 device reloads even though the virtual template interface is already registered in the interfaces MIB.