Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add VLAN Device Mapping model for consumption by various other models #14451

Open
DanSheps opened this issue Dec 6, 2023 · 5 comments
Open
Labels
complexity: high Expected to require a large amont of time and effort to implement relative to other tasks netbox status: backlog Awaiting selection for work type: feature Introduction of new functionality to the application

Comments

@DanSheps
Copy link
Member

DanSheps commented Dec 6, 2023

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 DanSheps added the type: feature Introduction of new functionality to the application label Dec 6, 2023
@DanSheps
Copy link
Member Author

DanSheps commented Dec 6, 2023

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?

@DanSheps DanSheps added the status: under review Further discussion is needed to determine this issue's scope and/or implementation label Dec 6, 2023
@sleepinggenius2
Copy link
Contributor

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
Copy link

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. 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.

Copy link
Contributor

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 github-actions bot added the pending closure Requires immediate attention to avoid being closed for inactivity label May 16, 2024
@jeremystretch jeremystretch added status: backlog Awaiting selection for work complexity: high Expected to require a large amont of time and effort to implement relative to other tasks and removed status: under review Further discussion is needed to determine this issue's scope and/or implementation pending closure Requires immediate attention to avoid being closed for inactivity labels May 22, 2024
@alehaa
Copy link
Contributor

alehaa commented Jun 29, 2024

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.

@jeremystretch jeremystretch added the netbox label Nov 1, 2024 — with Linear
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
complexity: high Expected to require a large amont of time and effort to implement relative to other tasks netbox status: backlog Awaiting selection for work type: feature Introduction of new functionality to the application
Projects
None yet
Development

No branches or pull requests

5 participants