7 Replies Latest reply on Nov 10, 2010 7:59 AM by bwiechman

    Problems with Trap Alerts


      I am seeing various issues with trap alerts not being sent properly after the upgrade to 10.1 RC. As far as I can tell there are several issues.

      The MIBs are sometimes being referenced differently. One alert had the condition snmpTrapOID equals RAINBOW-NOTIFICATIONS-MIB:rbMonitorAccessOn, but now is translated as RAINBOW-MIB:rainbow.0.4. Changing the condition allowed the alert to again successfully match the traps.

      Another set of traps are sent on link down messages. These were appearing in the trap listing with snmpTrapOID = SNMPv2-MIB:linkUp, but now appear as IF-MIB:linkUp which is also causing a failure of my alerts to properly catch some of these issues.

      (Edit: I see when I pegged the info in I didn't match up up/down traps. The actual linkUp/linkDown trap has not changed, the parent tree has, in this case from SNMPv2-MIB to IF-MIB)

      I haven't had a chance to completely dig through each trap alert to verify which ones do not work and why. We have a good number of trap alerts set up and some are difficult to trigger.

      Can you confirm if this behavior change is expected or not? Do I need to go through and update my alerts or is this a behavior that will be reverted to the previous behavior?

        • Re: Problems with Trap Alerts


          Thanks for the feedback! We are currently looking into this.


            • Re: Problems with Trap Alerts

              Any updates on this behavior change?

                • Re: Problems with Trap Alerts

                  The change of MIB database was done deliberately because of OID name changes. e.g. please see  http://www.oidview.com/mibs/0/IF-MIB.html for linkDown OID.

                  We are preparing repair script for TrapRules definition update which will be run during Orion Configuration Wizard. Meanwhile changing TrapRules definition manually to be compatible with new MIB database is good way to handle it.

                    • Re: Problems with Trap Alerts

                      That makes sense for the IF-MIB traps. The translation or mapping of other private mib traps has also changed.

                      For example the following trap changed in our network. The snmpTrapOID used to display RAINBOW-NOTIFICATIONS-MIB:rbMonitorAccessOn in the trap listing, now RAINBOW-MIB:rainbow.0.4 is displayed. This new translation does not match alert conditions configured for the former appearance/mapping. Thankfully we caught this early enough on this particular set of alerts because the condition that causes this also causes other conditions that we watch for (don't ask...), however I am still in the process of going through and attempting to verify all the OTHER trap alerts we have configured to ensure there are no other issues. This change is non-trivial and affects alerting. 


                      Is the repair script going to account for changes to MIBs other than the IF-MIB issue discussed?

                        • Re: Problems with Trap Alerts

                          At the moment, the repair script is only going to target the IF-MIB issue.  We're continuing to investigate a better way of handling the renaming issue while still being able to provide MIB updates on a consistent basis.

                            • Re: Problems with Trap Alerts

                              One other note on the new behavior.

                              Under the RC all traps appear to be identified by their numeric OID, instead of being translated to the more human readable format.


                              This can be dealt with when building trap alerts, by selecting the appropriate trap in the history, or referencing the MIBs.


                              However this is not all that helpful when viewing the trap history or including the trap details in an alert.


                              For example RAINBOW-MIB:rainbow.0.68 SNMP Trap means nothing to me unless I take the time to dig through the MIBs to locate the appropriate OID. On the other hand RAINBOW-NOTIFICATIONS-MIB:rbOduFailureOn  SNMP Trap is at least quickly understandable.

                              Further, a steady stream of numeric trap OIDs in the trap history is difficult and potentially troublesome alerts do not stand out.

                              From my trap history:





                              ... and so forth

                              I can look them up, or sometimes the other trap details provide sufficient information to deduce what the actual trap is, but in general it was much more obvious and user friendly when the trap OID was translated to the human readable name and I much prefer the previous behavior. I'm a busy person, and I'm sure I'm not alone in that. This extra work means that potentially troublesome traps may not be properly identified and monitored reducing the usefulness and cost effectiveness of Orion.

                              Note that I do see that some private vendor trap MIBs (notably Cisco) and the core SNMPv2-MIB and IF-MIB traps do appear to be translated to the human readable form.

                                • Re: Problems with Trap Alerts
                                  Considering the changes to how the trap OIDs are reported in alerts and logs now would it be possible to add a variable for alerts like snmpTrapOIDTranslated that would print the more human readable name of the OID so that this information is quickly accessible in the alert?