Prefix search almost useless #616

New Issue

adam · 2025-12-29T16:23:53+01:00

adam commented

2025-12-29 16:23:53 +01:00

Originally created by @Armadill0 on GitHub (Jan 10, 2017).

Problem:
We just filled Netbox 1.8.1 with many new Prefixes. Here we have a few examples:

10.4.0.0/27
10.4.0.32/27
10.175.16.0/24
10.175.18.0/24

and so on...

Results:

When I'm now entering "10" to the prefix search I'm only getting a prefix of one of our public IP ranges, which is something like "109.XXX...".
If I'm searching for "10.4" I only get "10.4.0.0/27" as a result.
"10.175.16" results in "10.175.16.0/24"
"10.175.18" results in "10.175.18.0/24"

There is no way to get all "10.*" prefixes neither from the search nor via the "Search within" filter.

Conclusion:
It seems like the search text is being converted to binary and filled with zeros to search for the prefix itself. Other search fields are searched in a wildcard behaviour.
My theory is that the search uses the Postgres Network address types which makes the search for prefixes nearly useless.

Request:
Please extend the prefix search to allow a string search in the prefixes.

MAC addresses also affected:
It seems we have a similar problem with the mac address filter. Maybe this can be fixed, too. E.g. there are no results for "00" although there should be multiple results starting with "00". 😄

Originally created by @Armadill0 on GitHub (Jan 10, 2017). **Problem:** We just filled Netbox 1.8.1 with many new Prefixes. Here we have a few examples: * 10.4.0.0/27 * 10.4.0.32/27 * 10.175.16.0/24 * 10.175.18.0/24 and so on... **Results:** * When I'm now entering "10" to the prefix search I'm only getting a prefix of one of our public IP ranges, which is something like "109.XXX...". * If I'm searching for "10.4" I only get "10.4.0.0/27" as a result. * "10.175.16" results in "10.175.16.0/24" * "10.175.18" results in "10.175.18.0/24" There is no way to get all "10.*" prefixes neither from the search nor via the "Search within" filter. **Conclusion:** It seems like the search text is being converted to binary and filled with zeros to search for the prefix itself. Other search fields are searched in a wildcard behaviour. My theory is that the search uses the Postgres Network address types which makes the search for prefixes nearly useless. **Request:** Please extend the prefix search to allow a string search in the prefixes. **MAC addresses also affected:** It seems we have a similar problem with the mac address filter. Maybe this can be fixed, too. E.g. there are no results for "00" although there should be multiple results starting with "00". :smile:

adam closed this issue

2025-12-29 16:23:53 +01:00

adam commented

2025-12-29 16:23:53 +01:00

@jeremystretch commented on GitHub (Jan 10, 2017):

NetBox prefix and IP search don't support wildcards. The value you enter is converted to an IP address or prefix. So for example, "10.4" becomes "10.4.0.0," which yields the prefix 10.4.0.0/27. This is the preferred approach over wildcards, because you can enter any IP address and NetBox will return all the prefixes which contain that IP.

This is particularly useful when prefix lengths don't fall on CIDR boundaries. For example, suppose you have the IP address 192.168.123.10 inside the prefix 192.168.122.0/23. Searching for 192.168.123.* wouldn't find the prefix, and 192.168.* would be far too broad.

There is no way to get all "10.*" prefixes neither from the search nor via the "Search within" filter.

Enter "10.0.0.0/8" to find all prefixes contained within.

It seems we have a similar problem with the mac address filter.

The MAC address filter accepts only a full MAC address, because we typically don't have a need to segment MAC addresses. (MAC addresses are not aggregatable.) Please open a separate issue for this request if you have a use case for it.

@jeremystretch commented on GitHub (Jan 10, 2017): NetBox prefix and IP search don't support wildcards. The value you enter is converted to an IP address or prefix. So for example, "10.4" becomes "10.4.0.0," which yields the prefix 10.4.0.0/27. This is the preferred approach over wildcards, because you can enter any IP address and NetBox will return all the prefixes which contain that IP. This is particularly useful when prefix lengths don't fall on CIDR boundaries. For example, suppose you have the IP address 192.168.123.10 inside the prefix 192.168.122.0/23. Searching for 192.168.123.* wouldn't find the prefix, and 192.168.* would be far too broad. > There is no way to get all "10.*" prefixes neither from the search nor via the "Search within" filter. Enter "10.0.0.0/8" to find all prefixes contained within. > It seems we have a similar problem with the mac address filter. The MAC address filter accepts only a full MAC address, because we typically don't have a need to segment MAC addresses. (MAC addresses are not aggregatable.) Please open a separate issue for this request if you have a use case for it.

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#616