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

[jcralbino]

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

[jcralbino]

@candlerb i have opened this bug

[jeremystretch]

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.

[jcralbino]

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

[jeremystretch]

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.

[jcralbino]

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.

Details here on how this image was taken: #6116 (reply in thread)

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?

[jcralbino]

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)

[github-actions]

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.

[jcralbino]

@jeremystretch

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

[jeremystretch]

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.