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

Virtual Chassis interface dynamic naming #6088

New Issue
Closed
opened 2025-12-29 19:36:37 +01:00 by adam · 13 comments
adam commented 2025-12-29 19:36:37 +01:00
Owner
Copy Link

Originally created by @AnythingOverIP on GitHub (Feb 15, 2022).

NetBox version

3.1.7

Feature type

New functionality

Proposed functionality

Similar to what has been brilliantly implemented in https://github.com/netbox-community/netbox/issues/7844 for interface names assigned to a module, it would be beneficial to be able to do the same with VC, based on the VC ID.

Switch ID 0: ge-{MemberID}/0/0 @ ge-{MemberID}/0/48 : would then results in interfaces ge-0/0/0 @ ge-0/0/48
Switch ID 1: ge-{MemberID}/0/0 @ ge-{MemberID}/0/48 : would then results in interfaces ge-1/0/0 @ ge-1/0/48
Switch ID 2: ge-{MemberID}/0/0 @ ge-{MemberID}/0/48 : would then results in interfaces ge-2/0/0 @ ge-2/0/48

Currently, when adding switches to a Stack, we have to go and delete, then recreate interfaces as they the interface name is not what's in the device type anymore.

Having a "default position ID" defined in the device type (i.e: if switch not a member of a VC, assign a value to {MemberID}, so interfaces templates are not to be maintained twice would be a great plus, but this would potentially be harder to maintain or model (i.e: Cisco devices would have a default value of 1, and Juniper a default value of 0).

To simplify the feasibility of this FR, I wouldn't mind maintaining two device types for the same piece of equipment (one being a stand-alone switch and the other a stack member). This would minimize the logic needed to have different naming schemes whether a switch is used in a VC or not.

Similar issues were previously raised in https://github.com/netbox-community/netbox/issues/5918 , https://github.com/netbox-community/netbox/issues/4177, but hopefully Netbox 3.x would now be able to accommodate this using what's implemented in #7844

Use case

That new module concept is huge and will simplify our Netbox inventory. My understanding is that it could almost replace VC in most cases, but rack elevations would not be represented properly. Also, multi-site or multi rack VC member locations would not be properly addressed by that. I'd like to see in the Virtual Chassis model some of the flexibility the module model is bringing. Switch stacks would then be easier to create/maintain.

Database changes

None AFAIK

External dependencies

No response

Originally created by @AnythingOverIP on GitHub (Feb 15, 2022). ### NetBox version 3.1.7 ### Feature type New functionality ### Proposed functionality Similar to what has been brilliantly implemented in https://github.com/netbox-community/netbox/issues/7844 for interface names assigned to a module, it would be beneficial to be able to do the same with VC, based on the VC ID. Switch ID 0: ge-{MemberID}/0/0 @ ge-{MemberID}/0/48 : would then results in interfaces ge-0/0/0 @ ge-0/0/48 Switch ID 1: ge-{MemberID}/0/0 @ ge-{MemberID}/0/48 : would then results in interfaces ge-1/0/0 @ ge-1/0/48 Switch ID 2: ge-{MemberID}/0/0 @ ge-{MemberID}/0/48 : would then results in interfaces ge-2/0/0 @ ge-2/0/48 Currently, when adding switches to a Stack, we have to go and delete, then recreate interfaces as they the interface name is not what's in the device type anymore. Having a "default position ID" defined in the device type (i.e: if switch not a member of a VC, assign a value to {MemberID}, so interfaces templates are not to be maintained twice would be a great plus, but this would potentially be harder to maintain or model (i.e: Cisco devices would have a default value of 1, and Juniper a default value of 0). To simplify the feasibility of this FR, I wouldn't mind maintaining two device types for the same piece of equipment (one being a stand-alone switch and the other a stack member). This would minimize the logic needed to have different naming schemes whether a switch is used in a VC or not. Similar issues were previously raised in https://github.com/netbox-community/netbox/issues/5918 , https://github.com/netbox-community/netbox/issues/4177, but hopefully Netbox 3.x would now be able to accommodate this using what's implemented in #7844 ### Use case That new module concept is huge and will simplify our Netbox inventory. My understanding is that it could almost replace VC in most cases, but rack elevations would not be represented properly. Also, multi-site or multi rack VC member locations would not be properly addressed by that. I'd like to see in the Virtual Chassis model some of the flexibility the module model is bringing. Switch stacks would then be easier to create/maintain. ### Database changes None AFAIK ### External dependencies _No response_
adam added the type: featurestatus: needs ownerpending closure labels 2025-12-29 19:36:37 +01:00
adam closed this issue 2025-12-29 19:36:37 +01:00
adam commented 2025-12-29 19:36:38 +01:00
Author
Owner
Copy Link

@empusas commented on GitHub (Feb 23, 2022):

I would keep the virtual chassis feature. If you replace it with module you might loose a lot of functionality.
As I understand it the module model, it assumes that the "module" is inside of the chassis of the main device.
But your stack members, fabric extenders etc. might be at a different place and you want to capture that information.
Only problem I see is that you would like to have the interface in the master device, for example if you have an automation. But then it might be misleading if you use the cabling feature as the cables might end at a different location as the master device.
Not an easy problem I guess.

@empusas commented on GitHub (Feb 23, 2022): I would keep the virtual chassis feature. If you replace it with module you might loose a lot of functionality. As I understand it the module model, it assumes that the "module" is inside of the chassis of the main device. But your stack members, fabric extenders etc. might be at a different place and you want to capture that information. Only problem I see is that you would like to have the interface in the master device, for example if you have an automation. But then it might be misleading if you use the cabling feature as the cables might end at a different location as the master device. Not an easy problem I guess.
adam commented 2025-12-29 19:36:38 +01:00
Author
Owner
Copy Link

@AnythingOverIP commented on GitHub (Feb 23, 2022):

I would keep the virtual chassis feature.

Definitely! My request is not to get rid of Virtual Chassis. Just to do some mileage on what has been done with Modules.

@AnythingOverIP commented on GitHub (Feb 23, 2022): > I would keep the virtual chassis feature. Definitely! My request is not to get rid of Virtual Chassis. Just to do some mileage on what has been done with Modules.
adam commented 2025-12-29 19:36:39 +01:00
Author
Owner
Copy Link

@steele-ntwrk commented on GitHub (Mar 15, 2022):

This is a great request 👍🏼 ! Great work!

I was about to open a similar one after watching the youtube video about Modules in Netbox 3.2 but thought I would have a search first.

I think two new fields can be added to the data model of the device type that will be assessed when creating a Virtual Chassis and update interfaces.

Example
virtual chassis capable: True
vcname: GigabitEthernet{VC}/0/1

There also seems to be some logic already there that when a device is marked as Master it imports all the interfaces, could renames the interfaces in the same process based on the above data model?

Cheers,
Steele

@steele-ntwrk commented on GitHub (Mar 15, 2022): This is a great request 👍🏼 ! Great work! I was about to open a similar one after watching the youtube video about Modules in Netbox 3.2 but thought I would have a search first. I think two new fields can be added to the data model of the device type that will be assessed when creating a Virtual Chassis and update interfaces. Example virtual chassis capable: True vcname: GigabitEthernet{VC}/0/1 There also seems to be some logic already there that when a device is marked as Master it imports all the interfaces, could renames the interfaces in the same process based on the above data model? Cheers, Steele
adam commented 2025-12-29 19:36:39 +01:00
Author
Owner
Copy Link

@wwerther commented on GitHub (Apr 1, 2022):

Already tested in Version 3.2 with Modules. It's working nice, to use interfaces names in module-type like:
TenGigabitEthernet1/{module}/1
so the addition would be to use
TenGigabitEthernet{vcid}/{module}/1
instead with the vcid replacd with the number in vc or a default value as stated in top request.

The question that will pop-up is what will happen if the VCID changes at a later time. So will deployed modules get permanent names or will the name be "replaced" dynamically when the position in VC would change.

@wwerther commented on GitHub (Apr 1, 2022): Already tested in Version 3.2 with Modules. It's working nice, to use interfaces names in module-type like: TenGigabitEthernet1/{module}/1 so the addition would be to use TenGigabitEthernet{vcid}/{module}/1 instead with the vcid replacd with the number in vc or a default value as stated in top request. The question that will pop-up is what will happen if the VCID changes at a later time. So will deployed modules get permanent names or will the name be "replaced" dynamically when the position in VC would change.
adam commented 2025-12-29 19:36:39 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 6, 2022):

The major distinction between modules and virtual chassis members (devices) is that device components are populated before assignment to a VC, whereas module components are populated at the same time. So you can't use the same approach of defining a placeholder value in the component name.

To simplify the feasibility of this FR, I wouldn't mind maintaining two device types for the same piece of equipment

I suspect you're going to be in the minority there.

Currently, when adding switches to a Stack, we have to go and delete, then recreate interfaces as they the interface name is not what's in the device type anymore.

It's recommended to just rename the interfaces in bulk rather than deleting & recreating them all.

@jeremystretch commented on GitHub (Apr 6, 2022): The major distinction between modules and virtual chassis members (devices) is that device components are populated _before_ assignment to a VC, whereas module components are populated at the same time. So you can't use the same approach of defining a placeholder value in the component name. > To simplify the feasibility of this FR, I wouldn't mind maintaining two device types for the same piece of equipment I suspect you're going to be in the minority there. > Currently, when adding switches to a Stack, we have to go and delete, then recreate interfaces as they the interface name is not what's in the device type anymore. It's recommended to just rename the interfaces in bulk rather than deleting & recreating them all.
adam commented 2025-12-29 19:36:39 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Apr 7, 2022):

Could we do something like {vcid:1} where anything after the ":" is the default, and have it check when a device is attached to a VC? I know it is a bit hacky but I do think it would greatly improve peoples UX experience.

Nevermind, I see that we can't relocate a module after the fact. Could we perhaps have a _unresolved_name cached on the object that we can check against and perhaps rename. This would also facilitate moving module slots without losing the interface state. Just a thought.

@DanSheps commented on GitHub (Apr 7, 2022): Could we do something like {vcid:1} where anything after the ":" is the default, and have it check when a device is attached to a VC? I know it is a bit hacky but I do think it would greatly improve peoples UX experience. Nevermind, I see that we can't relocate a module after the fact. Could we perhaps have a _unresolved_name cached on the object that we can check against and perhaps rename. This would also facilitate moving module slots without losing the interface state. Just a thought.
adam commented 2025-12-29 19:36:39 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jun 6, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Jun 6, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:36:40 +01:00
Author
Owner
Copy Link

@AnythingOverIP commented on GitHub (Jun 7, 2022):

@DanSheps , do you think it's worth keeping this FR opened? (pretty please! :) )

@AnythingOverIP commented on GitHub (Jun 7, 2022): @DanSheps , do you think it's worth keeping this FR opened? (pretty please! :) )
adam commented 2025-12-29 19:36:40 +01:00
Author
Owner
Copy Link

@steele-ntwrk commented on GitHub (Jun 8, 2022):

Could we do something like {vcid:1} where anything after the ":" is the default, and have it check when a device is attached to a VC? I know it is a bit hacky but I do think it would greatly improve peoples UX experience.

Nevermind, I see that we can't relocate a module after the fact. Could we perhaps have a _unresolved_name cached on the object that we can check against and perhaps rename. This would also facilitate moving module slots without losing the interface state. Just a thought.

I think this is a good idea, but I'm also not very well versed in programming.

@steele-ntwrk commented on GitHub (Jun 8, 2022): > Could we do something like {vcid:1} where anything after the ":" is the default, and have it check when a device is attached to a VC? I know it is a bit hacky but I do think it would greatly improve peoples UX experience. > > Nevermind, I see that we can't relocate a module after the fact. Could we perhaps have a _unresolved_name cached on the object that we can check against and perhaps rename. This would also facilitate moving module slots without losing the interface state. Just a thought. I think this is a good idea, but I'm also not very well versed in programming.
adam commented 2025-12-29 19:36:40 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Jun 10, 2022):

I think for now we have more pressing issues to work on and this can be manually achieved by bulk rename currently

@DanSheps commented on GitHub (Jun 10, 2022): I think for now we have more pressing issues to work on and this can be manually achieved by bulk rename currently
adam commented 2025-12-29 19:36:40 +01:00
Author
Owner
Copy Link

@AnythingOverIP commented on GitHub (Jun 15, 2022):

OK then! Thanks!

@AnythingOverIP commented on GitHub (Jun 15, 2022): OK then! Thanks!
adam commented 2025-12-29 19:36:40 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Aug 28, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Aug 28, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:36:40 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Sep 27, 2022):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Sep 27, 2022): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
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 pending closure status: needs owner 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#6088
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?