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 port functionality to virtual chassis #9084

New Issue
Closed
opened 2025-12-29 20:45:13 +01:00 by adam · 8 comments
adam commented 2025-12-29 20:45:13 +01:00
Owner
Copy Link

Originally created by @jschewebbn on GitHub (Jan 12, 2024).

NetBox version

v3.6.4

Feature type

Change to existing functionality

Proposed functionality

Currently one can view all interfaces for a virtual chassis on the master device. It would be helpful to be able to view the front and rear ports as well. In addition I suggest that the display of intefaces, front ports and rear ports be added to the display screen for a virtual chassis.

Use case

This makes it easier to make cable connections from a virtual device as one can find all of the information on the virtual device itself.

By adding ports support to the virtual device one can create virtual patch panels in addition to stacked switches. This is useful when there are a number of physical patch panels in a rack where all ports are uniquely numbered and one needs to connect a cable from that stack of patch panels to another device. One doesn't need to remember which physical patch panel the port is on, only the label of the port.

Database changes

No response

External dependencies

No response

Originally created by @jschewebbn on GitHub (Jan 12, 2024). ### NetBox version v3.6.4 ### Feature type Change to existing functionality ### Proposed functionality Currently one can view all interfaces for a virtual chassis on the master device. It would be helpful to be able to view the front and rear ports as well. In addition I suggest that the display of intefaces, front ports and rear ports be added to the display screen for a virtual chassis. ### Use case This makes it easier to make cable connections from a virtual device as one can find all of the information on the virtual device itself. By adding ports support to the virtual device one can create virtual patch panels in addition to stacked switches. This is useful when there are a number of physical patch panels in a rack where all ports are uniquely numbered and one needs to connect a cable from that stack of patch panels to another device. One doesn't need to remember which physical patch panel the port is on, only the label of the port. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: feature label 2025-12-29 20:45:13 +01:00
adam closed this issue 2025-12-29 20:45:14 +01:00
adam commented 2025-12-29 20:45:14 +01:00
Author
Owner
Copy Link

@jschewebbn commented on GitHub (Jan 12, 2024):

This has been discussed at https://github.com/netbox-community/netbox/discussions/12525

@jschewebbn commented on GitHub (Jan 12, 2024): This has been discussed at https://github.com/netbox-community/netbox/discussions/12525
adam commented 2025-12-29 20:45:15 +01:00
Author
Owner
Copy Link

@jeffgdotorg commented on GitHub (Jan 16, 2024):

Thanks for your interest in helping improve NetBox, and for taking the time to write a clear use case.

What you describe makes a kind of sense, but we think it strays too far from the first point of the NetBox design philosophy – "replicate the real world" – due to its repurposing of the virtual chassis object. Virtual chassis explicitly model collections of network devices with a shared control plane. Patch panels look similar at first glance, but their function is completely different and they lack anything resembling a control plane.

I'm closing this issue, but you may want to talk through your needs in discussions or in NetDev Slack. Somebody else may have hit upon a clever way of doing what you describe without any code changes.

@jeffgdotorg commented on GitHub (Jan 16, 2024): Thanks for your interest in helping improve NetBox, and for taking the time to write a clear use case. What you describe makes a kind of sense, but we think it strays too far from the first point of the NetBox design philosophy – ["replicate the real world"](https://docs.netbox.dev/en/stable/introduction/#replicate-the-real-world) – due to its repurposing of the virtual chassis object. Virtual chassis explicitly model collections of network devices with a shared control plane. Patch panels look similar at first glance, but their function is completely different and they lack anything resembling a control plane. I'm closing this issue, but you may want to talk through your needs in discussions or in NetDev Slack. Somebody else may have hit upon a clever way of doing what you describe without any code changes.
adam commented 2025-12-29 20:45:15 +01:00
Author
Owner
Copy Link

@jschewebbn commented on GitHub (Jan 17, 2024):

@jeffgdotorg there is a linked discussion where others were in support of this functionality. No one has come up with another option thus far.

Also what about the functionality to view the interfaces on the virtual chassis?

@jschewebbn commented on GitHub (Jan 17, 2024): @jeffgdotorg there is a linked discussion where others were in support of this functionality. No one has come up with another option thus far. Also what about the functionality to view the interfaces on the virtual chassis?
adam commented 2025-12-29 20:45:15 +01:00
Author
Owner
Copy Link

@jschewebbn commented on GitHub (Jan 17, 2024):

Note that this is an attempt to fix part of the functionality that was lost with version 3.6 as discussed in https://github.com/netbox-community/netbox/discussions/14354 and https://github.com/netbox-community/netbox/discussions/12525

@jschewebbn commented on GitHub (Jan 17, 2024): Note that this is an attempt to fix part of the functionality that was lost with version 3.6 as discussed in https://github.com/netbox-community/netbox/discussions/14354 and https://github.com/netbox-community/netbox/discussions/12525
adam commented 2025-12-29 20:45:15 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 17, 2024):

@jschewebbn The purpose of the virtual chassis model in NetBox is to model physical discrete devices which function with shared management planes, such a stack of switches configured to be managed as one. As this concept does not apply to patch panels, which have no management plane, it would not make sense to implement the proposed functionality.

No one has come up with another option thus far.

The proper approach would be to model these patch panels as individual devices, because they are.

@jeremystretch commented on GitHub (Jan 17, 2024): @jschewebbn The purpose of the [virtual chassis](https://docs.netbox.dev/en/stable/models/dcim/virtualchassis/) model in NetBox is to model physical discrete devices which function with shared management planes, such a stack of switches configured to be managed as one. As this concept does not apply to patch panels, which have no management plane, it would not make sense to implement the proposed functionality. > No one has come up with another option thus far. The proper approach would be to model these patch panels as individual devices, because they are.
adam commented 2025-12-29 20:45:16 +01:00
Author
Owner
Copy Link

@jschewebbn commented on GitHub (Jan 17, 2024):

Right, I am modeling the patch panels as separate devices. The issue is that a group of patch panels are labeled as a full group and knowing which number is in which distinct panel isn't always obvious. For instance if I have 2 48 port patch panels, the first one is labeled 1 through 48 and the second is labeled 49 through 96. It is nice to be able to say the cable is connected to port 50 and not need to remember which physical panel it's in. Furthermore I have cases where the patch panels are all labeled in a single group however not consecutively across the physical panels, so one must guess which panel has which port. I saw this functionality as similar to the access to the interfaces of all switches in a stack, as did others in the discussion, thus the feature request.

The second part of this feature request is displaying the interfaces (and possibly front and rear ports) on the virtual chassis display page. This would help with the functionality that was removed in version 3.6 for cable connections to switch stacks, see https://github.com/netbox-community/netbox/discussions/14354 for more details on that.

@jschewebbn commented on GitHub (Jan 17, 2024): Right, I am modeling the patch panels as separate devices. The issue is that a group of patch panels are labeled as a full group and knowing which number is in which distinct panel isn't always obvious. For instance if I have 2 48 port patch panels, the first one is labeled 1 through 48 and the second is labeled 49 through 96. It is nice to be able to say the cable is connected to port 50 and not need to remember which physical panel it's in. Furthermore I have cases where the patch panels are all labeled in a single group however not consecutively across the physical panels, so one must guess which panel has which port. I saw this functionality as similar to the access to the interfaces of all switches in a stack, as did others in the discussion, thus the feature request. The second part of this feature request is displaying the interfaces (and possibly front and rear ports) on the virtual chassis display page. This would help with the functionality that was removed in version 3.6 for cable connections to switch stacks, see https://github.com/netbox-community/netbox/discussions/14354 for more details on that.
adam commented 2025-12-29 20:45:16 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Jan 17, 2024):

The issue is that a group of patch panels are labeled as a full group and knowing which number is in which distinct panel isn't always obvious.

Unfortunately, this sounds more like a policy/procedure/standards issue rather then a issue that NetBox can solve. The virtual chassis model is not indended to resolve your specific use case.

The second part of this feature request is displaying the interfaces (and possibly front and rear ports) on the virtual chassis display page. This would help with the functionality that was removed in version 3.6 for cable connections to switch stacks, see #14354 for more details on that.

You would need to open a separate FR for that. We don't "combine" FR's unless the two requests are so intertwined that it doesn't make sense to open two separate FR's.

@DanSheps commented on GitHub (Jan 17, 2024): > The issue is that a group of patch panels are labeled as a full group and knowing which number is in which distinct panel isn't always obvious. Unfortunately, this sounds more like a policy/procedure/standards issue rather then a issue that NetBox can solve. The virtual chassis model is not indended to resolve your specific use case. > The second part of this feature request is displaying the interfaces (and possibly front and rear ports) on the virtual chassis display page. This would help with the functionality that was removed in version 3.6 for cable connections to switch stacks, see #14354 for more details on that. You would need to open a separate FR for that. We don't "combine" FR's unless the two requests are so intertwined that it doesn't make sense to open two separate FR's.
adam commented 2025-12-29 20:45:16 +01:00
Author
Owner
Copy Link

@jschewebbn commented on GitHub (Jan 18, 2024):

Thank you for the replies. I was hoping that netbox would be able to help make the policy easier, however I'll go back and work with our team on that.

I understand having separate FRs, I'll make sure to put a separate one in if we determine it's useful. Without the ports it's less likely to be useful.

@jschewebbn commented on GitHub (Jan 18, 2024): Thank you for the replies. I was hoping that netbox would be able to help make the policy easier, however I'll go back and work with our team on that. I understand having separate FRs, I'll make sure to put a separate one in if we determine it's useful. Without the ports it's less likely to be useful.
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 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#9084
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?