netbox: Patching front port to virtual chassis member interface is broken in UI
NetBox version
v3.4.2
Python version
3.8
Steps to Reproduce
- Create an empty rack (default settings with 42 HUs works).
- Add a device with 1 front port to rack.
- Create a virtual chassis with at least two members (pos. 1, 2,…) with at least one interface each, no master chassis (!), add members to rack.
- Attach a cable from front port to an interface of VC member at pos. 2 or higher.
Expected Behavior
The cable should be attached between front port and VC member’s interface. Only the interfaces of selected VC member are shown.
Observed Behavior
The interface selection always show all interfaces of all VC members even if selected VC member is no master. This can lead to confusion because you don’t expect to see other VC members’ interfaces.
We’ve made the following observations.
- This issue only occurs for VC members, not for single devices in the same rack.
- If VC member’s interface X is already patched, interface X is always marked as not available to connect for all other VC members.
- Patching from the VC member’s interface view works which suggests that this is indeed a VC related problem.
- When in the cable creation UI and when selecting any VC member, scrolling through the interface selector will always list interfaces of all VC members, even if selected VC member isn’t a master chassis (or, as in our case, no VC member is configured as master chassis).
I believe that this is an UI issue. My guess is that in /dcim/cables/add, the Interface selector always displays VC member 1’s interfaces instead the actual selected VC member.
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 29 (12 by maintainers)
Commits related to this issue
- Fixes: #11478 - Alters interface serializers get_display to include device to string representation. — committed to netbox-community/netbox by DanSheps a year ago
- Fix #11478 - Add vc_interfaces flag to control selection of VC interfaces (#13296) * Add `vc_interfaces` flag to control interface queryset * Fix test failure * Add new filters instead of using... — committed to netbox-community/netbox by DanSheps 10 months ago
- Changelog for #11478, #13513, #13599, #13605 — committed to netbox-community/netbox by jeremystretch 10 months ago
If we changed the serializer to provide the device name as part of the interface lookup, would that suffice for most people?
This bug is leading to unexpected outcomes in the API as well as GUI. Compare results of https://demo.netbox.dev/dcim/interfaces/?device=mysampledevice2 and https://demo.netbox.dev/dcim/interfaces/?device_id=110
The proposal from kkthxbye-code appears very reasonable. Allow an additional parameter to the query where the caller can specify whether all interfaces of the virtual-chassis or of the member only should be returned. Defaulting to True on the master and False on the rest. Challenge comes when not specified and devices from different VCs are requested but then it can return 400 error for “ambiguous query”. LAG selection or other GUI/API use cases can select what is appropriate for them.
We don’t use VC in a non-intended purpose, see below. What I’m saying is that the patch in https://github.com/netbox-community/netbox/pull/10743 renders the purpose of a master chassis in a VC obsolete because it will turn every chassis into a master chassis when using the
filter_device_id()function. That clearly doesn’t make sense and it has side effects for every part of NetBox wherefilter_device_id()is called. Inmodel_forms.pyfor example, it makes no sense: when attaching a cable, NetBox lets you select a specific device so that NetBox’s UI only shows you interfaces on that particular device. With the current patch forfilter_device_id(), every interface of a VC is listed instead of only the interface of the selected device (which may be part of a VC). So https://github.com/netbox-community/netbox/pull/10743 breaks the selection of a single device in the UI. This was not the behaviour of the UI before the patch was introduced. This has nothing to do with interface naming in VCs. It’s only about breaking the UI when adding a cable (and maybe other places wherefilter_device_id()is used which we haven’t found yet). Note that @arthanson himself says in in https://github.com/netbox-community/netbox/pull/10743 that he doesn’t know if the patch may have side effects.RE: VCs (though this is independent of what’s stated above): we do use the VC function as intended. We chose not to make a chassis a master chassis in NetBox because our configuration management will look at every member of a VC to determine the interface configuration to use. The “x/y” notation of an interface is derived from x = position number of VC member in NetBox / y = interface number (as it is done by most switch vendors; x will change when changing the position of a chassis in a stack which is analogue to changing the VC position of a chassis in NetBox). I don’t see how that is a problem. We don’t use MC-LAG or VPC in that context. That way we don’t need to do any interface renaming and can simply use Device Types without changes. I can’t find NetBox documentation that states that this is an unintended approach. Using a master chassis and the functionality that comes with it is clearly optional in the docs.
@thefreakquency Yes, that’s the reason why we completely avoid using the “master chassis” option in NetBox because it’s no logical that a physical chassis seems to have more interfaces than it actually has. Not using the master chassis option may create other problems but for us that approach works. @troeger I agree what you write in the comment that you linked to. That being said, I think it would be a good idea to start a discussion on the Discussions page. My hope still is that the patch that causes unwanted side effects (on top of the UI issues described here) will be reverted.
@thefreakquency Totally agreed, here is my argument for having interface listings on virtual chassis …
https://github.com/netbox-community/netbox/discussions/10953#discussioncomment-4935174
I understand that one day it was decided to go a different path, but to me, all this would have been easier to deal with if the complete listing of interfaces would happen on the VC instead of the master member.
In our use case, I have to model a device without any physical interfaces (including power) to represent the stack/VC. This non-racked “device” contains only the virtual interfaces (VLAN interfaces, loopbacks, lags, etc) of the stack. Then I add the physical members to the stack and rack them. This way, each member only holds their physical interfaces. Ideally, the information I put in the device I create first to represent the stack would lie under the VC.
Putting all interfaces under the master member of VC is like mixing the concept of virtual and physical device.
Not sure if it would be too much of a breaking change to consider this again…