Support for bridge group assignment

NetBox version

v2.11.2

Feature type

Data model extension

Proposed functionality

Introduce support for modeling bridge group interface assignments. This was originally raised in #6170 as a new interface type, but it was quickly realized that a more robust approach would be needed. I see two options for implementation:

1. Add a bridge field to the Interface model to function similarly to the parent field, and use a “bridge” interface to correlate bridge members.
2. Add a new BridgeGroup model. All member interfaces (include an actual “bridge” interface, if present) would be assigned to this.

Either approach would also require the introduction of a new “bridge” interface type as proposed in #6170.

Use case

Implementing this will allow users to accurately model interfaces and subinterfaces which belong to a common L2 domain within a device/VM.

Database changes

TBD

External dependencies

No response

[BarbarossaTM]

Is the “virtual” type not sufficient for this?

No because I cannot distinguish between an OpenVPN, Wireguard, vEth, macvlan, GRE, …, and bridge interface that way as all of them are virtual and have to fall back to some guesstimation elsewhere which I really would like to get rid of as it requires the name to be like br-*. On Linux boxes this can be done somehow when sticking to this naming convention on vendor boxes this might be harder or impossible. Adding a new interface type would be an easy fix for this problem.

[BarbarossaTM]

Hi @jeremystretch, thanks for #7622!

I was under the impression that the scope of this contained adding an interface type “bridge” so it would be possible to denote that on interface is a bridge (group/domain) even if it were not to have and members (at first). At least this was my intention in #6170 and that’s how I understood your summary above:

Either approach would also require the introduction of a new “bridge” interface type as proposed in #6170.

As far as I see in the code the #7622 does not include a new interface type. Could we please add this? With the current approach I don’t see how people would be able to model bridges without any member interfaces in Netbox (which I have a lot as other parts of the automation / system put interfaces into the bridges dynamically).

We maybe want to think about a search filter as well, so only interfaces of type bridge can be selected for the bridge attribute.

Thanks