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

Global VLAN #175

New Issue
Closed
opened 2025-12-29 16:18:52 +01:00 by adam · 15 comments
adam commented 2025-12-29 16:18:52 +01:00
Owner
Copy Link

Originally created by @x-zeroflux-x on GitHub (Jul 8, 2016).

HI Guys,

We use a VLAN for mgmt which spans multiple sites, rather than adding the same VLAN and making it site specific which we would do 99% of the time, can we have an option in site to be global which would automatically apply across all sites, so we only have to add it once?

Thanks
Shaun

Originally created by @x-zeroflux-x on GitHub (Jul 8, 2016). HI Guys, We use a VLAN for mgmt which spans multiple sites, rather than adding the same VLAN and making it site specific which we would do 99% of the time, can we have an option in site to be global which would automatically apply across all sites, so we only have to add it once? Thanks Shaun
adam closed this issue 2025-12-29 16:18:52 +01:00
adam commented 2025-12-29 16:18:53 +01:00
Author
Owner
Copy Link

@x-zeroflux-x commented on GitHub (Jul 8, 2016):

Furthermore to add to this this say i create VLAN 100 which is used across SITE A and SITE B with a prefix of 192.168.1.0/24. I cannot assign that same prefix across multiple sites, I have to create a prefix and VLAN per site.

Thoughts?

@x-zeroflux-x commented on GitHub (Jul 8, 2016): Furthermore to add to this this say i create VLAN 100 which is used across SITE A and SITE B with a prefix of 192.168.1.0/24. I cannot assign that same prefix across multiple sites, I have to create a prefix and VLAN per site. Thoughts?
adam commented 2025-12-29 16:18:53 +01:00
Author
Owner
Copy Link

@ryanmerolle commented on GitHub (Jul 8, 2016):

Linking to #111 given this should be considered with the new discrete VLAN discussion.

It's good to know how other tools tackle this, not that I agree, but here goes... Some other tools create VLANs when discovered via SNMP as individual records. They do not assume the VLAN, though having the same number/id, name, and description are all apart of the same L2 domain. As such these tools allow you to merge VLAN records after the fact as long as the numbers/ids match. That way you can associate VLANs on devices across a site or multiple sites.

@ryanmerolle commented on GitHub (Jul 8, 2016): Linking to #111 given this should be considered with the new discrete VLAN discussion. It's good to know how other tools tackle this, not that I agree, but here goes... Some other tools create VLANs when discovered via SNMP as individual records. They do not assume the VLAN, though having the same number/id, name, and description are all apart of the same L2 domain. As such these tools allow you to merge VLAN records after the fact as long as the numbers/ids match. That way you can associate VLANs on devices across a site or multiple sites.
adam commented 2025-12-29 16:18:53 +01:00
Author
Owner
Copy Link

@x-zeroflux-x commented on GitHub (Jul 8, 2016):

Yes that is correct - L2 Domains is how they define it too.

It would be nice to manage all this information without duplication of data from a user input side to achieve the same result.

@x-zeroflux-x commented on GitHub (Jul 8, 2016): Yes that is correct - L2 Domains is how they define it too. It would be nice to manage all this information without duplication of data from a user input side to achieve the same result.
adam commented 2025-12-29 16:18:54 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 8, 2016):

We should be able to make site assignment optional for VLANs. Will need to comb through the code and see presumed site assignment presents issues anywhere. I'm not sure how this would play with the concept of discrete L2 zones though.

Prefixes already need not be assigned to a particular site, so no changes should be needed there so long as you can define a global VLAN.

@jeremystretch commented on GitHub (Jul 8, 2016): We _should_ be able to make site assignment optional for VLANs. Will need to comb through the code and see presumed site assignment presents issues anywhere. I'm not sure how this would play with the concept of discrete L2 zones though. Prefixes already need not be assigned to a particular site, so no changes should be needed there so long as you can define a global VLAN.
adam commented 2025-12-29 16:18:54 +01:00
Author
Owner
Copy Link

@rdujardin commented on GitHub (Jul 12, 2016):

It would be nice if site assignment was optional, to take into account VLANs accross several sites.

@rdujardin commented on GitHub (Jul 12, 2016): It would be nice if site assignment was optional, to take into account VLANs accross several sites.
adam commented 2025-12-29 16:18:54 +01:00
Author
Owner
Copy Link

@cstueckrath commented on GitHub (Jul 20, 2016):

another way around this might be parent and child sites, so all site spanning vlans could go to the parent (and thus be available in all child sites as well) and the individual vlans could stick to the sub site, not visible to other sub sites.

@cstueckrath commented on GitHub (Jul 20, 2016): another way around this might be parent and child sites, so all site spanning vlans could go to the parent (and thus be available in all child sites as well) and the individual vlans could stick to the sub site, not visible to other sub sites.
adam commented 2025-12-29 16:18:55 +01:00
Author
Owner
Copy Link

@anthraxau commented on GitHub (Aug 2, 2016):

I would love this feature aswell as we run L2 across two sites.

Cheers

@anthraxau commented on GitHub (Aug 2, 2016): I would love this feature aswell as we run L2 across two sites. Cheers
adam commented 2025-12-29 16:18:55 +01:00
Author
Owner
Copy Link

@Censored3 commented on GitHub (Oct 27, 2016):

I'm actually awaiting this feature to start implementing NetBox; it's a showstopper.

I need stretched VLANs spanned across X sites - mind you, NOT global VLANs that are spanned across all sites - that way I would have trouble using duplicate VLANs on other sites that are actually in different L2 domains.
Please implement this one - I don't think it's all that uncommon - so I can start using NetBox as it seems to be the perfect AIO solution!

@Censored3 commented on GitHub (Oct 27, 2016): I'm actually awaiting this feature to start implementing NetBox; it's a showstopper. I need stretched VLANs spanned across X sites - mind you, NOT global VLANs that are spanned across all sites - that way I would have trouble using duplicate VLANs on other sites that are actually in different L2 domains. Please implement this one - I don't think it's all that uncommon - so I can start using NetBox as it seems to be the perfect AIO solution!
adam commented 2025-12-29 16:18:55 +01:00
Author
Owner
Copy Link

@peng-shawn commented on GitHub (Jan 14, 2017):

Created pull request for this issue. Please try it out if you want. I'm open for any suggestion.

Thanks

@peng-shawn commented on GitHub (Jan 14, 2017): Created pull request for this issue. Please try it out if you want. I'm open for any suggestion. Thanks
adam commented 2025-12-29 16:18:55 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Jan 16, 2017):

Another use case (or different feature?) is linking the same prefix to multiple site VLANs.

I have a layer 2 site-to-site link from a provider. I have assigned a prefix for the link. I would like to associate (site 1 vlan 123) and (site 2 vlan 123) with the same prefix. Potentially this same VLAN might be extended to a third site in future.

Right now I appear to have a few options:

  1. Don't associate the prefix with any site. This leaves site 1 vlan 123 and site 2 vlan 123 both not linked to any prefix.

  2. Associate the prefix with one site only. The other end is a VLAN with no prefix.

  3. Create the same prefix on both vlans. This results in a duplicate prefix in the database which is flagged up in red.

@candlerb commented on GitHub (Jan 16, 2017): Another use case (or different feature?) is linking the same prefix to multiple site VLANs. I have a layer 2 site-to-site link from a provider. I have assigned a prefix for the link. I would like to associate (site 1 vlan 123) and (site 2 vlan 123) with the same prefix. Potentially this same VLAN might be extended to a third site in future. Right now I appear to have a few options: 1. Don't associate the prefix with any site. This leaves site 1 vlan 123 and site 2 vlan 123 both not linked to any prefix. 2. Associate the prefix with one site only. The other end is a VLAN with no prefix. 3. Create the same prefix on both vlans. This results in a duplicate prefix in the database which is flagged up in red.
adam commented 2025-12-29 16:18:56 +01:00
Author
Owner
Copy Link

@Censored3 commented on GitHub (Mar 4, 2017):

Thx a lot for implementing! Comes a long way!
However I'd really like to be able to really assign a VLAN to multiple sites instead of just having globally... I don't think anyone ever really has a global VLAN? Any possibility for that?

@Censored3 commented on GitHub (Mar 4, 2017): Thx a lot for implementing! Comes a long way! However I'd really like to be able to really assign a VLAN to multiple sites instead of just having globally... I don't think anyone ever really has a global VLAN? Any possibility for that?
adam commented 2025-12-29 16:18:56 +01:00
Author
Owner
Copy Link

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

This issue of vlan assignment seems to come up at lot, in several different forms. I think the solution is to extent regions so that vlans (and perhaps other objects) can be assigned there.

@lampwins commented on GitHub (Mar 13, 2017): This issue of vlan assignment seems to come up at lot, in several different forms. I think the solution is to extent regions so that vlans (and perhaps other objects) can be assigned there.
adam commented 2025-12-29 16:18:56 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Mar 13, 2017):

That's not as flexible as being able to associate a VLAN with multiple arbitrary sites though.

If VLAN A is trunked to sites X and Y and Z, but VLAN B is only in sites X and Y, then that's what the model should show.

@candlerb commented on GitHub (Mar 13, 2017): That's not as flexible as being able to associate a VLAN with multiple arbitrary sites though. If VLAN A is trunked to sites X and Y and Z, but VLAN B is only in sites X and Y, then that's what the model should show.
adam commented 2025-12-29 16:18:56 +01:00
Author
Owner
Copy Link

@hawko2600 commented on GitHub (Oct 13, 2017):

ping @jeremystretch

This issue was closed in Feb then added to the 1.9 milestone in Mar (after closure) so I fear it may have become lost.

There's still no capability to correctly represent an arbitrary stretched layer 2 vlan as described by @candlerb above. The virtualisation capability could also do with the ability to comprehend that the cluster or VM exists in multiple sites when it lives on a stretched layer 2 vlan.

Other mentions of the problem are also in closed tickets, see e.g.:
https://github.com/digitalocean/netbox/issues/852#issuecomment-283056912

@hawko2600 commented on GitHub (Oct 13, 2017): ping @jeremystretch This issue was closed in Feb then added to the 1.9 milestone in Mar (after closure) so I fear it may have become lost. There's still no capability to correctly represent an arbitrary stretched layer 2 vlan as described by @candlerb above. The virtualisation capability could also do with the ability to comprehend that the cluster or VM exists in multiple sites when it lives on a stretched layer 2 vlan. Other mentions of the problem are also in closed tickets, see e.g.: https://github.com/digitalocean/netbox/issues/852#issuecomment-283056912
adam commented 2025-12-29 16:18:56 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Oct 13, 2017):

VLANs can now be made global - not assigned to any site - which is why the ticket was closed.

Being able to associate a VLAN with a list of sites should probably be a new feature request. For now, you can make a global VLAN and put in the description a list of sites it spans.

A similar case arises if you re-use the same VLAN tag within a site: you just create two VLANs with the same tag, and there's no explicit modelling of which devices or racks each VLAN spans (although there is the implicit L2/L3 relationship from device - interface - VRF/IP address - prefix - VLAN)

@candlerb commented on GitHub (Oct 13, 2017): VLANs can now be made global - not assigned to any site - which is why the ticket was closed. Being able to associate a VLAN with a list of sites should probably be a new feature request. For now, you can make a global VLAN and put in the description a list of sites it spans. A similar case arises if you re-use the same VLAN tag within a site: you just create two VLANs with the same tag, and there's no explicit modelling of which devices or racks each VLAN spans (although there is the implicit L2/L3 relationship from device - interface - VRF/IP address - prefix - VLAN)
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#175
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?