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

Filter devices and VMs by primary IP. #3523

New Issue
Closed
opened 2025-12-29 18:29:38 +01:00 by adam · 9 comments
adam commented 2025-12-29 18:29:38 +01:00
Owner
Copy Link

Originally created by @ebusto on GitHub (Mar 31, 2020).

Environment

  • Python version: 3.6.9
  • NetBox version: 2.7.11

Proposed Functionality

Enabling filtering devices and virtual machines by primary IP address.

Use Case

This would allow someone to easily lookup the NetBox entry for a system given only the IP address, and complements the existing MAC address and "has primary IP" filters.

Database Changes

None.

External Dependencies

None.

Originally created by @ebusto on GitHub (Mar 31, 2020). # Environment * Python version: 3.6.9 * NetBox version: 2.7.11 ### Proposed Functionality Enabling filtering devices and virtual machines by primary IP address. ### Use Case This would allow someone to easily lookup the NetBox entry for a system given only the IP address, and complements the existing MAC address and "has primary IP" filters. ### Database Changes None. ### External Dependencies None.
adam added the pending closure label 2025-12-29 18:29:38 +01:00
adam closed this issue 2025-12-29 18:29:38 +01:00
adam commented 2025-12-29 18:29:39 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Mar 31, 2020):

I don't think this is needed. If you are searching by IP, you can just as easily search the IP in global search then hit the parent.

@DanSheps commented on GitHub (Mar 31, 2020): I don't think this is needed. If you are searching by IP, you can just as easily search the IP in global search then hit the parent.
adam commented 2025-12-29 18:29:39 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 31, 2020):

I agree with @DanSheps. Filters generally don't span multiple relationships; doing so would increase the numbers of filters defined exponentially. If we were going to go this way, it would need to be implemented in a highly automated, scalable way for all filtersets.

@jeremystretch commented on GitHub (Mar 31, 2020): I agree with @DanSheps. Filters generally don't span multiple relationships; doing so would increase the numbers of filters defined exponentially. If we were going to go this way, it would need to be implemented in a highly automated, scalable way for all filtersets.
adam commented 2025-12-29 18:29:39 +01:00
Author
Owner
Copy Link

@ebusto commented on GitHub (Mar 31, 2020):

The primary IP is a direct attribute on the Device and VirtualMachine models. It would be far less round about than many of the fields you currently can filter on.

@ebusto commented on GitHub (Mar 31, 2020): The primary IP is a direct attribute on the Device and VirtualMachine models. It would be far less round about than many of the fields you currently can filter on.
adam commented 2025-12-29 18:29:39 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Apr 1, 2020):

@ebusto The primary IP is a Foreign Key relation to a IPAddress object. There is no IP address directly saved to the Device object.

@DanSheps commented on GitHub (Apr 1, 2020): @ebusto The primary IP is a Foreign Key relation to a IPAddress object. There is no IP address directly saved to the Device object.
adam commented 2025-12-29 18:29:39 +01:00
Author
Owner
Copy Link

@ebusto commented on GitHub (Apr 1, 2020):

Sure, an attribute that happens to be a foreign key (technically a OneToOneField, which inherits from ForeignKey, so close enough) relation, as is device_type, device_role, tenant, platform, site, and so on. All fields that you can currently filter on. Primary IP would be no different.

@ebusto commented on GitHub (Apr 1, 2020): Sure, an attribute that happens to be a foreign key (technically a OneToOneField, which inherits from ForeignKey, so close enough) relation, as is device_type, device_role, tenant, platform, site, and so on. All fields that you can currently filter on. Primary IP would be no different.
adam commented 2025-12-29 18:29:39 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 1, 2020):

Primary IP would be no different.

Primary IP is very different. For one, you're actually checking two fields on the device model: primary_ip4 and primary_ip6, unless you declare two separate filters, which imposes a burden of determining which to use on the client.

Second, the IPAddress model has no unique identifier other than its database ID (IP addresses are not necessarily unique). Per the above discussion, we're not going to add primary IP address/VRF filters for the device model, so we'd be limited to filtering devices by an IPAddress ID, which seems like it wouldn't be very useful.

@jeremystretch commented on GitHub (Apr 1, 2020): > Primary IP would be no different. Primary IP is very different. For one, you're actually checking two fields on the device model: `primary_ip4` and `primary_ip6`, unless you declare two separate filters, which imposes a burden of determining which to use on the client. Second, the IPAddress model has no unique identifier other than its database ID (IP addresses are not necessarily unique). Per the above discussion, we're not going to add primary IP address/VRF filters for the device model, so we'd be limited to filtering devices by an IPAddress ID, which seems like it wouldn't be very useful.
adam commented 2025-12-29 18:29:39 +01:00
Author
Owner
Copy Link

@ebusto commented on GitHub (Apr 1, 2020):

As a quick and dirty proof of concept, this works like a charm, with a test set of VMs using a mix of IPv4 and IPv6 primary IPs.

startswith is almost certainly not the right lookup.

primary_ip = django_filters.CharFilter(
        method = lambda qs, name, value: qs.filter(
            Q(primary_ip4__address__startswith=value) |
            Q(primary_ip6__address__startswith=value)
        ),
    )
@ebusto commented on GitHub (Apr 1, 2020): As a quick and dirty proof of concept, this works like a charm, with a test set of VMs using a mix of IPv4 and IPv6 primary IPs. `startswith` is almost certainly not the right lookup. ``` primary_ip = django_filters.CharFilter( method = lambda qs, name, value: qs.filter( Q(primary_ip4__address__startswith=value) | Q(primary_ip6__address__startswith=value) ), ) ```
adam commented 2025-12-29 18:29:39 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Apr 15, 2020):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@stale[bot] commented on GitHub (Apr 15, 2020): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 18:29:39 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Apr 22, 2020):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@stale[bot] commented on GitHub (Apr 22, 2020): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
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 pending closure
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#3523
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?