Open theS1LV3R opened 8 months ago
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:
{vc_position}
placeholders. This would allow new modules to be added on demand, even if the device is a VC member.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.
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.
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 I added some examples and more details, please ask if there are any other questions!
I'll open this up for anyone who would like to own the implementation. Please be sure to include sufficiently comprehensive tests.
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?
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, akavc_position
isNone
, 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:
xe-{vc_position:0}/{module}/1
.xe-0/0/1
.xe-2/0/1
.xe-{vc_position:0}/{module}/1
. You then create multiple devices:xe-0/0/1
xe-1/0/1
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 ofxe-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