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

Dual-stack or multiple OOB IP address #9997

New Issue
Closed
opened 2025-12-29 21:25:26 +01:00 by adam · 3 comments
adam commented 2025-12-29 21:25:26 +01:00
Owner
Copy Link

Originally created by @bluikko on GitHub (Jul 23, 2024).

NetBox version

v4.0.7

Feature type

Data model extension

Proposed functionality

Currently only one IP address may be marked as OOB IP address.
We run everything as dual-stack, including OOB. This issue proposes to change the OOB IP address to refer multiple IP addresses instead of just one IP address.

The original issue #8137 only considered IPv4 (obvious from the screenshot and text) and this is a problematic mindset but I digress.
A comment in https://github.com/netbox-community/netbox/issues/8137#issuecomment-999819759 brought up multiple IP addresses and how this is obviously more complex to implement. A latter comment left the door open for additional FR (this one).

Use case

To model dual-stack OOB.
And to a (much) lesser extent multiple OOB IP addresses.

Currently those with dual-stack OOB probably decide to not use this feature at all and instead use different methods.

Database changes

I do not know exactly but I assume the database would need to be able to refer multiple IP addresses instead of a single IP address as OOB in the Device model.

If it is indeed currently implemented as a single foreign key then I would imagine a layer of indirection might be necessary. It looks like some work was done in #13094 for this as a generic solution that could be used for all such references.

A quick & dirty solution would be to have oob_ip4 and oob_ip6 similar to the Primary IP Address fields, where these would be simple foreign keys. I would estimate this solution would cover the vast majority of the use cases, thought there are sure to be at least few users who would prefer more than one IP address per address family.
This would then have implications on displaying the data as there might be 2 separate fields similarly to the Primary IP address; instead of just listing all OOB IP addresses in a single form field.

Further discussion would probably be needed to reach the best implementation details.

External dependencies

None.

Originally created by @bluikko on GitHub (Jul 23, 2024). ### NetBox version v4.0.7 ### Feature type Data model extension ### Proposed functionality Currently only one IP address may be marked as OOB IP address. We run everything as dual-stack, including OOB. This issue proposes to change the OOB IP address to refer multiple IP addresses instead of just one IP address. The original issue #8137 only considered IPv4 (obvious from the screenshot and text) and this is a problematic mindset but I digress. A comment in https://github.com/netbox-community/netbox/issues/8137#issuecomment-999819759 brought up multiple IP addresses and how this is obviously more complex to implement. A latter comment left the door open for additional FR (this one). ### Use case To model dual-stack OOB. And to a (much) lesser extent multiple OOB IP addresses. Currently those with dual-stack OOB probably decide to not use this feature at all and instead use different methods. ### Database changes I do not know exactly but I assume the database would need to be able to refer multiple IP addresses instead of a single IP address as OOB in the Device model. If it is indeed currently implemented as a single foreign key then I would imagine a layer of indirection might be necessary. It looks like some work was done in #13094 for this as a generic solution that could be used for all such references. A quick & dirty solution would be to have `oob_ip4` and `oob_ip6` similar to the Primary IP Address fields, where these would be simple foreign keys. I would estimate this solution would cover the vast majority of the use cases, thought there are sure to be at least few users who would prefer more than one IP address per address family. This would then have implications on displaying the data as there might be 2 separate fields similarly to the Primary IP address; instead of just listing all OOB IP addresses in a single form field. Further discussion would probably be needed to reach the best implementation details. ### External dependencies None.
adam added the type: featurepending closurestatus: under reviewnetbox labels 2025-12-29 21:25:26 +01:00
adam closed this issue 2025-12-29 21:25:27 +01:00
adam commented 2025-12-29 21:25:27 +01:00
Author
Owner
Copy Link

@bluikko commented on GitHub (Jul 23, 2024):

Another much more radical option would be to mark interfaces as OOB instead of IP addresses and then use all IP addresses of that interface as OOB. I'd be fine with this and it looks much more simple to implement.

@bluikko commented on GitHub (Jul 23, 2024): Another much more radical option would be to mark *interfaces* as OOB instead of IP addresses and then use all IP addresses of that interface as OOB. I'd be fine with this and it looks much more simple to implement.
adam commented 2025-12-29 21:25:28 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Oct 24, 2024):

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. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Oct 24, 2024): 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. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 21:25:28 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Dec 2, 2024):

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.

@github-actions[bot] commented on GitHub (Dec 2, 2024): 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 netbox pending closure status: under review 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#9997
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?