Disregard mask when searching for IP addresses

[100Base-TX]

Hi,

The search functionality could use some improvements by adding support for either wildcard or partial searches.

A few examples:

1. When searching for IP Addresses, it'd be useful to be able to enter a partial IP. For instance "192.168.10" in the search box. It should ideally treat that search as a wildcard. Either as "%192.168.10%" or "192.168.10%".

2. Similar, but for prefixes. It currently kinda works for /24 boundaries. For instance i can type "192.168.10" in the Prefix search bar, and it will return 192.168.10x.x and any child prefixes. However if i type "192.168" it returns nothing. This seems like weird behavior.

For both of the above, you could certainly search by specifying the parent prefix. But you don't always know what it is from memory. You could find it by drilling down the tree view of prefixes, but that's more steps.

[jeremystretch]

This was covered in #787. Wildcards are of limited use when searching for IPs, as they only work along the dotted-decimal boundaries (at 8, 16, and 24 bits). Instead, you can search by covering prefix. For instance, instead of searching for "192.168.10," enter "192.168.10.0/24" in the parent prefix field.

Not only is this approach more efficient at the database level (as compared to casting all prefixes/IPs to strings), it decouples the matching logic from the dotted-decimal format. For example, I can search within 192.168.0.0/21, which cannot be expressed using a simple wildcard (you'd have to resort to using a regular expression).

[100Base-TX]

-----------Ignore this post, see next one --------------

Fair enough.

Would it be possible to allow searching by parent prefixes that don't necessarily exist then?

For instance, say there's 10.10.0.0/16 parent prefix. It has an immediate child /28 prefix (10.10.0.64/28 for instance). The current search behavior for the "parent prefix" field is that it will only return results for "10.10.0.0/16" and "10.10.0.64/28". If i try "10.10.0.0/22" for instance, it returns no results. Ideally it should return 10.10.0.64/28, and any prefixes that would be contained by that /22 mask.

Being able to search with arbitrary prefix masks is useful when you don't know the parent prefix, or if you are wanting to quickly test which allocated prefixes would get covered by an ACL.

From an efficiency point of view it should be a cheap query.

[100Base-TX]

Actually, the current behavior is different to what i just described.

So it works when searching with bigger masks, but not smaller ones.

For example, say you have this:

10.10.0.0/16
|---10.10.0.0/23
|---10.10.2.0/23

If i search for "10.10.0.0/20", it'll return both 10.10.0.0/23 and 10.10.2.0/23. That seems correct.

If i search for 10.10.3.0/24, it returns no results. I can see why - strictly speaking it doesn't have a parent prefix that is in that range. However i think that the better behavior would be to display any allocated IP addresses that can be matched by a 10.10.3.0/24 mask.

Thoughts?

[jeremystretch]

Searching with a parent prefix of 10.10.3.0/24 will return all IP addresses matched by that prefix. It will not return the prefix 10.10.2.0/23, because 10.10.2.0 is not covered by 10.10.3.0/24.

[100Base-TX]

But the children IP Addresses kind of are. I guess it just depends on how you look at it. It makes sense to me that "10.10.3.0/24" should return any allocated IP addresses that are in 10.10.3.[0-255], regardless of which prefix they belong to.

Perhaps it'd make sense for the default search field to accept that type of search? Then its like "show me IP addresses that match this search criteria", rather than "show me IP addresses who have a parent subnet that falls within this search criteria".

[jeremystretch]

Ok, I think I misunderstood what you were asking. NetBox treats prefixes and IP addresses entirely separately; you're just focused on IP addresses. If I understand correctly, the issue is that searching for 192.168.0.0/24 won't return an IP address 192.168.0.1/23, because its mask is larger than the /24.

This behavior is native to PostgreSQL, but I do see the value in allowing users to search for IPs without regard to their assigned masks. We'd need to read each INET type as though it has a /32 or /128 mask. This can be accomplished either by using set_masklen() or by recasting the host() form back to INET. The later is probably preferable as we don't have to worry selecting the correct mask length for the address family.

For example, this SQL query would include the IP address 192.168.0.1/23:

SELECT * FROM "ipam_ipaddress" WHERE CAST(HOST("ipam_ipaddress"."address") AS INET) <<= '192.168.0.0/24';

[100Base-TX]

Thanks for that stretch, champion.