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

Ability to use Virtual Chassis position in interface naming #9023

New Issue
Closed
opened 2025-12-29 20:44:19 +01:00 by adam · 9 comments
adam commented 2025-12-29 20:44:19 +01:00
Owner
Copy Link

Originally created by @theS1LV3R on GitHub (Jan 2, 2024).

NetBox version

v3.7.0

Feature type

New functionality

Proposed functionality

For modules, its currently possible to use {module} in an interface name in order for it to follow the module bay of which it is installed in ("Position" under a module bay). It would be great if there was an equivalent property (e.g. {vc_position}) to replace the equivalent for a virtual chassis position.

A default value could be done using something like {vc_position:0}, where if a device isn't in a cluster, aka vc_position is None, it would insert 0 instead.

Use case

Juniper devices name their interfaces using {type}-{member}/{module}/{interface}. Example: xe-1/2/3 would be a 10-gig port (xe), on the 2nd member of the VC (1 - 0-indexed), in the 2nd module bay (2 - 0 is built-in interfaces, 1 is the first bay), and the 4th interface (3 - 0-indexed).

I believe Cisco devices do something similar based on https://github.com/netbox-community/netbox/discussions/5794.

Examples:

  1. You create a new interface on an already existing switch, and define it as xe-{vc_position:0}/{module}/1.
    • If the current switch is not in a virtual chassis (VC) or cluster, the new interface name would become xe-0/0/1.
    • However if the switch is in a VC or cluster, and is member 3, then the interface would become xe-2/0/1.
  2. You define a device type and again define the interface as xe-{vc_position:0}/{module}/1. You then create multiple devices:
    • First one becomes xe-0/0/1
    • Second one gets added to the VC of the first one, automatically giving it the interface xe-1/0/1
  3. You have a module, again with the same interface definition, and add it to vc member 1 in module slot 2: xe-1/2/1

The way it currently works I have to define the interface as xe-0/{module}/1, meaning that if I create another switch in the VC, as in the second example, I'd have to rename all its interfaces to match up with what they actually are (xe-1/0/1 instead of xe-0/0/1). Same for the third example, I'd have to rename the module's interfaces.

Database changes

No response

External dependencies

No response

Originally created by @theS1LV3R on GitHub (Jan 2, 2024). ### NetBox version v3.7.0 ### Feature type New functionality ### Proposed functionality For modules, its currently possible to use `{module}` in an interface name in order for it to follow the module bay of which it is installed in ("Position" under a module bay). It would be great if there was an equivalent property (e.g. `{vc_position}`) to replace the equivalent for a virtual chassis position. A default value could be done using something like `{vc_position:0}`, where if a device isn't in a cluster, aka `vc_position` is `None`, it would insert 0 instead. ### Use case Juniper devices name their interfaces using `{type}-{member}/{module}/{interface}`. Example: `xe-1/2/3` would be a 10-gig port (`xe`), on the 2nd member of the VC (`1` - 0-indexed), in the 2nd module bay (`2` - 0 is built-in interfaces, 1 is the first bay), and the 4th interface (`3` - 0-indexed). I believe Cisco devices do something similar based on https://github.com/netbox-community/netbox/discussions/5794. Examples: 1. You create a new interface on an already existing switch, and define it as `xe-{vc_position:0}/{module}/1`. - If the current switch is *not* in a virtual chassis (VC) or cluster, the new interface name would become `xe-0/0/1`. - However if the switch *is* in a VC or cluster, and is member 3, then the interface would become `xe-2/0/1`. 2. You define a device type and again define the interface as `xe-{vc_position:0}/{module}/1`. You then create multiple devices: - First one becomes `xe-0/0/1` - Second one gets added to the VC of the first one, automatically giving it the interface `xe-1/0/1` 3. You have a module, again with the same interface definition, and add it to vc member 1 in module slot 2: `xe-1/2/1` The way it currently works I have to define the interface as `xe-0/{module}/1`, meaning that if I create another switch in the VC, as in the second example, I'd have to rename _all_ its interfaces to match up with what they actually are (`xe-1/0/1` instead of `xe-0/0/1`). Same for the third example, I'd have to rename the module's interfaces. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: featurestatus: needs ownerpending closurecomplexity: medium labels 2025-12-29 20:44:19 +01:00
adam closed this issue 2025-12-29 20:44:19 +01:00
adam commented 2025-12-29 20:44:19 +01:00
Author
Owner
Copy Link

@alehaa commented on GitHub (Jan 3, 2024):

I think this is a good feature request. However, I don't think it's that simple, as the order of actions is important when creating and naming interfaces. When a device is created on its own, the VC position is not yet known, but interfaces are created from the device template. If you then try to connect the device to the VC, or add new modules to an existing VC device, NetBox will complain about duplicate interfaces.

So I think two things need to be implemented to get a good user experience:

  1. As suggested by @theS1LV3R, module templates should add something like {vc_position} placeholders. This would allow new modules to be added on demand, even if the device is a VC member.
  2. When first creating a virtual chassis, some logic is needed to rename the existing interfaces accordingly.
@alehaa commented on GitHub (Jan 3, 2024): I think this is a good feature request. However, I don't think it's that simple, as the order of actions is important when creating and naming interfaces. When a device is created on its own, the VC position is not yet known, but interfaces are created from the device template. If you then try to connect the device to the VC, or add new modules to an existing VC device, NetBox will complain about duplicate interfaces. So I think two things need to be implemented to get a good user experience: 1. As suggested by @theS1LV3R, module templates should add something like `{vc_position}` placeholders. This would allow new modules to be added on demand, even if the device is a VC member. 2. When first creating a virtual chassis, some logic is needed to rename the existing interfaces accordingly.
adam commented 2025-12-29 20:44:20 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Jan 3, 2024):

With #9622 being merged in v3.2.6, you now have the ability to associate a device with a virtual chassis at creation, as long as you create the virtual chassis first. So, point 2 is really just a matter of process or order of operations issue, unless you're saying that a device may be used as a standalone device and only later be added to a virtual chassis. In that scenario, you would already have replaced the placeholders, so that information would need to be otherwise retained in some way for that to work. Issues #8648 and #10514 have previously been opened on this topic for additional reference.

In our environment, we just have a script that can be run to go through a device and do the vc_position replacement after it is instantiated. That includes module bay positions, so that modules that are subsequently added to the device can just use the built-in {module} placeholder for their components, which would also eliminate the need for point 1 above. With the addition of event rules in v3.7.0, were looking into being able to fully automate that process. We have some devices that change their component names, based on whether they are in a virtual chassis or not, in a way that a simple search and replace won't work, which is why we originally went down the script path.

@sleepinggenius2 commented on GitHub (Jan 3, 2024): With #9622 being merged in v3.2.6, you now have the ability to associate a device with a virtual chassis at creation, as long as you create the virtual chassis first. So, point 2 is really just a matter of process or order of operations issue, unless you're saying that a device may be used as a standalone device and only later be added to a virtual chassis. In that scenario, you would already have replaced the placeholders, so that information would need to be otherwise retained in some way for that to work. Issues #8648 and #10514 have previously been opened on this topic for additional reference. In our environment, we just have a script that can be run to go through a device and do the `vc_position` replacement after it is instantiated. That includes module bay positions, so that modules that are subsequently added to the device can just use the built-in `{module}` placeholder for their components, which would also eliminate the need for point 1 above. With the addition of event rules in v3.7.0, were looking into being able to fully automate that process. We have some devices that change their component names, based on whether they are in a virtual chassis or not, in a way that a simple search and replace won't work, which is why we originally went down the script path.
adam commented 2025-12-29 20:44:20 +01:00
Author
Owner
Copy Link

@BriacD commented on GitHub (Jan 31, 2024):

Would you be interested in sharing your script or offering some tips? I've realized the further along I get with my organization's Netbox implementation, the more I'm having to backtrack and fix issues like this.

@BriacD commented on GitHub (Jan 31, 2024): Would you be interested in sharing your script or offering some tips? I've realized the further along I get with my organization's Netbox implementation, the more I'm having to backtrack and fix issues like this.
adam commented 2025-12-29 20:44:20 +01:00
Author
Owner
Copy Link

@jeffgdotorg commented on GitHub (Apr 3, 2024):

I think I see where you're going with this, but it seems you ran out of steam halfway through the Use case section. Please revise that section of your original issue body with more details, including specific examples of how you envision using the proposed {vc_position} token.

@jeffgdotorg commented on GitHub (Apr 3, 2024): I think I see where you're going with this, but it seems you ran out of steam halfway through the **Use case** section. Please revise that section of your original issue body with more details, including specific examples of how you envision using the proposed `{vc_position}` token.
adam commented 2025-12-29 20:44:20 +01:00
Author
Owner
Copy Link

@theS1LV3R commented on GitHub (Apr 5, 2024):

@jeffgdotorg I added some examples and more details, please ask if there are any other questions!

@theS1LV3R commented on GitHub (Apr 5, 2024): @jeffgdotorg I added some examples and more details, please ask if there are any other questions!
adam commented 2025-12-29 20:44:20 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 15, 2024):

I'll open this up for anyone who would like to own the implementation. Please be sure to include sufficiently comprehensive tests.

@jeremystretch commented on GitHub (May 15, 2024): I'll open this up for anyone who would like to own the implementation. Please be sure to include sufficiently comprehensive tests.
adam commented 2025-12-29 20:44:21 +01:00
Author
Owner
Copy Link

@nkeulen commented on GitHub (Jun 8, 2024):

This feature would be very useful for me (adding a large number of stacked switches currently requires a lot of interface renaming).

I'd like to try and implement this. Can someone please assign it to me?

@nkeulen commented on GitHub (Jun 8, 2024): This feature would be very useful for me (adding a large number of stacked switches currently requires a lot of interface renaming). I'd like to try and implement this. Can someone please assign it to me?
adam commented 2025-12-29 20:44:21 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 9, 2025):

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 (Jul 9, 2025): 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/main/CONTRIBUTING.md).
adam commented 2025-12-29 20:44:21 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Aug 8, 2025):

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 (Aug 8, 2025): 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 complexity: medium 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#9023
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?