Discovery IP ranges not verified

Description

Configured many IP discovery ranges; but failed to notice a type in one of them. The bad range was 10.35.12.1 to 10.5.15.254 (should have been 10.35.15.254)...

This range was a) accepted as it, b) caused the system to apparently probe way more than desired – it was probing 10.65.x.y when it was noticed.

Because of the other ranges specified, this indicates that this typo revealed the following bugs:
1. no range verification is performed
2. no range overlap check is performed
3. a typo can result in way too much probing**

  •  

    • We have no idea if the probing included more than just the 10.* network addresses.

Environment

Operating System: Linux Platform: PC

Acceptance / Success Criteria

None

Lucidchart Diagrams

Activity

Show:

Seth Leger (community account) October 5, 2010 at 5:30 PM

I've added some basic validation to the IP addresses. Also in some parts of the discovery code, there was already a weird sanity check in place that said, if the begin IP address is numerically after the end IP address, then just silently swap them to produce a valid range.

Although this is strange behavior, I'm going to leave the behavior as-is for now (and I will log a WARN-level message if you have a range backwards) in case there is somebody out there relying on it. Hopefully they will notice the warning messages and correct their config files.

We still need to add range overlap validation.

Details

Assignee

Reporter

Labels

Components

Affects versions

Priority

PagerDuty

Created September 22, 2010 at 1:05 PM
Updated September 21, 2021 at 6:23 PM