|
As others mentioned, formatting the trap does not stop their arrival. It only alters the message you see. In this case,
Enterprise (1.3.6.1.6.3.1.1.5) generic:4 specific:0 args(0):
is an SNMPv2 authentication failure trap. It means that whatever device sent it to you is being queried by some agent or other using SNMP with a bad community string. The trapd.log or event browser will tell you the name of the device which is sending these traps. To stop them you will have to investigate the conditions which cause the device to do this and remedy them.
First check that it is not NetView which is the culprit. Use xnmsnmpconf (snmpconf on Windows) to see what community string you are using to poll this device and if the default is not correct, then you must add a specific entry for this device which is correct. You can also accomplish the same thing if you have IP Address wildcard or smartset entries which include this device and have the correct community string.
Once you have made certain that NetView is not the cause, or no longer the cause, then you should login to the remote device if you can and find whatever logs are available, and see whether there are any clues as to what device was making the queries which led to those traps. If it was NetView, then you have solved the problem. If not, then you should investigate why this other agent is querying that device and see that it is properly configured for the future.
There is no general way to cause a device to stop sending traps once it has been configured to do so, without reconfiguring it. Some devices have smart agents which can do this using an SNMP set of a particular variable, but that is implemented on a vendor-by-vendor basis. You would have to know how that particular agent worked in order to do that.
The only way to prevent a trap storm is to configure the remote the devices which send you traps so that they do not do so excessively. Some have easy ways to do this; other do not. That also is a per-vendor issue. If you cannot control the devices, then you can install an MLM as a buffer ( as others have suggested), either on the same box as NetView or on another close by. The MLM can be configured to threshold the traps for you and slow down the incoming rate so that it is more manageable.
Hope this helps,
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Network Availability Management
Network Management - Development
Tivoli Software, IBM Corp _______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
|