Uploaded image for project: 'Observium'
  1. Observium
  2. OBS-670

bark about unsaved-to-nvram config

Details

    • New Feature
    • Resolution: Fixed
    • Minor
    • None
    • None
    • Web Interface
    • CSCO

    Description

      suggest to consider instrumentation of the poller to gather appropriate metrics and add/remove a suitable warning banner on the overview page of any individual cisco kit that hasn't got its config saved to nvram

      a few NMS already do this; it's a handy feature to cope with shenanigans of less-than-diligent cow orkers

      ref.

      http://www.ccieflyer.com/2010-01-TerrySlattery.php

      other platforms may have similar

      thanks

      R.

      Attachments

        Activity

          [OBS-670] bark about unsaved-to-nvram config
          bot Observium Bot made changes -
          Status Original: Resolved [ 5 ] New: Closed [ 6 ]
          landy Mike Stupalov made changes -
          Resolution New: Fixed [ 1 ]
          Status Original: Open [ 1 ] New: Resolved [ 5 ]
          landy Mike Stupalov added a comment -

          sure, tnx.

          landy Mike Stupalov added a comment - sure, tnx.
          mtivi Martyushev Tim added a comment -

          This function is implemented via Probe "check_snmp_cisco_config"

          mtivi Martyushev Tim added a comment - This function is implemented via Probe "check_snmp_cisco_config"
          landy Mike Stupalov made changes -
          Workflow Original: classic default workflow [ 11429 ] New: Observium workflow [ 12973 ]
          adama Adam Armstrong added a comment -

          I just had a look at implementing this, and there are a couple of issues.

          a) it seems that on boot up, the device shows its running config has changed, but its startup config never has :

          sysUpTimeInstance = 42:0:56:11.70
          ccmHistoryRunningLastChanged.0 = 0:0:00:38.71
          ccmHistoryRunningLastSaved.0 = 0:0:00:00.00
          ccmHistoryStartupLastChanged.0 = 0:0:00:00.00

          b) The timestamps are, unhelpfully, based on sysUpTime, which is a 32-bit integer, and wraps after 497 days. Any router which has an uptime of more than ~1.5 years would no longer report this information properly.

          I'm not sure if it's worth doing with these caveats. I'm suprised the article didn't mention the first, it'd probably not be too hard to work around, but it's pretty show-stopping unless worked around. The second seems a bit worse long term, having a warning mechanism which stops working after a certain period of time is nasty.

          adama Adam Armstrong added a comment - I just had a look at implementing this, and there are a couple of issues. a) it seems that on boot up, the device shows its running config has changed, but its startup config never has : sysUpTimeInstance = 42:0:56:11.70 ccmHistoryRunningLastChanged.0 = 0:0:00:38.71 ccmHistoryRunningLastSaved.0 = 0:0:00:00.00 ccmHistoryStartupLastChanged.0 = 0:0:00:00.00 b) The timestamps are, unhelpfully, based on sysUpTime, which is a 32-bit integer, and wraps after 497 days. Any router which has an uptime of more than ~1.5 years would no longer report this information properly. I'm not sure if it's worth doing with these caveats. I'm suprised the article didn't mention the first, it'd probably not be too hard to work around, but it's pretty show-stopping unless worked around. The second seems a bit worse long term, having a warning mechanism which stops working after a certain period of time is nasty.
          robvanhooren Rob VanHooren created issue -

          People

            adama Adam Armstrong
            robvanhooren Rob VanHooren
            Votes:
            1 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: