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

Tracking connections other than network, console, or power #772

New Issue
Closed
opened 2025-12-29 16:25:39 +01:00 by adam · 2 comments
adam commented 2025-12-29 16:25:39 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Mar 16, 2017).

Issue type: Feature request

The current data model in NetBox allows for the representation of three discrete types of connections: network, console, and power. Roughly, these are represented using the following models and relations:

ConsolePort --> ConsoleServerPort
PowerPort --> PowerOutlet
Interface <-- InterfaceConnection --> Interface

A separate set of models is used for each of these as each type of connection may have different attributes associated with it. For example, a power outlet has an amperage and a voltage, whereas a network interface might have a MAC address and IP addresses assigned to it.

Through several recent discussions, users have expressed the need to model additional types of physical connections within NetBox. While it would not be prudent to extend any of the existing models beyond their designed purpose, it might make sense to introduce new models which would allow users to define other types of connections.

This is an exploratory feature request to compile user needs. If there's an additional type of physical connection you'd like to model in NetBox, please comment below. Be as detailed as possible when describing your use case: The more detail we can gather, the better we can hypothesize a data model.

Originally created by @jeremystretch on GitHub (Mar 16, 2017). ### Issue type: Feature request The current data model in NetBox allows for the representation of three discrete types of connections: network, console, and power. Roughly, these are represented using the following models and relations: ``` ConsolePort --> ConsoleServerPort PowerPort --> PowerOutlet Interface <-- InterfaceConnection --> Interface ``` A separate set of models is used for each of these as each type of connection may have different attributes associated with it. For example, a power outlet has an amperage and a voltage, whereas a network interface might have a MAC address and IP addresses assigned to it. Through several recent discussions, users have expressed the need to model additional types of physical connections within NetBox. While it would not be prudent to extend any of the existing models beyond their designed purpose, it might make sense to introduce new models which would allow users to define other types of connections. This is an exploratory feature request to compile user needs. If there's an additional type of physical connection you'd like to model in NetBox, please comment below. Be as detailed as possible when describing your use case: The more detail we can gather, the better we can hypothesize a data model.
adam added the status: accepted label 2025-12-29 16:25:39 +01:00
adam closed this issue 2025-12-29 16:25:39 +01:00
adam commented 2025-12-29 16:25:40 +01:00
Author
Owner
Copy Link

@ktims commented on GitHub (Mar 17, 2017):

Well, FibreChannel is the obvious first case, since it currently exists already in NetBox, but isn't an IP network. Stacking too, though the solution for this would seem to be explicit support for switch stacks (#99), rather than an expansion of interface types. Better support for VLANs/subinterfaces would also be nice, since it doesn't make sense for a tagged physical interface to have IPs bound either, though this also probably warrants a different approach.

I continue to advocate for generic, user-defined connection types. The model of interface <-> interface applies to a great many different kinds of non-IP interfaces, and being able to track these connections, even if their precise purpose-specific properties can't be tracked, would be very useful. In fact I don't want a domain-specific solution here; as you rightly point out elsewhere, this would lead to scope creep and clutter. Flexibility is king.

I still think that using the existing model, but allowing users to extend the type list makes the most sense. Just because it doesn't speak IP doesn't mean that the network model doesn't fit (evidenced by FC's inclusion); a network is fundamentally just a set of interconnected devices, and that is how it has been modelled in NetBox. Flags could be added to the types for features that NetBox supports, so a FC type doesn't have the 'can bind an IP address' property, but a custom 'POTS (ADSL)' type does, for example.

Having a separate generic model would be almost as useful though. Lots (10s?) of use cases have been enumerated in the other threads. I don't think many of them warrant explicit inclusion as features in NetBox, but being able to support all of them with one feature certainly would. I don't really want to get into my own use cases, because I would much rather see a generic solution implemented than one targeted at my own applications.

@ktims commented on GitHub (Mar 17, 2017): Well, FibreChannel is the obvious first case, since it currently exists already in NetBox, but isn't an IP network. Stacking too, though the solution for this would seem to be explicit support for switch stacks (#99), rather than an expansion of interface types. Better support for VLANs/subinterfaces would also be nice, since it doesn't make sense for a tagged physical interface to have IPs bound either, though this also probably warrants a different approach. I continue to advocate for generic, user-defined connection types. The model of interface <-> interface applies to a great many different kinds of non-IP interfaces, and being able to track these connections, even if their precise purpose-specific properties can't be tracked, would be very useful. In fact I don't want a domain-specific solution here; as you rightly point out elsewhere, this would lead to scope creep and clutter. Flexibility is king. I still think that using the existing model, but allowing users to extend the type list makes the most sense. Just because it doesn't speak IP doesn't mean that the network model doesn't fit (evidenced by FC's inclusion); a network is fundamentally just a set of interconnected devices, and that is how it has been modelled in NetBox. Flags could be added to the types for features that NetBox supports, so a FC type doesn't have the 'can bind an IP address' property, but a custom 'POTS (ADSL)' type does, for example. Having a separate generic model would be almost as useful though. Lots (10s?) of use cases have been enumerated in the other threads. I don't think many of them warrant explicit inclusion as features in NetBox, but being able to support all of them with one feature certainly would. I don't really want to get into my own use cases, because I would much rather see a generic solution implemented than one targeted at my own applications.
adam commented 2025-12-29 16:25:40 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 19, 2018):

As NetBox has gained quite a bit of popularity since its release, it's become increasingly important to limit and define its scope. NetBox is very well positioned as an IPAM/DCIM product and I want to avoid expanding any beyond that niche, particularly as there hasn't been much community interest in doing so. Closing this out.

@jeremystretch commented on GitHub (Oct 19, 2018): As NetBox has gained quite a bit of popularity since its release, it's become increasingly important to limit and define its scope. NetBox is very well positioned as an IPAM/DCIM product and I want to avoid expanding any beyond that niche, particularly as there hasn't been much community interest in doing so. Closing this out.
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
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#772
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?