SNMP Trap service listening on default port
We’ve run into a few cases where other (not-so-polite) apps having been stealing our access to incoming SNMP traps so we thought we would post here with some more details and troubleshooting tips.
By default traps are sent to a trap receiver that is listening on UDP port 162, the standard port for SNMP traps. That’s all great but in this era of server consolidation it sometimes happens that two different apps on a system want to receive traps, sometimes for different reasons.
So what’s a polite application supposed to do? On Windows, instead of listening on the port yourself you connect to the Windows SNMP Trap service and it acts like a broker sending incoming traps to each application that has asked to receive them. That’s what Tembria Server Monitor does but we’ve run into a couple cases where another app has decided to grab the port itself.
If you’ve added an SNMP Trap Event Monitor in Tembria Server Monitor but you’re not getting any traps, try using the good old ‘netstat -a -b’ command. It will give you a display similar to what you see in the screenshot above. Look through the output to see which application has a hold of the snmptrap port. The entry should look like “UDP hostname:snmptrap” and below it will be the application name which should be “[snmptrap.exe]” if the Windows SNMP Trap service has it.
If you see another app or something referring to “Java” then you know that another app has hijacked the port and you’ll need to move it to another machine where it can selfishly hog resources on its own.
Posted by Don