Hey @BenFan,
Good news first: for the specific 10.14.6.x vs 10.14.106.x collision you started with, your ipToInt function does fix it. I ran the numbers, 10.14.6.0 converts to 168,691,200 and 10.14.106.0 converts to 168,716,800, both positive integers, both correctly ordered with a real gap between them. That confusion is gone.
But before you close this out, there's a landmine hiding in exactly how you built that conversion, and it's going to bite you the moment you onboard a location on a more common private range.
You're using the bitwise shift operators (<<) to build the integer. In JavaScript those operators work on signed 32-bit integers, not arbitrary numbers. Bit 31 is the sign bit, and parts[0] << 24 is exactly the shift that lands the first octet's high bit right on top of it. That means any IP whose first octet is 128 or higher flips the whole result negative. Concretely:
- 10.x.x.x and 127.x.x.x and below stay positive, no problem, which is why your 10.14 test case looked clean.
- 172.16.x.x through 172.31.x.x (the other big RFC1918 private range) comes out negative.
- 192.168.x.x, one of the most common private ranges in the world, also comes out negative.
- Anything 128.x.x.x and above, same story.
So the day you add a location whose range is 192.168.1.0 to 192.168.1.255, that range's startInt and endInt come out as large negative numbers, while your existing 10.14.x ranges stay positive. Your comparison, ciIpInt >= startInt && ciIpInt <= endInt, will now treat a negative range boundary as "less than" every positive 10.x address, which reintroduces a version of the exact same false-overlap symptom you just fixed, just triggered by mixing ranges above and below that 128 threshold instead of by string comparison.
Two ways to fix it, pick whichever fits your style better:
- Keep the bitwise version but force it back to unsigned by appending >>> 0 to the final result. That coerces the value through ToUint32 instead of leaving it as a signed Int32, so 192.168.1.1 comes out as 3,232,235,777 instead of a negative number.
- Or switch to the plain arithmetic version I mentioned in my last reply, octet1 * 16777216 + octet2 * 65536 + octet3 * 256 + octet4, which never touches a bitwise operator and never overflows 32 bits since JS numbers are doubles under the hood.
function ipToInt(ip) {
if (!ip) return -1;
var parts = ip.trim().split('.');
if (parts.length !== 4) return -1;
return ((parseInt(parts[0]) << 24) +
(parseInt(parts[1]) << 16) +
(parseInt(parts[2]) << 8 +
parseInt(parts[3])) >>> 0;
}Two smaller things worth a look while you're in there:
- The image you attached (iprange-0) didn't come through on my side, attachments don't render for me, so if that's a screenshot of actual rows in ip_address_range, paste the start_ip/end_ip values as plain text and I'll check them against the logic directly. If it's the MID Server's own IP range field instead, that's a separate mechanism used for MID Server selection during discovery/orchestration, it has nothing to do with your CI location lookup, so don't let the two get cross-wired as the same "source of truth."
- Your excludedClasses NOT IN check on sys_class_name only matches the literal class value stored on the record. It won't catch anything extended further down from cmdb_ci_win_server, cmdb_ci_linux_server, etc. if your instance has custom subclasses under those. Worth a quick check of sys_db_object to confirm nothing important inherits from those six and slips through.
Once you've got the sign-overflow fix in and you're comfortable the numeric conversion is solid end to end, that ordering-by-specificity approach I mentioned last time still stands for the day you have genuinely overlapping ranges by design.
Thank you,
Vikram Karety
Octigo Solutions INC
