Assign VLAN to multiple L2VPNs

[johannwagner]

NetBox version

v3.3

Feature type

Change to existing functionality

Proposed functionality

We document VLANs transferred through a fabric with L2VPNs, e.g. adding the VLAN to the fabric-specific L2VPN.

Currently we are not able to add the VLAN to two different L2VPN instances, which means that we cannot document a VLAN that is transferred through two different fabrics.

Therefore, we propose to remove the requirement, that an object can only be attached to one L2VPN, at least for VLANs. I see that this limit is useful for interfaces.

Use case

We have two different fabrics, a "Core Fabric" in our data center and a "WAN Fabric" for our wide area network. We provide services to our customers tunneling the same VLAN from a port in the data center to a port in a WAN pop. So this VLAN needs to be transferred through the "Core Fabric" and the "WAN Fabric".

Database changes

None

External dependencies

None

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

[DanSheps]

How is it stitched together between the fabrics (a config example would be helpful)

[johannwagner]

I made a drawing for better understandability:

We need to connect Device 1 and Device 2 and choose to do it with VLAN 100. Therefore, we attach VLAN 100 to both Device interfaces and all the leaf switch interfaces, e.g. WAN-1, WAN-2, CORE-1 and CORE-2. WAN-2 and CORE-1 are connected via a fiber connection which is used as Tagged link between both worlds. Each VLAN which needs to travel between both fabrics needs to be configured there. Now, we would attach VLAN 100 to each farbic, i.e. WAN Fabric and Core Farbic, it participates in. We model those fabrics as L2VPNs. WAN Fabric is an L2VPN object and Core Farbic is another L2VPN object. All VLANS that participate in the fabrics are attached to the corresponding L2VPN as L2VPN termination with the type VLAN.

BUT we can currently only attach VLAN 100 to one L2VPN but we would need to attach it to both L2VPNs.

[DanSheps]

Maybe within the vlan assignment, we should add an optional "device" assignment. You then have the following options:

Interface <> L2VPN VLAN <> L2VPN VLAN + Device <> L2VPN

Could then maintain the existing uniqueness based on VLAN but ultimately each VLAN L2VPN assignment will be associated with a specific device.

[johannwagner]

I needed multiple reads to understand this proposal, but here we are. So, this means, that we could assign VLANs to two different L2VPNs, if they are "terminated" on two different Devices?

Some examples that would work together:

Device + VLAN -> L2VPN WAN-1 + VLAN 100 -> WAN WAN-2 + VLAN 100 -> WAN CORE-1 + VLAN 100 -> CORE CORE-2 + WLAN 100 -> CORE

Some examples, that wouldn't work together:

Device + VLAN -> L2VPN CORE-1 + VLAN 100 -> CORE CORE-1 + VLAN 100 -> WAN

If I understood this correctly, this would solve our issue and would be a great solution.

[DanSheps]

That is what I was thinking, yes.

And you are correct, in that the bottom scenario would not work. I don't know if it is even possible to make that work. I haven't tried personally to be honest.

[jeremystretch]

@DanSheps do you want to move forward with this?

[DanSheps]

I think yes, we should make this a little more robust in allowing additional assignment options.

[DanSheps]

I might have some time this coming week to work on this, but if someone else wants to volunteer feel free to speak up.

[johannwagner]

I would be happy to provide a PR for this!

[DanSheps]

@johannwagner Assigned to you.

[johannwagner]

@DanSheps I thought about an idea of implementing this.

Currently, VLANs are assigned to interfaces, not devices. Also there is no "intermediate" model or anything which could be easily used in assigned_object (e.g. https://github.com/netbox-community/netbox/blob/develop/netbox/ipam/models/l2vpn.py#L91), therefore there is no straight forward thing to do.

How would you tackle the implementation? Creating an additional GenericForeignKey on L2VPNTermination, which is only filled in this specific case, seems odd to me?

[DanSheps]

@johannwagner Sorry for not getting back.

My thought was to add a device field on the L2VPNTermination model, which is basically the though model for a M2M relationship. If you are still interested in this, let me know, otherwise I can take this on as well.

[johannwagner]

Feel free to give this a go! I am not sure how to tackle this in a clean way. Probably an easy one for an experienced maintainer but a lot of headache otherwise!

[DanSheps]

@jeremystretch Are we good adding this to v4.0 milestone based on your comment on the PR?

[DanSheps]

I re-did the drawing to hopefully make everything more clear.

f2e86238-2d11-4459-bcd2-137f005415c8.pdf

The L2VPN terminates on the VLAN on each "headend" device. You could have two discrete VLAN's between the sites, but within the sites you would have two devices terminating on 1 vlan and another device on that same VLAN not terminating the L2VPN.

This is where the problem comes in when you are trying to build a config for example from the available information, without inferring which devices are headends for the L2VPN terminating simply to the VLAN cannot work.

[DanSheps]

Blocked by #14451