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

"available-prefixes" functionality for VLAN's #2187

New Issue
Closed
opened 2025-12-29 17:23:06 +01:00 by adam · 10 comments
adam commented 2025-12-29 17:23:06 +01:00
Owner
Copy Link

Originally created by @TheNetworkGuy on GitHub (Dec 9, 2018).

Originally assigned to: @jeremystretch on GitHub.

Environment

  • Python version: 3.7.1
  • NetBox version: 2.5 beta 1

We are using Netbox to autodeploy customer networks (L3) using the API "available-prefixes" functionality (/api/ipam/prefixes/{PREFIX_ID}/available-prefixes/.) It would be great to have this functionality for VLAN's as well. This would require (in our environment) 2 different adjustments:

  • Add similar functionality to the API for VLAN deployment. For instance: (/api/ipam/vlan-groups/{VLAN_GROUP_ID}/available-vlans) will provide the next usable VLAN. This could also give a list of VLAN's if the user provides the amount of requested VLAN's in the JSON body.
  • Furthermore, It would be great to create a VLAN group and restricting this group to a selected amount of VLAN's (for instance, 150 - 170). We use VLAN groups for each customer deployment. This will keep each customer in its own group and prevent over-exhaustion of VLAN's.

For database changes: This would require a new string field in the database under vlan groups, specifying the restrictions for the VLAN group.

This would also require additional API changes.

Thanks for considering / reading this feature request.

Originally created by @TheNetworkGuy on GitHub (Dec 9, 2018). Originally assigned to: @jeremystretch on GitHub. <!-- NOTE: This form is only for proposing specific new features or enhancements. If you have a general idea or question, please post to our mailing list instead of opening an issue: https://groups.google.com/forum/#!forum/netbox-discuss NOTE: Due to an excessive backlog of feature requests, we are not currently accepting any proposals which significantly extend NetBox's feature scope. Please describe the environment in which you are running NetBox. Be sure that you are running an unmodified instance of the latest stable release before submitting a bug report. --> ### Environment * Python version: 3.7.1 * NetBox version: 2.5 beta 1 We are using Netbox to autodeploy customer networks (L3) using the API "available-prefixes" functionality (/api/ipam/prefixes/{PREFIX_ID}/available-prefixes/.) It would be great to have this functionality for VLAN's as well. This would require (in our environment) 2 different adjustments: - Add similar functionality to the API for VLAN deployment. For instance: (/api/ipam/vlan-groups/{VLAN_GROUP_ID}/available-vlans) will provide the next usable VLAN. This could also give a list of VLAN's if the user provides the amount of requested VLAN's in the JSON body. - Furthermore, It would be great to create a VLAN group and restricting this group to a selected amount of VLAN's (for instance, 150 - 170). We use VLAN groups for each customer deployment. This will keep each customer in its own group and prevent over-exhaustion of VLAN's. For database changes: This would require a new string field in the database under vlan groups, specifying the restrictions for the VLAN group. This would also require additional API changes. Thanks for considering / reading this feature request.
adam added the status: acceptedtype: feature labels 2025-12-29 17:23:06 +01:00
adam closed this issue 2025-12-29 17:23:07 +01:00
adam commented 2025-12-29 17:23:08 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 19, 2018):

I'm not sure I see much value in this. VLAN assignment is typically done with more attention to numbering than IP addressing due to the extremely limited number space. To this point:

Furthermore, It would be great to create a VLAN group and restricting this group to a selected amount of VLAN's (for instance, 150 - 170).

This would defeat the purpose of automatic allocation, since you already have a specific number(s) in mind. If this feature was implemented, it would be limited strictly to the next unallocated number within the available range, just like the IP/prefix function.

@jeremystretch commented on GitHub (Dec 19, 2018): I'm not sure I see much value in this. VLAN assignment is typically done with more attention to numbering than IP addressing due to the extremely limited number space. To this point: > Furthermore, It would be great to create a VLAN group and restricting this group to a selected amount of VLAN's (for instance, 150 - 170). This would defeat the purpose of automatic allocation, since you already have a specific number(s) in mind. If this feature was implemented, it would be limited strictly to the next unallocated number within the available range, just like the IP/prefix function.
adam commented 2025-12-29 17:23:08 +01:00
Author
Owner
Copy Link

@TheNetworkGuy commented on GitHub (Dec 19, 2018):

This is exactly my thought. Since you already give a range of VLAN numbers the only API interaction would be returning the next unallocated vlan number. In the given VLAN range, of course.

@TheNetworkGuy commented on GitHub (Dec 19, 2018): This is exactly my thought. Since you already give a range of VLAN numbers the only API interaction would be returning the next unallocated vlan number. In the given VLAN range, of course.
adam commented 2025-12-29 17:23:08 +01:00
Author
Owner
Copy Link

@yarnocobussen commented on GitHub (Jan 2, 2019):

The ability to restrict a VLAN group to one or more ranges could be a solid addition to Netbox.
Such an addition would make an "available vlans" function actually viable and useful.

An example which represents the use case for our production environments:

  • some vlans are not stretched between access networks, this range is 1-500
    -- this range is enforced as unique within a single access network, re-using it in another is allowed

  • some vlans are stretched between access networks, this range is 501-1000
    -- this range is enforced as unique across all access networks, re-using it in another is not allowed

Example groups in Netbox to administrate several of these groups:

  • local1 (can use 1-500)
  • local2 (can use 1-500)
  • global (can use 501-1000)

Now users start creating VLANs, using the "vlans available" functionality in the UI.
VLANs in local1 and local2 may overlap, so no issues are encountered just yet.
However, once you create 501 in local1 and configure it, you cause technical problems.
Further, one may also accidentally create VLAN 1 in the global group, causing further problems.

Currently, Netbox does't help with enforcing a convention to counteract these problems.
This could be solved by allowing you to restrict VLAN groups to specific ranges.

At this time, we use an ugly way to work around this issue:

  • all vlan ranges are pre-created for each group with status deprecated
  • provisioning queries the API for a VLAN with status deprecated in a specific group
  • the VLAN is then updated with some info and given the reserved or active status
  • deleted VLANs are stripped of all info and returned to the deprecated status
@yarnocobussen commented on GitHub (Jan 2, 2019): The ability to restrict a VLAN group to one or more ranges could be a solid addition to Netbox. Such an addition would make an "available vlans" function actually viable and useful. An example which represents the use case for our production environments: - some vlans are not stretched between access networks, this range is 1-500 -- this range is enforced as unique within a single access network, re-using it in another is allowed - some vlans are stretched between access networks, this range is 501-1000 -- this range is enforced as unique across all access networks, re-using it in another is not allowed Example groups in Netbox to administrate several of these groups: - local1 (can use 1-500) - local2 (can use 1-500) - global (can use 501-1000) Now users start creating VLANs, using the "vlans available" functionality in the UI. VLANs in local1 and local2 may overlap, so no issues are encountered just yet. However, once you create 501 in local1 and configure it, you cause technical problems. Further, one may also accidentally create VLAN 1 in the global group, causing further problems. Currently, Netbox does't help with enforcing a convention to counteract these problems. This could be solved by allowing you to restrict VLAN groups to specific ranges. At this time, we use an ugly way to work around this issue: - all vlan ranges are pre-created for each group with status deprecated - provisioning queries the API for a VLAN with status deprecated in a specific group - the VLAN is then updated with some info and given the reserved or active status - deleted VLANs are stripped of all info and returned to the deprecated status
adam commented 2025-12-29 17:23:08 +01:00
Author
Owner
Copy Link

@yarnocobussen commented on GitHub (Apr 26, 2019):

@jeremystretch Is there any further feedback you are looking for regarding this request? Perhaps any other form of help?

@yarnocobussen commented on GitHub (Apr 26, 2019): @jeremystretch Is there any further feedback you are looking for regarding this request? Perhaps any other form of help?
adam commented 2025-12-29 17:23:08 +01:00
Author
Owner
Copy Link

@stnzzz commented on GitHub (Dec 10, 2019):

Any hope for this to be implemented at some point?

We would love to have it, for the same purpose as the original author. We are assigning running VLAN numbers to tenants in the datacenter and creating them now requires manual GUI clicking and is very prone to errors, for example due to accidentally assigning a VLAN in the wrong site creating a conflicting VLAN.

In our case this would be used by our internal tool which fetches the next available IP addresses for interface networks and the next available VLAN number and then gives the user ready-formatted commands to add them to the devices.

@stnzzz commented on GitHub (Dec 10, 2019): Any hope for this to be implemented at some point? We would love to have it, for the same purpose as the original author. We are assigning running VLAN numbers to tenants in the datacenter and creating them now requires manual GUI clicking and is very prone to errors, for example due to accidentally assigning a VLAN in the wrong site creating a conflicting VLAN. In our case this would be used by our internal tool which fetches the next available IP addresses for interface networks and the next available VLAN number and then gives the user ready-formatted commands to add them to the devices.
adam commented 2025-12-29 17:23:09 +01:00
Author
Owner
Copy Link

@stnzzz commented on GitHub (Dec 20, 2019):

Wrote the internal user interface tool already but didn't bother to figure out a workaround (like a separate database or using a similar hack as @yarnocobussen) for this yet. :)

Personally I would care most about the first point in the original request, the limitation is not so important.

@stnzzz commented on GitHub (Dec 20, 2019): Wrote the internal user interface tool already but didn't bother to figure out a workaround (like a separate database or using a similar hack as @yarnocobussen) for this yet. :) Personally I would care most about the first point in the original request, the limitation is not so important.
adam commented 2025-12-29 17:23:09 +01:00
Author
Owner
Copy Link

@aslater3 commented on GitHub (Apr 6, 2020):

I think ability to set ranges would be a good addition. I'm just working on something very similar where we need to track VLAN across tenants and the ability to tie down a group of VLANs to a range would be perfect. At present, the only way I can see of doing this, is to either reserve all the VLANs you dont want available for assignment. Or do as stnzzz says and query on a different status other than available?

@aslater3 commented on GitHub (Apr 6, 2020): I think ability to set ranges would be a good addition. I'm just working on something very similar where we need to track VLAN across tenants and the ability to tie down a group of VLANs to a range would be perfect. At present, the only way I can see of doing this, is to either reserve all the VLANs you dont want available for assignment. Or do as stnzzz says and query on a different status other than available?
adam commented 2025-12-29 17:23:09 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Feb 22, 2021):

I'd like this feature too..
I don't want to get 'the first available' vlan, as my vlans are grouped per purpose
0-999 Infrastructure
1000-3999 customer vlans
My automation requires a free vlan in the 1000+ range.. right now, I just get them all sorted and loop through to get the first available

+1

@PieterL75 commented on GitHub (Feb 22, 2021): I'd like this feature too.. I don't want to get 'the first available' vlan, as my vlans are grouped per purpose 0-999 Infrastructure 1000-3999 customer vlans My automation requires a free vlan in the 1000+ range.. right now, I just get them all sorted and loop through to get the first available +1
adam commented 2025-12-29 17:23:09 +01:00
Author
Owner
Copy Link

@WilliamDEdwards commented on GitHub (Apr 21, 2021):

+1. It seems like it would be relatively simple to implement. Are there any plans to assign a milestone in the near future?

@WilliamDEdwards commented on GitHub (Apr 21, 2021): +1. It seems like it would be relatively simple to implement. Are there any plans to assign a milestone in the near future?
adam commented 2025-12-29 17:23:09 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 23, 2021):

Furthermore, It would be great to create a VLAN group and restricting this group to a selected amount of VLAN's (for instance, 150 - 170).

I've opened a separate FR (#8168) to address this as it has implications beyond the automatic creation API endpoint.

@jeremystretch commented on GitHub (Dec 23, 2021): > Furthermore, It would be great to create a VLAN group and restricting this group to a selected amount of VLAN's (for instance, 150 - 170). I've opened a separate FR (#8168) to address this as it has implications beyond the automatic creation API endpoint.
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 status: accepted 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#2187
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?