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

Allow non-master device interfaces to be selectively excluded from virtual chassis master device #6765

New Issue
Closed
opened 2025-12-29 19:45:10 +01:00 by adam · 4 comments
adam commented 2025-12-29 19:45:10 +01:00
Owner
Copy Link

Originally created by @atownson on GitHub (Aug 3, 2022).

NetBox version

v3.2.4

Feature type

New functionality

Proposed functionality

I'm proposing to create functionality so that non-master devices in a virtual chassis can have their interfaces selectively excluded from the master device. I'm completely open to implementation. Some implementation paths I thought of are:

  1. Flag the interfaces to be excluded on the interfaces themselves
  2. Define excluded interfaces per device within the virtual cluster (maybe in the Edit Virtual Chassis page)
  3. Provide a text box in the Edit Virtual Chassis page per device for an interface name regex pattern exclusion (or even inclusion with the default being '.+')

Option 1 seems the least plausible to me because it's likely not best practice to include a setting for all interfaces that only applies to interfaces of devices in a virtual chassis. But again, I'm open to suggestions.
The functionality of adding all interfaces by default is great.

Use case

According to this document, virtual chassis are the suggested way to model Cisco FEX devices in NetBox, and it works very well. The only issue is that not all FEX interfaces should be inherited by the master device (5K, etc.).
Example: A N2K-C2348UPQ-10GE FEX connected to a Nexus 5696Q should only inherit interfaces Ethernet{fex number}/1/1-48, but by default, inherits Ethernet{fex number}/1/1-48, Ethernet{fex number}/2/1-4, and Ethernet{fex number}/1-2. So, the later 6 interfaces should be excluded.

Database changes

Likely, but depends on implementation

External dependencies

None

Originally created by @atownson on GitHub (Aug 3, 2022). ### NetBox version v3.2.4 ### Feature type New functionality ### Proposed functionality I'm proposing to create functionality so that non-master devices in a virtual chassis can have their interfaces selectively excluded from the master device. I'm completely open to implementation. Some implementation paths I thought of are: 1. Flag the interfaces to be excluded on the interfaces themselves 2. Define excluded interfaces per device within the virtual cluster (maybe in the Edit Virtual Chassis page) 3. Provide a text box in the Edit Virtual Chassis page per device for an interface name regex pattern exclusion (or even inclusion with the default being '.+') Option 1 seems the least plausible to me because it's likely not best practice to include a setting for all interfaces that only applies to interfaces of devices in a virtual chassis. But again, I'm open to suggestions. The functionality of adding all interfaces by default is great. ### Use case According to [this document](https://github.com/netbox-community/netbox/wiki/Data-Model-Limitations#data-center-fabric-switches), virtual chassis are the suggested way to model Cisco FEX devices in NetBox, and it works very well. The only issue is that not all FEX interfaces should be inherited by the master device (5K, etc.). Example: A N2K-C2348UPQ-10GE FEX connected to a Nexus 5696Q should only inherit interfaces Ethernet{fex number}/1/1-48, but by default, inherits Ethernet{fex number}/1/1-48, Ethernet{fex number}/2/1-4, and Ethernet{fex number}/1-2. So, the later 6 interfaces should be excluded. ### Database changes Likely, but depends on implementation ### External dependencies None
adam added the type: feature label 2025-12-29 19:45:10 +01:00
adam closed this issue 2025-12-29 19:45:10 +01:00
adam commented 2025-12-29 19:45:10 +01:00
Author
Owner
Copy Link

@atownson commented on GitHub (Aug 5, 2022):

I will model these interfaces as management only. Disregard.

@atownson commented on GitHub (Aug 5, 2022): I will model these interfaces as management only. Disregard.
adam commented 2025-12-29 19:45:10 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 5, 2022):

Maybe a way around this would be to change the management boolean to a selection field with options revenue, management, and backplane. It would be a breaking change though and certainly would need further thought.

@jeremystretch commented on GitHub (Aug 5, 2022): Maybe a way around this would be to change the management boolean to a selection field with options revenue, management, and backplane. It would be a breaking change though and certainly would need further thought.
adam commented 2025-12-29 19:45:11 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Aug 5, 2022):

Honestly, I think FEX modelling requires something different entirely.

Personally, for now, I would model it as a module within the chassis and inventory items (FEXes show as inventory) for the individual components of the FEX. The reason for this, is if you do any of hte multi-homed vPC technologies, the FEX is individually controlled by each nexus as far as config. When the config differs, that portion that is affected is controlled by the primary vPC node.

As for inheriting the fabric interfaces, I don't have a good answer for that, the management boolean makes sense, but I also think there might be a better way for interfaces as a whole. Perhaps it is time to re-visit how we do the interface model completely and look at using some light polymorphism to handle the different interface "types" (Virtual, Physicial). This would allow for a more robust interface model and would simplify some of the logic (We could also only add relevant fields where they belong. For example, a Ethernet interface doesn't need a WWN for fiber channel. Ethernet doesn't need wireless interface settings, etc).

That wiki article was written before we had modules.

That said, FEX's and other remote line cards do require a different model I thinik and it might be time to look at that a little more closely (after we sort out VDC and a few other things)

@DanSheps commented on GitHub (Aug 5, 2022): Honestly, I think FEX modelling requires something different entirely. Personally, for now, I would model it as a module within the chassis and inventory items (FEXes show as inventory) for the individual components of the FEX. The reason for this, is if you do any of hte multi-homed vPC technologies, the FEX is individually controlled by each nexus as far as config. When the config differs, that portion that is affected is controlled by the primary vPC node. As for inheriting the fabric interfaces, I don't have a *good* answer for that, the management boolean makes sense, but I also think there might be a better way for interfaces as a whole. Perhaps it is time to re-visit how we do the interface model completely and look at using some light polymorphism to handle the different interface "types" (Virtual, Physicial). This would allow for a more robust interface model and would simplify some of the logic (We could also only add relevant fields where they belong. For example, a Ethernet interface doesn't need a WWN for fiber channel. Ethernet doesn't need wireless interface settings, etc). That wiki article was written before we had modules. That said, FEX's and other remote line cards do require a different model I thinik and it might be time to look at that a little more closely (after we sort out VDC and a few other things)
adam commented 2025-12-29 19:45:11 +01:00
Author
Owner
Copy Link

@atownson commented on GitHub (Aug 5, 2022):

Thanks for the input Jeremy and Dan. NetBox is impressive. Keep up the good work.

@atownson commented on GitHub (Aug 5, 2022): Thanks for the input Jeremy and Dan. NetBox is impressive. Keep up the good work.
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 type: feature
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#6765
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?