"available-prefixes" functionality for VLAN's

[TheNetworkGuy]

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.

[jeremystretch]

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.

[TheNetworkGuy]

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.

[yarnocobussen]

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]

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

[stnzzz]

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]

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.

[aslater3]

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?