Global search for IPs

[alexey-kirillov]

NetBox version

v3.4.1

Python version

3.8

Steps to Reproduce

1. create 10.0.0.0/24 prefix
2. create 10.0.0.1 IP in this prefix (and Don't create .2)
3. search for 10.0.0.1 - found!
4. search for 10.0.0.2 - NOTHING

Expected Behavior

Previously one could search for existing AND non-existing IPs and locate a correct prefix. Now it's only working for existing IPs. Frequently you don't have to create every IP object in netbox as this prefix has a dhcp server. At the same time it's convenient to locate prefix using a client IP.

Observed Behavior

You cannot find a relevant prefix for an IP if the IP wasn't explicitly created in NetBox

[jeremystretch]

You cannot find a relevant prefix for an IP if the IP wasn't explicitly created in NetBox

Yes, this is expected behavior when using the global search function: It's won't return results for records that don't exist. I honestly can't see why anyone would expect it to do that.

Previously one could search for existing AND non-existing IPs and locate a correct prefix.

This is still feasible via the same exact mechanism as before, by utilizing the search or quick search filters under the prefixes list. This mechanism applies logic which looks for any prefixes containing the specified IP address, whereas the global search intentionally does not.

[alexey-kirillov]

1. This was working before, that's why it was expected in 3.4+
2. Yes prefix search works, but inability to do it from the main page makes the system less convenient. Also in our case with less than 1000 prefixes it takes some time to load /ipam/prefixes/ to start searching.

[sleepinggenius2]

I was just about to open an issue on this myself, as it is a regression from versions prior to 3.4. You used to be able to put any IP into the global search and it would return the IP Address, if it existed, and/or the prefix that it belonged to. We used this all the time if we were given an IP address and needed to figure out what it belonged to. The convenience was that the global search would return the record for that specific IP if it existed or the prefix that it was a part of if it did not exist. Now, in order to achieve the same functionality, we have to search for the IP either in the global search or the IP Address search, then if it is not found, navigate to the Prefix search and search for the IP again. This is a task that our abuse team has to perform many times per day, and as a large number of IPs are assigned through DHCP or subnets are allocated to customers for their own assignment, and thus the IPs are not recorded in NetBox, these extra steps are a nuisance. I'm now having to explore alternative methods of achieving the previous functionality to address the regression in their workflow. I would add my vote to see net_contains be included as a "Partial match" for the Prefix object type in the global search once again.

[DCAuto]

@jeremystretch I know this issue is closed but my organization also used this functionality extensively. 5100 prefixes takes a LONG time for the prefixes page to load to search it. Bumping for awareness and to ask for reconsideration.

[baldgeek]

@jeremystretch Are you willing to revisit this? For similar reasons as @sleepinggenius2 mentioned our security group is struggling with this.

[jeremystretch]

You're certainly welcome to dig into how the new global search engine works and propose a specific new implementation to deliver the functionality you want to see. This issue was opened as a bug, which it's not, so it was closed. However, please bear in mind that any proposed solution will need to be accompanied by a reasonably detailed accounting of the technical strategy as well as any trade-offs with regard to performance, etc.

As an aside, this is precisely why we ask repeatedly for people to help test new releases during the beta period. To the best of my recollection, no one identified this as a desired feature, so it was not considered during work on the new search engine.

[DCAuto]

@jeremystretch Not to be a dick, but this was existing functionality. Are you asking that we list all existing functionality as a "desired feature" for future releases? To the best of my recollection this was not listed as deprecated functionality in the release notes.

[jeremystretch]

The v3.4 release notes very clearly indicate that the global search engine is being replaced with a completely new implementation. I'm not sure what level of detail you were expecting, but to me that very strongly implies that all previously existing search functionality would be impacted. Again, this is why we plead with the community to help evaluate our work before the final release. It's unfortunate that you did not opt to participate in the beta evaluation, but we can't be expected to act on feedback we're not given.