Open for Voting

Log Analyzer - Associate Interface Traps with an Interface, not a node

Problem:

In Log Analyzer, SNMP traps for specific interfaces (for example, the interface going down) are associated with the node, not with the interface.

Because of this, you can't easily ignore traps for interfaces that you don't wish to monitor.

Problem Example:

I have a Cisco 3850 switch that has 48 access ports and 2 uplinks. I don't monitor the access ports in NPM because I don't care about them. I monitor the uplinks because I do.  NPM fires an alert (based on polling) if the interface goes down.

Because NPM is polling interface status every 2 minutes, there can be a delay in noticing that an interface went down. To get notified faster, I would like to alert when an SNMP trap is received that the uplink ports have gone down.

Log Analyzer gets a trap that an interface on the switch went down. It tags the trap and sends an alert to NPM.

In NPM, my only possible trigger conditions are associated with the node, not with the interface. I can't alert only when the interface alias contains "uplink", for example. I can't only alert when the interface is monitored in NPM.

What I've done is to create an elaborate regex in Log Analyzer where the trap is only tagged  / sent to NPM if the interface alias does not match all the stuff I want to filter out. There are some issues with this. It would be much easier if I could ignore alerts that pertain to interfaces that we don't monitor in NPM.

Potential Solution:

Somehow associate traps for interfaces (link down  / link up / etc.) with the interface, not with the node. On the alert in NPM, allow the alert to trigger only if the interface is monitored by NPM, or if it is part of a certain group of interfaces, or has a certain custom property, etc.

Alternatively, allow the interface in NPM to have its status changed. This would allow the NPM polling rule for "Interface is Down" to fire without even needing to write a separate alert. I did not use it, but i understand this was possible in the old snmp trap product.