3 Replies Latest reply on May 9, 2009 4:28 PM by vhcato

    Changing SNMP System Contact

    JimmieV

      I'm having problems updating the SNMP System Contact info on Orion.  In my tests, I've updated different nodes (Cisco router, Extreme switch, Juniper firewall).  I've tried  re-adding the node without deleting the existing definition.  It seems to work initially, but after the first polling cycle, sysContact reverts to the old (no longer existing) value.  I can delete and re-add the node, but then I lose all of my historical data.

      Any suggestions?

        • Re: Changing SNMP System Contact
          jtimes

          Are you changing it in Orion or on the remote device?  That has to be changed in the remote device configuration, saved, and then rediscovered by Orion

            • Re: Changing SNMP System Contact
              JimmieV

              I started by just changing the config on the remote device.  I figured that in the next polling cycle, the update would appear for the node.  But Orion didn't rediscover the SNMP info (system contact, system location, etc.)  So then I tried to "force" Orion to rediscover by re-adding the node.  It worked initially, but then Orion would revert to the old SNMP strings at the first polling cycle, even though that information no longer existed on the node.  The only way I got it to update permenently was to delete/re-add the node.

                • Re: Changing SNMP System Contact
                  vhcato

                  The NPM server (or polling engine) stores some information locally about the devices it monitors, while other bits of info are only stored on the SQL server. I'm not sure if these particular SNMP values are included in what's kept locally, but if so, I've seen issues where there is an inconsistency between the info stored locally and what's in the SQL DB. The only way I've found to resolve it (short of deleting and re-adding the device) is to restart the NetPerfMon.exe process.

                  From what I understand, the NPM server is the authoritative source (over the SQL DB) for the pieces of info that it stores locally about monitored elements, but I've seen cases where there seems to be some contention that doesn't resolve properly. Restarting the service has always cleared everything up for these instances.