N o t e s

N o t e

Configuring for Network Management Applications

Using SNMP Tools To Manage the Switch

For example, to configure a trap receiver in a community named “red-team” with an IP address of 10.28.227.130 to receive only “critical” log messages:

HPswitch(config)# snmp-server trap-receiver red-team 10.28.227.130 critical

To replace one community name with another for the same IP address, you must use no snmp-server host < community-name> < ip-address > to delete the unwanted community name. Otherwise, adding a new community name with an IP address already in use with another community name simply creates two allowable community name entries for the same management station.

If you do not specify the event level ([<none all non-info critical debug>]) then the switch does not send event log messages as traps. “Well-Known” traps and threshold traps (if configured) will still be sent.

Using the CLI To Enable Authentication Traps

For this feature to operate, one or more trap receivers must be configured on the switch. See “In the default configuration, there are no trap receivers configured, and the authentication trap feature is disabled. From the CLI you can configure up to ten SNMP trap receivers to receive SNMP traps from the switch. As an option, you can also configure the switch to send Event Log messages as traps. CLI: Configuring and Displaying Trap Receivers” on page 10-8.

Using the CLI To Enable Authentication Traps.

Syntax: [no] snmp-server enable traps authentication

Enables or disables sending an authentication trap to the configured trap receiver(s) if an unauthorized management station attempts to access the switch.

For example:

HPswitch(config)# snmp-server enable traps authentication

Check the Event Log in the console interface to help determine why the authentication trap was sent. (Refer to “Using the Event Log To Identify Problem Sources” on page C-22.)

10-11