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).
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?
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.
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 :-)
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.
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...?
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
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.
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.
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.
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.
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 :)
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.
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?
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.
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....
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?
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.
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.
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?