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

Support for Multiple L2 Domains #109

New Issue
Closed
opened 2025-12-29 15:33:25 +01:00 by adam · 3 comments
adam commented 2025-12-29 15:33:25 +01:00
Owner
Copy Link

Originally created by @peelman on GitHub (Jun 30, 2016).

based on the discussion here

Terminology Clarification

To head off any terminology issues; by Layer 2 Domain I am referring to OSI Layer 2, which can be segmented by VLANs into multiple broadcast domains. in the same way multiple layer 3 subnets can reside in the same VLAN, multiple VLANs can reside in the same layer 2 domain. If you manage multiple distinct networks, VLAN 200 on one network can be different from VLAN 200 on another network, which may exist at the same site. Given this, and the propensity of Layer 2 networks to stretch between sites via point to point circuits, the current simple model of Sites having many VLANs breaks down.

Summary

So basically Instead of (forgive the crude ERD syntax):

[Site] -|----|< [VLAN]

I would be looking for:

[Site] >|----|- [L2 Domain] -|----|< [VLAN]

Given that change, if you have a Point to Point circuit connecting layer 2 domains across sites you can define the VLANs that ride along it and have them be continuous between the sites (letting the documentation (netbox) better reflect reality. (Extension Goal, assigning VLANs to Circuits?)

I don't take the complexity this introduces lightly; but it only takes one VLAN ID being used twice or one VLAN that traverses sites to break the current setup.

Our case

In our use-case as a colocation facility, we have a customer network, which is air-gapped (firewalled) from our infrastructure network. Basically, we act as an ISP to ourselves and others. Those are two independently managed Layer-2 domains, and this says nothing of the occasional need we have to document customer layer-2 domains and networks.

Right now we don't have any VLAN duplication across our internal and external networks, but that doesn't mean that rule will hold forever. in phpIPAM i can define multiple L2 domains and the VLANs they contain, and assign subnets to them as need be. Then in the Subnet view i get a nice indicator of not only the VLAN that it is assigned to, but also the L2 domain that VLAN exists in, so I know which of our networks that subnet exists on.

A configuration as simple as this ours could probably be done with Sites (it appears that VLANs have to be unique inside a Site), but you can have a Layer 2 domain that crosses sites (as many of us do), so that would 'break' the documentation.

Originally created by @peelman on GitHub (Jun 30, 2016). [based on the discussion here](https://www.reddit.com/r/networking/comments/4k89ty/i_built_an_ipamdcim_thing/d3d6vmu) ##### Terminology Clarification > To head off any terminology issues; by Layer 2 Domain I am referring to OSI Layer 2, which can be segmented by VLANs into multiple broadcast domains. in the same way multiple layer 3 subnets can reside in the same VLAN, multiple VLANs can reside in the same layer 2 domain. If you manage multiple distinct networks, VLAN 200 on one network can be different from VLAN 200 on another network, which may exist at the same site. Given this, and the propensity of Layer 2 networks to stretch between sites via point to point circuits, the current simple model of Sites having many VLANs breaks down. #### Summary So basically Instead of (forgive the crude ERD syntax): ``` [Site] -|----|< [VLAN] ``` I would be looking for: ``` [Site] >|----|- [L2 Domain] -|----|< [VLAN] ``` Given that change, if you have a Point to Point circuit connecting layer 2 domains across sites you can define the VLANs that ride along it and have them be continuous between the sites (letting the documentation (netbox) better reflect reality. (Extension Goal, assigning VLANs to Circuits?) I don't take the complexity this introduces lightly; but it only takes one VLAN ID being used twice or one VLAN that traverses sites to break the current setup. #### Our case In our use-case as a colocation facility, we have a customer network, which is air-gapped (firewalled) from our infrastructure network. Basically, we act as an ISP to ourselves and others. Those are two independently managed Layer-2 domains, and this says nothing of the occasional need we have to document customer layer-2 domains and networks. Right now we don't have any VLAN duplication across our internal and external networks, but that doesn't mean that rule will hold forever. in phpIPAM i can define multiple L2 domains and the VLANs they contain, and assign subnets to them as need be. Then in the Subnet view i get a nice indicator of not only the VLAN that it is assigned to, but also the L2 domain that VLAN exists in, so I know which of our networks that subnet exists on. A configuration as simple as this ours could probably be done with Sites (it appears that VLANs have to be unique inside a Site), but you can have a Layer 2 domain that crosses sites (as many of us do), so that would 'break' the documentation.
adam added the status: duplicate label 2025-12-29 15:33:25 +01:00
adam closed this issue 2025-12-29 15:33:25 +01:00
adam commented 2025-12-29 15:33:30 +01:00
Author
Owner
Copy Link

@mdlayher commented on GitHub (Jun 30, 2016):

Looks to me like this may be a duplicate of https://github.com/digitalocean/netbox/issues/111.

@mdlayher commented on GitHub (Jun 30, 2016): Looks to me like this may be a duplicate of https://github.com/digitalocean/netbox/issues/111.
adam commented 2025-12-29 15:33:30 +01:00
Author
Owner
Copy Link

@peelman commented on GitHub (Jun 30, 2016):

Bloody hell. I even searched for it and didn't see it.

@peelman commented on GitHub (Jun 30, 2016): Bloody hell. I even searched for it and didn't see it.
adam commented 2025-12-29 15:33:31 +01:00
Author
Owner
Copy Link

@mdlayher commented on GitHub (Jun 30, 2016):

No worries! Closing as a duplicate. Thanks for the detailed request though.

@mdlayher commented on GitHub (Jun 30, 2016): No worries! Closing as a duplicate. Thanks for the detailed request though.
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: duplicate
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#109
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?