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

Introduce additional L2VPN types #11780

New Issue
Closed
opened 2025-12-29 21:49:46 +01:00 by adam · 7 comments
adam commented 2025-12-29 21:49:46 +01:00
Owner
Copy Link

Originally created by @Niklasr69 on GitHub (Oct 27, 2025).

NetBox version

v4.4.3

Feature type

Change to existing functionality

Proposed functionality

Summary:
Add two new L2VPN type values to represent BGP-signaled L2VPN tunnels: BGP-L2VPN-CCC and BGP-L2VPN-VLAN.
Proposed names:
BGP-L2VPN-CCC, BGP-L2VPN-VLAN (short, uppercase, consistent with existing type naming conventions).

Use case

Motivation:
BGP-signaled L2VPNs are created via control plane mechanisms and have different lifecycle/automation characteristics than manually created L2VPNs. Adding explicit types improves filtering, automation, documentation, and allows type-specific validation.

Database changes

To support the new L2VPN types "BGP-L2VPN-CCC" and "BGP-L2VPN-VLAN", the database schema requires an update to the existing L2VPN type field. Specifically, the enum choices for the L2VPN type field need to be extended to include these new values. This involves creating a database migration that modifies the allowed values in the relevant column without altering the existing data.

External dependencies

No response

Originally created by @Niklasr69 on GitHub (Oct 27, 2025). ### NetBox version v4.4.3 ### Feature type Change to existing functionality ### Proposed functionality **Summary:** Add two new L2VPN type values to represent BGP-signaled L2VPN tunnels: BGP-L2VPN-CCC and BGP-L2VPN-VLAN. **Proposed names:** BGP-L2VPN-CCC, BGP-L2VPN-VLAN (short, uppercase, consistent with existing type naming conventions). ### Use case **Motivation:** BGP-signaled L2VPNs are created via control plane mechanisms and have different lifecycle/automation characteristics than manually created L2VPNs. Adding explicit types improves filtering, automation, documentation, and allows type-specific validation. ### Database changes To support the new L2VPN types "BGP-L2VPN-CCC" and "BGP-L2VPN-VLAN", the database schema requires an update to the existing L2VPN type field. Specifically, the enum choices for the L2VPN type field need to be extended to include these new values. This involves creating a database migration that modifies the allowed values in the relevant column without altering the existing data. ### External dependencies _No response_
adam added the type: featurenetbox labels 2025-12-29 21:49:46 +01:00
adam closed this issue 2025-12-29 21:49:46 +01:00
adam commented 2025-12-29 21:49:47 +01:00
Author
Owner
Copy Link

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

My gut feeling is that these are not appropriate L2VPN choices for NetBox. NetBox's L2VPN types represent service types (VPLS, VPWS, VXLAN-EVPN), not combinations of auto-discovery/signaling mechanisms and encapsulation types.

"CCC" appears to be Juniper-specific legacy technology (not an RFC standard), and "VLAN" refers to an encapsulation type (RFC 4448), not a service type. BGP auto-discovery and signaling already works with existing types like VPLS (RFC 4761) and VPWS (RFC 6624). If you need to document that a specific L2VPN uses BGP signaling with VLAN-tagged encapsulation, custom fields could be appropriate rather than creating new type values.

My feeling is that L2VPN types should distinguish service types, not implementation details. Having said that, I'm far from an expert in L2VPN technology and welcome input from others.

@jnovinger commented on GitHub (Oct 28, 2025): My gut feeling is that these are not appropriate L2VPN choices for NetBox. NetBox's L2VPN types represent service types (VPLS, VPWS, VXLAN-EVPN), not combinations of auto-discovery/signaling mechanisms and encapsulation types. "CCC" appears to be Juniper-specific legacy technology (not an RFC standard), and "VLAN" refers to an encapsulation type (RFC 4448), not a service type. BGP auto-discovery and signaling already works with existing types like VPLS (RFC 4761) and VPWS (RFC 6624). If you need to document that a specific L2VPN uses BGP signaling with VLAN-tagged encapsulation, custom fields could be appropriate rather than creating new type values. My feeling is that L2VPN types should distinguish service types, not implementation details. Having said that, I'm far from an expert in L2VPN technology and welcome input from others.
adam commented 2025-12-29 21:49:47 +01:00
Author
Owner
Copy Link

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

You may find Custom Objects useful here. See the VXLAN example in this blog post where the user introduces a vendor specific field (eos_l3_mtu). Not an exact match for what you're trying to do, but something to explore.

@mrmrcoleman commented on GitHub (Oct 28, 2025): You may find Custom Objects useful here. See the VXLAN example in [this blog post](https://netboxlabs.com/blog/netbox-custom-objects-examples-netbox-data-model-no-code-extension/) where the user introduces a vendor specific field (`eos_l3_mtu`). Not an exact match for what you're trying to do, but something to explore.
adam commented 2025-12-29 21:49:48 +01:00
Author
Owner
Copy Link

@mr1716 commented on GitHub (Oct 29, 2025):

What’s preventing users from adding this manually?

@mr1716 commented on GitHub (Oct 29, 2025): What’s preventing users from adding this manually?
adam commented 2025-12-29 21:49:48 +01:00
Author
Owner
Copy Link

@jnovinger commented on GitHub (Oct 30, 2025):

What’s preventing users from adding this manually?

What is the "this" that you are referring to? The original FR or something Mark or I said?

@jnovinger commented on GitHub (Oct 30, 2025): > What’s preventing users from adding this manually? What is the "this" that you are referring to? The original FR or something Mark or I said?
adam commented 2025-12-29 21:49:48 +01:00
Author
Owner
Copy Link

@mr1716 commented on GitHub (Oct 30, 2025):

@jnovinger the original request

@mr1716 commented on GitHub (Oct 30, 2025): @jnovinger the original request
adam commented 2025-12-29 21:49:48 +01:00
Author
Owner
Copy Link

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

@Niklasr69 , why don't the existing L2VPN service types cover your use case?

NetBox's current L2VPN types (VPLS, VPWS, EVPN-VPWS, etc.) already exist and seemingly cover the type of L2VPNs you're talking about. These service types can be deployed with various signaling mechanisms and encapsulation types.

For documenting implementation details like signaling method or encapsulation type, custom fields would be appropriate rather than creating new type values. This preserves the principle that L2VPN types distinguish the service being provided, not how it's implemented.

@jnovinger commented on GitHub (Nov 3, 2025): @Niklasr69 , why don't the existing L2VPN service types cover your use case? NetBox's current L2VPN types (VPLS, VPWS, EVPN-VPWS, etc.) already exist and seemingly cover the type of L2VPNs you're talking about. These service types can be deployed with various signaling mechanisms and encapsulation types. For documenting implementation details like signaling method or encapsulation type, custom fields would be appropriate rather than creating new type values. This preserves the principle that L2VPN types distinguish the service being provided, not how it's implemented.
adam commented 2025-12-29 21:49:49 +01:00
Author
Owner
Copy Link

@Niklasr69 commented on GitHub (Nov 8, 2025):

Thank you for the detailed response and clarification on the existing L2VPN types.

I understand the project's reasoning for not expanding the type choices at this time and I've found a way to effectively use the existing types to categorize the BGP-signaled L2VPNs for my automation workflow.

Closing this issue as resolved. Thanks again for your time!

@Niklasr69 commented on GitHub (Nov 8, 2025): Thank you for the detailed response and clarification on the existing L2VPN types. I understand the project's reasoning for not expanding the type choices at this time and I've found a way to effectively use the existing types to categorize the BGP-signaled L2VPNs for my automation workflow. Closing this issue as resolved. Thanks again for your time!
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 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#11780
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?