You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
based on the discussion here
Terminology Clarification
Summary
So basically Instead of (forgive the crude ERD syntax):
I would be looking for:
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.
The text was updated successfully, but these errors were encountered: