Modeling of L2 forwarding planes

[jcralbino]

Hello Community,

Although netbox is a great tool to model a network and a DC environment, i feel that it lacks some capabilities when it comes to model a Layer 2 environment, and how the information in netbox can be used for the automation of the infrastructure

Currently the layer 2 environment is modeling using two classes defined here:

• Class VLANGroup:
  A VLAN group is an arbitrary collection of VLANs within which VLAN IDs and names must be unique.
• Class VLAN :
  A VLAN is a distinct layer two forwarding domain identified by a 12-bit integer (1-4094). Each VLAN must be assigned to a Site, however VLAN IDs need not be unique within a Site. A VLAN may optionally be assigned to a VLANGroup, within which all VLAN IDs and names but be unique. Like Prefixes, each VLAN is assigned an operational status and optionally a user-defined Role. A VLAN can have zero or more Prefixes assigned to it.

Using this classes, the way VLAN management can be implemented provides some limitations that can be explained in the following scenarios:

Scenario A: Assign VLANS to Sites.

• Assigning a VLAN to a site allow us to define the scope of the VLAN, but we are not performing any validation.

Limitation 1: No uniqueness validation when deploying vlans in sites

• When assigning the VLAN to a site we are not enforcing uniqueness on the VLAN ID , neither on VLAN Name.

• This can be a valid use case, but in order to distinguish different vlans we need to use custom fields or tags before assigning them to devices.

• Ultimately the same VLAN id can also be assigned to the same interface.. See bellow screenshots of tests done in https://demo.netbox.dev,

  Vlan creations
  

  Vlans assigned to switches:
  

Limitation 2: When defining vlans to sites we cannot enforce vlan ranges

• In order to take advantage of uniqueness validation and vlan range definition ( max and min value) we need to use vlan groups.

Scenario B: Assign VLANs to VLAN Groups

Limitation 3: Vlan groups are more then an arbitrary collection of vlans

• As VLAN Groups are used to provide uniqueness of VLAN IDs and VLAN Names across the vlan group they are the only way we have to enforce a vlan policy.
• The drawback is that they are also enforcing distinct forwarding domains, even if the same vlan id is used in the same site, but on different vlan groups.

Limitation 4: Using VLAN Groups to define vlans to be assigned to specific devices

• If we create VLAN Groups and use a vlan group to assign those vlans to specific scenarios, for example:
  • vlan-group-esx-cluster-1-portgroup2 : All VLANs inside this port group are unique and correct name is created, using this vlan group to assign trunk interfaces to all esx menbers of a specific cluster can be done.

The limitation here is that the mapping VLAN Group<->VLAN ID, also defines a unique forwarding data plane.
This creates problems in document for example the interfaces assigned to this unique layer two forwarding plane. In netbox the interfaces will be attached to the vlan id only assigned to this group.

Limitation 5: Using VLAN Groups to define vlans to deploy in specific switches.

• If we want to automate the deployment of a group of vlans to set of switches. Where the vlan group is actually the representation of the vlan database of the switch
• This can be a useful scenario when VTP is not deployed, and we need to make sure that vlans assigned to a trunk are also deployed in a specific switch
• The limitation in this scenario is that using separate VLAN Groups, will break the Layer 2 forwarding plane established in netbox. This will impact the way interfaces, and prefix are mapped to a VLAN id.

Scenario C: Modeling of Overlay forwarding planes

In the modern Campus and Datacenter environment a Layer 2 forwarding plane is implemented using overlay network technology , here are some examples focused in creating layer 2 data planes forwarding.

• Shortest Path Bridging (SPB), specified in the IEEE 802.1aq standard, wiki link
• TRILL , TRILL (Transparent Interconnection of Lots of Links , wiki link
• FabricPath , Cisco paper
• VXLAN
• Others can also be considered..

The main difficulty in mapping this overlay technologies is the fact that in netbox mapping this to a vlan group is not enough to document correctly this environment.

Possible Proposal:

• separation of the concept of a layer two forwarding plane from the vlan/vlan group to a separate entity.

  • For example the Creation of a Layer 2 Bridge domain class, that will be able to document better a Layer two forwarding data plane, without limiting VLAN Groups to define unique layer 2 forwarding planes.
    Also this will solve the limitation 1 when a vlan is assigned to sites

  • If this new l2 bridge domain is not assigned to a vlan, or vlan group, then previous model limits are maintained for backwards compatibility

  • For example as defined in this issue Creation of L2 Bridge Domain #9373

  • this will allow the vlan group to be used more broadly.

• Creation of a L2VPN model used to document the overlay technology if used for the layer two forwarding data plane. Something like Add L2VPN Support - ELINE, ELAN, ETREE, Bridge Domain via VPLS, EVPN, VXLAN #8157

  • this will take advantage of a separate class used to define a layer 2 forwarding plane , although the concept can be used also when no overlay technology is used for

[DanSheps]

Limitation 1: No uniqueness validation when deploying vlans in sites

You can create a custom validator

Limitation 2: When defining vlans to sites we cannot enforce vlan ranges

You can create a custom validator

Limitation 3: Vlan groups are more then an arbitrary collection of vlans

It doesn't enforce a unique broadcast domain. You can use it for that, with a custom validator, but it currently does not.

Limitation 4: Using VLAN Groups to define vlans to be assigned to specific devices

See above comment

Limitation 5: Using VLAN Groups to define vlans to deploy in specific switches.

You should be resolving all the vlans potentially deployed to one specific device, not just going group by group.

You can query: https://<netbox>/api/ipam/vlans/?available_on_device=<mydevicepk>&brief=true&offset=100 to resolve all vlans available on a device.

Scenario C: Modeling of Overlay forwarding planes

This is being addressed separately and there is no need to bring it up here.

[jcralbino]

Hello @DanSheps

Regarding the Limitation 3. when you refer:

Limitation 3: Vlan groups are more then an arbitrary collection of vlans

It doesn't enforce a unique broadcast domain. You can use it for that, with a custom
validator, but it currently does not.

We can see in this issue #5284 , where we extended VLANGroup mapping to multiple sites, in order to track discrete L2 domain, so there is a strong correlation. I understand that the VLANGroup does not enforce a unique broadcast domain, but it does provides severe limitations on the VLAN Forwarding plane.

I do agree that ultimately the distinct L2 forwarding plane is implemented on the VLAN level, and taking that into consideration also, i would be in favor of allowing a VLAN to be mapped to multiple VLANGroups. If VLANGroups is just arbitrary collection of VLANs as documented, then we should be able to have one VLAN mapped to multiple VLANGroups.

Currently if you assign a VLAN with the same ID, to multiple vlan Groups, you will indeed create two separate forwarding planes, and that is clear on how the Interfaces are mapped to a specific VLAN.

If this is possible, the need to have a separate L2 Bridge Domain is not needed, as the VLAN is actually doing that work. Is this a Feature request that can be added to the Core?