Current status alarms vs alarms that require manual recovery

[dmacesic]

Right now we have link up/down alarms that are logged and need manual recovery to clear the status. Is there a way for alarms to auto-recover depending on type?

Also, obviously if such an auto-recovered alarm appears above a certain threshold, example 3 connectivity losses in a day, then an alarm that needs to be manually recovered could be generated?

The objective is to show the current status of the network, but have an alarm stay "sticky" so that chronic problems may be addressed.

[LindsayHill]

Link Up/Down alarms already do auto-recover automatically. If an interface goes down, it will raise an alarm. When it comes back up, it should raise another Info-level alarm, which recovers the original alarm.

This is standard behaviour, unless you've changed it. Both syslogs and traps can be configured with Recovery/Restore traps/logs.

There are some capabilities around alerting on frequent alarms, but I don't think you'll be able to get the granularity of control you might be after for traps. There are some more capabilities with syslogs around frequency/interval suppression settings.

You should also be checking your interface alarm filtering settings - you may need to tweak these to stop desktop ports from creating alarms.

There is also an option in qvdm.conf that delays forwarding of interface up/down events, which can help with suppressing short term flaps.

[dmacesic]

Thank you, we will test this.

Where exactly is the "Recovery/Restore traps/logs" configuration located in IMC 7? I may be blind, I can't find it.

[Thunder_GAO]

Alaram details page has that feature.

[LindsayHill · Accepted solution]

Go to Alarm -> Trap Management -> Trap Definition.

As an example, search for "Link Up"

Click the Modify link.

Look at the "Restore Trap" section.

You'll see something similar with Syslogs. When defining a Syslog to Alarm rule, you can set an "Alarm Recovery Rule"

[dmacesic]

Thank you, found it!