LMS 4.0 polling device even when device is removed from inventory

savic.marija · ‎11-08-2011

Hello,

we have added device manually into inventory, and created poller for interface utilization regarding this device.

Afer removing device from invetory this device is still beeing polled.

The problem is that backup ISDN interface is beeing activated when the device is polled. And we don't want this to happen.

Di we did smething wrong in this procedure?

Thanks!

Martin Ermel · ‎11-08-2011

can you tell at which intervall the device is being polled ?

If it is around every 3-4 minutes, the cause is Fault Management and you have to remove it from there.

But it is also possible to exclude the (PPP) interface from polling.

savic.marija · ‎11-08-2011

Thank you for answering so fast!

Yes, the interval is about 3min.

How to remove one device completely from DFM? In version 3.0 there was a rediscover/delete option in DFM, but in 4.0 there is only redicover/refresh option (in Admin> Collection Settings > Fault > Fault Monitoring Device Administration) I guess I am missing something .

I found the topic DFM - Delete Devices on this forum saying to

go to Inventory -> Device Admin -> Manage Device States, click on the count.

ant to unmanage a device here.

But isnt't this for all LMS applications - not only DFM ?

We were thinking about excluding this interface from pooling but when we go to :

Monitor> Fault Settings > Setup > Fault Device Details for this device we get the error on the picture:

Martin Ermel · ‎11-08-2011

It is not you who is missing something, it is the GUI that is missing the "Delete" button... :-(

That is a side-effect of removing the individual applications like RME, CM, DFM in LMS 4.x; Now there is only one place to add or delete a device. I didn't found a task to exclude an individual device from Fault management (or any other function) and I think there is only the option to suspend a device completely (also not for an individual task)

The code is still there for the delete button but it is commented out...

In LMS 3.x it was impossible to see Device Details when DFM had not access to a device that it should manage. The error you get points to the same direction - is it SNMP accessible?

If SNMP is not the cause, please post the mentioned log file.

savic.marija · ‎11-14-2011

After device was deleted - it could not be found anywhere in LMS ( inventory or DFM)- we noticed polling trough wireshark. This error I posted we got after adding device to inventory again and trying to remove it completely. Device is SNMP accessible.Here is the mentioned log:

at com.cisco.nm.trx.kdm.utils.DMExportToXML.setSelectedDevices(DMExportToXML.java:40)

at com.cisco.nm.trx.kdm.actionform.DeviceReportsActionForm.setSelectedDevices(DeviceReportsActionForm.java:56)

at com.cisco.nm.trx.kdm.action.DeviceReportsAction.perform(DeviceReportsAction.java:322)

at org.apache.struts.action.ActionServlet.processActionPerform(ActionServlet.java:1786)

at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1585)

at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:509)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:647)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)

at com.cisco.nm.cmf.util.AjaxAccessFilter.doFilter(AjaxAccessFilter.java:189)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)

at com.cisco.nm.cmf.util.AccessLogFilter.doFilter(AccessLogFilter.java:128)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)

at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)

at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200)

at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)

at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:775)

at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:704)

at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:897)

at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)

at java.lang.Thread.run(Thread.java:619)

But there is one more odd thing. When I readd the device (on November 11th) to inventory, in DFM (Admin> Collection Settings >Fault>Fault Monitoring Device Administration) we can see:

Import time stamp is 24th Oct. Even if I click on rediscover it doesnt change the Time Last Discovered - it stays 26th Oct.

looks like the device is stucked somehow.

We had several other devices that we removed this way - but they didnt make the problem.