Creation of L2 Bridge Domain #6489

Originally created by @jcralbino on GitHub (May 16, 2022).

NetBox version

V3.2.3

Feature type

Data model extension

Proposed functionality

L2 BRIDGE DOMAIN can be used to improve the way the same layer 2 extension is configured within netbox

Currently netbox provides a limited model for VLAN, and VLANS can be aggregated in a VLAN Group.
The limitation is that a VLAN Group is not an actual representation of a broadcast domain but of an aggregation of vlans that share some characteristics ( same site, same switch)

A L2 BRIDGE DOMAIN , will be a representation of an actual shared broadcast domain across different vlans(as currently netbox considers that vlans placed in in different vlan groups are separated objects).

This means that we will have :

1 VLAN can be part of one VLAN GROUP.
1 L2 BRIDGE DOMAIN can be associate with one or more VLAN GROUP.
1 VLAN can be part of only one L2 BRIDGE DOMAIN. But bridge domains can be cascaded
1 L2 BRIDGE DOMAIN can be assigned to more than one VLAN that share the same vlan id

If the same VLAN ID Is used In different VLAN GROUPS and if they share the same L2 BRIDGE DOMAIN this will represent that all are sharing the same broadcast domain
L2 BRIDGE DOMAIN can be having following field
- protocol ( vxlan, 802.1q, l2vpn, trill, spb )
- Description
- Parent Bridge Domain
Another Data model can be used to represent the different Protocols used for L2 Overlay technologies.

Use case

Improve the way layer 2 networks are modeled in netbox as currently we do not identify well shared broadcast domains across vlan groups

This will allow the representation in the model of different protocols that extend layer 2 bridge domains.

Database changes

Adding a new object for L2 Bridge Domain
Introduce foreign keys in vlan id and vlan group

External dependencies

None

Originally created by @jcralbino on GitHub (May 16, 2022). ### NetBox version V3.2.3 ### Feature type Data model extension ### Proposed functionality L2 BRIDGE DOMAIN can be used to improve the way the same layer 2 extension is configured within netbox Currently netbox provides a limited model for VLAN, and VLANS can be aggregated in a VLAN Group. The limitation is that a VLAN Group is not an actual representation of a broadcast domain but of an aggregation of vlans that share some characteristics ( same site, same switch) A L2 BRIDGE DOMAIN , will be a representation of an actual shared broadcast domain across different vlans(as currently netbox considers that vlans placed in in different vlan groups are separated objects). This means that we will have : - 1 VLAN can be part of one VLAN GROUP. - 1 L2 BRIDGE DOMAIN can be associate with one or more VLAN GROUP. - 1 VLAN can be part of only one L2 BRIDGE DOMAIN. But bridge domains can be cascaded - 1 L2 BRIDGE DOMAIN can be assigned to more than one VLAN that share the same vlan id If the same VLAN ID Is used In different VLAN GROUPS and if they share the same L2 BRIDGE DOMAIN this will represent that all are sharing the same broadcast domain - L2 BRIDGE DOMAIN can be having following field - protocol ( vxlan, 802.1q, l2vpn, trill, spb ) - Description - Parent Bridge Domain - Another Data model can be used to represent the different Protocols used for L2 Overlay technologies. ### Use case Improve the way layer 2 networks are modeled in netbox as currently we do not identify well shared broadcast domains across vlan groups This will allow the representation in the model of different protocols that extend layer 2 bridge domains. ### Database changes - Adding a new object for L2 Bridge Domain - Introduce foreign keys in vlan id and vlan group ### External dependencies None

adam added the type: feature pending closure labels 2025-12-29 19:41:22 +01:00

adam closed this issue

adam commented

@DanSheps commented on GitHub (May 17, 2022):

Would #8157 cover all of this?

@DanSheps commented on GitHub (May 17, 2022): Would #8157 cover all of this?

adam commented

2025-12-29 19:41:23 +01:00

@jcralbino commented on GitHub (May 17, 2022):

The issue i see with the L2VPN approach in that FR is the way it wants to provide visibility on how the bridge domain is done. It focus also mainly in assignments to a vlan. It seems hard to have a link to the vlan group. The actual representation of a shared bridge domain is not clear in that model

Here I wanted to improve the model to better document a l2 shared broadcast domain ( refered here as L2 BRIDGE DOMAIN). This domain can be extended, even using 802.1q, and connect two separate vlans that are part of different vlan groups.

As it is vlan groups can represent the following interesting use cases

a group of vlans associated to a esx interface , and corresponding association to a port group/switch
a set of vlans configured in a switch
a set of vlans configured in one site, within a core/user setup

With the additional field for a vlan l2 bridge domain we can improve what a vlan group actual represents

a l2 bridge domain, dc-a, can be assigned to several vlan groups identifying that all the vlans inside ( with same 802.1q tag) share the same broadcast domain
In this case a vlan group can represent a set of vlan that will share the same characteristics ( example a esx portgroup and corresponding assignment to a switch interfaces)
associating a l2 bridge domain, dc-a-b, to some of the vlans inside a vlan group , overriding the value provided in the group can identify the extension of this vlan across two environments
- dc-a-b , is a new l2 bridge domain , and dc-a as the dc-a-b defined as parent l2 bridge domain
  This will allow a good representation of possible l2 bridge domains that are extended across different vlan groups
- In the second site we can have a l2 bridge domain dc-b created using dc-a-b as parent
- Local defined l2 bridge domains ( dc-a , dc-b ) will be assigned to relevant vlan groups in each location
- extended l2 bridge domains will be defined as parents of the local ones , and assigned only to the vlan ids that are extended

I think there is room for both approaches, L2VPN is just one of the ways the extension of a l2 bridge domain is done.

We could potentially have

a L2 BRIDGE DOMAIN to represent the logical extension of vlans across vlan groups
a separated Object (L2VPN model) associated with the protocol of a L2 Bridge Domain to document how the extension is done
the L2VPN model can then be associated with layer 3 interfaces that are actually performing the tunnelling of the l2 traffic

@jcralbino commented on GitHub (May 17, 2022): The issue i see with the L2VPN approach in that FR is the way it wants to provide visibility on how the bridge domain is done. It focus also mainly in assignments to a vlan. It seems hard to have a link to the vlan group. The actual representation of a shared bridge domain is not clear in that model Here I wanted to improve the model to better document a l2 shared broadcast domain ( refered here as L2 BRIDGE DOMAIN). This domain can be extended, even using 802.1q, and connect two separate vlans that are part of different vlan groups. As it is vlan groups can represent the following interesting use cases - a group of vlans associated to a esx interface , and corresponding association to a port group/switch - a set of vlans configured in a switch - a set of vlans configured in one site, within a core/user setup With the additional field for a vlan l2 bridge domain we can improve what a vlan group actual represents - a l2 bridge domain, dc-a, can be assigned to several vlan groups identifying that all the vlans inside ( with same 802.1q tag) share the same broadcast domain In this case a vlan group can represent a set of vlan that will share the same characteristics ( example a esx portgroup and corresponding assignment to a switch interfaces) - associating a l2 bridge domain, dc-a-b, to some of the vlans inside a vlan group , overriding the value provided in the group can identify the extension of this vlan across two environments - dc-a-b , is a new l2 bridge domain , and dc-a as the dc-a-b defined as parent l2 bridge domain This will allow a good representation of possible l2 bridge domains that are extended across different vlan groups - In the second site we can have a l2 bridge domain dc-b created using dc-a-b as parent - Local defined l2 bridge domains ( dc-a , dc-b ) will be assigned to relevant vlan groups in each location - extended l2 bridge domains will be defined as parents of the local ones , and assigned only to the vlan ids that are extended I think there is room for both approaches, L2VPN is just one of the ways the extension of a l2 bridge domain is done. We could potentially have - a L2 BRIDGE DOMAIN to represent the logical extension of vlans across vlan groups - a separated Object (L2VPN model) associated with the protocol of a L2 Bridge Domain to document how the extension is done - the L2VPN model can then be associated with layer 3 interfaces that are actually performing the tunnelling of the l2 traffic

adam commented

@jcralbino commented on GitHub (May 18, 2022):

I have edited the initial posts above in order to fix some typos, and to make sure they are more clear

@jcralbino commented on GitHub (May 18, 2022): I have edited the initial posts above in order to fix some typos, and to make sure they are more clear

adam commented

@DanSheps commented on GitHub (May 19, 2022):

Can you give me a real world example of how you would bridge two VLANs? Config wise I mean

@DanSheps commented on GitHub (May 19, 2022): Can you give me a real world example of how you would bridge two VLANs? Config wise I mean

adam commented

@jcralbino commented on GitHub (May 23, 2022):

Lets consider this topology:

original file here

In here we would have L3 in each Core switch, and a FW to protect specific User vlans deployed across the campus.
Also we use the VLAN Groups to document range assignment to different floors or buildings as needed.

But the goal is indeed to take advantage of VLAN groups as an aggregation of vlans instead of being a representation of a broadcast domain. where for example vlan id 100 in two different vlan groups can be seen as sharing the same broad cast domain.

Scenario1: 802.1Q

If we consider that we have a normal 802.1Q network with stacks and uplinks in a hub and spoke topology. Where each floor is a spoke with redundant uplinks to the core.
VlanGroups here in this setup are used to document and model the different ranges of vlans assigned to the different floors.
If we had a L2 BridgeDomain, L2BD_BuildingA assigned to several groups we could obtain the following relationships.
- Netbox Menu : L2 Bridge Domain: <L2BD_BuildingA> we would have a page in netbox that will list the following:
  - A VLAN List that for every VLAN ID, regardless of the vlan group, assigned to the same L2 Bridge Domain we would identify the device interfaces assigned to this VLAN ID, and IP Interfaces assigned to this L2 Bridge Domain
  - A configuration page detailing the Protocol used for the Bridge Domain , and Vlan Groups assigned to it. All the other fields like description would be shown here also. In this case protocol could be 802.1Q. The parent L2 Bridge Domain would also appear here.
L2 Extended BridgeDomain to another core, In this case we could have in the Interlink-Building the extension of the vlans that are to be deployed behind the FW.
So VLAN2000-2099 can be deployed at request, in each floor switch regardless of the building. Therefore they need to be extended in Layer 2 accross the two cores
Bridbing this vlans can be done in this scenario using a normally 802.1.Q trunk. As we are using stacks to provide redundant paths there is no single point of failure and no need for Spanning Tree.

automation procedures:

We will obtain from netbox the vlanGroup-BldA-floor1 deployed in this stack of switches, and use automation to make sure all vlans are configured in that switch.
The same validation will be done in the trunk uplinks for the core, and switch.
We can check that the core switch, also includes in its VLAN DB, all the required vlans as defined in vlanGroup-BldA-floor1
Current limitation is that Devices Interfaces deployed vlans part of the vlanGroup-BldA-floor1, will not be seen in other groups unless a L2 Bridge domain is used

Scenario 2: SPB Overlay

In more modern enterprise environment, we could have the same topology using SPB (IEEE802.1aq and RFC 6329 ) as an overlay technology to extend the Layer 2 across campus
In this case L2 Bridge Domain, can have the same assignments between VLAN Groups but in the detail page we would seE:
- Protocol : Defined as SPB ( New Data model could be used to map the configuration required for this protocol).
In this the extension across buildings is done using an IP underlay, and SPB will provide the overlay technology. But the Bridge Domain concept remains intact regardless of the protocol. Meaning:
- If we would go to a Netbox Menu : L2 Bridge Domain: <L2BD_BuildingA>, or <L2BD_BldExtended> we would have a page in netbox that will list the following:
- A VLAN List that for every VLAN ID, regardless of the vlan group, assigned to the same L2 Bridge Domain we would identify the device interfaces assigned to this VLAN ID, and IP Interfaces assigned to this L2 Bridge Domain
- In the detailed configuration page we would see the Protocol used for the Bridge Domain as SPB. The parent L2 Bridge Domain would also appear here. Relevant fields to model this Overlay technology would be seen there also.
Bridbing this vlans can be done in this scenario using SPB that use an underlay based in a layer 3 routed environment. Assigning a Service ID to the vlans that need to be extended and configuring them in the core of each building will allow us to bridge the vlans. As we are using stacks to provide redundant paths there is no single point of failure.

Scenario n: TRILL , VXLAN..

Regardless of how you build the scenario, and the overlay technology used introducing a L2 Bridge Domain concept that can correlate VLAN ID, accross VLAN Groups is needed. This will allow us to identify the Interfaces and IP address assigned to that Bridge Domain that is using a specific VLAN ID
For the sake of simplicity i assume that using the VLAN ID on the client side, means that the same Bridge Domain is deployed, although this may not be always the case. As the Bridge Domain that is itself a logical concept will be mapped to some other unique identifier ( VXLAN Network Identified for VxLAN, Customer VLan ID for SPB...). Nevertheless that is something that could be document inside the VLAN Group.

PS: This approach would not break the current utilization of VLAN Groups for scenarios where other users consider this object as a definition of a bridge domain.

@jcralbino commented on GitHub (May 23, 2022): Lets consider this topology: ![image](https://user-images.githubusercontent.com/44149262/169806710-d0e07113-5bbe-4ee0-a600-2d2fc9b7c37b.png) [original file here](https://viewer.diagrams.net/?tags=%7B%7D&highlight=0000ff&edit=_blank&layers=1&nav=1&title=L2BridgeDomain.drawio#Uhttps%3A%2F%2Fraw.githubusercontent.com%2Fjcralbino%2Fshared%2Fmain%2FL2BridgeDomain.drawio) In here we would have L3 in each Core switch, and a FW to protect specific User vlans deployed across the campus. Also we use the VLAN Groups to document range assignment to different floors or buildings as needed. But the goal is indeed to take advantage of VLAN groups as an aggregation of vlans instead of being a representation of a broadcast domain. where for example vlan id 100 in two different vlan groups can be seen as sharing the same broad cast domain. ### Scenario1: 802.1Q - If we consider that we have a normal 802.1Q network with stacks and uplinks in a hub and spoke topology. Where each floor is a spoke with redundant uplinks to the core. - VlanGroups here in this setup are used to document and model the different ranges of vlans assigned to the different floors. - If we had a L2 BridgeDomain, L2BD_BuildingA assigned to several groups we could obtain the following relationships. - Netbox Menu : L2 Bridge Domain: <L2BD_BuildingA> we would have a page in netbox that will list the following: - A VLAN List that for every VLAN ID, regardless of the vlan group, assigned to the same L2 Bridge Domain we would identify the device interfaces assigned to this VLAN ID, and IP Interfaces assigned to this L2 Bridge Domain - A configuration page detailing the Protocol used for the Bridge Domain , and Vlan Groups assigned to it. All the other fields like description would be shown here also. In this case protocol could be 802.1Q. The parent L2 Bridge Domain would also appear here. - L2 Extended BridgeDomain to another core, In this case we could have in the Interlink-Building the extension of the vlans that are to be deployed behind the FW. - So VLAN2000-2099 can be deployed at request, in each floor switch regardless of the building. Therefore they need to be extended in Layer 2 accross the two cores - **Bridbing this vlans** can be done in this scenario using a normally 802.1.Q trunk. As we are using stacks to provide redundant paths there is no single point of failure and no need for Spanning Tree. #### automation procedures: - We will obtain from netbox the vlanGroup-BldA-floor1 deployed in this stack of switches, and use automation to make sure all vlans are configured in that switch. - The same validation will be done in the trunk uplinks for the core, and switch. - We can check that the core switch, also includes in its VLAN DB, all the required vlans as defined in vlanGroup-BldA-floor1 - Current limitation is that Devices Interfaces deployed vlans part of the vlanGroup-BldA-floor1, will not be seen in other groups unless a L2 Bridge domain is used ### Scenario 2: SPB Overlay - In more modern enterprise environment, we could have the same topology using SPB (IEEE802.1aq and RFC 6329 ) as an overlay technology to extend the Layer 2 across campus - In this case L2 Bridge Domain, can have the same assignments between VLAN Groups but in the detail page we would seE: - Protocol : Defined as SPB ( New Data model could be used to map the configuration required for this protocol). - In this the extension across buildings is done using an IP underlay, and SPB will provide the overlay technology. But the Bridge Domain concept remains intact regardless of the protocol. Meaning: - If we would go to a Netbox Menu : L2 Bridge Domain: <L2BD_BuildingA>, or <L2BD_BldExtended> we would have a page in netbox that will list the following: - A VLAN List that for every VLAN ID, regardless of the vlan group, assigned to the same L2 Bridge Domain we would identify the device interfaces assigned to this VLAN ID, and IP Interfaces assigned to this L2 Bridge Domain - In the detailed configuration page we would see the Protocol used for the Bridge Domain as SPB. The parent L2 Bridge Domain would also appear here. Relevant fields to model this Overlay technology would be seen there also. - **Bridbing this vlans** can be done in this scenario using SPB that use an underlay based in a layer 3 routed environment. Assigning a Service ID to the vlans that need to be extended and configuring them in the core of each building will allow us to bridge the vlans. As we are using stacks to provide redundant paths there is no single point of failure. ### Scenario n: TRILL , VXLAN.. - Regardless of how you build the scenario, and the overlay technology used introducing a L2 Bridge Domain concept that can correlate VLAN ID, accross VLAN Groups is needed. This will allow us to identify the Interfaces and IP address assigned to that Bridge Domain that is using a specific VLAN ID - For the sake of simplicity i assume that using the VLAN ID on the client side, means that the same Bridge Domain is deployed, although this may not be always the case. As the Bridge Domain that is itself a logical concept will be mapped to some other unique identifier ( VXLAN Network Identified for VxLAN, Customer VLan ID for SPB...). Nevertheless that is something that could be document inside the VLAN Group. PS: This approach would not break the current utilization of VLAN Groups for scenarios where other users consider this object as a definition of a bridge domain.

adam commented

@shatt79 commented on GitHub (May 24, 2022):

Can you give me a real world example of how you would bridge two VLANs? Config wise I mean

Easy. Here's an example using IOS-XR. I'm just taking two sub-interfaces on two different routers, and bridging them together over an EoMPLS pseudowire. One sub is even double tagged. I've also created a BDI (new version of SVI) and added it to the bridge-domain. The old concept of VLANs and chassis level significance is obsolete - at least in the provider/datacenter world. To create layer 2 networks, you create bridge-domains and add interfaces, sub-interfaces, BDIs, VFIs and PWs to those BDs.

If a customer had two sites, and they wanted me to bridge both of those sites together so they have internet access using the same subnet, this is how it'd be built in our aggregation layer. Just a fake example, of course.

Router 1:

interface lo10
description LDP Loopback
ip address 10.20.30.55 255.255.255.255
!
interface bdi 100
description Gateway for Customer ABC
ip address 23.45.67.1 255.255.255.248
!
interface gi101/0/0/1.177 l2transport
encapsulation dot1q 177
rewwrite ingress tag pop 1 symmetric
!
l2vpn
bridge group Customer_ABC
bridge-domain 177
interface gi101/0/0/1.177
neighbor 10.20.30.65 pw-id 100
routed-interface bdi 100
!
!

Router 2:

interface lo10
description LDP Loopback
ip address 10.20.30.65 255.255.255.255
!
interface Te0/2/0/2.216 l2transport
encapsulation dot1q 216 second-dot1q 311
rewrite ingress tag pop 2 symmetric
!
l2vpn
bridge group Customer_ABC
bridge-domain 216
interface te0/2/0/2.216
neighbor 10.20.30.55 pw-id 100

@shatt79 commented on GitHub (May 24, 2022): > Can you give me a real world example of how you would bridge two VLANs? Config wise I mean Easy. Here's an example using IOS-XR. I'm just taking two sub-interfaces on two different routers, and bridging them together over an EoMPLS pseudowire. One sub is even double tagged. I've also created a BDI (new version of SVI) and added it to the bridge-domain. The old concept of VLANs and chassis level significance is obsolete - at least in the provider/datacenter world. To create layer 2 networks, you create bridge-domains and add interfaces, sub-interfaces, BDIs, VFIs and PWs to those BDs. If a customer had two sites, and they wanted me to bridge both of those sites together so they have internet access using the same subnet, this is how it'd be built in our aggregation layer. Just a fake example, of course. Router 1: interface lo10 description LDP Loopback ip address 10.20.30.55 255.255.255.255 ! interface bdi 100 description Gateway for Customer ABC ip address 23.45.67.1 255.255.255.248 ! interface gi101/0/0/1.177 l2transport encapsulation dot1q 177 rewwrite ingress tag pop 1 symmetric ! l2vpn bridge group Customer_ABC bridge-domain 177 interface gi101/0/0/1.177 neighbor 10.20.30.65 pw-id 100 routed-interface bdi 100 ! ! Router 2: interface lo10 description LDP Loopback ip address 10.20.30.65 255.255.255.255 ! interface Te0/2/0/2.216 l2transport encapsulation dot1q 216 second-dot1q 311 rewrite ingress tag pop 2 symmetric ! l2vpn bridge group Customer_ABC bridge-domain 216 interface te0/2/0/2.216 neighbor 10.20.30.55 pw-id 100

adam commented

@DanSheps commented on GitHub (May 24, 2022):

Easy. Here's an example using IOS-XR. I'm just taking two sub-interfaces on two different routers, and bridging them together over an EoMPLS pseudowire.

Your use case seems to be covered by #8157

@jcralbino 's use case seems more nuanced, I would like to see an actual config for that one . Specifically the Scenario 1. I am having a hard time understanding exactly what is going on and perhaps a configuration example like your example would assist. If the example is the same as yours, then #8157 would likely solve it.

@DanSheps commented on GitHub (May 24, 2022): > Easy. Here's an example using IOS-XR. I'm just taking two sub-interfaces on two different routers, and bridging them together over an EoMPLS pseudowire. Your use case seems to be covered by #8157 @jcralbino 's use case seems more nuanced, I would like to see an actual config for that one . Specifically the Scenario 1. I am having a hard time understanding exactly what is going on and perhaps a configuration example like your example would assist. If the example is the same as yours, then #8157 would likely solve it.

adam commented

@jcralbino commented on GitHub (May 24, 2022):

@DanSheps
The fact is that i want to use VLAN Groups to automate also how the VLANs are configured across the infrastructure. Either on a set of interfaces for trunk vlans (esx port groups for example) or across a set of switch.

As defined in the model "A VLAN group is an arbitrary collection of VLANs within which VLAN IDs and names must be unique."

The issue i have with the current model is that a VLAN Group also defines a unique broadcast domain.
I would like to separate that concept of L2 forwarding data plane ( Bridge Domain) from the vlan group.

Currently i do not know how the L2VPN model is being planned , and it could be that https://github.com/netbox-community/netbox/issues/8157 may provide what i need, but using that concept for a legacy 802.1q deployment is not correct. And the fact is also that current way layer 2 modeling works can also be improved by providing different class ( L2 Bridge domain ) that will clearly identify a distinct forwarding plane

Anyway i opened a discussion for this topic https://github.com/netbox-community/netbox/discussions/9418 if you wish to discuss the layer 2 modeling of several generic scenarios, and the limitations it currently has for the scenarios I identified.

@jcralbino commented on GitHub (May 24, 2022): @DanSheps The fact is that i want to use VLAN Groups to automate also how the VLANs are configured across the infrastructure. Either on a set of interfaces for trunk vlans (esx port groups for example) or across a set of switch. As defined in the model "A VLAN group is an arbitrary collection of VLANs within which VLAN IDs and names must be unique." The issue i have with the current model is that a VLAN Group also defines a unique broadcast domain. I would like to separate that concept of L2 forwarding data plane ( Bridge Domain) from the vlan group. Currently i do not know how the L2VPN model is being planned , and it could be that https://github.com/netbox-community/netbox/issues/8157 may provide what i need, but using that concept for a legacy 802.1q deployment is not correct. And the fact is also that current way layer 2 modeling works can also be improved by providing different class ( L2 Bridge domain ) that will clearly identify a distinct forwarding plane Anyway i opened a discussion for this topic https://github.com/netbox-community/netbox/discussions/9418 if you wish to discuss the layer 2 modeling of several generic scenarios, and the limitations it currently has for the scenarios I identified.

adam commented

@DanSheps commented on GitHub (May 27, 2022):

@DanSheps The fact is that i want to use VLAN Groups to automate also how the VLANs are configured across the infrastructure. Either on a set of interfaces for trunk vlans (esx port groups for example) or across a set of switch.

Unfortunately we cannot cater to 1 specific use case (your automation). If you need to validate, based on the criterion set up in your discussion you opened, you can create a custom validator that does just that for you.

With that, you should have the tools to properly limit vlan collisions within a specific domain using VLAN Groups, Site Groups and VLANs.

As defined in the model "A VLAN group is an arbitrary collection of VLANs within which VLAN IDs and names must be unique."

The issue i have with the current model is that a VLAN Group also defines a unique broadcast domain. I would like to separate that concept of L2 forwarding data plane ( Bridge Domain) from the vlan group.

A VLAN group does not define a unique broadcast domain, you just are assuming that based your own configuration which is not 100% accurate.

@DanSheps commented on GitHub (May 27, 2022): > @DanSheps The fact is that i want to use VLAN Groups to automate also how the VLANs are configured across the infrastructure. Either on a set of interfaces for trunk vlans (esx port groups for example) or across a set of switch. Unfortunately we cannot cater to 1 specific use case (your automation). If you need to validate, based on the criterion set up in your discussion you opened, you can create a custom validator that does just that for you. With that, you should have the tools to properly limit vlan collisions within a specific domain using VLAN Groups, Site Groups and VLANs. > As defined in the model "A VLAN group is an arbitrary collection of VLANs within which VLAN IDs and names must be unique." > > The issue i have with the current model is that a VLAN Group also defines a unique broadcast domain. I would like to separate that concept of L2 forwarding data plane ( Bridge Domain) from the vlan group. A VLAN group does not define a unique broadcast domain, you just are assuming that based your own configuration which is not 100% accurate.

adam commented

@jcralbino commented on GitHub (Jun 10, 2022):

Hello @DanSheps

From the perspective of defining a unique broadcast domain indeed the VLAN is doing that.
But as the VLAN Group current implementation is limited to allowing one VLAN to be part of a unique VLAN Group, then this is also limiting the use of VLAN Group. Due to this limitation the VLAN Group by inheritance is also limiting the broadcast domain

Can we change this implementation in a way that one VLAN can be part of multiple VLAN Groups?

@jcralbino commented on GitHub (Jun 10, 2022): Hello @DanSheps From the perspective of defining a unique broadcast domain indeed the VLAN is doing that. But as the VLAN Group current implementation is limited to allowing one VLAN to be part of a unique VLAN Group, then this is also limiting the use of VLAN Group. Due to this limitation the VLAN Group by inheritance is also limiting the broadcast domain Can we change this implementation in a way that one VLAN can be part of multiple VLAN Groups?

adam commented

@github-actions[bot] commented on GitHub (Aug 10, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Aug 10, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented