On Mon, 12 Feb 2018 11:28:04 +0100 Ingeborg Hellemo ingeborg.hellemo@uit.no wrote:

The business report for Link Availability are supposed to show links that are expected to be up but are experiencing downtime. Links that have never been up or that are down and the linkDown alert is acknowledged/cleared will not show up here. Have I understood this correctly?

No, you haven't entirely.

It's true that the business reports use the alert history to provide a summary. If there are no alerts for a link in the history, then no data will be shown for it (it never had any problems NAV knows about).

Acknowledging and clearing do not enter into it at all.

Acknowledging an alert only means a note is added to the alert, and the default status tool filter will not show acknowledged alerts. The alert is still there, and is still waiting to be resolved. In most cases, acknowledgment is used to say something akin to "We know about this problem and are working to fix it".

Clearing an alert means to forcefully resolve the alert status, i.e. setting the end time of the problem to NOW(). That does not mean the alert disappears from history. In fact, if the problem is still present, NAV may decide to post a new alert about it.

We now have a handful of links which have been down "forever", but NAV did at some point last Friday decide that the links were up, ended the linkDown status and shows the links in the business report with nn% downtime. All these links are still down and NAV thinks the link is Inactive. (It is possible that the NAV processes including ipdevpoll was restarted at the point the error was introduced)

How can we clean up this mess and remove the links from the business report?

There is no NAV-sanctioned way to "clean up". There are problems registered in the history of these interfaces, and so it will be shown in business reports.

You do already have an open bug report about removing maintenance periods from the business reports, which makes sense. Unfortunately, you cannot put links on maintenance, only locations, rooms or whole devices, so that would likely not help you.

The real question is why NAV thought these links were up if they really weren't. That would take some log digging. Did ipdevpoll detect link state changes on these interfaces, or did snmptrapd receive traps about it?

If ipdevpoll was the source, what filter are you using for linkState alerts in ipdevpoll.conf? The topology filter is the default, which means ipdevpoll will never generate linkState events for interfaces that aren't known to be uplinks or downlinks. Did NAV have topology information for your "dead" interfaces, or did you change the filter to 'any'?