Device Up Time With Cisco Works

[richard.brown]

Is there a way to track all of my Cisco Devices UP Time? What I am looking to do is produce a report that will show all of my devices total up and down time.

Thanks!

[Martin Ermel]

THANKS!

And I will be pleased to forward this to my SE- but the way from him to the responsibles could be a long one ...

(I hope you know a shortcut :)

[Joe Clarke]

The account team has all the power to put dollars behind the request. They should be the ones to drive the request with the business unit.

[yjdabear]

My concern is different Account Teams/SEs would end up using different verbiage in describing the same issue, which would underrepresent the amount of customer interest out there. In this case, is it sufficient to have our Account Team/SE help put a vote on the CSCsi13931 you mentioned?

[Joe Clarke]

Votes come in the form of Product Enhancement Requests or PERS. The PERS request(s) can then reference the bug. Additionally, SRs linked to bugs have some weight, but when it comes to new features, putting a business case behind the request goes a longer way than an enhancement bug.

[Martin Ermel]

I am sure ;-) that the Cisco techies like the SEs and yourself can point out to the BU that this is more like an inaccuracy from the SNMP implementation that - if it is ported to LMS evolves to a BUG for the LMS software, because LMS shows definitely *WRONG* information when the counter wraps!

But I made the experience that BUs can sometimes be somewhat deaf or so....

[yjdabear]

An IOS device crashed recently. It either went down abruptly enough that the IOS did not get a chance to record a Syslog of the reload, or even if the IOS did, the TCP/IP stack wasn't fully initialized in time to get the one-time Syslog message sent out. Of course this meant LMS 2.6's Syslog-based Reload Report didn't catch this, whereas with LMS 2.2 still fresh in memory, we know the old sysUpTime mechanism would have. This prompts me to seek the following clarification on CSCsi13931: Its description makes it sound like the Reload Report of RME 4.1 (or 5.0?) in LMS 3.0 will again revert back to relying on SNMP, because only sysUpTime and snmpEngineTime are mentioned. Is this correct? Is the Syslog-based Reload Report removed?

[Joe Clarke]

No. We are not adding any of the old availability components to RME 4.x. RME's reload report will still be based on syslog messages. Every time the inventory is collected for a device, the sysUpTime is recorded (this is done even in RME 4.0). This bug simply asks for this value to be recorded in such a way that it can detect wraps after the device has been up for more than 400 days.

As I have said previously, we are going to be release an add-on to LMS that will add the health monitoring and polling features into CiscoWorks, but this will be vastly different that what RME 3.x availability provided.

[yjdabear]

So does this mean RME 4.0 should have reported the device reload in the situation I described? I guess I'm not seeing the benefit of keeping tabs on sysUpTime, when it's not used for reload reporting purpose.

With this new add-on for LMS 3.0 onboard, can we be sure it'd catch all varieties of devices reloads/crashes, including that variety in my example? It's not ideal to have the users go to two different places (the add-on and the RME Reload Report) just to piece together a full picture of if anything reloaded/crashed.

[Joe Clarke]

No, the sysUpTime in RME 4.0 is just seen in the Detailed Device Report.

This add-on won't be a replacement in terms of RME for syslog reporting, and neither are fault management applications. I'm curious, did DFM pick anything up about this crash?