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

Link Aggregation created in a switch assigned to a virtual chassis is not available for the second switch #4962

New Issue
Closed
opened 2025-12-29 19:22:40 +01:00 by adam · 10 comments
adam commented 2025-12-29 19:22:40 +01:00
Owner
Copy Link

Originally created by @jcralbino on GitHub (Jun 3, 2021).

NetBox version

v2.11.4

Python version

3.8

Steps to Reproduce

Using the GUI we performed this:

  1. Created a virtual chassis: stack-1-withoutmaster

  2. Create first switch: stack1-sw1

  3. Create second switch: stack1-sw2

  4. Associate them to the stack-1-withoutmaster, without selecting a master.
    As i do not associate a master both switches have only their own interfaces

  5. Create Link Aggregation type (lag-stack1-port1) in stack1-sw1

  6. Associate lag-stack-port1 to stack1-sw1 interface e1/1

  7. Failed to associate lag-stack-port1 on stack1-sw2.

This is not possible now in 2.11.4 , It was possible in 2.11.2

Expected Behavior

  1. Created a virtual chassis: stack-1-withoutmaster

  2. Create first switch: stack1-sw1

  3. Create second switch: stack1-sw2

  4. Associate them to the stack-1-withoutmaster, without selecting a master.
    As i do not associate a master both switches have only their own interfaces

  5. Create Link Aggregation type (lag-stack1-port1) in stack1-sw1

  6. Associate lag-stack-port1 to stack1-sw1 interface e1/1

  7. Associate lag-stack-port1 on stack1-sw2 on interface e1/1

Observed Behavior

LAG object not provided in the dropdown menu

Originally created by @jcralbino on GitHub (Jun 3, 2021). ### NetBox version v2.11.4 ### Python version 3.8 ### Steps to Reproduce Using the GUI we performed this: 1. Created a virtual chassis: stack-1-withoutmaster 2. Create first switch: stack1-sw1 3. Create second switch: stack1-sw2 4. Associate them to the stack-1-withoutmaster, without selecting a master. As i do not associate a master both switches have only their own interfaces 5. Create Link Aggregation type (lag-stack1-port1) in stack1-sw1 6. Associate lag-stack-port1 to stack1-sw1 interface e1/1 7. Failed to associate lag-stack-port1 on stack1-sw2. This is not possible now in 2.11.4 , It was possible in 2.11.2 ### Expected Behavior 1. Created a virtual chassis: stack-1-withoutmaster 2. Create first switch: stack1-sw1 3. Create second switch: stack1-sw2 4. Associate them to the stack-1-withoutmaster, without selecting a master. As i do not associate a master both switches have only their own interfaces 5. Create Link Aggregation type (lag-stack1-port1) in stack1-sw1 6. Associate lag-stack-port1 to stack1-sw1 interface e1/1 7. Associate lag-stack-port1 on stack1-sw2 on interface e1/1 ### Observed Behavior LAG object not provided in the dropdown menu
adam added the status: under review label 2025-12-29 19:22:40 +01:00
adam closed this issue 2025-12-29 19:22:40 +01:00
adam commented 2025-12-29 19:22:40 +01:00
Author
Owner
Copy Link

@jcralbino commented on GitHub (Jun 3, 2021):

@candlerb i have opened this bug

@jcralbino commented on GitHub (Jun 3, 2021): @candlerb i have opened this bug
adam commented 2025-12-29 19:22:41 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 3, 2021):

IMO this is desired behavior. The LAG selection widget relies on the device_id filter to filter the list of interface choices returned. This filter restricts the interfaces queryset to only those assigned to the specified device or, if the device is a VC master, to a peer VC member. Altering this behavior would break the filter for other uses.

As i do not associate a master both switches have only their own interfaces

Setting a VC master and defining the LAG interfaces on that master will resolve the issue.

@jeremystretch commented on GitHub (Jun 3, 2021): IMO this is desired behavior. The LAG selection widget relies on the `device_id` filter to filter the list of interface choices returned. This filter restricts the interfaces queryset to only those assigned to the specified device or, _if the device is a VC master_, to a peer VC member. Altering this behavior would break the filter for other uses. > As i do not associate a master both switches have only their own interfaces Setting a VC master and defining the LAG interfaces on that master will resolve the issue.
adam commented 2025-12-29 19:22:41 +01:00
Author
Owner
Copy Link

@jcralbino commented on GitHub (Jun 4, 2021):

This is a undesired behaviour in my opinion as it will limit the utilisation of the virtualchassis.

There many use cases where setting a master is not mandatory, as within the multi chassis environment were we do not have a shared control plane. Therefore the interfaces will be kept in each member and not renamed in those cases

This is something I tested in previous versions and that was working

@jcralbino commented on GitHub (Jun 4, 2021): This is a undesired behaviour in my opinion as it will limit the utilisation of the virtualchassis. There many use cases where setting a master is not mandatory, as within the multi chassis environment were we do not have a shared control plane. Therefore the interfaces will be kept in each member and not renamed in those cases This is something I tested in previous versions and that was working
adam commented 2025-12-29 19:22:41 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 4, 2021):

as within the multi chassis environment were we do not have a shared control plane

Ah, I think this is the crux of your problem. A virtual chassis is intended to model a shared control plane. If the devices have independent control planes (as in a multi-chassis LAG deployment), a virtual chassis should not be used, because they are still independent devices. Each device in a multi-chassis LAG setup has its own LAG interface that needs to be modeled discretely.

@jeremystretch commented on GitHub (Jun 4, 2021): > as within the multi chassis environment were we do not have a shared control plane Ah, I think this is the crux of your problem. A virtual chassis is intended to model a shared control plane. If the devices have independent control planes (as in a multi-chassis LAG deployment), a virtual chassis should not be used, because they are still independent devices. Each device in a multi-chassis LAG setup has its own LAG interface that needs to be modeled discretely.
adam commented 2025-12-29 19:22:41 +01:00
Author
Owner
Copy Link

@jcralbino commented on GitHub (Jun 4, 2021):

What I have seen is that we are not enforcing here the placement of a master.

With this in mind I see here two possibilities for its utilisation

  1. Virtual chassis with master configured :
  • master handles management plane where one ip is used to manage the full virtual chassis
  • master handles control plane and Data plane
  • Normally a rename of interfaces of the second member is mandatory as the master will own this interfaces
  • typical use case for switches
  1. Virtual chassis without master:
  • the devices are part of a chassis or cluster.
  • Each device is Maintaining its management plane
  • The control plane and data plane does not require interfaces renaming
    Example where a Multi-chassis lag is implemented using a protocol(vPC for example). In terms of your remark here, i believe that this is not completely accurate.

Each device in a multi-chassis LAG setup has its own LAG interface that needs to be modeled discretely.

In this cases we can model this still with a shared LAG interface. Having the same name across two devices.
This is what i got when i tested this in 2.11.2, where i was able to have virtual chassis without a master, and still associate the same lag interface to both switches.
image
Details here on how this image was taken: https://github.com/netbox-community/netbox/discussions/6116#discussioncomment-687381

  1. As a summary of possible examples for this use case where a master is not set.
    1. cluster of firewall, where active / passive is used but interfaces are owned by each device. Each interface should be configured exactly the same and we can use netbox to report and test this compliance.
    2. cluster of load balancer, with similar approach for the firewall
    3. to support all types of multi chassis link aggregation. Like a
      VPC domains in Cisco, where a link aggregation can be used across two devices that do no have a master device . ( current limited on the way lag interfaces widget provides available interfaces )

If these use cases are not be supported then the utilization of a master should be enforced.

But as this was working in 2.11.2, and probably other versions although i can't confirm.
I believe that enforcing the use of lag only when a master is configured is too limited .
Is there a strong technical reason for this, as it seems the database is already prepared to support this option?

@jcralbino commented on GitHub (Jun 4, 2021): What I have seen is that we are not enforcing here the placement of a master. With this in mind I see here two possibilities for its utilisation 1. Virtual chassis with master configured : - master handles management plane where one ip is used to manage the full virtual chassis - master handles control plane and Data plane - Normally a rename of interfaces of the second member is mandatory as the master will own this interfaces - typical use case for switches 2. Virtual chassis without master: - the devices are part of a chassis or cluster. - Each device is Maintaining its management plane - The control plane and data plane does not require interfaces renaming Example where a Multi-chassis lag is implemented using a protocol(vPC for example). In terms of your remark here, i believe that this is not completely accurate. > Each device in a multi-chassis LAG setup has its own LAG interface that needs to be modeled discretely. In this cases we can model this still with a shared LAG interface. Having the same name across two devices. This is what i got when i tested this in 2.11.2, where i was able to have virtual chassis without a master, and still associate the same lag interface to both switches. ![image](https://user-images.githubusercontent.com/44149262/120890066-d1609700-c600-11eb-848d-4870102fba58.png) Details here on how this image was taken: https://github.com/netbox-community/netbox/discussions/6116#discussioncomment-687381 3. As a summary of possible examples for this use case where a master is not set. 1) cluster of firewall, where active / passive is used but interfaces are owned by each device. Each interface should be configured exactly the same and we can use netbox to report and test this compliance. 2) cluster of load balancer, with similar approach for the firewall 3) to support all types of multi chassis link aggregation. Like a VPC domains in Cisco, where a link aggregation can be used across two devices that do no have a master device . ( current limited on the way lag interfaces widget provides available interfaces ) If these use cases are not be supported then the utilization of a master should be enforced. But as this was working in 2.11.2, and probably other versions although i can't confirm. I believe that enforcing the use of lag only when a master is configured is too limited . Is there a strong technical reason for this, as it seems the database is already prepared to support this option?
adam commented 2025-12-29 19:22:42 +01:00
Author
Owner
Copy Link

@jcralbino commented on GitHub (Jun 4, 2021):

The LAG selection widget relies on the device_id filter to filter the list of interface choices returned. This filter restricts the interfaces queryset to only those assigned to the specified device or, if the device is a VC master, to a peer VC member. Altering this behavior would break the filter for other uses.

Can we create a different filter for the lag interfaces widget in order to restrict the interfaces queryset ( they should be all of the lag type) to only those assigned to the specified device or, if the device is a VC member, to the other peer VC member.

Also this will reduce the impact of this change. If we return only in the filter, interfaces of the lag type then we will not have interface name colision (other interfaces that may have same name across a virtual chassis)

@jcralbino commented on GitHub (Jun 4, 2021): > _The LAG selection widget relies on the device_id filter to filter the list of interface choices returned. This filter restricts the interfaces queryset to only those assigned to the specified device or, if the device is a VC master, to a peer VC member. Altering this behavior would break the filter for other uses._ > Can we create a different filter for the lag interfaces widget in order to restrict the interfaces queryset ( they should be all of the lag type) to only those assigned to the specified device or, if the device is a VC member, to the other peer VC member. Also this will reduce the impact of this change. If we return only in the filter, interfaces of the lag type then we will not have interface name colision (other interfaces that may have same name across a virtual chassis)
adam commented 2025-12-29 19:22:42 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Aug 13, 2021):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Aug 13, 2021): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:22:42 +01:00
Author
Owner
Copy Link

@jcralbino commented on GitHub (Sep 1, 2021):

@jeremystretch

Is there a change we can revisit this ? Can we use separate interface filters for the link aggregation interfaces as discussed above ?

@jcralbino commented on GitHub (Sep 1, 2021): @jeremystretch Is there a change we can revisit this ? Can we use separate interface filters for the link aggregation interfaces as discussed above ?
adam commented 2025-12-29 19:22:42 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 1, 2021):

No, I'm afraid we cannot. I explained above that this is an intentional design choice. You'll need to define a LAG interface for each member of a multi-chassis LAG.

@jeremystretch commented on GitHub (Sep 1, 2021): No, I'm afraid we cannot. I explained above that this is an intentional design choice. You'll need to define a LAG interface for each member of a multi-chassis LAG.
adam commented 2025-12-29 19:22:43 +01:00
Author
Owner
Copy Link

@jcralbino commented on GitHub (Sep 3, 2021):

Hello Jeremy. Thanks for the reply.

Then we should add to the documentation that a master in a virtual chassis is mandatory. As it is not clear to me what is the use case where it makes sense to have a virtual chassis without a master .

I am sure a lot of people are using this without a master, but the documentation should make clear what is the use case for when a virtual chassis without master can be used .

@jcralbino commented on GitHub (Sep 3, 2021): Hello Jeremy. Thanks for the reply. Then we should add to the documentation that a master in a virtual chassis is mandatory. As it is not clear to me what is the use case where it makes sense to have a virtual chassis without a master . I am sure a lot of people are using this without a master, but the documentation should make clear what is the use case for when a virtual chassis without master can be used .
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: under review
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#4962
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?