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 min/max VID values to VLAN groups for validation #5838

New Issue
Closed
opened 2025-12-29 19:33:21 +01:00 by adam · 5 comments
adam commented 2025-12-29 19:33:21 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Dec 23, 2021).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v3.1.2

Feature type

Data model extension

Proposed functionality

Add two new fields to the VLANGroup model:

  • min_vid
  • max_vid

These fields will be used to validate the assignment of child VLANs to the group. They will default to the absolute minimum and maximum values for a VLAN ID (1 and 4094 respectively), so their introduction will not cause a breaking change.

Use case

This was originally proposed under #2658 but warrants its own separate FR.

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.

Database changes

Add two new positive small integer fields to the VLANGroup model as noted above.

External dependencies

No response

Originally created by @jeremystretch on GitHub (Dec 23, 2021). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v3.1.2 ### Feature type Data model extension ### Proposed functionality Add two new fields to the VLANGroup model: * `min_vid` * `max_vid` These fields will be used to validate the assignment of child VLANs to the group. They will default to the absolute minimum and maximum values for a VLAN ID (1 and 4094 respectively), so their introduction will not cause a breaking change. ### Use case This was originally proposed under #2658 but warrants its own separate FR. > 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. ### Database changes Add two new positive small integer fields to the VLANGroup model as noted above. ### External dependencies _No response_
adam added the status: acceptedtype: feature labels 2025-12-29 19:33:21 +01:00
adam closed this issue 2025-12-29 19:33:21 +01:00
adam commented 2025-12-29 19:33:21 +01:00
Author
Owner
Copy Link

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

Maybe extend this idea a little bit ?
We could introduce a 'VlanRange' object type, just like ip ranges.
a vlanrange has to be part of a vlangroup.
the vlangroup always will contain all vlans and makes sure they are unique.
the vlanrange then can be used to provision vlans within a certain range of the vlangroup.

@PieterL75 commented on GitHub (Dec 23, 2021): Maybe extend this idea a little bit ? We could introduce a 'VlanRange' object type, just like ip ranges. a vlanrange has to be part of a vlangroup. the vlangroup always will contain all vlans and makes sure they are unique. the vlanrange then can be used to provision vlans within a certain range of the vlangroup.
adam commented 2025-12-29 19:33:22 +01:00
Author
Owner
Copy Link

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

That sounds over-complicated IMO. VLAN groups essentially already function as ranges; this just provides the option of reducing the range from the default min/max VIDs.

@jeremystretch commented on GitHub (Dec 23, 2021): That sounds over-complicated IMO. VLAN groups essentially already function as ranges; this just provides the option of reducing the range from the default min/max VIDs.
adam commented 2025-12-29 19:33:22 +01:00
Author
Owner
Copy Link

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

Giving it a second thought..
and yeah, it will overcomplicate it...
We just need to create several vlan groups to cover the entire 4096 vlans that are now in one group. and maybe link them together with a tag...
I'm happy with the proposed FR :-)

@PieterL75 commented on GitHub (Dec 23, 2021): Giving it a second thought.. and yeah, it will overcomplicate it... We just need to create several vlan groups to cover the entire 4096 vlans that are now in one group. and maybe link them together with a tag... I'm happy with the proposed FR :-)
adam commented 2025-12-29 19:33:22 +01:00
Author
Owner
Copy Link

@snowie-swe commented on GitHub (Dec 27, 2021):

iknow its closed. somesort of parent child relationship would be really nice.
Or something similar as IP Prefix binding it towards VRF.
Same can be made with just multiple groups and a good name standard.
But it would help to have when you do have multiple dc or environments within the same locations.

DC1
1-100 infra
101 - 999 transit
1000 - 4096 - Servers

DC2
1-100 infra
101 - 999 transit
1000 - 4096 - Servers

DCX
1-100 infra
101 - 999 transit
1000 - 4096 - Servers

@snowie-swe commented on GitHub (Dec 27, 2021): iknow its closed. somesort of parent child relationship would be really nice. Or something similar as IP Prefix binding it towards VRF. Same can be made with just multiple groups and a good name standard. But it would help to have when you do have multiple dc or environments within the same locations. DC1 1-100 infra 101 - 999 transit 1000 - 4096 - Servers DC2 1-100 infra 101 - 999 transit 1000 - 4096 - Servers DCX 1-100 infra 101 - 999 transit 1000 - 4096 - Servers
adam commented 2025-12-29 19:33:23 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Dec 27, 2021):

You can add a tag to vlangroups that belong together.
That's my approach anyway.
As Jeremy pointed out, it will created extra complexity that can be solved with a simple tag.

P

@PieterL75 commented on GitHub (Dec 27, 2021): You can add a tag to vlangroups that belong together. That's my approach anyway. As Jeremy pointed out, it will created extra complexity that can be solved with a simple tag. P
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#5838
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?