Every day I get this report. It always contains 1 or 2 devices, every day another. I'm trying to figure out what is interesting in these reports. So far I have not been able to so.
The sysuptime has changed.... a couple of seconds. The system clock had deviated a bit and is now synchronized with the time server....only this device...tomorrow another one etc
The amount free and used ram changed... a couple of bytes. Normal right? Load fluctuates, so does memory.
Then I see the interfaces? No, I get hit with the interface indexes (why is that, anyone?)
I suppose these interfaces changed because the time on the machine has changed?
Why can't I even see the status went from up to down? Or if it remained up or down.
I have a problem explaining the use of these reports to my customers. And I do feel this report should indicated that there might be a problem, but the bogus reports like the one I get every day, will prevent the sysadmin from noticing it.
A sysUpTime change is useless. Free and available memory may also be useless. Interface last change time could be interesting. This indicates that the interface had a state change at the given time. A state change could mean the interface was bounced (see the ifLastChange description in the IF-MIB).
As for making these reports more useful, it would be a good idea to disable what you don't need or don't care about. This can be done under RME > Administration > Inventory > Inventory Change Filter. Here you select the items you DO NOT want to monitor for changes.
For example, for this report, I would check System:SysUpTime and Memory Pool:Free (MB) and Memory Pool:Used (MB). Playing with these filters can usually get you a set of inventory change reports that make sense for your organization.
For the report to become useful certain things should change.
Sysuptime can be very interesting because it can indicate a reboot/reload of a device.
If suddenly my free mem goes from 30% to 5% I would like to know.
I feel a realistic threshold value before a detected change triggers a change report is what we need here.
If an interface bounces comes up or goes down I'd like to know what interface had this problem. But I need to know if it came up went down or bounced, and I don't want to go out and match an ifIndex to an existing interface, I want to see it's name and description.
With regards to disabling the monitoring of certain changes I noticed that even if I don't monitor Interface: Last Changed , I still monitor Operational and Admin State. That makes me feel I can safely try to disable this. I assume the fact that I only see "Last Changed" indicates that the interface state has not changed.
I'm please to know that all the relevant parameters are monitored but the report definitely requires some adjustments
I'm looking forward to hear about the improvement Cisco has in the pipeline for this type of reports.
For reloads, the RME reloads report might be more useful. For a large dip in free memory, DFM can report on that. RME is not a fault management tool per se, so I don't see threshold capability being added to this report. I think the goal of the inventory change report is to report on hardware changes for the most part.
However, if you wanted to persue adding a thresholding feature per object, contact your account team to build a business case for it using a PERS request.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...