Support Bridge-Interfaces in Interface-Template Import #1500

New Issue

MrUnknownDE · 2026-04-06T02:39:03+02:00

MrUnknownDE commented

2026-04-06 02:39:03 +02:00

Originally created by @m-hau on 8/7/2025

NetBox version

v4.3.4

Feature type

Change to existing functionality

Proposed functionality

Issue #8272 respective PR #11869 added the possibility to "pre-bridge" interfaces (templates) in a device/module type, so any devices/modules created from it will already have on their interfaces the correct bridge interfaces set. This is useful for example when the hardware-device contains a hardware-network-switch with multiple built-in ports (both internal/cpu and external/physical).

While this feature already exists and works, it currently (as the PR also states) is not supported when importing device/module types. So when importing such a device/module type, you have to manually check and potentially adjust/correct the bridge configuration post-import.
This asymmetry between manually created and imported device types is especially impactful for the usage of device type libraries, both official/public and private, where you import a potentially large number of different device/module types. While the libraries can specify these bridge relations, that information is silently lost during the import into NetBox.

Unfortunately does the original PR not specify why exactly import is considered such a hard problem. For the simple cases where the bridge of an interface is in the same device/module type as the interface itself, it should be a simple ordering issue (create bridge first, then bridged interfaces). Edge-cases I can think of are circular (interface A is bridged by B, and interface B is bridged by A) and recursive (interface A is bridged by B, and interface C is bridged by B) bridge relationships.
Everything else (aka any cross-type-bridges) are impossible to safely model on the device/module type level, because you can't make any assumptions about the device/module composition the created instances may have.

I propose that when importing a device/module type, any of its interfaces can optionally have a bridge attribute, whose value is the name of the bridge interface as a string. If the attribute is not present, its value should be considered null. The values null and empty string mean "not set". Its value is subject to the same restrictions/constraints as the existing database/model field, most importantly that it can't be itself (an interface cannot be bridged to itself), and it must be an interface on the same device/module type (but not necessarily of type bridge). Failing to satisfy these data requirements will cause an error, reporting to the user an actionable message, and not create the device/module type or any of its components. When the import is successful, all created interface templates will have the bridge field set accordingly to the import-input-data.

I am willing to work on this. PR #13199 seems to be a nice reference since it does basically the same for rf_role, except I can skip (but still double-check) the changes to the database model. Any further hints or guidance is appreciated.

Use case

Device type libraries, both official/public and private, can properly document these built-in bridge relations. Consumers can simply import the device/module types in NetBox, without having to manually adjust/correct them post-import.

Database changes

No database change should be required, since the interface template already has all required fields.

External dependencies

No additional dependencies should be required.

*Originally created by @m-hau on 8/7/2025* ### NetBox version v4.3.4 ### Feature type Change to existing functionality ### Proposed functionality Issue #8272 respective PR #11869 added the possibility to "pre-bridge" interfaces (templates) in a device/module type, so any devices/modules created from it will already have on their interfaces the correct bridge interfaces set. This is useful for example when the hardware-device contains a hardware-network-switch with multiple built-in ports (both internal/cpu and external/physical). While this feature already exists and works, it currently (as the PR also states) is not supported when importing device/module types. So when importing such a device/module type, you have to manually check and potentially adjust/correct the bridge configuration post-import. This asymmetry between manually created and imported device types is especially impactful for the usage of device type libraries, both official/public and private, where you import a potentially large number of different device/module types. While the libraries can specify these bridge relations, that information is silently lost during the import into NetBox. Unfortunately does the original PR not specify why exactly import is considered such a hard problem. For the simple cases where the bridge of an interface is in the same device/module type as the interface itself, it should be a simple ordering issue (create bridge first, then bridged interfaces). Edge-cases I can think of are circular (interface A is bridged by B, and interface B is bridged by A) and recursive (interface A is bridged by B, and interface C is bridged by B) bridge relationships. Everything else (aka any cross-type-bridges) are impossible to safely model on the device/module type level, because you can't make any assumptions about the device/module composition the created instances may have. I propose that when importing a device/module type, any of its interfaces can optionally have a `bridge` attribute, whose value is the name of the bridge interface as a string. If the attribute is not present, its value should be considered `null`. The values `null` and empty string mean "not set". Its value is subject to the same restrictions/constraints as the existing database/model field, most importantly that it can't be itself (an interface cannot be bridged to itself), and it must be an interface on the same device/module type (but not necessarily of type `bridge`). Failing to satisfy these data requirements will cause an error, reporting to the user an actionable message, and not create the device/module type or any of its components. When the import is successful, all created interface templates will have the `bridge` field set accordingly to the import-input-data. <hr> I am willing to work on this. PR #13199 seems to be a nice reference since it does basically the same for `rf_role`, except I can skip (but still double-check) the changes to the database model. Any further hints or guidance is appreciated. ### Use case Device type libraries, both official/public and private, can properly document these built-in bridge relations. Consumers can simply import the device/module types in NetBox, without having to manually adjust/correct them post-import. ### Database changes No database change should be required, since the interface template already has all required fields. ### External dependencies No additional dependencies should be required.

MrUnknownDE closed this issue

2026-04-06 02:39:03 +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: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low complexity: low 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 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 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 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 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 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 netbox netbox pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure pending closure status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner status: needs owner 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 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 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 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 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 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 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#1500