Network search for the new global seach feature

[kkthxbye-code]

I want to gather some feedback for the global seach feature regarding searching for IP related fields.

Related issue: #11315

I have a PoC for a "Network" lookup type in the global search, which would mirror in part the previous global search. However I need feedback as to what is expected when searching for an IP or an IP with mask in this mode. So please contribute your ideal responses for different IP address searches in the new mode.

• What is expected as a result when searching for an IP without a mask.
• What is expected as a result when searching for an IP with a mask.

Please take into consideration all models which provide a field representing an IP address or a prefix, including IPAddress, Prefix and IPRange.

[candlerb]

When searching for 1.2.3.4 I would expect to find:

• IP Address 1.2.3.4/XX
• Any Range containing address 1.2.3.4 (e.g. 1.2.3.2 - 1.2.3.5)
• Any Prefix containing address 1.2.3.4 (e.g. 1.2.3.0/29)

(and not find 1.2.3.40/XX)

When searching for 1.2.3.0/24 I would expect to find:

• That prefix exactly
• Any prefix within that prefix
• Any range with start or end address within that prefix
• Optionally: any IP address within that prefix (I say 'optionally' because it's easy enough to select a prefix and then click on "Child addresses")

Looking #11315, it seems the issue is not agreeing on the functionality, but how to implement it within the new global search framework. It seems to me that these IP address searches will need to be special-cased - perhaps this is what you mean by a "Network lookup type".

Possibly related is what happens when you enter a partial IP address like "10.9.1" - see #6016

[markkuleinio]

+1, and consider also adding the matching aggregate at the end of the results list.

[kkthxbye-code]

Any Range containing address 1.2.3.4 (e.g. 1.2.3.2 - 1.2.3.5)

Unfortunately this will never work with the new search feature as start_address and end_address are seperate fields. The new search feature is built on a single table used as a search index, so we cannot do any queries that checks if the query is between two seperate fields.

Looking #11315, it seems the issue is not agreeing on the functionality, but how to implement it within the new global search framework.

You might be right, but if we are going by how it worked in v3.3, the following input from you is at odds with the previous functionality:

Any prefix within that prefix

The old search feature did the opposite, showing the prefix and parent prefixes of the search query, but not contained prefixes. Similarly I don't believe IP ranges were included in the old global search.

It seems to me that these IP address searches will need to be special-cased - perhaps this is what you mean by a "Network lookup type".

These are lookup types:

But I think I've moved away from that idea.

[kkthxbye-code]

This is what I've come up with so far. I've moved away from the separate lookup idea.

develop...kkthxbye-code:netbox:poc-ip-search

The following functionality is added when doing a Partial lookup search (the default when searching from the global search bar) for a string that parses as an IP address:

• Containing Prefixes will be shown, that means that even if the IP doesn't exist it will show all prefixes where the searched IP is a part of.
• As above for prefix matches, all parent will be shown.
• All matching parent aggregates will be shown.

This all matches the search bar behavior, except IPs contained in the search query are not returned in the search result.

Example searching for a prefix:

Example searching for an IP in the prefix:

Example searching for a non-existent IP in the prefix:

Code changes:

• Added the net_contains_or_equals lookup type to TextField, same as the ipam one, but casting the lhs to inet.
• Adding inet and cidr types to FieldTypes. The inet type is not used for the functionality implemented so far. Straight IP matching is still just doing string comparison.
• If the search query parses as an IPNetwork, add another OR'd where condition checking for net_contains_or_equals for rows with the cidr type.

All existing search behavior should be identical otherwise.
*

[jeremystretch]

Thanks for tackling this @kkthxbye-code! A couple thoughts:

Added the net_contains_or_equals lookup type to TextField

Rather than registering the lookup for TextField (which wouldn't make sense in most cases), we should be able to use a query function to handle the casting. Performance should be the same as the resulting SQL query should be identical.

The inet type is not used for the functionality implemented so far.

Is the plan to use a similar approach for IP addresses? So that, for example, searching for 192.0.2.1 does not match 192.0.2.12?

Also:

query_filter &= Q(object_typeo__in=object_types)

Noticed a literal "type o" typo here which I thought was amusing. 🙂

[kkthxbye-code]

Rather than registering the lookup for TextField (which wouldn't make sense in most cases), we should be able to use a query function to handle the casting. Performance should be the same as the resulting SQL query should be identical.

I'll play around with that, thanks!

Is the plan to use a similar approach for IP addresses? So that, for example, searching for 192.0.2.1 does not match 192.0.2.12?

I'm not actually sure, does it make sense to do so in the partial lookup mode? When searching for 192.0 for example, would it be a correct assumption that the user wants all IP addresses starting with 192.0? Or are we just interested in fully formed IP's 192.0.2.1 only matching that specific IP (already possible if you specify the mask).

The main reason for including the inet type in the FieldTypes is that it makes it easier to add search functionality (like IP specific search logic) in the future and since changing FieldTypes requires a reindex I found it better to add it now than later.

I'm not really a typical user of netbox, so all input is appreciated as to what should be added. I think the current PoC satisfies the original issue in #11315.

Noticed a literal "type o" typo here which I thought was amusing. 🙂

Hah, good catch, I'll fix that up when I get time to look at the other stuff.

[xeor]

Anyone done any progress on the original issue #11315? The issue (and everyone related) is locked as it turned into a unrelated heated debate.

I didn't dig into the new global search, but would a logic like this be acceptable?

try:
  ipobj = ipaddress.ip(query)
  results.append(prefixes_containing(ipobj))
except NotValid:
  pass

Or will that be non-acceptible?

Another way is to prefix the query and look for special keywords; ip=1.2.3.4..

I'm not sure what fits into the future versions of Netbox. Can you give us a headsup @jeremystretch , so people won't work on something that would not be acceptable..

[kkthxbye-code]

Network search was already added to the global search (v3.4.5), so I'm really confused as to what you are talking about:

#11686

#11685

Also, please do not tag maintainers to get attention.