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

[rhysperry111]

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.

[jeremystretch]

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.

[rhysperry111]

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.

[jeremystretch]

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.