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

Allow Virtual Circuit Termination on All Interface Types and Support Multiple Virtual Circuit Terminations on a Single Interface #10962

New Issue
Closed
opened 2025-12-29 21:38:27 +01:00 by adam · 6 comments
adam commented 2025-12-29 21:38:27 +01:00
Owner
Copy Link

Originally created by @loubladi on GitHub (Mar 28, 2025).

NetBox version

v4.2.6

Feature type

Data model extension

Proposed functionality

Currently, NetBox restricts Virtual Circuit Terminations to Virtual Interfaces only. This proposal extends Virtual Circuit Termination to support all interface types, including physical interfaces.

This change would enhance NetBox’s ability to model various types of network connections across all layers, beyond traditional L2/L3 circuits. The Virtual Circuit model was a significant addition, enabling the mapping of physical infrastructure using Cables and Circuits while also representing higher-level logical connectivity through Virtual Circuits. However, it currently lacks the ability to seamlessly link these two perspectives—physical and logical—into a unified network view.

Key Enhancements:

  • Modify the CircuitTermination model to allow linking any type of interface, not just virtual interfaces.
  • Ensure an interface can have multiple Virtual Circuit terminations (multi-termination support).
  • Update the UI and API to support selecting physical and virtual interfaces for Virtual Circuit termination.

Use case

This feature would allow NetBox to model any type of connection between devices across all network layers, improving its flexibility in network topology representation.

Example Scenarios:

  1. Optical Transport Networks (OTN) – Model DWDM optical paths between transponders using Virtual Circuits.
  2. MPLS & SD-WAN – Represent logical overlays over physical infrastructure.
  3. Service Provider Networks – Represent L2VPN, L3VPN, and Pseudowire terminations directly on physical interfaces.

Database changes

  • Modify constraints on CircuitTermination to allow linking to any interface type.
  • Ensure multi-termination support for interfaces.
  • Add necessary migrations to handle existing Virtual Circuit terminations.

External dependencies

N/A

Originally created by @loubladi on GitHub (Mar 28, 2025). ### NetBox version v4.2.6 ### Feature type Data model extension ### Proposed functionality Currently, NetBox restricts Virtual Circuit Terminations to Virtual Interfaces only. This proposal extends Virtual Circuit Termination to support all interface types, including physical interfaces. This change would enhance NetBox’s ability to model various types of network connections across all layers, beyond traditional L2/L3 circuits. The Virtual Circuit model was a significant addition, enabling the mapping of physical infrastructure using Cables and Circuits while also representing higher-level logical connectivity through Virtual Circuits. However, it currently lacks the ability to seamlessly link these two perspectives—physical and logical—into a unified network view. Key Enhancements: - Modify the CircuitTermination model to allow linking any type of interface, not just virtual interfaces. - Ensure an interface can have multiple Virtual Circuit terminations (multi-termination support). - Update the UI and API to support selecting physical and virtual interfaces for Virtual Circuit termination. ### Use case This feature would allow NetBox to model any type of connection between devices across all network layers, improving its flexibility in network topology representation. Example Scenarios: 1. Optical Transport Networks (OTN) – Model DWDM optical paths between transponders using Virtual Circuits. 2. MPLS & SD-WAN – Represent logical overlays over physical infrastructure. 3. Service Provider Networks – Represent L2VPN, L3VPN, and Pseudowire terminations directly on physical interfaces. ### Database changes - Modify constraints on CircuitTermination to allow linking to any interface type. - Ensure multi-termination support for interfaces. - Add necessary migrations to handle existing Virtual Circuit terminations. ### External dependencies N/A
adam added the type: featurepending closurestatus: revisions needed labels 2025-12-29 21:38:27 +01:00
adam closed this issue 2025-12-29 21:38:28 +01:00
adam commented 2025-12-29 21:38:28 +01:00
Author
Owner
Copy Link

@bctiemann commented on GitHub (Apr 3, 2025):

In review the use cases you cite are not valid for virtual circuits; either they are actually physical hardware (with a logical component) or they are already covered by existing functionality (i.e. L2VPN). Do you have other use cases where this would be applicable? Otherwise this does not seem to be a particularly valuable addition.

@bctiemann commented on GitHub (Apr 3, 2025): In review the use cases you cite are not valid for virtual circuits; either they are actually physical hardware (with a logical component) or they are already covered by existing functionality (i.e. L2VPN). Do you have other use cases where this would be applicable? Otherwise this does not seem to be a particularly valuable addition.
adam commented 2025-12-29 21:38:28 +01:00
Author
Owner
Copy Link

@loubladi commented on GitHub (Apr 7, 2025):

My primary use case is Optical Transport Networks (OTN). We’re currently working on a synchronization mechanism between NetBox and our Cisco DWDM management system. Due to the current restrictions on Virtual Circuit Terminations, we’ve had to introduce an artificial workaround—duplicating interfaces into both physical and virtual types—just to satisfy the existing validation logic.

Image

We had been eagerly waiting for the Virtual Circuits functionality and were really excited when it was introduced. We believed it would finally allow us to model our DWDM network within NetBox while still retaining the ability to use Circuits for physical connectivity.

The L2VPN example was meant as an illustration. In practice, NetBox is a highly flexible framework, and each organization adapts the built-in objects to suit their specific operational model. This proposed change would embrace that flexibility: by allowing Virtual Circuits to terminate on any interface type and by supporting multiple terminations per interface, users would be empowered to define their own modeling strategies.

For example:
• One user might model DWDM networks with OCH/OTS channels.
• Another could use it to represent LLDP-based logical adjacencies.
• Others might model control-plane protocols like IS-IS or OSPF.
• And someone else might use it for abstract service layering above physical infrastructure.

The value of this change lies in making the Virtual Circuit model more abstract and extensible, so it can support diverse use cases—not just telco-style L2/L3 services. While not every deployment will need this, those who do could benefit significantly, without impacting those who don’t.

@loubladi commented on GitHub (Apr 7, 2025): My primary use case is Optical Transport Networks (OTN). We’re currently working on a synchronization mechanism between NetBox and our Cisco DWDM management system. Due to the current restrictions on Virtual Circuit Terminations, we’ve had to introduce an artificial workaround—duplicating interfaces into both physical and virtual types—just to satisfy the existing validation logic. <img width="1205" alt="Image" src="https://github.com/user-attachments/assets/a86513c9-3369-4dc0-af84-86c03162e3e7" /> We had been eagerly waiting for the Virtual Circuits functionality and were really excited when it was introduced. We believed it would finally allow us to model our DWDM network within NetBox while still retaining the ability to use Circuits for physical connectivity. The L2VPN example was meant as an illustration. In practice, NetBox is a highly flexible framework, and each organization adapts the built-in objects to suit their specific operational model. This proposed change would embrace that flexibility: by allowing Virtual Circuits to terminate on any interface type and by supporting multiple terminations per interface, users would be empowered to define their own modeling strategies. For example: • One user might model DWDM networks with OCH/OTS channels. • Another could use it to represent LLDP-based logical adjacencies. • Others might model control-plane protocols like IS-IS or OSPF. • And someone else might use it for abstract service layering above physical infrastructure. The value of this change lies in making the Virtual Circuit model more abstract and extensible, so it can support diverse use cases—not just telco-style L2/L3 services. While not every deployment will need this, those who do could benefit significantly, without impacting those who don’t.
adam commented 2025-12-29 21:38:29 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 7, 2025):

Optical Transport Networks (OTN) – Model DWDM optical paths between transponders using Virtual Circuits.

These are physical circuits and thus should not be modeled as virtual circuits. We're currently exploring solution for modeling WDM networks (see #16433 and probably others).

MPLS & SD-WAN – Represent logical overlays over physical infrastructure.
Service Provider Networks – Represent L2VPN, L3VPN, and Pseudowire terminations directly on physical interfaces.

These are overlay technologies also would not be modeled as virtual circuits. NetBox is already capable of modeling MPLS/VPN and various L2VPN topologies. If there are specific features you're looking for in this area, please submit a feature request(s) citing your specific use cases.

@jeremystretch commented on GitHub (Apr 7, 2025): > Optical Transport Networks (OTN) – Model DWDM optical paths between transponders using Virtual Circuits. These are physical circuits and thus should not be modeled as virtual circuits. We're currently exploring solution for modeling WDM networks (see #16433 and probably others). > MPLS & SD-WAN – Represent logical overlays over physical infrastructure. > Service Provider Networks – Represent L2VPN, L3VPN, and Pseudowire terminations directly on physical interfaces. These are overlay technologies also would not be modeled as virtual circuits. NetBox is already capable of modeling MPLS/VPN and various L2VPN topologies. If there are specific features you're looking for in this area, please submit a feature request(s) citing your specific use cases.
adam commented 2025-12-29 21:38:29 +01:00
Author
Owner
Copy Link

@loubladi commented on GitHub (Apr 7, 2025):

If DWDM modeling is something that’s being worked on, we’ll definitely keep an eye on future updates.

Referencing MPLS services as a use case was a mistake on my part.

The original idea was to use Virtual Circuits as an abstraction layer, enabling users to model any protocol or logical connectivity as they see fit. This would allow users to represent additional network layers that aren’t yet supported in NetBox but are on the roadmap—such as OTN or service mappings.

That said, I understand if this feature request doesn’t align with the current development goals. I’m fine with closing this FR for now.

@loubladi commented on GitHub (Apr 7, 2025): If DWDM modeling is something that’s being worked on, we’ll definitely keep an eye on future updates. Referencing MPLS services as a use case was a mistake on my part. The original idea was to use Virtual Circuits as an abstraction layer, enabling users to model any protocol or logical connectivity as they see fit. This would allow users to represent additional network layers that aren’t yet supported in NetBox but are on the roadmap—such as OTN or service mappings. That said, I understand if this feature request doesn’t align with the current development goals. I’m fine with closing this FR for now.
adam commented 2025-12-29 21:38:29 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Apr 15, 2025):

This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.

@github-actions[bot] commented on GitHub (Apr 15, 2025): This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.
adam commented 2025-12-29 21:38:30 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Apr 23, 2025):

This issue is being closed as no further information has been provided. If you would like to revisit this topic, please first modify your original post to include all the requested detail, and then ask that the issue be reopened.

@github-actions[bot] commented on GitHub (Apr 23, 2025): This issue is being closed as no further information has been provided. If you would like to revisit this topic, please first modify your original post to include all the requested detail, and then ask that the issue be reopened.
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 pending closure status: revisions needed 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#10962
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?