{vc_position} template variable for component naming in Virtual Chassis (at creation time) #232

New Issue

MrUnknownDE · 2026-04-05T16:23:18+02:00

MrUnknownDE commented

2026-04-05 16:23:18 +02:00

Originally created by @Etibru on 3/4/2026

NetBox version

v4.4.10-Docker-3.4.2

Feature type

New functionality

Proposed functionality

This feature has been requested multiple times but was closed as "not planned"

This issue is a re-request to reopen the discussion, as the use case remains valid and widely needed.

NetBox currently supports the {module} template variable when defining interface names on module types. This allows interfaces to automatically reflect the position of the module in which they are installed (for example : ge-0/{module}/0).

However, there is no equivalent variable for the position of the virtual chassis members. This means that when a device is part of a virtual chassis, the interfaces cannot automatically reflect the location of the VC members. Users are forced to manually rename all interfaces after adding a device to a VC, which is a tedious and error-prone process.

Add a new template variable {vc_position}, usable in interface name templates (both on device types and module types), which resolves to the value vc_position of the device in its virtual chassis at the time of component creation.

ge-{vc_position}/{module}/0 ==> ge-2/1/0
xe-{vc_position:0}/{module}/0 ==> xe-2/1/0 (fallback to 0 if not in a VC)

Pictures

Use case

Juniper interface naming follows ge-{vc_member}/{module}/{port}.
Example: xe-1/2/3 = 10G port, VC member 1, module bay 2, port 3.
Currently this is impossible to model correctly in NetBox when using Module Types.

Cisco stacked switches use GigabitEthernet{member}/{module}/{port}.

Scope & Known Limitations

This feature request covers only the initial creation of components (interfaces, etc.)
That is when a device type or module type is instantiated. The {vc_position} variable is resolved once at creation time, using the device's current VC position.

This implementation does not cover:

Automatic renaming of existing components when a device is added to, removed from, or repositioned within a Virtual Chassis.

This is an intentional scope limitation. Unlike {module}, where a module cannot exist independently of a device, a device can be freely assigned to or removed from a Virtual Chassis over time. Handling dynamic renaming on VC membership changes is a more complex problem and will require a separate follow-up issue.

Database changes

No response

External dependencies

No response

*Originally created by @Etibru on 3/4/2026* ### NetBox version v4.4.10-Docker-3.4.2 ### Feature type New functionality ### Proposed functionality This feature has been requested multiple times but was closed as "not planned" - https://github.com/netbox-community/netbox/issues/14659 - https://github.com/netbox-community/netbox/issues/10514 - https://github.com/netbox-community/netbox/issues/8648 This issue is a re-request to reopen the discussion, as the use case remains valid and widely needed. NetBox currently supports the `{module}` template variable when defining interface names on module types. This allows interfaces to automatically reflect the position of the module in which they are installed (for example : `ge-0/{module}/0`). However, there is no equivalent variable for the position of the virtual chassis members. This means that when a device is part of a virtual chassis, the interfaces cannot automatically reflect the location of the VC members. Users are forced to manually rename all interfaces after adding a device to a VC, which is a tedious and error-prone process. Add a new template variable `{vc_position}`, usable in interface name templates (both on device types and module types), which resolves to the value `vc_position` of the device in its virtual chassis **at the time of component creation**. - `ge-{vc_position}/{module}/0` ==> `ge-2/1/0` - `xe-{vc_position:0}/{module}/0` ==> `xe-2/1/0` (fallback to `0` if not in a VC) #### Pictures <img width="737" height="467" alt="Image" src="https://github.com/user-attachments/assets/7484b54c-e4fa-4fa5-a362-da6fb919c500" /> <img width="687" height="407" alt="Image" src="https://github.com/user-attachments/assets/df28c296-3a54-474b-9a8a-6a87d22b2fa5" /> ### Use case Juniper interface naming follows `ge-{vc_member}/{module}/{port}`. Example: `xe-1/2/3` = 10G port, VC member 1, module bay 2, port 3. Currently this is impossible to model correctly in NetBox when using Module Types. Cisco stacked switches use `GigabitEthernet{member}/{module}/{port}`. ### Scope & Known Limitations This feature request covers only the initial creation of components (interfaces, etc.) That is when a device type or module type is instantiated. The `{vc_position}` variable is resolved once at creation time, using the device's current VC position. This implementation does not cover: - Automatic renaming of existing components when a device is added to, removed from, or repositioned within a Virtual Chassis. This is an intentional scope limitation. Unlike `{module}`, where a module cannot exist independently of a device, a device can be freely assigned to or removed from a Virtual Chassis over time. Handling dynamic renaming on VC membership changes is a more complex problem and will require a separate follow-up issue. ### Database changes _No response_ ### External dependencies _No response_

MrUnknownDE closed this issue

2026-04-05 16:23:18 +02:00

Sign in to join this conversation.

Branches Tags

main

21455-sql-indexes-audit

21357-register-model-actions

feature

20924-plugin-ui-components

21766-improve-test-coverage-for-sortable-table-columns

21157-export-template-public-models

21025-pre-render-config-contexts

21364-swagger

feature-ip-prefix-link

20911-dropdown-3

fix_module_substitution

21160-filterset

20911-dropdown-2

20044-elevation-stuck-lightmode

7604-filter-modifiers-v3

20660-script-load

19724-graphql

14884-script

19720-macaddress-interface-generic-relation

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

No Label complexity: high netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted status: accepted type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/netbox#232

{vc_position} template variable for component naming in Virtual Chassis (at creation time) #232