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

Make multiple L2VPNs terminatable on one interface #11702

New Issue
Open
opened 2025-12-29 21:48:47 +01:00 by adam · 5 comments
adam commented 2025-12-29 21:48:47 +01:00
Owner
Copy Link

Originally created by @PaulR282 on GitHub (Oct 7, 2025).

NetBox version

v4.4.1

Feature type

Data model extension

Proposed functionality

It would be helpful if you can terminate multiple e.g. VXLAN tunnels on one interface.

Use case

Typically, you terminate VXLAN tunnels on LoopBack interfaces. You can of course do multiple tunnels per interface but this is not possible in netbox (Error: L2VPN Termination already assigned).

Database changes

No response

External dependencies

No response

Originally created by @PaulR282 on GitHub (Oct 7, 2025). ### NetBox version v4.4.1 ### Feature type Data model extension ### Proposed functionality It would be helpful if you can terminate multiple e.g. VXLAN tunnels on one interface. ### Use case Typically, you terminate VXLAN tunnels on LoopBack interfaces. You can of course do multiple tunnels per interface but this is not possible in netbox (Error: `L2VPN Termination already assigned`). ### Database changes _No response_ ### External dependencies _No response_
adam added the type: featurestatus: under reviewnetbox labels 2025-12-29 21:48:47 +01:00
adam commented 2025-12-29 21:48:48 +01:00
Author
Owner
Copy Link

@julianstolp commented on GitHub (Oct 9, 2025):

I need the ability to connect multiple l2vpns to a single vlan so a general approach allowing multiple l2vpns to a single vlan or interface would be nice.

@julianstolp commented on GitHub (Oct 9, 2025): I need the ability to connect multiple l2vpns to a single vlan so a general approach allowing multiple l2vpns to a single vlan or interface would be nice.
adam commented 2025-12-29 21:48:49 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 9, 2025):

I don't have any objection to this, but are there any existing use cases that rely on the one-to-one mapping constraint? We want to avoid breaking those, if so.

@jeremystretch commented on GitHub (Oct 9, 2025): I don't have any objection to this, but are there any existing use cases that _rely_ on the one-to-one mapping constraint? We want to avoid breaking those, if so.
adam commented 2025-12-29 21:48:49 +01:00
Author
Owner
Copy Link

@PaulR282 commented on GitHub (Oct 28, 2025):

@jeremystretch I don't think there are any use cases that rely on that. The L2VPN itself will be furthermore a one-to-one mapping. Just the Interface/VLAN <-> L2VPN Termination will be one-to-many.

@PaulR282 commented on GitHub (Oct 28, 2025): @jeremystretch I don't think there are any use cases that rely on that. The L2VPN itself will be furthermore a one-to-one mapping. Just the Interface/VLAN <-> L2VPN Termination will be one-to-many.
adam commented 2025-12-29 21:48:50 +01:00
Author
Owner
Copy Link

@jnovinger commented on GitHub (Nov 3, 2025):

@DanSheps, as the original implementer of L2VPN functionality, can you weigh in on whether relaxing the one-to-one constraint between L2VPN terminations and interfaces would break any existing use cases?

The request is to allow multiple VXLAN (or other L2VPN) tunnels to terminate on a single interface.

@jnovinger commented on GitHub (Nov 3, 2025): @DanSheps, as the original implementer of L2VPN functionality, can you weigh in on whether relaxing the one-to-one constraint between L2VPN terminations and interfaces would break any existing use cases? The request is to allow multiple VXLAN (or other L2VPN) tunnels to terminate on a single interface.
adam commented 2025-12-29 21:48:50 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Nov 3, 2025):

you terminate VXLAN tunnels on LoopBack interfaces

You are talking about the NVE, what the L2VPN model is trying to model is the "VNI"

While yes you do have the Tunnel NVE terminating to a Loopback, the actual VXLAN instance, which is what is meant to be modelled here, is not terminating to a single Loopback for multiple VXLANs.

For terminating to a VLAN on a specific device (which I suspect is what you are trying to do here), you should be choosing the "VLAN" option. I think your request here largely overlaps with: #14451 as that is how it should be handled ultimately.

For @julianstolp's request, I think it would be served by #11466 which is blocked by #14451 as well, however in the alternative, it would need to be handled by modelling L2 subinterfaces, which is the correct way to map multiple VXLANs on a single device to a single vlan (but I am not 100% sure on this as I don't of any realistic use-case in the real world to do this)

I don't think there is a need for this FR as they seem to be deviating from the intention of the model.

I could see adding a "Souce Interface" for each Termination that would serve as defining your NVE interface and that could maybe make sense for most cases, even not VXLAN use-cases. This might make #11466 redundant as you could then relax the restrictions on the assigned_object to allow duplication as long as the source interface and assigned_object (be it a Interface, VMInterface or VLAN) are unique.

The L2VPN itself will be furthermore a one-to-one mapping. Just the Interface/VLAN

This is not accurate, within the L2VPN whether 1:2 or 1:M is allowed is dependant on the type of the L2VPN being modelled. VXLAN allows 1:M already.

@DanSheps commented on GitHub (Nov 3, 2025): > you terminate VXLAN tunnels on LoopBack interfaces You are talking about the NVE, what the L2VPN model is trying to model is the "VNI" While yes you do have the Tunnel NVE terminating to a Loopback, the actual VXLAN instance, which is what is meant to be modelled here, is not terminating to a single Loopback for multiple VXLANs. For terminating to a VLAN on a specific device (which I suspect is what you are trying to do here), you should be choosing the "VLAN" option. I think your request here largely overlaps with: #14451 as that is how it should be handled ultimately. For @julianstolp's request, I think it would be served by #11466 which is blocked by #14451 as well, however in the alternative, it would need to be handled by modelling L2 subinterfaces, which is the correct way to map multiple VXLANs on a single device to a single vlan (but I am not 100% sure on this as I don't of any realistic use-case in the real world to do this) I don't think there is a need for this FR as they seem to be deviating from the intention of the model. I could see adding a "Souce Interface" for each Termination that would serve as defining your NVE interface and that could maybe make sense for most cases, even not VXLAN use-cases. This might make #11466 redundant as you could then relax the restrictions on the `assigned_object` to allow duplication as long as the `source interface` and `assigned_object` (be it a Interface, VMInterface or VLAN) are unique. > The L2VPN itself will be furthermore a one-to-one mapping. Just the Interface/VLAN This is not accurate, within the L2VPN whether 1:2 or 1:M is allowed is dependant on the type of the L2VPN being modelled. VXLAN allows 1:M already.
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 netbox status: under review type: feature
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#11702
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?