Enterasys Networks X-PeditionTM manual Snmp Informs, Shaping Trap Traffic, Statistics

Network Management through SNMP

SNMP Informs

SNMP Informs were first introduced in SNMPv2. An Inform is essentially nothing more than an acknowledged trap. That is, when a remote application receives an Inform it sends back an “I got it” message. When you send an Inform you use the remote engineID with the message and the securityName and engineID exist as a pair in the Remote User table. The SNMP trap program discovers the remote engineID as other applications would and creates the SNMPv3 message with the proper user that the remote side is expecting to receive.

SNMP v3 on the XSR is supported by several CLI and SNMP agent enhancements. SNMP v1/v2c traps can be configured with remote IP addresses to send traps with the snmp-server host command. For SNMP v3, each agent has a unique identifier - the engine ID - which is used to configure users in the User Security Model (USM). With the SNMP v3 USM, the XSR requires configuration of remote engine IDs and remote users.

To set up an inform recipient, first set the engine ID of the remote SNMP entity with snmp-server engineID. USM users may then be added with snmp-server user. Complete the configuration using snmp-server host to specify remote SNMP entities that will receive informs. The snmp- server informs command can be used to change the global retry, timeout and queue default settings. The snmp-server enable traps command remains the same in all SNMP versions. This command enables both traps and informs.

For a full description of SNMP commands, refer to the XSR CLI Reference Guide. Also refer to NetSight Atlas Router Services Manager v2.0 documentation to query and change SNMP values. Because the SNMP manager is disabled at boot-up, you must either manually enable the SNMP manager using the CLI, or enable it in startup-config.

Shaping Trap Traffic

Two controls are available to manage network traffic caused by SNMP traps. The first, set by the snmp-servermin-trap-spacingcommand, configures minimum spacing between successive traps to ensure that they are spaced without causing delay and cap the number of packets generated by traps.

The second control defines the maximum number of traps that can be sent in a given time window. The time window is a moving sum of the number of traps sent to the network. If the number of traps sent in the previous window-time is less than the value set by the snmp-servermax-traps-per-windowcommand, then more traps can be sent.

Both methods work simultaneously and independently and only when both are satisfied will a trap be sent. Otherwise, traps will be queued and sent as soon as conditions satisfy both traffic shaping methods.

Statistics

The XSR supports SNMP gets for MIBs listed in “Chapter 1: Network Management “of the XSR CLI Reference Guide. Also, refer to NetSight Atlas Router Services Manager v2.0 to query and change SNMP values.

XSR User’s Guide 2-39