SNMP Trap : monitor not down

Why doesn't the following bring my monitor status down?



# Wed Feb 4 16:34:57 2009 IP matched

# Wed Feb 4 16:34:57 2009 Community string matched

# Wed Feb 4 16:34:57 2009 Generic ID matched

# Wed Feb 4 16:34:57 2009 trap 0 removed - match result: 0



with these settings:

OID *

OID type text

OID value ignore value

When trap ... DOWN



(ps: testing from vm esx3i via vicfg-snmp)

What is the OID type?

I don't know, it's very poorly documented: http://pubs.vmware.com/vi3i_i35u2/admin/wwhelp/wwhimpl/common/html/wwhelp.htm?context=admin&file=BSA_Configuration.8.13.html



But I've tried both numeric and text and both have the same reaction.



Of course I could just go and remove a harddisk, but I'd rather test it this way :-)



If you do know any other way to test just let me know. But don't bother if it ends here...



thanks

Have you tried sending a test as they outline in their document.



When doing so, let the SNMP Trap Receiver run in debug mode. Simply stop the ServersCheck service, then from the command prompt in the main ServersCheck directory type:

monitoring_snmptrap.exe > debuglog.txt



Let it run for a couple of minutes and then send a trap to the ServersCheck system.



Reply with the output of the debuglog.txt (remove the MIBS loading shown at the beginning)

That's exactly how I did it before.



But here goes:

# Wed Feb 4 17:48:15 2009 trap received from 10.0.22.21 - 1 -

# Wed Feb 4 17:48:16 2009 trap ignored for 1232368595SNMPTRAP; no match for 10.0.22.21 and 10.0.22.251

# Wed Feb 4 17:48:16 2009 trap ignored for 1232392759SNMPTRAP; no match for 10.0.22.21 and 10.0.254.1

# Wed Feb 4 17:48:16 2009 trap ignored for 1232446209SNMPTRAP; no match for 10.0.22.21 and 10.0.23.253

# Wed Feb 4 17:48:16 2009 trap ignored for 1232447124SNMPTRAP; no match for 10.0.22.21 and 10.0.23.251

# Wed Feb 4 17:48:16 2009 trap ignored for 1232793411SNMPTRAP; no match for 10.0.22.21 and 10.0.23.254

# Wed Feb 4 17:48:16 2009 IP matched

# Wed Feb 4 17:48:16 2009 Community string matched

# Wed Feb 4 17:48:16 2009 Generic ID matched

# Wed Feb 4 17:48:16 2009 trap 0 removed - match result: 0



The only difference is the first ignores from other (working) rules.

We will pass it on to development as additional debugging might be needed and they will need to make a special build for that.

Last night I received a 'live' trap from the VM machine that is actually working and making the monitor fail.



Here's some more info:

status of SNMPTRAP (Infrastructure - VMWARE2 (22.21)) changed to DOWN at Wed Feb 4 23:19:12 2009. Reason: Error: Trap received from 10.0.22.21 GID:6 SID:4 OID: enterprises.6876.50.101=1 / .



So I guess you don't need to look further, the test snmptrap from VM probably isn't according to the standards or sending empty info.



This actual trap was sent after suspending the VM.

Thank you for the update.



Can you check if you have a file called trap-rejected.log in your /logging subdirectory ?



In there should be the test trap sent.