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

Add "Clustered Network Device" type to represent redundant network devices #11440

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

Originally created by @rhysperry111 on GitHub (Aug 1, 2025).

NetBox version

v4.3.5

Feature type

Data model extension

Proposed functionality

Add a new "Clustered Network Device" type that allows identical network devices to be grouped. These devices should share mostly identical configs (so a change to the configuration of ports/interfaces on the cluster should propagate down to its physical members), barring a few exceptions for special properties to do with device hostnames, serial numbers e.t.c, management configuration and priority.

This is different from the existing "Virtual Chassis" abstraction as in that case the chassis is treated as one device with more interfaces rather than two devices working together but with the same configuration.

The exact details of what configuration is shared between members is up to each vendors' implementation, so it would likely need a way to pick what is synced and what is independent when setting up the cluster.

Use case

Ref: Discussion#9515

In many cases network device vendors have active/active and active/passive modes to allow your devices to form redundant groups. These are different from stacked chassis as you operate them as if they are a single device with identical configurations.

Currently Netbox does not have a way of representing this nicely, proving a hindrance to companies looking to make Netbox their one-stop solution for physical and logical networking documentation.

Database changes

Unsure.

External dependencies

None.

Originally created by @rhysperry111 on GitHub (Aug 1, 2025). ### NetBox version v4.3.5 ### Feature type Data model extension ### Proposed functionality Add a new "Clustered Network Device" type that allows identical network devices to be grouped. These devices should share mostly identical configs (so a change to the configuration of ports/interfaces on the cluster should propagate down to its physical members), barring a few exceptions for special properties to do with device hostnames, serial numbers e.t.c, management configuration and priority. This is different from the existing "Virtual Chassis" abstraction as in that case the chassis is treated as one device with more interfaces rather than two devices working together but with the same configuration. The exact details of what configuration is shared between members is up to each vendors' implementation, so it would likely need a way to pick what is synced and what is independent when setting up the cluster. ### Use case Ref: [Discussion#9515](https://github.com/netbox-community/netbox/discussions/9515#discussioncomment-13051049) In many cases network device vendors have active/active and active/passive modes to allow your devices to form redundant groups. These are different from stacked chassis as you operate them as if they are a single device with identical configurations. Currently Netbox does not have a way of representing this nicely, proving a hindrance to companies looking to make Netbox their one-stop solution for physical and logical networking documentation. ### Database changes Unsure. ### External dependencies None.
adam added the type: featurestatus: revisions needed labels 2025-12-29 21:45:16 +01:00
adam closed this issue 2025-12-29 21:45:16 +01:00
adam commented 2025-12-29 21:45:17 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 7, 2025):

Thank you for your interest in extending NetBox. Unfortunately, the information you have provided does not constitute an actionable feature request. Per our contributing guide, a feature request must include a thorough description of the proposed functionality, including any database changes, new views or API endpoints, and so on. It must also include a detailed use case justifying its implementation. If you would like to elaborate on your proposal, please modify your post above. If sufficient detail is not added, this issue will be closed.

Please also ensure that your issue conforms to the complete feature request template.

@jeremystretch commented on GitHub (Aug 7, 2025): Thank you for your interest in extending NetBox. Unfortunately, the information you have provided does not constitute an actionable feature request. Per our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md), a feature request must include a thorough description of the proposed functionality, including any database changes, new views or API endpoints, and so on. It must also include a detailed use case justifying its implementation. If you would like to elaborate on your proposal, please modify your post above. If sufficient detail is not added, this issue will be closed. Please also ensure that your issue conforms to the complete feature request template.
adam commented 2025-12-29 21:45:17 +01:00
Author
Owner
Copy Link

@rhysperry111 commented on GitHub (Aug 7, 2025):

The contributing guide simply says: "Be sure to provide sufficient context and detail to convey exactly what you're proposing and why". I believe this has been met using my description of what the feature should achieve and can be backed up by the interest shown in the linked discussion.

It doesn't seem entirely realistic to expect users to be able to provide exact details of how they expect the database schema to change, or how the new object will be interacted with over the API in a feature request, and that feels more up to the pull request to implement the feature.

@rhysperry111 commented on GitHub (Aug 7, 2025): The contributing guide simply says: "Be sure to provide sufficient context and detail to convey exactly what you're proposing and why". I believe this has been met using my description of what the feature should achieve and can be backed up by the interest shown in the linked discussion. It doesn't seem entirely realistic to expect users to be able to provide exact details of how they expect the database schema to change, or how the new object will be interacted with over the API in a feature request, and that feels more up to the pull request to implement the feature.
adam commented 2025-12-29 21:45:18 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 7, 2025):

If you aren't prepared to share a reasonably detailed implementation proposal, please consider first raising your idea as a discussion. Others might be able to assist you in considering the options for implementation and drafting a sufficient proposal. This must be completed and agreed upon well in advance of beginning work on a pull request. This saves both your time and ours.

I'm going to close this FR as it's not actionable in its current form. You are welcome to resubmit a new feature request if you are able to draft at least a high-level proposed implementation, including any data model and workflow changes.

@jeremystretch commented on GitHub (Aug 7, 2025): If you aren't prepared to share a reasonably detailed implementation proposal, please consider first raising your idea as a [discussion](https://github.com/netbox-community/netbox/discussions/new?category=ideas). Others might be able to assist you in considering the options for implementation and drafting a sufficient proposal. This must be completed and agreed upon well in advance of beginning work on a pull request. This saves both your time and ours. I'm going to close this FR as it's not actionable in its current form. You are welcome to resubmit a new feature request if you are able to draft at least a high-level proposed implementation, including any data model and workflow changes.
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: revisions needed 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#11440
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?