Uploaded image for project: 'OpenNMS'
  1. OpenNMS
  2. NMS-12755

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

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 19.0.0, 19.0.1, 19.1.0, 20.1.0, 21.1.0, 22.0.4, 23.0.4, 24.1.3, 25.2.1
    • Fix Version/s: Meridian-2019.1.12, 26.2.2
    • Component/s: Alarms, Events
    • Security Level: Default (Default Security Scheme)
    • Labels:
    • Sprint:
      Horizon 2020 - Sept 2-16, Horizon 2020 - Sept 16-30
    • HB Backlog Status:
      Backlog

      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'

       

      IPO-MIB-override.events.xml

      IPO-MIB.events.xml

        Attachments

          Activity

            People

            Assignee:
            j-white Jesse White
            Reporter:
            schlend David Schlenk
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:
              HB Grooming Date:

                Git Integration