starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

VC: Show VC Interfaces on All Members #2341

New Issue
Closed
opened 2025-12-29 17:24:59 +01:00 by adam · 6 comments
adam commented 2025-12-29 17:24:59 +01:00
Owner
Copy Link

Originally created by @hSaria on GitHub (Feb 3, 2019).

Environment

  • Python version: 3.6.6
  • NetBox version: 2.5.5

Proposed Functionality

When viewing a member in a virtual chassis, the interfaces for all members should be shown, regardless if the member is the master or not.

Use Case

When placed in a virtual chassis, the devices act as a single logical entity. Whether a member is or isn't the master does not change the configuration. The mastership should not influence where the user should/shouldn't browse to. I understand that going to the Virtual Chassis page would show the master, though the confusion caused by viewing non-master devices still exists.

Database Changes

None, as far as I'm aware.

External Dependencies

None.

Changes Required

In dcim/models.py, Device class, vc_interfaces function, update:

if self.virtual_chassis and self.virtual_chassis.master == self:

to

if self.virtual_chassis:
Originally created by @hSaria on GitHub (Feb 3, 2019). ### Environment * Python version: 3.6.6 * NetBox version: 2.5.5 ### Proposed Functionality When viewing a member in a virtual chassis, the interfaces for all members should be shown, regardless if the member is the master or not. ### Use Case When placed in a virtual chassis, the devices act as a single logical entity. Whether a member is or isn't the master does not change the configuration. The mastership should not influence where the user should/shouldn't browse to. I understand that going to the Virtual Chassis page would show the master, though the confusion caused by viewing non-master devices still exists. ### Database Changes None, as far as I'm aware. ### External Dependencies None. ### Changes Required In `dcim/models.py`, `Device` class, `vc_interfaces` function, update: ```python if self.virtual_chassis and self.virtual_chassis.master == self: ``` to ```python if self.virtual_chassis: ```
adam closed this issue 2025-12-29 17:25:00 +01:00
adam commented 2025-12-29 17:25:00 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 4, 2019):

Not a fan of this as I prefer to be able to view members individually with only their local interfaces, but I'll leave it open for feedback.

@jeremystretch commented on GitHub (Feb 4, 2019): Not a fan of this as I prefer to be able to view members individually with only their local interfaces, but I'll leave it open for feedback.
adam commented 2025-12-29 17:25:01 +01:00
Author
Owner
Copy Link

@hSaria commented on GitHub (Feb 4, 2019):

How would you view the interfaces of the master?

@hSaria commented on GitHub (Feb 4, 2019): How would you view the interfaces of the master?
adam commented 2025-12-29 17:25:01 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 4, 2019):

On the master device.

@jeremystretch commented on GitHub (Feb 4, 2019): On the master device.
adam commented 2025-12-29 17:25:01 +01:00
Author
Owner
Copy Link

@hSaria commented on GitHub (Feb 4, 2019):

That’ll just show the interfaces for all members.

On 4 Feb 2019, at 6:00 pm, Jeremy Stretch notifications@github.com wrote:

On the master device.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@hSaria commented on GitHub (Feb 4, 2019): That’ll just show the interfaces for all members. > On 4 Feb 2019, at 6:00 pm, Jeremy Stretch <notifications@github.com> wrote: > > On the master device. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub, or mute the thread.
adam commented 2025-12-29 17:25:01 +01:00
Author
Owner
Copy Link

@robertlynch3 commented on GitHub (Feb 7, 2019):

On a Juniper VC you have one device that is deemed the 'master', but the interfaces on the other members are still live and a part of the VC even if the other members are in a backup/linecard mode.

@robertlynch3 commented on GitHub (Feb 7, 2019): On a Juniper VC you have one device that is deemed the 'master', but the interfaces on the other members are still live and a part of the VC even if the other members are in a backup/linecard mode.
adam commented 2025-12-29 17:25:01 +01:00
Author
Owner
Copy Link

@hSaria commented on GitHub (Feb 7, 2019):

@rml596 that's pretty much the point I'm trying to make; it bears no meaning that a particular device is a master – the master is only there to maintain a single control plane (RE) across multiple data planes (PFE). And it's not just limited to Juniper VC; pretty much all virtualization models are based around resource sharing (combine or split), be it interfaces or otherwise.

A few discrepancy that I see in the virtual chassis model are:

  • The model is associative: Although the VC is a discrete object, it is only there to allow devices to point to its object ID.
  • The functionality of VC is split into different objects: While the VC object exists, all of the member priorities/positions are actually assigned on the device object (makes sense if you say "device owns those values," but in reality, those values should only be used when VC is in effect, and not all device will be). This already creates a bug: create VC, set master to be device 1, go to device 1 and set virtual_chassis to null. Now you have a VC pointing to a master, but that master doesn't point back to that VC). There are already other bugs due to virtual chassis (#2170 for example).
  • Cyclic relationship: Who's the parent of the Virtual Chassis object? The master of that VC or does it just not have a parent? For the looks of it, the master of the VC seems to be the parent, yet the master is also a member (child) of the same VC it is a master to – and as I described in the previous point, you can remove the "master" device as a member of the VC, but keep the VC pointing to the master.

I don't mean this in a negative way, but the VC model seems a bit premature, though that's only because I'm comparing it to the rest of NetBox that is very well structured, elegant, and meticulously thought-out (the standard is pretty high 😃).

If there was any other way to create shared interfaces (primarily LAGs), I'd completely avoid the Virtual Chassis model to begin with until it is restructured or had its functions clearly defined. As it stands, all these different gotcha's/lines-in-the-sand amount to a lot of work-arounds, all of which can be addressed by making a child-parent relationship (non-cyclical, of course). However, the change will raise some hard-hitting questions, primarily:

where would shared interfaces/resources live?

A simple answer is to create shared interfaces on the virtual chassis object and only show a reference to them on every device (just a shadow). If the VC ever gets deleted, the shared interfaces will be lost, which I think should be the case. And bonus point: every device would be physically (layer-1) independent from another and your view of a single device will show which ports that device has access to (physical or virtual).

Of course, I understand that the people maintaining this beautiful solution are very busy with other tasks, though I did want to mention this for the sake of consideration when spending more time on the existing solution.

@hSaria commented on GitHub (Feb 7, 2019): @rml596 that's pretty much the point I'm trying to make; it bears no meaning that a particular device is a master – the master is only there to maintain a single control plane (RE) across multiple data planes (PFE). And it's not just limited to Juniper VC; pretty much all virtualization models are based around resource sharing (combine or split), be it interfaces or otherwise. A few discrepancy that I see in the virtual chassis model are: - The model is associative: Although the VC is a discrete object, it is only there to allow devices to point to its object ID. - The functionality of VC is split into different objects: While the VC object exists, all of the member priorities/positions are actually assigned on the device object (makes sense if you say "device owns those values," but in reality, those values should only be used when VC is in effect, and not all device will be). This already creates a bug: create VC, set master to be device 1, go to device 1 and set virtual_chassis to null. Now you have a VC pointing to a master, but that master doesn't point back to that VC). There are already other bugs due to virtual chassis (#2170 for example). - Cyclic relationship: Who's the parent of the Virtual Chassis object? The master of that VC or does it just not have a parent? For the looks of it, the master of the VC seems to be the parent, yet the master is also a member (child) of the same VC it is a master to – and as I described in the previous point, you can remove the "master" device as a member of the VC, but keep the VC pointing to the master. I don't mean this in a negative way, but the VC model seems a bit premature, though that's only because I'm comparing it to the rest of NetBox that is very well structured, elegant, and meticulously thought-out (the standard is pretty high 😃). If there was any other way to create shared interfaces (primarily LAGs), I'd completely avoid the Virtual Chassis model to begin with until it is restructured or had its functions clearly defined. As it stands, all these different gotcha's/lines-in-the-sand amount to a lot of work-arounds, all of which can be addressed by making a child-parent relationship (non-cyclical, of course). However, the change will raise some hard-hitting questions, primarily: > where would shared interfaces/resources live? A simple answer is to create shared interfaces on the virtual chassis object and only show a reference to them on every device (just a shadow). If the VC ever gets deleted, the shared interfaces will be lost, which I think should be the case. And bonus point: every device would be physically (layer-1) independent from another and your view of a *single* device will show which ports that device has access to (physical or virtual). Of course, I understand that the people maintaining this beautiful solution are very busy with other tasks, though I did want to mention this for the sake of consideration when spending more time on the existing solution.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#2341
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?