Downloads |
Table Of Contents
Memory Pool—SNMP Notification Support
Prerequisites for Memory Pool—SNMP Notification Support
Restrictions for Memory Pool—SNMP Notification Support
Information About Memory Pool—SNMP Notification Support
How to Enable Memory Pool—SNMP Notification Support
Configuration Examples for Memory Pool—SNMP Notification Support
Enabling Memory Pool—SNMP Notification Support: Example
snmp-server enable traps memory
Memory Pool—SNMP Notification Support
First Published: November 3, 2003Last Updated: July 26, 2007This feature adds command-line interface (CLI) commands to enable SNMP notifications for the Cisco Enhanced Memory Pool MIB (CISCO-ENHANCED-MEMPOOL-MIB).
History for the Memory Pool—SNMP Notification Support Feature
Finding Support Information for Platforms and Cisco IOS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.
Contents
•
Prerequisites for Memory Pool—SNMP Notification Support
•
•
•
•
Prerequisites for Memory Pool—SNMP Notification Support
Before you can compile CISCO-ENHANCED-MEMPOOL-MIB, you need to compile the following MIBs in the order listed:
1.
2.
3.
4.
5.
6.
7.
All MIBs used on Cisco devices are available through Cisco.com at http://www.cisco.com/go/mibs.
Restrictions for Memory Pool—SNMP Notification Support
Access to the MIB is restricted to a read-only level.
Information About Memory Pool—SNMP Notification Support
The CISCO-ENHANCED-MEMPOOL-MIB module describes SNMP objects that enable users to remotely monitor the memory pool statistics of all physical entities, such as line cards and route processors, in a managed device. This is particularly useful for high-end routers that may have a large number of line cards. Beginning in Cisco IOS Release 12.3(4)T, the MIB has been enhanced to provide buffer pool and buffer cache statistics.
In addition to the statistics provided by the MIB, SNMP notifications (traps or informs) can be configured to be sent when the maximum number of memory buffers changes (in other words, when a new buffer peak is reached).
How to Enable Memory Pool—SNMP Notification Support
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Configuration Examples for Memory Pool—SNMP Notification Support
This section provides the following configuration example:
•
Enabling Memory Pool—SNMP Notification Support: Example
In the following example, all available memory-related SNMP notifications are enabled and configured to be sent as informs to the host myhost.cisco.com using the community string public:
Router(config)# snmp-server enable traps memory bufferpeakRouter(config)# snmp-server host myhost.cisco.com informs version 3 public memoryNote that as of this release, only the buffer peak memory notification type is available. Additional memory notification type keywords may be added in future releases.
Additional References
The following sections provide references related to the Memory Pool—SNMP Notification Support feature.
Related Documents
Memory buffers
Buffer Tuning (Cisco Tech Note 15091)
SNMP Configuration
Configuring SNMP Support
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/ffun_c/fcfprt3/fcf014.htm
Standards
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
—
MIBs
RFCs
No new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature.
—
Technical Assistance
Command Reference
This section documents modified commands only.
•
snmp-server enable traps memory
To enable a device to send Simple Network Management Protocol (SNMP) notifications when memory pool buffer usage reaches a new peak, use the snmp-server enable traps memory command in global configuration mode. To stop notifications from being generated, use the no form of this command.
snmp-server enable traps memory [bufferpeak]
no snmp-server enable traps memory [bufferpeak]
Syntax Description
Command Default
SNMP notifications in the MEMPOOL-MIB are not enabled.
Command Modes
Global configuration
Command History
Usage Guidelines
SNMP notifications can be sent as traps or inform requests. This command enables both traps and inform requests.
This command enables or disables memory buffer peak (cempMemBufferNotify) notifications.When they are enabled, these notifications are sent when the value of the maximum number of buffer objects changes.
In current releases of Cisco IOS software, this command has the same behavior whether you use or omit the bufferpeak keyword.
The cempMemBufferNotify notification type is defined as {cempMIBNotifications 1} in the CISCO-ENHANCED-MEMPOOL-MIB. For a complete description of this notification and additional MIB functions, see the CISCO-ENHANCED-MEMPOOL-MIB.my file, available on Cisco.com at http://www.cisco.com/go/mibs/.
Examples
In the following example all available memory related SNMP notifications are enabled and configured to be sent as informs to the host myhost.cisco.com using the community string public:
Router(config)# snmp-server enable traps memoryRouter(config)# snmp-server host myhost.cisco.com informs version 3 public memoryRelated 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] [traps | informs] [version {1 | 2c | 3 [auth | noauth | priv]}] community-string [udp-port port] [notification-type]
no snmp-server host {hostname | ip-address} [vrf vrf-name] [traps | informs] [version {1 | 2c | 3 [auth | noauth | priv]}] community-string [udp-port port] [notification-type]
Syntax Description
Command Default
This command is disabled by default. No notifications are sent.
Command Modes
Global configuration
Command History
Usage Guidelines
If you enter this command with no keywords, the default is to send all trap types 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, a SNMP entity that receives an inform request acknowledges the message with a SNMP response protocol data unit (PDU). If the sender never receives the response, the inform request can be sent again. Thus, informs are more likely 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 retried several times. The retries increase traffic and contribute to a higher overhead on the network.
If you do not enter a snmp-server host command, no notifications are sent. To configure the router to send SNMP notifications, you must enter at least one snmp-server host command. If you enter the command with no 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. For example, 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.
A notification-type option's availability depends on the router type and Cisco IOS software features supported on the router. For example, the envmon notification type is available only if the environmental monitor is part of the system. To see what notification types are available on your system, use the command help ? at the end of the snmp-server host command.
The vrf keyword allows you to specify the notifications being sent to a specified IP address over a specific VRF. The VRF defines a VPN membership of a customer so data is stored using the VPN.
Notification-Type Keywords
The notification-type keywords used in the snmp-server host command do not always match the keywords used in the corresponding snmp-server enable traps command. For example, the notification keyword applicable to Multiprotocol Label Switching Protocol (MPLS) traffic engineering tunnels is specified as mpls-traffic-eng (containing two hyphens and no intervening spaces). The corresponding parameter in the snmp-server enable traps command is specified as mpls-traffic-eng (containing an intervening space and a hyphen).
This syntax difference is necessary to ensure that the command-line interface (CLI) interprets the notification-type keyword of the snmp-server host command as a unified, single-word construct, which preserves the capability of the snmp-server host command to accept multiple notification-type keywords in the command line. The snmp-server enable traps commands, however, often use two-word constructs to provide hierarchical configuration options and to maintain consistency with the command syntax of related commands. Table 1 maps some examples of snmp-server enable traps commands to the keywords used in the snmp-server host command.
Table 1 Notification Keywords and Corresponding SNMP Enable Traps Commands
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 172.20.2.160 comaccessRouter(config)# access-list 10 deny any
Note
The following example shows how to send RFC 1157 SNMP traps to a host specified 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 172.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 172.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 company.com over the VRF named trap-vrf using the community string public:
Router(config)# snmp-server host company.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 10.56.125.47 using the community string public:
Router(config)# snmp-server enable traps cefRouter(config)# snmp-server host 10.56.125.47 informs version 2c public cefRelated Commands
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2003-2004, 2006-2007 Cisco Systems, Inc. All rights reserved.
