Should alarms clear automatically if you put the device in unmanage mode?

mfregeau

Hello everyone

We had this situation and I am wondering if this is something that is known and if it is something that should and can be fixed.

We had an interface that was reporting errors and discards.  So much so that we put the device in unmanaged mode while we fixed it.

I put the device in unmanaged mode up to a couple of days later.  We fixed the issue, but forgot to put the device back in managed mode.

Now that is the reason why we put the device in unmanaged mode with date, and that's fine.

The issue is when the device came back, on its own, in managed mode, it shot out a couple of extra interface errors that we took as new ones because the issue had been fixed a couple of days before.  Now I can only immagine that since there were no new errors or discards on the interfaces, that those were left over from the previous situation.

My question is this.  If you put the device in unmanaged mode or maintenance mode like we call it here.  If there are some errors left in the queue, shouldn't the system clear those by itself?  Only the errors in the queue should be cleared.  When the device comes back from unmanaged, the alarms will be checked once again anyways and that way we would be sure that only "fresh" alarms come out.

I think so, but what do you think?  Is there a way to do this already?  If yes, can someone show me how?

Thank you for your time.

stuartwhyte

The scenario you describe is the perfect example of where the unmanage feature does NOT work well.

When you unmanage a device you are are basically saying "don't poll this device any longer", and that is exactly what happens - any figures in the errors and discards fields are NOT updated during this unmanage window.  If you had (say) 100 errors recorded, they would still be there after the period of unmanagement, until such time as the device is polled and the figures updated.

Whilst you could have the alert cleared by always having "node is up" in the trigger condition, and "node is unmanaged" (an unmanged node is not up, and so therefore the alert reset condition is satisfied), as soon as the node is managed and comes back up, the error counts are still (potentially) there.  A work around for this is to have a timer on the the trigger condition of at least two polling periods, to allow time for the updated error/discard counters to be collected before an alert is gnrerted.

Hope this helps

Stuart