Device view showing wrong interfaces when part of a Virtual Chassis

[svetlinski]

Good afternoon,

I have recently created Patch Panel devices with front and rear ports in our Netbox. I proceeded to enter information about the cables and connect the front ports to the switch ports.
When I look at the patch panel "device" view, it's all good - I can see all the cables, labels, and where they are connected.
Currently, some of the ports in 1 patch panel connect to 1 switch and other ports, to a second switch. For example, port 1 connects to Switch A and port 2 connects to Switch B. Those are displayed without issues at the patch panel page.
When I open the page for Switch A, it seems to display the interfaces for both - Switch A and Switch B

Here, you can see that somehow, there are 2 interfaces under the same device.
The Interfaces page for Switch A shows 100 interfaces, when in fact, the switch only has 52 physical interfaces on its own.
The Interfaces page for Switch B shows 52 interfaces.
If I remove the additional interfaces from Switch A, they are also removed from Switch B.
There is a virtual chassis created, it includes 4 physical switches. Switch A and Switch B are part of this virtual chassis. Switch A is the master of the vc.
If I delete the virtual chassis, then all the interfaces are split correctly. When I deleted the virtual chassis, I checked Switch A and it showed the correct 52 interfaces. Switch B also showed the correct 52 interfaces.
The below is from Switch A, you can clearly see that the interfaces are properly numbered and not repeating following the deletion of the vc.

Is this a known bug that has been fixed and all I need to do is upgrade?

Thanks in advance.

[kkthxbye-code]

Not sure I understand completely what you are saying, but it seems like you just misunderstood what virtual chassis are in netbox.

https://docs.netbox.dev/en/stable/models/dcim/virtualchassis/

One of the member devices may be designated as the VC master: This device will typically be assigned a name, services, virtual interfaces, and other attributes related to managing the VC. If a VC master is defined, interfaces from all VC members are displayed when navigating to its device interfaces view. This does not include management-only interfaces belonging to other members.

[svetlinski]

I see, thank you for the supplied information. I guess this depends on whether any of the interfaces are actually connected or not?
For example, I have created many other VCs, but when I look at the master, it doesn't show me the rest of the members' interfaces in the interface view. This new VC is the first one I noticed it displays the other members' interfaces and the only difference here is that those are now properly connected all the way through, rather than just enabled and created in Netbox. Could that be why I see difference in the VCs and masters' interface views?

[kkthxbye-code]

I guess this depends on whether any of the interfaces are actually connected or not?

No, the only exception is management interfaces, all other interfaces are shown on the master.

[troeger]

In relation to this discussion, as well as issues #10610 and #11718, I would argue that the current behavior of Netbox with respect to interfaces and virtual chassis is problematic. It would be interesting to have some insights about the original motivation for this feature.

The data model of Netbox is strictly hierarchical and very explicit, which is one of the things I really like about it. The behavior here, however, seems to break the synchronicity of actions:

• When I add a second device to a virtual chassis, and query the list of devices afterwards, two devices are returned.
• When I add a second interface to a normal device, and query the list of interfaces for this device afterwards, two interfaces are returned.
• When I add a second interface to a device in a virtual chassis, and query the list of interfaces for this device afterwards, the result depends on something completely unrelated to the device itself.

I would argue that "magically" varying the list of interfaces for a device, depending on the context it is living in (= virtual chassis), is confusing. It is in conflict with the mental model being build up by most other parts of Netbox.

The obvious alternative to the current behavior is to have a read-only list of interfaces on the virtual chassis, generated from the participating devices. Device interfaces are always the interfaces of this device. But ... I am pretty sure that this approach was ruled out originally for some good reason.

[mtinberg]

I can't speak for the Netbox developers, but the main purpose of Netbox is to drive configuration management process, and stacked devices (Virtual Chassis) have one control plane and behave as one device, so having queries of the primary Device return all the interfaces managed by that control plane makes sense for templating configs. The devices aren't the data model and the data model isn't the devices, so while stacked devices have multiple Device records so that the individual components can be placed in Racks, logically it operates as one device which is how the Interfaces are integrated. — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: Peter Tröger ***@***.***> Sent: Friday, February 10, 2023 7:34 AM To: netbox-community/netbox ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [netbox-community/netbox] Device view showing wrong interfaces when part of a Virtual Chassis (Discussion #10953) In relation to this discussion, as well as issues #10610<#10610> and #11718<#11718>, I would argue that the current behavior of Netbox with respect to interfaces and virtual chassis is problematic. It would be interesting to have some insights about the original motivation for this feature. The data model of Netbox is strictly hierarchical and very explicit, which is one of the things I really like about it. The behavior here, however, seems to break the synchronicity of actions: * When I add a second device to a virtual chassis, and query the list of devices afterwards, two devices are returned. * When I add a second interface to a normal device, and query the list of interfaces for this device afterwards, two interfaces are returned. * When I add a second interface to a device in a virtual chassis, and query the list of interfaces for this device afterwards, the result depends on something completely unrelated to the device itself. I would argue that "magically" varying the list of interfaces for a device, depending on the context it is living in (= virtual chassis), is confusing. It is in conflict with the mental model being build up by most other parts of Netbox. The obvious alternative to the current behavior is to have a read-only list of interfaces on the virtual chassis, generated from the participating devices. Device interfaces are always the interfaces of this device. But ... I am pretty sure that this approach was ruled out originally for some good reason. — Reply to this email directly, view it on GitHub<#10953 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM7B25D6IAZIWCFUVLDWWY7X5ANCNFSM6AAAAAASDM6Q3A>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[troeger]

I totally understand the intended use case, so please see this mainly as a concept debate.

The assumption here is that a shared management plane somehow extends the list of interfaces for one particular device (=VC master). The chassis members collaborate so that a non-master VC member is "borrowing" its physical interfaces to the master. The latter now has a combination of physical and borrowed interfaces. The master "is" the VC.

Given the fact that physical (!) cable management and rack placement are a fundamental purpose of Netbox, I find it just surprising to "weaken" the device concept in this way. A list of interfaces for a physical device can not be trusted to be a list of connection endpoints for this (!) physical device. The list may even dynamically change, without changing the device itself.

In my personal opinion, VC member interfaces should be moved to the VC object itself. As you said - this is now a new device that collects all the member interfaces. VC member devices should then have their interfaces "removed", or at least have them locked for editing and connecting. You no longer connect a cable to a physical device interface, you connect it to a VC interface.

[mtinberg]

The assumption here is that a shared management plane somehow extends the list of interfaces for one particular device (=VC master).

Yes, from a logical and config management perspective a stacked device is one device, the interfaces are all part of one device.

cable management and rack placement are a fundamental purpose of Netbox

Config management and physical management are both fundamental purposes of Netbox and in this case there are some conflicting requirements, so decisions need to be made as to which trade-offs are worth making.

In my personal opinion, VC member interfaces should be moved to the VC object itself.

There is already another case where Device records aren't used and that is for Virtual Machines, your proposal would separate singleton Devices from stacked Virtual Chassis in as fundamental a way as VMs are separated from Devices. People using Netbox for config management would need to query both data models to get all the inventory needed and many more fields/custom_fields would need to be duplicated between Device and VirtualChassis, along with other inbound references from other models. This also creates problems when a singleton device is upgraded to a stack, do the db records need to be rewritten for all attached interfaces? Are related fields like Platform inherited?

You no longer connect a cable to a physical device interface, you connect it to a VC interface.

I'm not sure what the benefit here is, you still have to physically connect a cable to the right interface, Gi2/0/10 being referenced from the VC switch-idf-3 instead of Device switch-idf-3:2, the actual physical device doesn't seem any easier to me. it might be a no-op because usually stacking cables are short and the devices are racked in-order, so the interface name also tells you which stack member it belongs to, although that doesn't have to be the case, if there were overlapping stacks in a rack you'd definitely want to have the members well labeled. eg. ru1: switch-idf-3 ru2: switch-idf-4 ru3: switch-idf-3:2 (expanded switch-idf-3 later) ... I'm not sure how explicit your instructions to field service staff need to be to get the right result when handing out cutover sheets, is there confustion being caused by the way this is modeled? — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison [cid:2bdbbe9c-83e9-4f13-9ca4-7305e09c8d66]

…

________________________________ From: Peter Tröger ***@***.***> Sent: Friday, February 10, 2023 11:20 AM To: netbox-community/netbox ***@***.***> Cc: Mark Tinberg ***@***.***>; Comment ***@***.***> Subject: Re: [netbox-community/netbox] Device view showing wrong interfaces when part of a Virtual Chassis (Discussion #10953) I totally understand the intended use case, so please see this mainly as a concept debate. The assumption here is that a shared management plane somehow extends the list of interfaces for one particular device (=VC master). The chassis members collaborate so that a non-master VC member is "borrowing" its physical interfaces to the master. The latter now has a combination of physical and borrowed interfaces. The master "is" the VC. Given the fact that physical (!) cable management and rack placement are a fundamental purpose of Netbox, I find it just surprising to "weaken" the device concept in this way. A list of interfaces for a physical device can not be trusted to be a list of connection endpoints for this (!) physical device. The list may even dynamically change, without changing the device itself. In my personal opinion, VC member interfaces should be moved to the VC object itself. As you said - this is now a new device that collects all the member interfaces. VC member devices should then have their interfaces "removed", or at least have them locked for editing and connecting. You no longer connect a cable to a physical device interface, you connect it to a VC interface. — Reply to this email directly, view it on GitHub<#10953 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM7IPI65HMSXWEF57KTWWZ2HFANCNFSM6AAAAAASDM6Q3A>. You are receiving this because you commented.Message ID: ***@***.***>