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

IP search results should include any IP ranges the address is contained in #10513

New Issue
Closed
opened 2025-12-29 21:32:28 +01:00 by adam · 1 comment
adam commented 2025-12-29 21:32:28 +01:00
Owner
Copy Link

Originally created by @Azmodeszer on GitHub (Nov 26, 2024).

NetBox version

v.41.7

Feature type

Change to existing functionality

Triage priority

N/A

Proposed functionality

Currently searching for an IP address also includes any potential prefixes and aggregates that contain it (regardless whether the IP actually exists as an object or not). Could this be extended so that IP ranges are also checked and included in the results?

If the search happens to be for the starting or end address of the range, this works, obviously because of the definitive matching fields, but anything "theoretical" in between does not.

Use case

Well, I think the benefit should be obvious, but as a concrete example (which actually led me to create this request) I was looking up some local IPs earlier today without realizing they were dynamic addresses from a DHCP pool. The search results only showed the matching prefix and aggregate, since for obvious reasons DHCP IPs without a static mapping do not have IP address objects in the database. Would've been handy to have the DHCP ranges (which we have documented in NB) show up right away in the results for me to quickly realize what I was searching for.

Database changes

None, I guess? Whatever function is used to check if an IP is part of a prefix or aggregate could just be applied to IP range objects as well.

External dependencies

No response

Originally created by @Azmodeszer on GitHub (Nov 26, 2024). ### NetBox version v.41.7 ### Feature type Change to existing functionality ### Triage priority N/A ### Proposed functionality Currently searching for an IP address also includes any potential prefixes and aggregates that contain it (regardless whether the IP actually exists as an object or not). Could this be extended so that IP ranges are also checked and included in the results? If the search happens to be for the starting or end address of the range, this works, obviously because of the definitive matching fields, but anything "theoretical" in between does not. ### Use case Well, I think the benefit should be obvious, but as a concrete example (which actually led me to create this request) I was looking up some local IPs earlier today without realizing they were _dynamic_ addresses from a DHCP pool. The search results only showed the matching prefix and aggregate, since for obvious reasons DHCP IPs without a static mapping do not have IP address objects in the database. Would've been handy to have the DHCP ranges (which we have documented in NB) show up right away in the results for me to quickly realize what I was searching for. ### Database changes None, I guess? Whatever function is used to check if an IP is part of a prefix or aggregate could just be applied to IP range objects as well. ### External dependencies _No response_
adam added the type: feature label 2025-12-29 21:32:28 +01:00
adam closed this issue 2025-12-29 21:32:28 +01:00
adam commented 2025-12-29 21:32:29 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 6, 2025):

Could this be extended so that IP ranges are also checked and included in the results?

Unfortunately I don't think this is possible given the way the global search backend works. However, I encourage anyone interested to see if they can some up with a clever solution. If so, please feel free to submit a new FR detailing the proposed implementation and we'll continue the conversation from there.

@jeremystretch commented on GitHub (Feb 6, 2025): > Could this be extended so that IP ranges are also checked and included in the results? Unfortunately I don't think this is possible given the way the global search backend works. However, I encourage anyone interested to see if they can some up with a clever solution. If so, please feel free to submit a new FR detailing the proposed implementation and we'll continue the conversation from there.
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#10513
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?