Nagios Support Forum

There are multiple traps that we don't want to receive, in some cases all the traps from specific MIBs. We want to ingest the MIBs so the traps would be recognized properly but we want to be able to easily drop them. I can think of three solutions--all of them are looking as jumping through the hoops.
1. Adding EXEC statement like this to each trap: echo 'authenticationFailure received' > /dev/null
I tried it and it actually stopped ALL the traps from being ingested. I removed the statement but i still don't have traps coming.
2. Updating the default snmp handler script to exclude specific traps, e.g. the code to exclude authenticationFailure trap from SNMPv2-MIB:
....
if service != "Traps - SNMPv2-MIB - authenticationFailure"
return_code = get_return_code(severity)
post_results(host, service, mytime, mondata_res, return_code)

3. Using a MATCH statement to explicitly not match on any variable, e.g.
MATCH $3: (DROP THIS TRAP)

It seems that there should be a better, easier way. The solutions #1 and #3 would work on a specific trap only. #2 requires coding and maintaining the script. I'd like to be able to drop all traps from a specific MIB or drop all traps with severity Warning.
Please advise if there is a better, more generic technique to do that.

Look at your /etc/snmp/snmptt.conf* files. There you can set the alert level of individual traps to normal, critical, warning, etc.

I'd like to do it at the GUI level in Nagios when I configure traps. There are tons of traps that keep coming and need to be configured. What I do not want is to go to the file and manually change something every time the new trap comes in. It is not a question of severity - i'd like to drop them so they would not be seen and processed.
I am fine with a bunch of administrators even with lower-level skills in Nagios and/or Traps working with Nagios GUI but I have a problem with them accessing the configuration file and changing it directly--too big of the margin of error.

Changing the file directly is actually does not buy me anything -- everything I can do in the file I can do in the GUI i believe.
So the question remains: how to I completely drop the traps beside the three 'jumping through the hoops' methods in the original post? Is there easier way? Is there a way to drop ALL traps based on severity or a MIB?

Snmptt doesn't drop traps--it processes them and decides if they're in the .conf file and if so sets the state to that defined, or if it isn't in the file, it logs the trap as unknown.
Editing the .conf* files is the same as using the GUI to edit the files, just more efficient.
If you want to use the GUI, feel free. It's under admin.

I understand--no dropping traps. I've tried the following technique described above and it worked:

3. Using a MATCH statement to explicitly not match on any variable, e.g.
MATCH $3: (DROP THIS TRAP)

When I added it to a specific trap definition, that trap got dropped.

My question now is about another technique above:
1. Adding EXEC statement like this to each trap: echo 'authenticationFailure received' > /dev/null

I retested it and it seems to have no effect -- I am still getting the traps. It looks like the EXEC statements when defined work in ADDITION to the default SNMP handler and not as a replacement to the handler.
Is my understanding correct?

See the snmp options under the admin tab and set the status for the desired traps to the desired state.