Filter
Top Products
12-23
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:
Notes 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
Note For this feature to operate, one or more trap receivers must be configured on
the switch. See “Configuring Trap Receivers” on page 12-22.
Using the CLI To Enable Authentication Traps.
For example:
ProCurve(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 Logging To Identify Problem
Sources” on page C-22.)
ProCurve(config)# snmp-server trap-receiver red-team
10.28.227.130 critical
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.