starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Disregard mask when searching for IP addresses #754

New Issue
Closed
opened 2025-12-29 16:25:30 +01:00 by adam · 7 comments
adam commented 2025-12-29 16:25:30 +01:00
Owner
Copy Link

Originally created by @100Base-TX on GitHub (Mar 8, 2017).

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.

Originally created by @100Base-TX on GitHub (Mar 8, 2017). 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.
adam added the type: feature label 2025-12-29 16:25:30 +01:00
adam closed this issue 2025-12-29 16:25:30 +01:00
adam commented 2025-12-29 16:25:31 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 8, 2017):

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).

@jeremystretch commented on GitHub (Mar 8, 2017): 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).
adam commented 2025-12-29 16:25:31 +01:00
Author
Owner
Copy Link

@100Base-TX commented on GitHub (Mar 8, 2017):

-----------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 commented on GitHub (Mar 8, 2017): -----------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.
adam commented 2025-12-29 16:25:31 +01:00
Author
Owner
Copy Link

@100Base-TX commented on GitHub (Mar 8, 2017):

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?

@100Base-TX commented on GitHub (Mar 8, 2017): 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?
adam commented 2025-12-29 16:25:31 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 8, 2017):

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.

@jeremystretch commented on GitHub (Mar 8, 2017): 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.
adam commented 2025-12-29 16:25:31 +01:00
Author
Owner
Copy Link

@100Base-TX commented on GitHub (Mar 8, 2017):

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".

@100Base-TX commented on GitHub (Mar 8, 2017): 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".
adam commented 2025-12-29 16:25:32 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 8, 2017):

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';
@jeremystretch commented on GitHub (Mar 8, 2017): 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';
adam commented 2025-12-29 16:25:32 +01:00
Author
Owner
Copy Link

@100Base-TX commented on GitHub (Mar 9, 2017):

Thanks for that stretch, champion.

@100Base-TX commented on GitHub (Mar 9, 2017): Thanks for that stretch, champion.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#754
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?