Patching front port to virtual chassis member interface is broken in UI

[cs-1]

NetBox version

v3.4.2

Python version

3.8

Steps to Reproduce

1. Create an empty rack (default settings with 42 HUs works).
2. Add a device with 1 front port to rack.
3. 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.
4. 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.

[DanSheps]

So what is happening is we are actually getting all interfaces from the VC when querying this method (if you search for chassis specific interfaces, you will see them). I will need to confirm that this is the intended result, I don't believe so though.

[cs-1]

Hi Dan! The behaviour was different in earlier versions. Regarding the intended result: the observed behaviour would be correct for a master chassis where all interfaces of members of the same VC should be listed. For non-master chassis it should only list the interfaces of that particular chassis. (We don't use the master chassis functionality in our scenario.)

[cs-1]

Quick P.S.: the problem also exists in v3.4.3.

[lp-2]

hi @DanSheps
Could you please tell me the exact path in the source code where the problem is located? I would like to try to fix it.

Thanks in advance

[kkthxbye-code]

Seems to be caused by: #10743

Changing the API to always return all VC interfaces when filtering on device id seems like an error, though I get why it was needed for LAG assignment. Not sure what the correct solution is here. Reverting the change would break LAG assignment again I assume.

[cs-1]

The change definitely breaks what used to work in the UI. Does it make sense to discuss this with @jeremystretch ? @lp-2 is currently trying to figure out a solution but we probably don't have enough insight into the design of NetBox to tell whether our proposed solution is acceptable (if we find one, that is).

[kkthxbye-code]

@cs-1 - A couple of things:

Cable is actually always attached to VC member 1's interface with the same number.

This is not the case for me. When attaching the cable, all interfaces show up but it's still possible to attach them to the right device, it's just impossible to know which device is which if the interfaces are named the same.

but we probably don't have enough insight into the design of NetBox to tell whether our proposed solution is acceptable (if we find one, that is).

I guess one option is to:

• Revert the change in 10610 interface_id query on lag return vc interfaces #10743
• Add an option to the rest API for interfaces that controls wether vc interfaces are included in situations where the device is not a master.
• Refix the LAG select field issue in Can't assign interface to LAG from slave device of virtual chassis #10610 with the new API option.

Wether this makes sense in a modelling sense I can't tell you, I know next to nothing about VC's.

[cs-1]

This is not the case for me. When attaching the cable, all interfaces show up but it's still possible to attach them to the right device, it's just impossible to know which device is which if the interfaces are named the same.

Yes, same here. But that's exactly the problem. In VC scenarios, interface numbers "y" can be the same on each individual VC member. Only the VC chassis position "x" gives your an identification "x/y" of an interface. There's typically no need to add "x" to each chassis member's interface name, it's redundant information and it also makes using "Device Type" templating difficult to use because in these templates, interfaces are numerated as if not part of a VC (y = 1..48).

• Add an option to the rest API for interfaces that controls wether vc interfaces are included in situations where the device is not a master.
• Refix the LAG select field issue in Can't assign interface to LAG from slave device of virtual chassis #10610 with the new API option.

These two options sound reasonable. I tend to think that refixing the LAG select field issue is the most plausible solution. It's not logical to get all interfaces of all VC members when querying only a single, non-master VC member.

[kkthxbye-code]

Yes, same here. But that's exactly the problem. In VC scenarios, interface numbers "y" can be the same on each individual VC member. Only the VC chassis position "x" gives your an identification "x/y" of an interface. There's typically no need to add "x" to each chassis member's interface name, it's redundant information and it also makes using "Device Type" templating difficult to use because in these templates, interfaces are numerated as if not part of a VC (y = 1..48).

I understand the issue, just wanted to clarify that what I quoted from the original issue wasn't correct, as it makes it seem like regardless of which interface you pick it is always connected to the lowest index VC member. If you don't mind, please update the issue text for posterity.

It's not logical to get all interfaces of all VC members when querying only a single, non-master VC member.

I agree, and I'm sure it was unintended, and thus a bug. Let me know if you want to try to contribute a fix yourself :)

[cs-1]

I understand the issue, just wanted to clarify that what I quoted from the original issue wasn't correct, as it makes it seem like regardless of which interface you pick it is always connected to the lowest index VC member. If you don't mind, please update the issue text for posterity.

Oops! Yes, I'll fix the description. Sorry for the confusion.

I agree, and I'm sure it was unintended, and thus a bug. Let me know if you want to try to contribute a fix yourself :)

Yes, that's what we try to figure out whether we can help to fix it. @lp-2 is currently looking into the code.