5 Replies Latest reply on Sep 2, 2010 9:45 PM by smartd

    SNMP Trap and Syslog Limitations


      I would like to better understand the limitations to the SNMP and SysLog viewers through NPM. 

      We are running NPM 9.5.1, but are expeciting to upgrade to 10 sometime in the near future.

      Is there any way for the Trap Viewer to provide information about a received trap that is not in the variable ${Message}? 

      Specifically, if interface 2/27 on RouterA is configured with a description of "Connection to ClientX" and we get an alert that that interface is down, the message contains nothing for us to link this interface to "ClientX"

      I have seen several posts and discussions related to similar requests about adding variables to the trap viewer, but I have not seen anything posted as a solution to these issues. 

      Is there any way to get the interface description or other DB stored information about a node/interface to discplay in the trap notification (I am sending these to the Windows Event Log via a rule.  SCOM then picks up this message as an alarm which ultimately triggers the creation of an incident).

      Also, why is there such a disconnect between the Trap Viewer and the rest of NPM?

        • Re: SNMP Trap and Syslog Limitations

          As noted in Announcing General Availability of Orion NPM 10.0, the following Trap features have been added in v10 (I've highlighted the ones relevant to your post):


          • Using the standard Orion ${vbName1} and ${vbData1}variable format,,  trap variable binding names and value pairs are now available as  alerting and message variables.
          • The Trap Viewer now allows you to use pattern matching on trap  details to create custom trap alerts.
          • Orion NPM node variables are now available for use in Syslog and  trap alerts.
          • Syslog and trap alerts now respect unmanaged node status.
          • Orion NPM can now change the status of an interface based on the  content of a trap message.

          Does this help?

            • Re: SNMP Trap and Syslog Limitations



              I'm having trouble accomplishing the reverse of what you say v10 enables. I would like to create an Event in NPM based on a Syslog message. While Syslog Viewer may be able to retrieve node variables for its alerts, I do not see any where in Advanced Alerting to create an Event based on a Syslog message. Also, in Syslog Viewer, there does not appear to be an action to generate an Event in NPM.


              If there's a way to do this, I would be very grateful. The goal is to create an NPM event when a VMotion occurs between ESX servers.


              Thank you,


              • Re: SNMP Trap and Syslog Limitations


                I have been tring to get this working since migrating to NPM v10. We use traps for the bulk of our monitoring in conjunction with advanced alerts. The main reason is to get an email the instance a link/interface goes down. Syslog's is a whole other story that's not worth getting into .

                Specific to this quote "Orion NPM node variables are now available for use in Syslog and trap alerts. "

                There is a limitation as to what works and what doesn't unless I'm missing something. This seems to be very specific to NODES and not to NODE INTERFACES??? We (as well as others) are very descriptive with our interface descriptions. It helps our ops folks with identifying the devices affected by a down link etc. Has anyone actually been able to have an SNMP trap received by trap receiver and email the trap which includes not only the node and interface but the interface description that was added to the device configuration via CLI?



                  • Re: SNMP Trap and Syslog Limitations

                    I've been testing the Trap Alert function and it seems to work with the variable bindings (vbName1, vbData1, etc.) but not with Node variables.  That must be a typo.

                    Also have seen that if I set up a Trap Alert to send an email, even if I delete the rule the email still gets sent.  Have to stop/start services to get it to stop.