This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Interface last state change monitoring accuracy

Hi Folks,

another request here to improve on current features within NCM.

Background

Currently for most switches in our network acquiring an accurate date as to when an interface's state was last changed via the iflastchange MIB over SNMP is near impossible. This is because of a counter roll over flaw in the sysuptime MIB on Cisco and other devices that rely on RFC1213's sysUpTime. Because this counter is only a 16 bit counter it rolls over every 496 days. The iflastchange takes its timestamps from sysUpTime counter so you may or may not have an accurate interface state change date depending on whether you device as been up more than 496 days or not. The is more information on this topic below.

We, like many others need the use of a tool like this to be able to determine how long an interface has been dormant for, so to recycle unused ports.

https://supportforums.cisco.com/message/573244#573244

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCdm72652 

If you have a small network or reload you devices regularly you won't have this problem. But if your network is large and you work in datacentres then you'll appreciate that reloading your 4500/6500 devices on a regular basis is not an option. Cisco has acknowledged this flaw in the sysUpTime counter but there appears no intention to correct it as it is not a 'bug' as such. Ths is why I am proposing this particular request.

Feature request   

NCM attempts to provide this information already and as mentioned above in certain environments it might be enough. But what I am proposing is a more accurate way of recording interface status changes that would be exempt from counter rollovers. By using the polling engine that NCM already has NCM could poll the interfaces for 'status' on a '4500'  for example, at given intervals and mark the time when the status of the interface changes. This process would use the time on the NCM server to log the 'last interface status change' rather than polling the potentially flawed timestamp of the iflastchange MIB.

I am not suggesting NCM automatically monitors the status of every single interface in a users database. I'm requesting an option to be able to select by either device types or a similar interface selection window as NPM. If I could selectively monitor all the 4500s, 6500s and 3750 stacks on our network for last interface status change I pesonallywould be happy.

The polling rate wouldn't have to be that frequent either. We measure our interface state changes by the number of days, not by the hour or minute. A few polls a day to a device for its interface states would be more than sufficient for most users I would imagine and it place very little additional strain on the NCM polling engine.

So why not just use NPM you might be asking. NPM is more for Performance monitoring not so much for inventory management like NCM. Also most importantly the majority of folks will tend to monitor active interfaces in NPM for utilisation stats. Most of the time when looking to recycle a port we are looking a inactive ports. Currently we monitor nearly 6000 interfaces in our NPM environment; these ints are all active uplinks. The sheer scale required to monitor every single interface on every switching device on top of the active ints would be huge.

Apologies for the lengthy post, any comments, questions or improvements please chime in, specially if you would like to see this please let everyone know :-)  

      

 
  • Hi Ciaq--

    Great post. Marked for PM to review.

    M

  • Very well written, Ciag. Enhancement request 54672.


  • Thanks for your responses folks

  • Hello again,

    I'm looking to see how others deal with the above mentioned problem, specially around datacentre cisco devices. As you might imagine reloading datacentre devices to reset the sysuptime counter is not an option or at least not a very palatable one.

    We have been looking at other tools from Tuscany and Rebasoft who provide suitable work arounds to this issue by circumventing the iflastchange OID, but would much rather keep our NMS with Solarwinds as much as possible.

    I am very interested to find out how others deal with recycling switchports on devices that have had sysuptime counter roll overs, specifically how do you keep track of how long a switchport has been unused for on your datacentre devices if those devices have an up-time greater than 496 days? Do you use documentation, dedicated tools, device reloads etc?

    Any info would be greatly appreciated

    Regards

  • Hello again,

    just wondering if UDT can do this? With specific focus on being able to tell how long an interface has been 'down' for. I know it can give an overall history of available ports on a box but can it give port by port info on how long a port has been inactive (And exact date/timestamp). I've had a look at the documentation and the demo website and it's not clear whether or not it's possible.

    It seems like the perfect platform for this feature, and I would be astonished if it was not included in UDT or at least being slated for a future release.

    Or seeing as UDT backends to a SQL might it be possible if it was integrated as part of NPM to you use report writer to create a report to find ports that have been inactive for XX number of days?

    Kind regards

    Ciaran