Nagios Support Forum

I get a lot of snmp traps of a particular oid. I only need to process 5%. The way I understand trap processing is that snmptrapd listens to udp 162. It seems logical I can write a pre filter to replace the traphandler. The pre filter will pass on what I need and drop what I don't. That works, I can see the traps drop and never get sent to the proper handler snmptthandler. However I still see the traps making it into nagios.log and be processed. How are the traps getting around the filter? Is it possible to drop uneeded traps or do I need to create some kind of trap proxy in from of nagiosxi trap receiver?

Hi @dslaughter,

Thanks for your post.

It's an interesting issue you have here, and more context might be helpful. High level, I think you are right that your filter isn't filtering like you think it should. You may be correct that a proxy receiver/forwarder is more helpful for you, but then on the other other hand you now have two things to implement sufficiently well in that case, since you would still have to figure out how to filter correctly in front of your forwarding function.

How is your filter implemented? How were you hoping it screened out traps you didn't want to process? Where does it sit in the process chain from the port to Nagios? How is it supposed to work?

You say you only need to process 5%. Which 5% is that? 5% of traps for that oid per machine? 5% of the aggregate across the environment? How are you choosing which to drop/not drop?

You say you can see the traps drop -- how are you deciding that the traps are indeed dropped?

Aaron

I have several devices that generate a lot of traps. This device allows other teams to build connections. I have no control over the device , I only receive up and down traps. The device configures connections with names. I will not know names until the trap arrives. The teams need to receive a notice when one goes down.

The 5% is just a 'feels like number'. I've received over a million traps this month so far and I only needed around 1500. This is not a good situation but I'm working on it.

I wanted to try and catch the traps as they come in and drop them unless it matches a filter. snmptrapd is listening to udp 162 so I started there. I looked at snmptrapd.conf it was only a couple lines. I changed the trap handle to my filter. The filter (bash) would forward or drop based on oid/name. The script worked. I setup log messages to see traps pass and drop. The drops would not be forwarded to the handler. However I was still seeing the traps I'm filtering in nagios.log and unknown objects.

#!/bin/bash
HANDLER="/usr/sbin/snmptthandler"
WHITELIST="/usr/local/nagios/etc/trap_whitelist.txt"
DEBUGLOG="/var/log/snmptrap_debug.log"
DROPLOG="/var/log/snmptrap_filter.log"
# Read entire trap
TRAP_CONTENT=$(cat)
# Extract trap OID
TRAP_OID=$(echo "$TRAP_CONTENT" | awk '/snmpTrapOID/ {print $NF; exit}' \
| sed 's/^SNMPv2-SMI::enterprises\./1.3.6.1.4.1./' \
| tr -d '\r\n ')
echo "$(date) RAW_OID=<$TRAP_OID>" >> "$DEBUGLOG"
ACTION="PASS"
# Only filter these enterprise traps
case "$TRAP_OID" in
1.3.6.1.4.1.30.1.1.4.1.2*|1.3.6.1.4.1.30.1.1.4.2.2*)
if grep -qiFf "$WHITELIST" <<< "$TRAP_CONTENT"; then
ACTION="PASS"
echo "$TRAP_CONTENT" | "$HANDLER"
else
ACTION="DROP"
echo "$(date) DROPPED OID=$TRAP_OID" >> "$DROPLOG"
echo "$TRAP_CONTENT" >> "$DROPLOG"
fi
;;
*)
# All other traps pass through
ACTION="PASS"
echo "$TRAP_CONTENT" | "$HANDLER"
;;
esac
echo "$(date) OID=$TRAP_OID ACTION=$ACTION" >> "$DEBUGLOG"
exit 0

So you get a large number of traps covering a range of oids, but you only want to deal with traps with certain oids, correct?

I have not spent a lot of time in the guts of snmptt but some Google AI output suggests traps matching specific oids can be sent to /dev/null, and also that you can set log_enable = 0 for some events, which may help you out.

https://share.google/aimode/tZI9jVw1gPTW9xpHB

There are certain oids however I filter those by a name in the content. If oid matches check for name. I can't throw them all away. I just don't understand how they get past the filter.

I'd guess that somehow TRAP_CONTENT isn't right although it looks fine. Of course if that were true, the traps you want would also be broken.
Snmptt is getting the traps and processing them or there wouldn't be anything in nagios logs or unconfigured objects. Traps going to unconfigured objects often means snmptt can't find the trap definition in it's config. Can you add the trap data for the unconfigured objects to the snmptt config?

I've had to modify my process. Originally I had every trap create its own service but with all the changes and new connections I ended with 100's of services. So I changed the config to put the traps in unknown objects. I would go through unknown object and add only the services I need. After a while it became difficult because all the unknown objects you have to go through. Next I setup a screen scraper to delete unknown objects if they don't match the name and eventually the script can't keep up. Now I'm trying to drop the trap before it gets processed. The filter works but somehow the trap gets to snmptt anyway and runs nxti.

Here is the trap definition from the trap interface.
clearedEndpointConnectionLost .1.3.6.1.4.1.30.1.1.4.2.2.2.2011 Status Events Normal Cleared Lost connection to endpointVariables: 1: majorClearId 2: majorClearDesc 3: majorClearAction 4: majorClearSeverity 5: majorClearNode 6: majorClearComponent 7: majorClearContext 8: majorClearTimestamp 9: majorClearDomain
clearedEndpointUnavailable .1.3.6.1.4.1.30.1.1.4.1.2.2.2010 Status Events Normal Cleared Endpoint Unavailable endpointVariables: 1: criticalClearId 2: criticalClearDesc 3: criticalClearAction 4: criticalClearSeverity 5: criticalClearNode 6: criticalClearComponent 7: criticalClearContext 8: criticalClearTimestamp 9: criticalClearDomain
endpointConnectionLost .1.3.6.1.4.1.30.1.1.4.2.2.2011 Status Events Major Lost connection to endpointVariables: 1: majorId 2: majorDesc 3: majorAction 4: majorSeverity 5: majorNode 6: majorComponent 7: majorContext 8: majorTimestamp 9: majorDomain
endpointUnavailable .1.3.6.1.4.1.30.1.1.4.1.2.2010 Status Events Critical Endpoint Unavailable endpointVariables: 1: criticalId 2: criticalDesc 3: criticalAction 4: criticalSeverity 5: criticalNode 6: criticalComponent 7: criticalContext 8: criticalTimestamp 9: criticalDomain

The source for the filter is above

Here is some log snippets
Tue Mar 17 21:24:40 UTC 2026 OID=1.3.6.1.4.1.30.1.1.4.1.2.2.2010 ACTION=DROP
Tue Mar 17 21:24:40 UTC 2026 RAW_OID=<1.3.6.1.4.1.30.1.1.4.2.2.2.2011>
Tue Mar 17 21:24:40 UTC 2026 OID=1.3.6.1.4.1.30.1.1.4.2.2.2.2011 ACTION=DROP
Tue Mar 17 21:24:43 UTC 2026 RAW_OID=<1.3.6.1.4.1.30.1.1.4.2.2.2.2011>
Tue Mar 17 21:24:43 UTC 2026 OID=1.3.6.1.4.1.30.1.1.4.2.2.2.2011 ACTION=PASS
Tue Mar 17 21:24:44 UTC 2026 RAW_OID=<SNMPv2-SMI::mib-2.15.0.2>
Tue Mar 17 21:24:44 UTC 2026 OID=SNMPv2-SMI::mib-2.15.0.2 ACTION=PASS
Tue Mar 17 21:24:44 UTC 2026 RAW_OID=<1.3.6.1.4.1.3065.4.1.0.2>
Tue Mar 17 21:24:44 UTC 2026 OID=1.3.6.1.4.1.3065.4.1.0.2 ACTION=PASS
Tue Mar 17 21:24:44 UTC 2026 RAW_OID=<SNMPv2-SMI::mib-2.15.0.2>
Tue Mar 17 21:24:44 UTC 2026 OID=SNMPv2-SMI::mib-2.15.0.2 ACTION=PASS
Tue Mar 17 21:24:44 UTC 2026 RAW_OID=<1.3.6.1.4.1.3065.4.1.0.2>
Tue Mar 17 21:24:45 UTC 2026 OID=1.3.6.1.4.1.3065.4.1.0.2 ACTION=PASS
Tue Mar 17 21:24:46 UTC 2026 RAW_OID=<1.3.6.1.4.1.30.1.1.4.2.2.2.2011>
Tue Mar 17 21:24:46 UTC 2026 OID=1.3.6.1.4.1.30.1.1.4.2.2.2.2011 ACTION=PASS
Tue Mar 17 21:24:58 UTC 2026 RAW_OID=<1.3.6.1.4.1.30.1.1.4.2.2.2011>
Tue Mar 17 21:24:58 UTC 2026 OID=1.3.6.1.4.1.30.1.1.4.2.2.2011 ACTION=DROP
Tue Mar 17 21:24:58 UTC 2026 RAW_OID=<1.3.6.1.4.1.30.1.1.4.1.2.2010>
Tue Mar 17 21:24:58 UTC 2026 OID=1.3.6.1.4.1.30.1.1.4.1.2.2010 ACTION=DROP


The drops go nowhere. They are not forwarded to a handler.
else
ACTION="DROP"
echo "$(date) DROPPED OID=$TRAP_OID" >> "$DROPLOG"
echo "$TRAP_CONTENT" >> "$DROPLOG"
fi

Everything looks correct however its still getting to snmptt.conf

One way or another your script is sending the traps to snmptt.

kg2857 wrote: ↑Tue Mar 17, 2026 5:35 pm One way or another your script is sending the traps to snmptt.

Agreed. Any traps in unconfigured objects got there through snmptt. https://assets.nagios.com/downloads/nag ... ios_XI.pdf

@dslaughter could you post your config files?

Where/when/how/what is calling your filter script? It looks to me like that filter script is running in that you see that it write to your log files, but it doesn't seem not to be also sending the traps along the path.

I'd imagine that the issue is the default case. You may want to make the logging different for those forwarded traps, after this line: # All other traps pass through