Management of Switch Stacks / Virtual Chassis

[blindzero]

Hi there,

I know that there were already feature requests in the issues, but unfortunately they all have been closed, most of them with some comment like this

The current implementation most closely mirrors the way a stack actually functions: The master device is responsible for operation of the control plane. I'm sorry if the was this is implemented in NetBox does not meet your needs, but we will not be changing it.

Another hint was

I'm afraid this has already been discussed and we settled on the current implementation. The solution is to assign any "shared" interfaces to the virtual chassis master device.

The netbox documentation says on virtual chassis:

A virtual chassis represents a set of devices which share a common control plane. A common example of this is a stack of switches which are connected and configured to operate as a single managed device.

To achieve that I want to bring up again the idea / request to change or enhance the model of virtual chassis.

• the management IP is technically not coming from ONE interface in the master device, but available on all devices in the stack
• often the management is not only assigned to one dedicated interface, but also to a VLAN (any port of that VLAN) or LAG
• if defining some "virtual management" interface on the master device, I do not see any of the management / service information on any of the other member info pages
• the documentation's sentence "...share a common control plane" already states that all members share something else. It is not the case that the "master" shares something with the others

With these assumptions I also want to point out that I don't get the point why all interfaces of all members are shown in the master's interface list. Especially in more active/active-like configurations this is also not correct.
It also clutters the interface list very much. If a combined interface list should be presented, this should be the case in the virtual chassis / stack-level, not the individual device. Also because the interface naming is becoming wrong then. E.g. with cisco the interface name on a single device is e.g. te[1-24]. If I have 3 members in a stack I have these ports 3 times, not very helpful. In the stacke the interface name becomes te[unit#]/0/[1-24], so i.e. te3/0/24.

I also want to add personally, that I don't get why some of the feature requests are deflected by the team that strongly. Especially, when multiple users advocate for a change / can clearly explain the practical use-case...

Best & Thanks,
Matthias

[jcralbino]

Hi
I would also like to see additional importing the model how the stacks are modelled
Another issue, somehow related, comes on now to document correctly also multi chassis lags.

In some cases those devices have complete separate management plange , and control plane while using a protocol based where two devices control the status of a multi chassis link aggregation