Ability to use Virtual Chassis position in interface naming

[theS1LV3R]

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 #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

[alehaa]

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.

[sleepinggenius2]

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.

[BriacD]

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.

[jeffgdotorg]

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.

[theS1LV3R]

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

[jeremystretch]

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

[nkeulen]

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?