Notification filter not applying?

Problem:
We are trying to remove a subnet from the default nodeDown notification, the filter looks like this:
(IPADDR != '0.0.0.0') & !(IPADDR IPLIKE 10.10.*.*)

When we click on validate, we do not see any 10.10 hosts in the list, however 10.10 hosts are still hitting and sending notifications…

Here’s the raw xml:

<notification name="nodeDown" status="on" writeable="yes">
      <uei>uei.opennms.org/nodes/nodeDown</uei>
      <rule>(IPADDR != '0.0.0.0') &amp; !(IPADDR IPLIKE 10.10.*.*)</rule>
      <destinationPath>Techstaff</destinationPath>
      <text-message>All services are down on node %nodelabel%.  &#xd;

Clearly I must be doing something wrong, but it is escaping me.

Expected outcome:
Notifications are not triggered on 10.10.X.X interfaces/hosts.

OpenNMS version:
30.0.1

I’ve not been able to tackle this, I’ve rebuilt the notification, the hosts do not appear in the validate list at all ( no IP/Interface on the host to be excluded ) and yet they still get notified. Is this a bug?

Yea this has to be a bug, I built a new notification and changed our exclusion filter to an inclusive one and still get notifications hitting it for interfaces that don’t show up in the validate list.

I’m not seeing a related bug in Jira, is no one else really having this issue?

I’m talking to myself here but keeping the thread going in case anyone else runs into this. So I think I got this sorted out.

Our node in question that we do not want to notify has monitored IP 10.10.0.81, it also has an unmonitored/managed IP detected of 10.255.255.2. Well the query in Postgres was returning the 10.255.255.2 address so it was hitting our notification and getting through the filter:

(don’t mind the stupid long IPLIKE filter, I was trying different permutations to exclude 10.10..)

opennms=# SELECT DISTINCT ipInterface.ipAddr FROM ipInterface JOIN node ON (ipInterface.nodeID = node.nodeID) WHERE (((IPLIKE(ipInterface.IPADDR, '1-9.*.*.*') OR IPLIKE(ipInterface.IPADDR, '10.1-9.*.*') OR IPLIKE(ipInterface.IPADDR, '10.11-255.*.*') OR IPLIKE(ipInterface.IPADDR, '11-255.*.*.*'))) AND (node.nodeId = 193)) LIMIT 1;
    ipaddr    
--------------
 10.255.255.2

Debug:

2022-08-03 09:02:45,095 DEBUG [Notifd:BroadcastEventProcessor-Thread] o.o.n.f.JdbcFilterDao: Filter.isRuleMatching((((IPADDR IPLIKE 1-9.*.*.* | IPADDR IPLIKE 10.1-9.*.* | IPADDR IPLIKE 10.11-255.*.* | IPADDR IPLIKE 11-255.*.*.*)) & (nodeId == 193))): SQL s
tatement: SELECT DISTINCT ipInterface.ipAddr FROM ipInterface JOIN node ON (ipInterface.nodeID = node.nodeID) WHERE (((IPLIKE(ipInterface.IPADDR, '1-9.*.*.*') OR IPLIKE(ipInterface.IPADDR, '10.1-9.*.*') OR IPLIKE(ipInterface.IPADDR, '10.11-255.*.*') OR IPL
IKE(ipInterface.IPADDR, '11-255.*.*.*'))) AND (node.nodeId = 193)) LIMIT 1
2022-08-03 09:02:45,099 DEBUG [Notifd:BroadcastEventProcessor-Thread] o.o.n.f.JdbcFilterDao: isRuleMatching: rule "(((IPADDR IPLIKE 1-9.*.*.* | IPADDR IPLIKE 10.1-9.*.* | IPADDR IPLIKE 10.11-255.*.* | IPADDR IPLIKE 11-255.*.*.*)) & (nodeId == 193))" matche
s an entry in the database

Even though 10.255.255.2 is not selected for monitoring/force unmanaged we still get a positive result on it and so this node with a monitored IP of 10.10.0.81 falls through and gets notified even though I don’t think it should.

Does this quantify as a bug or is this intended behavior?

Mystery solved, the SQL query does indeed hit on ANY IP associated with a node, even if it is not monitored because there’s no constraint other than if that IP is included on the filter and matches the nodeID, no other verification if it’s managed, not or monitored or not.

If I go in and delete the IP, as soon as a rescan triggers, it appears agin.

I think this is wrong because it does NOT show up in the validate list that way. So the Validation list is incomplete, either

  • It needs to be fixed to not include these ancillary unmonitored IPs.
  • Allow changing these IPs to Unmanaged and filter to isManaged on the table.

Before anyone says you can click Admin and unmanage it, no, you can’t, not if it’s already excluded:

Here’s the list of IPs on the node:

Here’s the list of manage/unmanage:

the 30.XX address and the 10.255.255.2 do NOT appear in the email validate list, but do return positive on the query because they’re on the node.

Hard to say if that’s a bug or intended. The filter dialect in OpenNMS absolutely has some quirks and inconsistencies, but all it was designed to do was return a list of IP interfaces from the database.

If you had several nodes each with an unmanaged IP interface of 10.255.255.2 it would probably match on all of them, in fact, which is probably not expected behavior, either.

I hate being a broken record, but you’re always welcome to open a bug report on our jira. Depth of details and reproducers absolutely help issues get noticed and picked up faster and you’ve done a lot of great troubleshooting here.

https://issues.opennms.org/browse/NMS-14604 :slight_smile:

Cloning the repo now to see if I can get a merge request to go along with the BR.

1 Like