Is Netbox missing the concept of a Layer 2 Network?

[pv2b]

I'm looking at rolling out Netbox in our organization, but we've run into a pain point when it comes to correctly assigning address to networks. As far as I can tell, currently a prefix can be assigned to one single VLAN only.

I believe it's an incorrect assumption that a prefix only belongs to a single VLAN. A few common scenarios where this doesn't quite work:

• Direct point-to-point connections between two routers without an intervening switch. (Such as two routers connected together both with IPv4 and IPv6.)
• Private VLAN / PVLAN functionality, where different VLAN numbers are used to restrict hosts to talking to only specific subsets of hosts. This also includes the concept in Cisco ACI of multiple EPGs (endpoint groups) connected to a single Bridge Domain, where security is enforced on traffic between endpoint groups.
• Use cases where VLAN numbers are only locally significant, for example where VLAN translation is used, or in overlay networking scenarios such as Cisco ACI, where VLAN tags are used as an encapsulation for traffic bound to or from an EPG. Also applies to cases where two switches are connected with untagged VLANs, with different VLAN ID's on both sides (common for customer/provider connections).
• Cases where firewalls are installed at Layer 2, providing security for traffic passing between different VLANs, but all on the same set of IP/IPv6 subnets.

I'm sure there are other scenarios as well, but these are the ones I've thought of so far.

Instead, what I think is needed is a concept of a Network, which represents a set of hosts that can talk to each other directly without the use of intervening routers. There are a few other words that could be used for this concept, such as Network, Layer 2 Network, Bridge Domain, or Segment. I'm sure you can think of others too, but I think the word Network is simple and generic enough, that it could probably encompass other use cases I haven't even thought of. (Of course, the exact terminology isn't critical, any of my suggestions would be OK.)

In the current data model, a Prefix belongs to exactly one VLAN. Instead, I would suggest that a Prefix belongs to exactly one Network, which is terminated in one or more VLANs or Interfaces. This is similar to how L2VPN works right now, except currently, it's not possible to assign prefixes directly to L2VPNs (only to VLANs), and it's not possible to assign more than one L2VPN to one interface, without using subinterfaces. Also, L2VPN is far too specific to map into all these use cases.

So, as for a first stab as a possible design:

[PREFIX] N --- 1 [NETWORK] N ---- 1 [NETWORK TERMINATION] N --- N [ VLAN / Interface ]

One important thing is that multiple Network Terminations should be valid towards a single Interface, as long as 802.1q is used. (Or, in more clear English, a router could be connected to several networks, all with individually selectable VLAN tags.)

As for the use cases above, and how their implementation would be changed if a Network object was created:

• Direct point-to-point connections with IPv4 and IPv6 networks: This wouldn't really change much. Just as today, two IP addresses belonging to two different prefixes would be assigned to the two devices, however, it would be possible to map these two (otherwise unrelated in terms of Netbox) prefixes together into a single Network object.
• Private VLAN / PVLAN functionality: One or more Prefixes would be associated with said Network. That Network would then be terminated with multiple VLANs, representing the various PVLAN communities. (It would probably be possible to use a local customization to extend the VLAN object to represent a PVLAN, if needed)
• Locally significant VLAN numbering: Because the VLAN tag is set in the termination, this allows for cases such as VLAN translation, or locally significant VLAN encapculations for EPGs to be used.
• Cases where firewalls are installed at Layer 2: The Layer 3 address would be assigned to the virtual "bridge interface" of the firewall, and the Layer 2 network would be terminated at the physical "inside" and "outside" interfaces (or subinterfaces), as well as to any relevant switch VLANs.

It may be possible to fold in L2VPN and Provider Networks into this concept of a "Network" as well (perhaps as different Network Types?) thereby ending up with a simplified data model in the end?

I'm far from the first person to have run into issues due to the lack of the concept of a "Network" in Netbox, here are a few similar discussions I found that unfortunately didn't lead anywhere:

#7860
#9373
#7336
#9418

Of course there are other ways instead of implementing a Network object (although in my opinion, a Network object is the cleanest way to do this, and it supports multiple common use cases). For example, custom fields might be used to allow an IP Prefix to be assigned to multiple VLANs and/or to L2VPNs or provider networks, but hopefully this could be part of core instead?

Hope what I just wrote makes sense, it probably needs a bit of refinement before it can become a concrete proposal.

[pv2b]

One thing occurs to me after writing all this, perhaps what Netbox really needs is the ability to create custom object types? That way, if I need to represent some vendor-specific network concept that's doesn't cleanly map to any existing Netbox object type, I could just create one, and then use custom fields to tie those new objects together with existing stock Netbox object types.

[candlerb]

VLAN is the closest thing Netbox provides currently. For example, for a P2P link, you can create a VLAN, and assign it to both ends of the link as an Access port. It's a mild annoyance that you must assign a VLAN ID, but VID=1 is a pretty sensible choice as it usually implies "the native vlan". And you can have multiple ports, each with a separate VLAN with VID=1; it doesn't imply that these ports are bridged together.

However, for a P2P link, I generally wouldn't bother with assigning it like this. If it's a numbered link, then you have the implicit relationship of child IP address to parent prefix (without needing to associate the prefix with a VLAN). And if it's an unnumbered link, then there is no common "prefix" object to be linked to the VLAN anyway.

I agree your more complex use cases don't fit this well.

One thing occurs to me after writing all this, perhaps what Netbox really needs is the ability to create custom object types?

You need to use Plugins to do this. Adding full custom object types would turn Netbox into Salesforce :-{

[mtinberg]

Concur that if you want to try out a new complex data model that Plugins are the way to create custom objects, and if it's a good idea and spreads than either the people use the popular plugin, or the idea can be brought into mainline. One thing I did note in your description though is a focus on the model and not in what the output would be from a config templating perspective. The way I see it, modeling more closely to how network devices actually behave isn't by itself​ valuable, the value comes from modeling the differences needed to template or audit config data, so a more accurate representation that doesn't change the output, or makes the output tools more complex, isn't a win for me. The model should be an abstraction and a little bit simplified compared to reality, otherwise you are adding administrative complexity on top of the already existing operational complexity of the network device itself. So, I would write down what you expect the output to be and how you expect to use the data you propose to model to get an idea of how detailed the model needs to be to be useful. — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: Brian Candler ***@***.***> Sent: Sunday, May 21, 2023 12:49 PM To: netbox-community/netbox ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [netbox-community/netbox] Is Netbox missing the concept of a Layer 2 Network? (Discussion #12673) VLAN is the closest thing Netbox provides currently. For example, for a P2P link, you can create a VLAN, and assign it to both ends of the link as an Access port. It's a mild annoyance that you must assign a VLAN ID, but VID=1 is a pretty sensible choice as it usually implies "the native vlan". And you can have multiple ports, each with a separate VLAN with VID=1; it doesn't imply that these ports are bridged together. However, for a P2P link, I generally wouldn't bother with assigning it like this. If it's a numbered link, then you have the implicit relationship of child IP address to parent prefix (without needing to associate the prefix with a VLAN). And if it's an unnumbered link, then there is no common "prefix" object to be linked to the VLAN anyway. I agree your more complex use cases don't fit this well. One thing occurs to me after writing all this, perhaps what Netbox really needs is the ability to create custom object types? You need to use Plugins to do this. Adding full custom object types would turn Netbox into Salesforce :-{ — Reply to this email directly, view it on GitHub<#12673 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM6KD5MHLH2DGDIAQMLXHJIRBANCNFSM6AAAAAAYJMHDQM>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[pv2b]

Hi!

Yes, the focus is on the model, because I believe there are multiple useful use cases that could be enabled by that model, and think it's generic enough to be in the mainline Netbox. There's a ton of concepts that are far too specific to Cisco ACI that I would never expect them to go into Netbox mainline. And, in a sense, it's a little meaningless to talk about suggested configuration output without being able to express the structure in a way that enables us to use the desired functionality.

Anyway, as for a configuiration output specific to Cisco ACI, in order to represent a new network with Cisco ACI, the following needs to happen:

1. A tenant in Cisco ACI needs to be created.
2. At least one VRF needs to be added to the tenant.
3. A Bridge Domain needs to be created for each network.
4. An Application Profile needs to be created, which acts as a container for multiple Endpoint Groups.
5. One or more Endpoint Groups (EPG) need to be deployed, connected to these Bridge Domains. (N EPG <-> 1 BD)

(If you wanted, I could provide you with some XML of how these managed objects would look, exactly, but I doubt it'd make things any clearer, probably just less so.)

The Cisco ACI Tenant could probably have a 1:1 mapping with a Netbox Tenant, so I'm not too worried about that. I might need to extend a few fields here.

The Cisco ACI VRF could probably have a 1:1 mapping with a Netbox VRF, again not worried about this.

The Bridge Domain is where I'm seeing the proposed Network object type would be useful. It represents a single virtual layer-2 network. (This could also possibly be represented as an L2VPN.) Devices never connect directly to a Bridge Domain, only ever through an Endpoint Group.

The Application Profile essentially acts as a container for endpoint groups. I'm not too concerned about these, I could probably get away with just putting everything in a single container per tenant, or if I need multiple containers, I could just put the Application Profile's name on whatever. If I decide to use VLANs to represent EPGs, a VLAN Group could potentially represent an EPG.

Finally, the Endpoint Group represents a group of machines or devices. In that sense, it's like a Private VLAN, where it can talk directly at Layer 2 with other devices, but communication is restricted by security policy. In the case of Cisco ACI, that's done in Contracts. (I believe representing security policy in Netbox is out of scope right now, so let's not talk too much about that.) This could be fairly close to a VLANs aren't really the right choice, because the VLAN tag doesn't really belong to the EPG, it belongs to where the EPG ends up being terminated. (VLANs are only used as "labels" to identify a specific EPG and are not globally significant in ACI, although, as a matter of practice, I guess you could pretend they're not globally significant if you want them representable by Netbox.) Also, you still have the problem that multiple VLANs end up sharing the same (set of) prefixes.

Adding a Network object as I suggested neatly provides a close 1:1 mapping to a Bridge Domain in Cisco ACI land, while also enabling use cases such as PVLAN, or cases where Layer 2 networks are segmented by firewalls (you have multiple VLANs all on the same L3 network, with a bridging firewall protecting the traffic).

Finally, there's the whole question about how these EPGs end up being terminated on switch ports, but I think we'll leave that for another discussion. It's complicated. :-)

[mtinberg]

How many of those data points would be tracked and configured in Netbox and pushed to ACI, or pushed from Netbox to equipment directly, and how many should be managed by ACI, possibly being synched to Netbox for read-only display purposes only? I find that mocking up the output logic first helps when making choices in how to normalize the data model, so the data is in the right "shape" for how it's intended to be used. I have been resistant in my automation efforts in creating 1:1 mapping between vendor config management platforms and Netbox and instead recommend just using the vendor config management tools in their idiomatic way, unless we can demonstrate some simplified abstraction where Netbox provides value. I'm happy to have resources delegated from the IPAM to other tools that then self-manage them. In your case (I haven't used ACI) it sounds like VLAN numbers are auto-provisioned and configured by ACI so tracking them and their relationship to Prefixes in Netbox may not be important. Tracking that a Device exists and what system manages the config, tracking Prefix/VLAN allocations and association to Tenants to make them available to ACI, or and any place where ACI managed devices interface with non-ACI traditionally managed and templated configs, makes sense to me, then pointing to the other management system for further details on what data it owns. Are you looking to migrate from ACI into your own in-house config management and need to re-create the same Layer2 domains using another tool? Are there business/service rules you'd like to be able to enforce or audit outside of the way ACI is currently configured where Netbox could store an independent understanding of config intent? Is it the edge switch port to device relationship you want to manage and the first hop into ACI? To go back to the beginning, you probably want to create or commission a plugin with your proposed data model and see how well it works for you, it may work well for others too. — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: pv2b ***@***.***> Sent: Monday, May 22, 2023 10:55 AM To: netbox-community/netbox ***@***.***> Cc: Mark Tinberg ***@***.***>; Comment ***@***.***> Subject: Re: [netbox-community/netbox] Is Netbox missing the concept of a Layer 2 Network? (Discussion #12673) Hi! Yes, the focus is on the model, because I believe there are multiple useful use cases that could be enabled by that model, and think it's generic enough to be in the mainline Netbox. There's a ton of concepts that are far too specific to Cisco ACI that I would never expect them to go into Netbox mainline. And, in a sense, it's a little meaningless to talk about suggested configuration output without being able to express the structure in a way that enables us to use the desired functionality. Anyway, as for a configuiration output specific to Cisco ACI, in order to represent a new network with Cisco ACI, the following needs to happen: 1. A tenant in Cisco ACI needs to be created. 2. At least one VRF needs to be added to the tenant. 3. A Bridge Domain needs to be created for each network. 4. An Application Profile needs to be created, which acts as a container for multiple Endpoint Groups. 5. One or more Endpoint Groups (EPG) need to be deployed, connected to these networks. (If you wanted, I could provide you with some XML of how these managed objects would look, exactly, but I doubt it'd make things any clearer, probably just less so.) The Cisco ACI Tenant could probably have a 1:1 mapping with a Netbox Tenant, so I'm not too worried about that. I might need to extend a few fields here. The Cisco ACI VRF could probably have a 1:1 mapping with a Netbox VRF, again not worried about this. The Bridge Domain is where I'm seeing the proposed Network object type would be useful. It represents a single virtual layer-2 network. (This could also possibly be represented as an L2VPN.) Devices never connect directly to a Bridge Domain, only ever through an Endpoint Group. The Application Profile essentially acts as a container for endpoint groups. I'm not too concerned about these, I could probably get away with just putting everything in a single container per tenant, or if I need multiple containers, I could just put the Application Profile's name on whatever. If I decide to use VLANs to represent EPGs, a VLAN Group could potentially represent an EPG. Finally, the Endpoint Group represents a group of machines or devices. In that sense, it's like a Private VLAN, where it can talk directly at Layer 2 with other devices, but communication is restricted by security policy. In the case of Cisco ACI, that's done in Contracts. (I believe representing security policy in Netbox is out of scope right now, so let's not talk too much about that.) This could be fairly close to a VLANs aren't really the right choice, because the VLAN tag doesn't really belong to the EPG, it belongs to where the EPG ends up being terminated. (VLANs are only used as "labels" to identify a specific EPG and are not globally significant in ACI, although, as a matter of practice, I guess you could pretend they're not globally significant if you want them representable by Netbox.) Also, you still have the problem that multiple VLANs end up sharing the same (set of) prefixes. Adding a Network object as I suggested neatly provides a close 1:1 mapping to a Bridge Domain in Cisco ACI land, while also enabling use cases such as PVLAN, or cases where Layer 2 networks are segmented by firewalls (you have multiple VLANs all on the same L3 network, with a bridging firewall protecting the traffic). Finally, there's the whole question about how these EPGs end up being terminated on switch ports, but I think we'll leave that for another discussion. It's complicated. :-) — Reply to this email directly, view it on GitHub<#12673 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM3VNHWWSWYQXFIZVLTXHOD6TANCNFSM6AAAAAAYJMHDQM>. You are receiving this because you commented.Message ID: ***@***.***>