Eventconf with same UEI but differing masks does not follow first-found-wins rule when some events have alarm-data elements and some do not
Description
In 18.0.4 and prior, if you had multiple eventconf where some events had the same UEI but differing masks and some of those events had alarm-data elements and some did not, the general rule that the first matching event found in the eventconf tree would win. Starting with 19.0.0-1 this changed, as now if you do this but the first instance of the UEI does not have alarm-data, then no alarms will ever get created for that UEI no matter if the incoming trap matches that first event's mask or not. If all events have alarm-data, it does seem to work as before. I'd guess some kind of lookup table for whether or not an UEI might be an alarm was created to improve alarm performance, but perhaps it does not respect masks?
To test, copy the two attached event files to $ONMS_HOME/etc/events/ and add them to eventconf.xml with the override file appearing first. Send the following trap via snmptrap (from the net-snmp-utils package on CentOS 7):
snmptrap -v1 -c public localhost .1.3.6.1.4.1.6889.2.2.1.2 "" 6 48 "" .1.3.6.1.4.1.6889.2.2.1.2.1.1 i 3 .1.3.6.1.4.1.6889.2.2.1.2.1.2 s 'datetime' .1.3.6.1.4.1.6889.2.2.1.2.1.3 s 'id' .1.3.6.1.4.1.6889.2.2.1.2.1.4 s 'description' .1.3.6.1.4.1.6889.2.2.1.2.1.5 i 9 .1.3.6.1.4.1.6889.2.2.1.2.1.6 s 'data' .1.3.6.1.4.1.6889.2.2.1.2.1.7 s 'alarmDescr' .1.3.6.1.4.1.6889.2.2.1.2.1.8 s 'remAction'
This should create a raise alarm with Critical severity, but does not do so even though the mask in the override file filters on vbnumber 5 being vbvalue 8. If you then remove the override file and send the trap again, it'll work. Add the file back, but change the event with the same UEI in the override file, and it'll work again.
FWIW you can clear the above alarm with
snmptrap -v1 -c public localhost .1.3.6.1.4.1.6889.2.2.1.2 "" 6 48 "" .1.3.6.1.4.1.6889.2.2.1.2.1.1 i 1 .1.3.6.1.4.1.6889.2.2.1.2.1.2 s 'datetime' .1.3.6.1.4.1.6889.2.2.1.2.1.3 s 'id' .1.3.6.1.4.1.6889.2.2.1.2.1.4 s 'description' .1.3.6.1.4.1.6889.2.2.1.2.1.5 i 9 .1.3.6.1.4.1.6889.2.2.1.2.1.6 s 'data' .1.3.6.1.4.1.6889.2.2.1.2.1.7 s 'alarmDescr' .1.3.6.1.4.1.6889.2.2.1.2.1.8 s 'remAction'
In 18.0.4 and prior, if you had multiple eventconf where some events had the same UEI but differing masks and some of those events had alarm-data elements and some did not, the general rule that the first matching event found in the eventconf tree would win. Starting with 19.0.0-1 this changed, as now if you do this but the first instance of the UEI does not have alarm-data, then no alarms will ever get created for that UEI no matter if the incoming trap matches that first event's mask or not. If all events have alarm-data, it does seem to work as before. I'd guess some kind of lookup table for whether or not an UEI might be an alarm was created to improve alarm performance, but perhaps it does not respect masks?
To test, copy the two attached event files to $ONMS_HOME/etc/events/ and add them to eventconf.xml with the override file appearing first. Send the following trap via snmptrap (from the net-snmp-utils package on CentOS 7):
snmptrap -v1 -c public localhost .1.3.6.1.4.1.6889.2.2.1.2 "" 6 48 "" .1.3.6.1.4.1.6889.2.2.1.2.1.1 i 3 .1.3.6.1.4.1.6889.2.2.1.2.1.2 s 'datetime' .1.3.6.1.4.1.6889.2.2.1.2.1.3 s 'id' .1.3.6.1.4.1.6889.2.2.1.2.1.4 s 'description' .1.3.6.1.4.1.6889.2.2.1.2.1.5 i 9 .1.3.6.1.4.1.6889.2.2.1.2.1.6 s 'data' .1.3.6.1.4.1.6889.2.2.1.2.1.7 s 'alarmDescr' .1.3.6.1.4.1.6889.2.2.1.2.1.8 s 'remAction'This should create a raise alarm with Critical severity, but does not do so even though the mask in the override file filters on vbnumber 5 being vbvalue 8. If you then remove the override file and send the trap again, it'll work. Add the file back, but change the event with the same UEI in the override file, and it'll work again.
FWIW you can clear the above alarm with
snmptrap -v1 -c public localhost .1.3.6.1.4.1.6889.2.2.1.2 "" 6 48 "" .1.3.6.1.4.1.6889.2.2.1.2.1.1 i 1 .1.3.6.1.4.1.6889.2.2.1.2.1.2 s 'datetime' .1.3.6.1.4.1.6889.2.2.1.2.1.3 s 'id' .1.3.6.1.4.1.6889.2.2.1.2.1.4 s 'description' .1.3.6.1.4.1.6889.2.2.1.2.1.5 i 9 .1.3.6.1.4.1.6889.2.2.1.2.1.6 s 'data' .1.3.6.1.4.1.6889.2.2.1.2.1.7 s 'alarmDescr' .1.3.6.1.4.1.6889.2.2.1.2.1.8 s 'remAction'