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!

[Joe Clarke]

Unfortunately, the only way to get a report with sysUpTime is to get an entire Detailed Device Report in Resource Manager Essentials (this assumes RME 4.0). We are adding sysUpTime to the list of custom report objects in LMS 3.0 (due out in late Spring of this year).

[richard.brown]

So only off the RME detailed report can I get system uptime? With RME 4.0 I am not able to create a custom report that will only show me device name, IP, model, location, and uptime?

Thanks!

[Joe Clarke]

Correct, the Detailed Device Report is currently the only way to report on sysUpTime in RME 4.0. RME 4.1 (part of LMS 3.0) will support creating custom reports with sysUpTime.

[tushar.patel]

When is RME 4.1 released?

[Joe Clarke]

RME 4.1 will be released as part of LMS 3.0 which is due out in late spring of this year.

[Martin Ermel]

do you know if RME 4.1 can get around the problem of the 32bit counter for sysUpTime;

or will RME 4.1 only have the ability to generate a report with focus on the field 'SysUpTime' currently implemented in the 'Detailed Device Report'?

If it is 'only' the report that will be implemented - are there plans to get around the counter problem and e.g fetch the sysUpTime from a (future) propietary OID that shows the uptime as in a 'show version' command or form a parse of that output ...

- customer just generated a report on 'sysUpTime' from cli and was wondering about several devices that seems to have reloaded the past 24 hours....- but no user complained :-)

[Joe Clarke]

RME will not do any manipulation of sysUpTime to get around the 32-bit limitation. All that is being added to RME 4.1 is the ability to create a custom report with the sysUpTime field.

There has been a feature request raised to implement a private object to support a 64-bit sysUpTime, but it was closed. Instead a workaround was given:

The uptime value in the show version output is accurate even after 496 days.

Routers running 12.0(3)T or higher can also use the snmpEngineTime object from

the SNMP-FRAMEWORK-MIB. This object keeps track of seconds since the

SNMP engine started. While not as granular as sysUpTime, it will not roll

over for 135 years. By polling both sysUpTime and snmpEngineTime together, then

taking the full value of sysUpTime and combining it with the additional two

digits from snmpEngineTime, one can gain additional granularity. Note, if

sysUpTime is polled right during roll-over, time will change +/- one year.

[Martin Ermel]

it is what I expected - it could have been so easy for the end-users...

the workaround is ok if 've got a custom tool and workflow to get the info and process it - in a seperate program...

what is about the idea, that even if the SNMP Agent could not get around the problem -then the management SW can do...?

Like this:

after every completed "normal" Inv Collect the OIDs mentioned in the workaround get collected by an InvCollect post-process and update the according fields in RME db - and the normal Inv Collect does not touch this field....

and LMS becomes stronger with more accurate information

[Joe Clarke]

It's certainly possible for management applications to do post-processing of sysUpTime. You should raise this with your SE so that a business case can be built.

[Joe Clarke]

Since there are at least tow customers interested in a larger sysUpTime in RME, I filed CSCsi13931 as an enhancement request for RME 4.1. You should have your account team reference this when building their business case.

[yjdabear]

We got a custom avloader from Cisco for LMS 2.2 that warned on the possibility of sysUpTime wrap-around in RME 3.x Reloads Reports. Does RME 4.1 do that? If not, I think it's worthwhile enhancement, because most users are not going to want to know about the nitty-gritty of the 32-bit limitaion with sysUpTime but would appreciate a little "caveat" like that. What I always wonder about though is why RME can't take the "show version" uptime value instead of relying on the SNMP MIB with this known limitation. I don't think it'd be difficult to implement, given RME has the underlying mechanism of "network show commands" readily available to fetch that info.

[Joe Clarke]

There is no such warning in RME. It would be better for RME to implement the tracking of sysUpTime via the workaround I mentioned previously than using show commands. If we added show command support to inventory that would further complicate an already complicated process. Plus, it would put an additional requirement of telnet/SSH credentials on inventory where as now all we require is a read-only community string.

That's not to say that adding show command support (or some other method of inventory retrieval won't be added in the future), but in this case, there is a solution RME could be using that only requires SNMP.

[yjdabear]

Is that workaround implemented in RME 4.1?

[Joe Clarke]

No, but I filed CSCsi13931 to request it.