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

Assign VLANs also to Regions not only Sites or Global #745

New Issue
Closed
opened 2025-12-29 16:25:22 +01:00 by adam · 9 comments
adam commented 2025-12-29 16:25:22 +01:00
Owner
Copy Link

Originally created by @tioan on GitHub (Mar 3, 2017).

I would like i would like to be able to assign a vlan or vlan group also to an region not only global or to an site.

Now with region #164 and global vlan #235 support in Version 1.9 #933 i use two regions, one for our factory premises with 20 sites (every building as its own site) and a second region with only one site for the remote datacenter.

Now i can set all vlans that i want to use at the whole factory premises to global instead of an site.
But then all this vlan are even available at the secound region which is undesired.

Originally created by @tioan on GitHub (Mar 3, 2017). I would like i would like to be able to assign a vlan or vlan group also to an region not only global or to an site. Now with region #164 and global vlan #235 support in Version 1.9 #933 i use two regions, one for our factory premises with 20 sites (every building as its own site) and a second region with only one site for the remote datacenter. Now i can set all vlans that i want to use at the whole factory premises to global instead of an site. But then all this vlan are even available at the secound region which is undesired.
adam closed this issue 2025-12-29 16:25:23 +01:00
adam commented 2025-12-29 16:25:23 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 17, 2017):

How would you modify the existing data model to accomplish this?

@jeremystretch commented on GitHub (Mar 17, 2017): How would you modify the existing data model to accomplish this?
adam commented 2025-12-29 16:25:23 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 17, 2017):

You can create VLAN groups that are not restricted by site. This is probably even more flexible than assigning VLANs to regions, and it doesn't require any changes to the data model.

I'm going to close this out as this seems like a workable solution but please comment if you disagree.

@jeremystretch commented on GitHub (Mar 17, 2017): You can create VLAN groups that are not restricted by site. This is probably even more flexible than assigning VLANs to regions, and it doesn't require any changes to the data model. I'm going to close this out as this seems like a workable solution but please comment if you disagree.
adam commented 2025-12-29 16:25:23 +01:00
Author
Owner
Copy Link

@lampwins commented on GitHub (Mar 17, 2017):

@jeremystretch the VLAN group would belong to the global context then right? I think the bigger issue here is being able to assign a vlan/group to a subset of sites. In terms of a source of truth, if I am looking at a particular device, how would I make the association that a vlan/group should be applied to that device? Because I don't want my vlan/group to be applied to all devices, just a subset? Does that make sense?

@lampwins commented on GitHub (Mar 17, 2017): @jeremystretch the VLAN group would belong to the global context then right? I think the bigger issue here is being able to assign a vlan/group to a subset of sites. In terms of a source of truth, if I am looking at a particular device, how would I make the association that a vlan/group should be applied to that device? Because I don't want my vlan/group to be applied to all devices, just a subset? Does that make sense?
adam commented 2025-12-29 16:25:24 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 17, 2017):

@lampwins I don't follow. A VLAN being assigned to a site does not necessarily mean that it should exist on a particular device within that site. Some external knowledge about the network design is needed to make that call.

@jeremystretch commented on GitHub (Mar 17, 2017): @lampwins I don't follow. A VLAN being assigned to a site does not necessarily mean that it should exist on a particular device within that site. Some external knowledge about the network design is needed to make that call.
adam commented 2025-12-29 16:25:24 +01:00
Author
Owner
Copy Link

@lampwins commented on GitHub (Mar 17, 2017):

@jeremystretch You are correct, however it is an interpretation based on the current ambiguity of model in this case. Take this scenario for example; my config management system is building out a new device and looks to netbox for data. The closest a vlan can be to a device currently is at the site level. So that is only interpretation that my config management system can make, as I only want it looking at netbox for data as it is the source of truth.

Thinking about it more, the real solution to that particular problem would be vlan port assignment #150

So I get where you are coming from, it is just a different way of looking at it.

@lampwins commented on GitHub (Mar 17, 2017): @jeremystretch You are correct, however it is _an_ interpretation based on the current ambiguity of model in this case. Take this scenario for example; my config management system is building out a new device and looks to netbox for data. The closest a vlan can be to a device currently is at the site level. So that is only interpretation that my config management system can make, as I only want it looking at netbox for data as it is the source of truth. Thinking about it more, the real solution to that particular problem would be vlan port assignment #150 So I get where you are coming from, it is just a different way of looking at it.
adam commented 2025-12-29 16:25:24 +01:00
Author
Owner
Copy Link

@teutonet commented on GitHub (Apr 12, 2017):

We would like to request this feature too.
With this feature we can better represent the hierarchical vlan structure in our datacenters.
The data model has to be extended by a region field in the vlan model. Now you can set a vlan global to a region and/or local to a site.
For example:
VLAN 1 the backbone is available in all sites of region 1.
VLAN 2 a customer VLAN is only available in site 1 of region 1.
VLAN 3 another customer VLAN is only available in site 2 of region 1.

In the moment I have no idea how to maintain uniqueness of vlans within region and sites.
A vlan where site is set, has to be unique only in this site. A vlan where only region is set, has to be unique only in this region.

With a vlan group you have no direct relation from a vlan to a region, because vlan groups can only be assigned to sites.

@teutonet commented on GitHub (Apr 12, 2017): We would like to request this feature too. With this feature we can better represent the hierarchical vlan structure in our datacenters. The data model has to be extended by a _region_ field in the vlan model. Now you can set a vlan global to a region and/or local to a site. For example: VLAN 1 the backbone is available in all sites of region 1. VLAN 2 a customer VLAN is only available in site 1 of region 1. VLAN 3 another customer VLAN is only available in site 2 of region 1. In the moment I have no idea how to maintain uniqueness of vlans within region and sites. A vlan where site is set, has to be unique only in this site. A vlan where only region is set, has to be unique only in this region. With a vlan group you have no direct relation from a vlan to a region, because vlan groups can only be assigned to sites.
adam commented 2025-12-29 16:25:24 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 12, 2017):

@TeutoNet Again, you can easily create VLANGroups to establish this hierarchy.

@jeremystretch commented on GitHub (Apr 12, 2017): @TeutoNet Again, you can easily create VLANGroups to establish this hierarchy.
adam commented 2025-12-29 16:25:24 +01:00
Author
Owner
Copy Link

@vibe-x commented on GitHub (Apr 13, 2017):

@jeremystretch
With VLANGroups you can just assign a group to a site, or global. Let's have a look at the possibilities:
Some configured information:

VLAN 1 (ungrouped) has a prefix (1.2.3.4/24)
VLAN 1 (ungrouped) has a prefix (5.6.7.8/24)

Regions:
A is in Berlin
B is in Frankfurt
No we have 2 completely different sites (alpha, beta) in each region, because of failover.
So we have 4 sites (A.alpha, A.beta | B.alpha, B.beta) total. Both sites (alpha,beta) shares the same VLAN.
I cannot configure the VLAN globally inside a region, so I would need to go one of the following 2 ways:

  1. configure the VLAN 1 (Uplink) globally and name it uplink1, uplink2, which do not pass, because the VLAN1 of Berlin is not configurable in Frankfurt and the other way around either (because of prefix). So we have to bind it to site (see 2nd way).

  2. Build a VLAN Group and assign it to a site (your suggestion), but wait, now the VLAN1 is either A.alpha or A.beta. We would need to configure VLANs multiple times, which makes it much complicated.

So i thought about using site as global instance, but later, if you need to split alpha, beta, you could use rack groups, but theese cannot be used to assign vlans either. You will have no filters available to get a satisfying result.

I hope you can understand, why it would be very nice to assign VLANs, or at least VLANGroups per region, to configure failover scenarios for example.
If you need any more information, please tell me.

@vibe-x commented on GitHub (Apr 13, 2017): @jeremystretch With VLANGroups you can just assign a group to a site, or global. Let's have a look at the possibilities: Some configured information: VLAN 1 (ungrouped) has a prefix (1.2.3.4/24) VLAN 1 (ungrouped) has a prefix (5.6.7.8/24) Regions: A is in Berlin B is in Frankfurt No we have 2 completely different sites (alpha, beta) in each region, because of failover. So we have 4 sites (A.alpha, A.beta | B.alpha, B.beta) total. Both sites (alpha,beta) shares the same VLAN. I cannot configure the VLAN globally inside a region, so I would need to go one of the following 2 ways: 1. configure the VLAN 1 (Uplink) globally and name it uplink1, uplink2, which do not pass, because the VLAN1 of Berlin is not configurable in Frankfurt and the other way around either (because of prefix). So we have to bind it to site (see 2nd way). 2. Build a VLAN Group and assign it to a site (your suggestion), but wait, now the VLAN1 is either A.alpha or A.beta. We would need to configure VLANs multiple times, which makes it much complicated. So i thought about using site as global instance, but later, if you need to split alpha, beta, you could use rack groups, but theese cannot be used to assign vlans either. You will have no filters available to get a satisfying result. I hope you can understand, why it would be very nice to assign VLANs, or at least VLANGroups per region, to configure failover scenarios for example. If you need any more information, please tell me.
adam commented 2025-12-29 16:25:25 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 13, 2017):

@vibe-x Create a global VLANGroup named "Region A" and assign the desired VLANs to it. Create another one for "Region B." Problem solved. There's no need to strictly couple the groups to Region objects.

@jeremystretch commented on GitHub (Apr 13, 2017): @vibe-x Create a global VLANGroup named "Region A" and assign the desired VLANs to it. Create another one for "Region B." Problem solved. There's no need to strictly couple the groups to Region objects.
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
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#745
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?