Closed jcralbino closed 2 years ago
Would #8157 cover all of this?
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
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
I have edited the initial posts above in order to fix some typos, and to make sure they are more clear
Can you give me a real world example of how you would bridge two VLANs? Config wise I mean
Lets consider this topology:
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.
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.
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
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 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.
@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.
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?
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.
This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
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
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
External dependencies
None