starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-13 13:53:31 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Support for Switch Stacks #748

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

Originally created by @lampwins on GitHub (Mar 4, 2017).

Issue type: feature request

I tried to find this in past issues, sorry if this is a duplicate. I would like support for physical switch stacks (virtual chassis in juniper world). A stack made is up of several physical devices but managed as one device. The current parent/child device construct for internal bay based chassis device types will not suffice. I want to be able to rack the stack members independently (beyond the obvious here, another use case is for extended stacks that span more than one rack). This should also not require the creation of another special "stack member" role as this would lead to duplication of device types that are also allowed to be stand alone devices. I will begin implementing this to see what it would take.

Originally created by @lampwins on GitHub (Mar 4, 2017). ### Issue type: feature request I tried to find this in past issues, sorry if this is a duplicate. I would like support for physical switch stacks (virtual chassis in juniper world). A stack made is up of several physical devices but managed as one device. The current parent/child device construct for internal bay based chassis device types will not suffice. I want to be able to rack the stack members independently (beyond the obvious here, another use case is for extended stacks that span more than one rack). This should also not require the creation of another special "stack member" role as this would lead to duplication of device types that are also allowed to be stand alone devices. I will begin implementing this to see what it would take.
adam added the status: duplicate label 2025-12-29 16:25:25 +01:00
adam closed this issue 2025-12-29 16:25:25 +01:00
adam commented 2025-12-29 16:25:26 +01:00
Author
Owner
Copy Link

@dberube1 commented on GitHub (Mar 4, 2017):

There was a previous issue #99 that was created for this same request. The conclusion wound up being closing the ticket due to the complexities of creating a viable way of illustrating the interconnections of a stack as a single logical device in Netbox. This is a topic that may get revisited in the future.

That being said here's how I documented the virtual chassis's in my environment. This is an example of a Juniper EX4550 virtual chassis. Each member will be a separate device but the switches all show relationship with each other by being connected by the vcp ports. This would also allow you to extend the virtual chassis across racks easily.

  1. Create a device for each FPC in the stack with the appropriate interface names including the vcp ports.
  • FPC 0 - xe-0/0/0 thru xe-0/0/31; vcp-255/2/0, vcp-255/2/3
  • FPC 1 - xe-1/0/0 thru xe-1/0/31; vcp-255/2/0, vcp-255/2/3
  1. Connect the vcp ports from each switch to the corresponding port on the other switch. ex. vcp-255/2/0 on fpc0 goes to vcp-255/2/3 on fpc1.

I found this method to work pretty well and makes it easy to reconfigure my virtual chassis stacks in Netbox if I ever have to add/remove a switch from the virtual chassis.

@dberube1 commented on GitHub (Mar 4, 2017): There was a previous issue #99 that was created for this same request. The conclusion wound up being closing the ticket due to the complexities of creating a viable way of illustrating the interconnections of a stack as a single logical device in Netbox. This is a topic that may get revisited in the future. That being said here's how I documented the virtual chassis's in my environment. This is an example of a Juniper EX4550 virtual chassis. Each member will be a separate device but the switches all show relationship with each other by being connected by the vcp ports. This would also allow you to extend the virtual chassis across racks easily. 1. Create a device for each FPC in the stack with the appropriate interface names including the vcp ports. - FPC 0 - xe-0/0/0 thru xe-0/0/31; vcp-255/2/0, vcp-255/2/3 - FPC 1 - xe-1/0/0 thru xe-1/0/31; vcp-255/2/0, vcp-255/2/3 2. Connect the vcp ports from each switch to the corresponding port on the other switch. ex. vcp-255/2/0 on fpc0 goes to vcp-255/2/3 on fpc1. I found this method to work pretty well and makes it easy to reconfigure my virtual chassis stacks in Netbox if I ever have to add/remove a switch from the virtual chassis.
adam commented 2025-12-29 16:25:26 +01:00
Author
Owner
Copy Link

@BMH64 commented on GitHub (Mar 6, 2017):

For my Cisco stacks, I create the individual switches name them all as SWITCHNAME (SW1), SWITCHNAME (SW2), etc... and then on each of those device you create 2 interfaces that are stackwise or flexstack ports depending on your device and interconnect them. On the master switch is where I assign the IP address or any other stack specific info. That's the best way I have been able to do this.

@BMH64 commented on GitHub (Mar 6, 2017): For my Cisco stacks, I create the individual switches name them all as SWITCHNAME (SW1), SWITCHNAME (SW2), etc... and then on each of those device you create 2 interfaces that are stackwise or flexstack ports depending on your device and interconnect them. On the master switch is where I assign the IP address or any other stack specific info. That's the best way I have been able to do this.
adam commented 2025-12-29 16:25:26 +01:00
Author
Owner
Copy Link

@lampwins commented on GitHub (Mar 7, 2017):

I have been working on a PoC for this. Will update when I have a viable, long term model for it.

@lampwins commented on GitHub (Mar 7, 2017): I have been working on a PoC for this. Will update when I have a viable, long term model for it.
adam commented 2025-12-29 16:25:26 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 7, 2017):

I've reopened #99 due to the renewed interest in this feature. Marking this one as a duplicate and closing it out, but please feel free to continue the discussion in #99.

@jeremystretch commented on GitHub (Mar 7, 2017): I've reopened #99 due to the renewed interest in this feature. Marking this one as a duplicate and closing it out, but please feel free to continue the discussion in #99.
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: duplicate
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#748
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?