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

Set a flag in the /dcim/interfaces/ to show that an address has been assigned #1588

New Issue
Closed
opened 2025-12-29 16:33:14 +01:00 by adam · 3 comments
adam commented 2025-12-29 16:33:14 +01:00
Owner
Copy Link

Originally created by @bdlamprecht on GitHub (Mar 1, 2018).

Issue type

[X] Feature request

Environment

  • Python version: 3.6
  • NetBox version: v2.3.0

Description

This came up in the NetworkToCode Slack channel today and while I have a basic understanding of why it isn't currently implemented, I'm just posing the question here just to see if it was at all possible and if so, what performance hits would occur.

The question came up when I discovered that you could see the relationship between address and interface at the endpoint /ipam/ip-address/, but not the other way around (i.e. no way to see if an interface even has an address assigned at /dcim/interfaces/).

What I'm trying to accomplish is to be able to look at /dcim/interfaces/ and immediately tell if I should use a Layer2 interface template (no assigned address) or a Layer3 interface template (an address IS assigned).

If there is an address, I don't even care it is, as I've already coded the logic to loop through the addresses assigned to a device.

Perhaps this is just a simple mind thinking out loud here, but wouldn't it be possible to set a flag on the /dcim/interfaces/ model when an address is assigned and then clear that flag if the address assignment was removed?

While I don't really understand the intricate details of the Django ORM, this example came up:

Joey Wilhelm [4:10 PM]
If you would like to add a `has_ipaddresses` boolean in the API, you would want to start with something like this:
>>> from django.db.models import Exists, OuterRef
>>> 
>>> from dcim.models import Interface
>>> from ipam.models import IPAddress
>>>
>>> ip_addresses = IPAddress.objects.filter(interface_id=OuterRef('pk'))
>>> interfaces = Interface.objects.annotate(has_ipaddresses=Exists(ip_addresses))

Thoughts one way or another?

Originally created by @bdlamprecht on GitHub (Mar 1, 2018). ### Issue type [X] Feature request <!-- An enhancement of existing functionality --> ### Environment * Python version: 3.6 * NetBox version: v2.3.0 ### Description This came up in the NetworkToCode Slack channel today and while I have a basic understanding of why it isn't currently implemented, I'm just posing the question here just to see if it was at all possible and if so, what performance hits would occur. The question came up when I discovered that you could see the relationship between `address` and `interface` at the endpoint `/ipam/ip-address/`, but not the other way around (i.e. no way to see if an `interface` _even has_ an `address` assigned at `/dcim/interfaces/`). What I'm trying to accomplish is to be able to look at `/dcim/interfaces`/ and immediately tell if I should use a Layer2 interface template (no assigned `address`) or a Layer3 interface template (an address **IS** assigned). If there is an address, I don't even care it is, as I've already coded the logic to loop through the addresses assigned to a device. Perhaps this is just a simple mind thinking out loud here, but wouldn't it be possible to set a flag on the `/dcim/interfaces/` model when an address is assigned and then clear that flag if the address assignment was removed? While I don't really understand the intricate details of the Django ORM, this example came up: ``` Joey Wilhelm [4:10 PM] If you would like to add a `has_ipaddresses` boolean in the API, you would want to start with something like this: >>> from django.db.models import Exists, OuterRef >>> >>> from dcim.models import Interface >>> from ipam.models import IPAddress >>> >>> ip_addresses = IPAddress.objects.filter(interface_id=OuterRef('pk')) >>> interfaces = Interface.objects.annotate(has_ipaddresses=Exists(ip_addresses)) ``` Thoughts one way or another?
adam added the status: acceptedtype: feature labels 2025-12-29 16:33:14 +01:00
adam closed this issue 2025-12-29 16:33:14 +01:00
adam commented 2025-12-29 16:33:15 +01:00
Author
Owner
Copy Link

@bdlamprecht commented on GitHub (Mar 1, 2018):

I've been playing around with this some today and I think I may have found an alternative to setting a flag for when an IP address is assigned that wouldn't require any "penalties" due to primary-key and foreign-key lookups (pardon my terminology if it is not accurate).

As far as I can gather, the only instance where an interface carries specific vlans (access, tagged, tagged_all) AND has an IP address assigned is in the case of sub-interfaces. However, the current way to model that scenario within NetBox is to define each one separately (parent and child relationship are not tied together within NetBox).

If some type of check were created to ensure that interfaces can only be assigned VLANs OR IP addresses (similar to how you cannot have mode:access and tagged_vlans: { } at the same time), I believe this would work.

Can anyone think of why this would not be do-able?

@bdlamprecht commented on GitHub (Mar 1, 2018): I've been playing around with this some today and I _think_ I may have found an alternative to setting a `flag` for when an IP address is assigned that wouldn't require any "penalties" due to `primary-key` and `foreign-key` lookups (pardon my terminology if it is not accurate). As far as I can gather, the only instance where an interface carries specific vlans (`access`, `tagged`, `tagged_all`) **AND** has an IP address assigned is in the case of sub-interfaces. However, the current way to model that scenario within NetBox is to define each one separately (parent and child relationship are not tied together within NetBox). If some type of check were created to ensure that interfaces can only be assigned VLANs **OR** IP addresses (similar to how you cannot have `mode:access` and `tagged_vlans: { }` at the same time), I believe this would work. Can anyone think of why this would not be do-able?
adam commented 2025-12-29 16:33:15 +01:00
Author
Owner
Copy Link

@flycam commented on GitHub (Jul 30, 2018):

If some type of check were created to ensure that interfaces can only be assigned VLANs OR IP addresses (similar to how you cannot have mode:access and tagged_vlans: { } at the same time), I believe this would work.

On Linux, it is possible to set an ip directly to an interface, and then also have tagged vlans on that interface as well.

@flycam commented on GitHub (Jul 30, 2018): > If some type of check were created to ensure that interfaces can only be assigned VLANs OR IP addresses (similar to how you cannot have mode:access and tagged_vlans: { } at the same time), I believe this would work. On Linux, it is possible to set an ip directly to an interface, and then also have tagged vlans on that interface as well.
adam commented 2025-12-29 16:33:15 +01:00
Author
Owner
Copy Link

@bdlamprecht commented on GitHub (Jul 30, 2018):

Thanks for the information, that is interesting.

When you say something is impossible, leave it to Linux to prove otherwise. 😄

@bdlamprecht commented on GitHub (Jul 30, 2018): Thanks for the information, that is interesting. When you say something is impossible, leave it to Linux to prove otherwise. :smile:
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 status: accepted 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#1588
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?