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

Virtual Chassis LAG configuration #1517

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

Originally created by @ghost on GitHub (Jan 29, 2018).

Issue type
[X] Feature request
[] Bug report
[] Documentation

Environment
Python version: 3.6
NetBox version: 2.3-beta1

Description
The new virtual chassis function doesn't include the LAG configuration inside the virtual chassis. When you are adding a LAG interface on one of the VC member its not possible to choose the LAG on one of the other devices. Its possible to add this feature in a new version?

Originally created by @ghost on GitHub (Jan 29, 2018). **Issue type** [X] Feature request [] Bug report [] Documentation **Environment** Python version: 3.6 NetBox version: 2.3-beta1 **Description** The new virtual chassis function doesn't include the LAG configuration inside the virtual chassis. When you are adding a LAG interface on one of the VC member its not possible to choose the LAG on one of the other devices. Its possible to add this feature in a new version?
adam added the type: bug label 2025-12-29 16:32:37 +01:00
adam closed this issue 2025-12-29 16:32:37 +01:00
adam commented 2025-12-29 16:32:38 +01:00
Author
Owner
Copy Link

@lampwins commented on GitHub (Jan 29, 2018):

I think this should also include virtual interfaces. The virtual chassis implementation is a great step forward, but I do not think in the current form, it solves the control plane model. In a virtual chassis, a physical interface may reside on a member, but it belongs to the virtual chassis, not that member, from a control plane perspective. LAG and virtual interfaces present an equally challenging case in that they only belong to the virtual chassis. So I still think the interfaces actually need to be stripped from the individual members and assigned only to the virtual chassis. When viewing an individual member, it makes sense to be able to see the interfaces that physically reside on that member. But doing so would allow LAG and virtual interfaces to be assigned to just the virtual chassis and for LAG member interfaces to span all members.

@lampwins commented on GitHub (Jan 29, 2018): I think this should also include virtual interfaces. The virtual chassis implementation is a great step forward, but I do not think in the current form, it solves the control plane model. In a virtual chassis, a physical interface may reside on a member, but it belongs to the virtual chassis, not that member, from a control plane perspective. LAG and virtual interfaces present an equally challenging case in that they _only_ belong to the virtual chassis. So I still think the interfaces actually need to be stripped from the individual members and assigned only to the virtual chassis. When viewing an individual member, it makes sense to be able to see the interfaces that physically reside on that member. But doing so would allow LAG and virtual interfaces to be assigned to just the virtual chassis and for LAG member interfaces to span all members.
adam commented 2025-12-29 16:32:38 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 30, 2018):

I did some work on this in 1cd629e; please try it out and let me know what you think.

For LAGs and virtual interfaces in general, the answer is going to be "only define them on the VC master." It's not ideal, but it's the most practical approach we have for now.

@jeremystretch commented on GitHub (Jan 30, 2018): I did some work on this in 1cd629e; please try it out and let me know what you think. For LAGs and virtual interfaces in general, the answer is going to be "only define them on the VC master." It's not ideal, but it's the most practical approach we have for now.
adam commented 2025-12-29 16:32:38 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 1, 2018):

This appears to be resolved. (Even if it isn't, please try any further testing on the develop-2.3 branch as the VirtualChassis data model has been overhauled.)

@jeremystretch commented on GitHub (Feb 1, 2018): This appears to be resolved. (Even if it isn't, please try any further testing on the `develop-2.3` branch as the VirtualChassis data model has been overhauled.)
adam commented 2025-12-29 16:32:38 +01:00
Author
Owner
Copy Link

@dgarros commented on GitHub (Feb 2, 2018):

@jeremystretch do you have a summary of the changes you are planning to make to the VC data model ?

I tried the current implementation in 2.3beta1 and I'm still trying to figure out the best way to consume a VC and easily collect all information needed to generate the configuration.

Thks

@dgarros commented on GitHub (Feb 2, 2018): @jeremystretch do you have a summary of the changes you are planning to make to the VC data model ? I tried the current implementation in 2.3beta1 and I'm still trying to figure out the best way to consume a VC and easily collect all information needed to generate the configuration. Thks
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: bug
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#1517
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?