Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Excluded IP ranges are ignored in discovery

Description

Like the subject says, nodes in the excluded discovery ranges are still being discovered. Here's my discovery config:

<?xml version="1.0" encoding="UTF-8"?>
<discovery-configuration
xmlns="http://xmlns.opennms.org/xsd/config/discovery" threads="2"
packets-per-second="1" initial-sleep-time="30000"
restart-sleep-time="86400000" retries="1" timeout="2000">
<include-range>
<begin>10.123.123.1</begin>
<end>10.123.123.250</end>
</include-range>
<exclude-range>
<begin>10.123.123.22</begin>
<end>10.123.123.22</end>
</exclude-range>
<exclude-range>
<begin>199.34.228.130</begin>
<end>199.34.228.132</end>
</exclude-range>
<exclude-range>
<begin>10.123.123.140</begin>
<end>10.123.123.180</end>
</exclude-range>
</discovery-configuration>

Yet everything in 10.123.123.140-180 is still being discovered.

Acceptance / Success Criteria

None

Lucidchart Diagrams

Activity

Show:

Dan Wilson March 30, 2012 at 11:58 AM

Ahh... that makes sense. I'm not using provisiond, so I'll research how to exclude things in capsd. Thanks!

Benjamin Reed March 30, 2012 at 11:54 AM

So are these interfaces part of a node that is in the include range, and they're getting found through SNMP scanning, after discovery? Because that's an entirely different thing from discovery ranges.

IE, if you are using provisiond, you would need to configure the foreign source to exclude certain ranges with an IpInterfacePolicy, or for capsd, I think it is based on the include/exclude ranges there.

The fix I made was only for discovery, IE, the process that generates "newSuspect" events after doing a ping sweep.

Dan Wilson March 30, 2012 at 11:41 AM

This doesn't appear to have been fixed for me. I installed version 1.10.1-0.20120328.1 from the unstable rhel6 repo and it's still finding nodes interfaces that I have excluded. These are hidden lo interfaces on existing (previously found) nodes. I've deleted them a few times and re-checked my discovery configuration. But they keep getting found.

Is it not fixed in the version I installed?

Benjamin Reed March 14, 2012 at 2:29 PM

Found it! A return inside a loop that caused it to match based on the first range only, regardless of how many there are.

Fixed in the 1.10 branch.

Ryan Bellows March 8, 2012 at 5:09 PM

I'm seeing this as well, upgrade from 1.8.11 to 1.10 broke exclude ranges. Identical behavior and reproducibility as Richard.

Fixed

Details

Assignee

Reporter

Components

Fix versions

Affects versions

Priority

PagerDuty

Created November 9, 2011 at 4:43 PM
Updated January 27, 2017 at 4:21 PM
Resolved March 14, 2012 at 2:29 PM

Flag notifications