starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

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

New Issue
Open
opened 2025-12-29 20:42:57 +01:00 by adam · 5 comments
adam commented 2025-12-29 20:42:57 +01:00
Owner
Copy Link

Originally created by @DanSheps on GitHub (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

Originally created by @DanSheps on GitHub (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 [![](https://mermaid.ink/img/pako:eNqllFtvgjAYhv9K02v1wkvulhgX4yFmm16RLB39wE5oSSkkRvjv64EGpmLm5EKgPt_b9zvQM44EBRxgkDNGEkmykCN9zaBiEaCzezMX4woxirZLFOKtZBmRJ7SEU4g7pFCS8QRxkgHS1MbcRdxq9UGjRSFmnCkmeIHmRnT_NteoX0QSUmIefFzjbqvpfrt5wtfOcE7E-Lul_gEyY9xu_uBGBkmnVc51Rt1qEh8RKQqWcKCf4usbIuUyfgUOkkVoLiTof_tqrZ_96mXzDw-VZmyiNn4xu1sMy9yohVl3rVuTPDcxjxuhboxstvpHiYFhqFLC-5TZ-8LOgiuQMXl2KDuZfspeq-SKJAlQ52Xn3_wsFgeW92z9-lTqejIR557NAB1IcYGMx0OIG8laWOJqDG9oOfK6ST3UdvYvYOeoETYLGxkgl_5NpvaML5kvx5X3tjB3DQwFDZdqYAfPhRyPcKYZwqg-3ezIhFgdwPQ80I-UyKNpZaM5UirxfuIRDpQsYYTLnBIF7XmIg5ikhV4FypSQa3dc2lOz-QEn5pxk?type=png)](https://mermaid.live/edit#pako:eNqllFtvgjAYhv9K02v1wkvulhgX4yFmm16RLB39wE5oSSkkRvjv64EGpmLm5EKgPt_b9zvQM44EBRxgkDNGEkmykCN9zaBiEaCzezMX4woxirZLFOKtZBmRJ7SEU4g7pFCS8QRxkgHS1MbcRdxq9UGjRSFmnCkmeIHmRnT_NteoX0QSUmIefFzjbqvpfrt5wtfOcE7E-Lul_gEyY9xu_uBGBkmnVc51Rt1qEh8RKQqWcKCf4usbIuUyfgUOkkVoLiTof_tqrZ_96mXzDw-VZmyiNn4xu1sMy9yohVl3rVuTPDcxjxuhboxstvpHiYFhqFLC-5TZ-8LOgiuQMXl2KDuZfspeq-SKJAlQ52Xn3_wsFgeW92z9-lTqejIR557NAB1IcYGMx0OIG8laWOJqDG9oOfK6ST3UdvYvYOeoETYLGxkgl_5NpvaML5kvx5X3tjB3DQwFDZdqYAfPhRyPcKYZwqg-3ezIhFgdwPQ80I-UyKNpZaM5UirxfuIRDpQsYYTLnBIF7XmIg5ikhV4FypSQa3dc2lOz-QEn5pxk) ### External dependencies None
adam added the type: featurenetboxstatus: backlogcomplexity: high labels 2025-12-29 20:42:57 +01:00
adam commented 2025-12-29 20:42:58 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (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 commented on GitHub (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?
adam commented 2025-12-29 20:42:58 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Dec 8, 2023):

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.
@sleepinggenius2 commented on GitHub (Dec 8, 2023): 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.
adam commented 2025-12-29 20:42:58 +01:00
Author
Owner
Copy Link

@jdavidson2021 commented on GitHub (Jan 2, 2024):

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.

@jdavidson2021 commented on GitHub (Jan 2, 2024): > 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.
adam commented 2025-12-29 20:42:58 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (May 16, 2024):

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 (May 16, 2024): 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 2025-12-29 20:42:59 +01:00
Author
Owner
Copy Link

@alehaa commented on GitHub (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.

@alehaa commented on GitHub (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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label complexity: high netbox status: backlog type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#8926
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?