Assign VLAN to multiple L2VPNs #7494

@github-actions[bot] commented on GitHub (Apr 12, 2023):

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.

@github-actions[bot] commented on GitHub (Apr 12, 2023): 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](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented

@DanSheps commented on GitHub (Apr 13, 2023):

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

@DanSheps commented on GitHub (Apr 13, 2023): How is it stitched together between the fabrics (a config example would be helpful)

adam commented

@johannwagner commented on GitHub (Apr 13, 2023):

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.

@johannwagner commented on GitHub (Apr 13, 2023): I made a drawing for better understandability: ![Example (1)](https://user-images.githubusercontent.com/12380026/231818705-59d20015-f4c4-4be6-8ad4-c7e254ee0046.png) 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.

adam commented

2025-12-29 20:24:09 +01:00

@DanSheps commented on GitHub (Apr 14, 2023):

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.

@DanSheps commented on GitHub (Apr 14, 2023): 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.

adam commented

@johannwagner commented on GitHub (May 1, 2023):

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.

@johannwagner commented on GitHub (May 1, 2023): 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.

adam commented

2025-12-29 20:24:11 +01:00

@DanSheps commented on GitHub (May 2, 2023):

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.

@DanSheps commented on GitHub (May 2, 2023): 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.

adam commented

@jeremystretch commented on GitHub (Jun 14, 2023):

@DanSheps do you want to move forward with this?

@jeremystretch commented on GitHub (Jun 14, 2023): @DanSheps do you want to move forward with this?

adam commented

@DanSheps commented on GitHub (Jun 19, 2023):

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

@DanSheps commented on GitHub (Jun 19, 2023): I think yes, we should make this a little more robust in allowing additional assignment options.

adam commented

@DanSheps commented on GitHub (Jun 19, 2023):

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

@DanSheps commented on GitHub (Jun 19, 2023): I might have some time this coming week to work on this, but if someone else wants to volunteer feel free to speak up.

adam commented

@johannwagner commented on GitHub (Jun 19, 2023):

I would be happy to provide a PR for this!

@johannwagner commented on GitHub (Jun 19, 2023): I would be happy to provide a PR for this!

adam commented

@DanSheps commented on GitHub (Jun 19, 2023):

@johannwagner Assigned to you.

@DanSheps commented on GitHub (Jun 19, 2023): @johannwagner Assigned to you.

adam commented

@johannwagner commented on GitHub (Jun 27, 2023):

@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?

@johannwagner commented on GitHub (Jun 27, 2023): @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?

adam commented

@DanSheps commented on GitHub (Aug 28, 2023):

@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.

@DanSheps commented on GitHub (Aug 28, 2023): @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.

adam commented

@johannwagner commented on GitHub (Aug 28, 2023):

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!

@johannwagner commented on GitHub (Aug 28, 2023): 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!

adam commented

@DanSheps commented on GitHub (Aug 31, 2023):

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

@DanSheps commented on GitHub (Aug 31, 2023): @jeremystretch Are we good adding this to v4.0 milestone based on your comment on the PR?

adam commented

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

@DanSheps commented on GitHub (Nov 22, 2023):

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

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 commented on GitHub (Nov 22, 2023): I re-did the drawing to hopefully make everything more clear. [f2e86238-2d11-4459-bcd2-137f005415c8.pdf](https://github.com/netbox-community/netbox/files/13444704/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.

adam commented