Add VLAN Device Mapping model for consumption by various other models

[DanSheps]

NetBox version

3.6.6

Feature type

New functionality

Proposed functionality

Add a new model, VLANDeviceMapping, that may be consumed by various other models (initially, L2VPN assigned_object attribute)

Use case

Currently, there is no way to denote that a VLAN is connected to a device, other then to look at the individual interfaces and enumerate them to determine if a VLAN is available on a specific device.

This makes it difficult to link a VLAN to a device for the purpose of adding a VXLAN (L2VPN) terminantion to that VLAN on that specific device (See #11466).

Database changes

External dependencies

None

[DanSheps]

After discussion between maintainers, it was decided that an intermediate model should be added between VLAN and Device for linking to L2VPN Terminations.

Two questions to discuss:

• Should VLANDeviceMapping device FK be nullable
  • This would allow a migration to the VLANDeviceMapping and instant deprecation of vlan being an assignable object to L2VPNTermination
• When a vlan is added too an interface as a tagged/untagged VLAN, should that automatically create a mapping?

[sleepinggenius2]

I'm really excited for this proposal. Your use case for VXLAN is not relevant on our network, but the even simpler use case of just associating VLANs with a device to be able to easily generate the VLAN stanzas in a switch config would be huge for us. I looked at implementing this with a multi-object custom field on the device, but that still left two issues that I couldn't resolve:

1. Using a custom field does not allow for adding edge attributes on the relationship. This is important on some of our equipment where a particular VLAN stanza requires additional configuration, for example: specifying that a particular VLAN should or should not be forwarded to the CPU. I do hope that the implementation of this new mapping table will support tags and custom fields to support this.
2. Associating a VLAN to a device should limit the VLANs available to be assigned to interfaces on that device. Therefore, my response to your question "When a vlan is added too an interface as a tagged/untagged VLAN, should that automatically create a mapping?" would be the exact opposite, you should have to create the mapping first before being able to use that VLAN as a tagged/untagged VLAN on a device interface. I understand that's a significant paradigm shift from how it works today, so an additional field and/or configuration option might need to be introduced to enable or disable that behavior. That would be very helpful for us to get around a number of limitations with the ways that VLANs can be scoped today, as there is currently no way to group locations, only sites, and a site can only be part of one site group. We constantly run into the issue where different teams need to be able to group the sites/locations where they have equipment in different ways, and that has led to a lot of VLANs in the global space, because there is no other way to scope them to support all the devices that they need to be able to be provisioned on. That then leads to a very long list of VLANs (including duplicate IDs) when selecting a tagged/untagged VLAN for an interface and at least a lot of frustration on the end user, if not errors.

[jdavidson2021]

I'm really excited for this proposal. Your use case for VXLAN is not relevant on our network, but the even simpler use case of just associating VLANs with a device to be able to easily generate the VLAN stanzas in a switch config would be huge for us. I looked at implementing this with a multi-object custom field on the device, but that still left two issues that I couldn't resolve:

2. Associating a VLAN to a device should limit the VLANs available to be assigned to interfaces on that device. Therefore, my response to your question "When a vlan is added too an interface as a tagged/untagged VLAN, should that automatically create a mapping?" would be the exact opposite, you should have to create the mapping first before being able to use that VLAN as a tagged/untagged VLAN on a device interface. I understand that's a significant paradigm shift from how it works today, so an additional field and/or configuration option might need to be introduced to enable or disable that behavior. That would be very helpful for us to get around a number of limitations with the ways that VLANs can be scoped today, as there is currently no way to group locations, only sites, and a site can only be part of one site group. We constantly run into the issue where different teams need to be able to group the sites/locations where they have equipment in different ways, and that has led to a lot of VLANs in the global space, because there is no other way to scope them to support all the devices that they need to be able to be provisioned on. That then leads to a very long list of VLANs (including duplicate IDs) when selecting a tagged/untagged VLAN for an interface and at least a lot of frustration on the end user, if not errors.

I would agree with many of your comments. We have nearly 20k devices and nearly 6k VLANs in our NetBox inventory. We wouldn't really utilize the the VXLAN portion of this request either, but our biggest issue with NetBox is how cumbersome it is to assign VLANs to interfaces. A method to easily associate a list of VLAN's to a device prior to assigning VLANs to interfaces could simplify VLAN assignments for us, but a way to associate VLANs to an interface during the interface CSV import would be our ideal solution.

[github-actions[bot]]

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.

[alehaa]

Associating a VLAN to a device should limit the VLANs available to be assigned to interfaces on that device.

I would find this really annoying as it would introduce an extra step. In my opinion, it would be sufficient to explicitly associate a VLAN with a device (either for using L2VPN or standalone, e.g. for switch configuration). VLANs used by interfaces could be queried from those and added to the list returned for the HTML and API views. If custom logic is needed to automatically create VLAN mappings, this could be solved via scripts, as these can now be triggered by events.

For adding the new model and forms I could prepare a PR if needed @DanSheps.