Introduce the ability to create "Virtual" circuits

[jsenecal]

NetBox version

v3.5.4

Feature type

Change to existing functionality

Proposed functionality

Allow a new Circuit Termination variant which would link to a "Parent" circuit and optionally allow the user to select a virtual interface of either Parent side connected interface.

Currently this is not possible as Circuits require a physical port, which prevent the assignment of a sub-interface for instance.

Use case

As the operator of a service provider network, we often lease connections from third parties.
These connections often have multiple components, some of which run "on top" of other components, think many different vlans on a parent link, with each vlan being terminated to a different location or "Z" side.

This was discussed in #10558, as well as during community meetings and multiple slack conversations.
#10558 (comment) is a very good description of the use case.

Allowing netbox to properly document these is a must for service providers such as myself and would be of great benefit to the netbox community.

Database changes

Amongst other things, the CircuitTermination model would need to have an additional ForeignKey to circuits.CircuitTermination.

Additionally, a ForeignKey to dcim.Interface would allow to track the sub-interface related to the Parent circuit termination connected interface (and thus enable traces from sub-interfaces as well).

External dependencies

None

Additional information

I would be more than happy to provide a PR with those changes and related UI/Tests/Docs should the feature be accepted.

[shatt79]

I'd like to expand upon this.

In reality, a physical circuit would have two endpoints but multiple intermediate path elements. The circuits module in Netbox is practically useless because I can't see anything but the two endpoints. I want to see the DLR of the entire path including all patch panels, WDMs, etc along the way.

In real networks, "services" are multiplexed on a physical path. I can carry voice, video, data, etc on the same cable. But within Netbox, I have no way to document that. The proper way to model this would be to have a "parent" or "infrastructure" physical circuit (with a circuit ID) that documents the entire physical path from A to Z, much like the cable trace view shows. The problem with the cable trace is that I can't assign a circuit ID to that or reference it in any way. The second part to properly modeling this would be to allow the creation of "child" or "service" circuits underneath the physical parent/infrastructure circuit. These circuits would/could be different VLANs, PPP groups, etc, possibly terminating to different sub-interfaces, using different DWDM channels, etc. These child circuits would also have their own circuit ID, and would associate with both a tenant and parent circuit. The "overlay" feature was a welcome addition, but its missing a crucial piece that would actually make it usable. When documenting an L2VPN, you don't attach interfaces to them. You would attach EVCs... Virtual circuits. Those EVCs would then have 2 or more UNIs or EFPs (interfaces)

Proper circuit modeling should be the cornerstone of any DCIM/F&E system. Netbox does not allow one to document the physical path of a circuit. If there is a problem on a physical or logical circuit, there is no way to generate an A to Z DLR to hand to a tech for troubleshooting. I have to use a different (and expensive) system for that. This creates swivel chairing and introduces data inconsistency. We would no longer have a source of truth.

[kmorin18]

I agree that from a service provider perspective this is super useful

[jsenecal]

The circuits module in Netbox is practically useless because I can't see anything but the two endpoints. I want to see the DLR of the entire path including all patch panels, WDMs, etc along the way.

In real networks, "services" are multiplexed on a physical path.

The use case you are explaining here is something entirely different @shatt79.

What you want is the ability to define Services components and track those items. This can be achieved in a plugin (this is what I did).

In NetBox, Circuits are there to document third-party "links" to be considered as gray/black boxes where the consumer aka the operator is unaware of the details of such circuits besides their purpose or their A and Z sides.

[gblanchard]

I was also just looking for this feature. Happy to see that familiar names are showing up here :)

[fguigou-dstny]

So... Not sure this is the place to ask this, but is anyone close to an implementation of sorts? Because I'm looking for the same feature, and if not, I'll do it myself, but it would be a shame to write the entire thing just to have it pop up in the next release of Netbox ;)

[jsenecal]

So... Not sure this is the place to ask this, but is anyone close to an implementation of sorts? Because I'm looking for the same feature, and if not, I'll do it myself, but it would be a shame to write the entire thing just to have it pop up in the next release of Netbox ;)

I havent worked on it since its implementation only really makes sense in the core models, and I dont usually work on core models unless there is an accepted FR. Having this designed as a plugin would make it really cumbersome to use.

[dejantep]

I just stumbled upon a case where i was not able to connect port to a circuit because whole port is used as l2vpn termination.
There is no multiplexing on this particualar port but i would still like to document physical connection as a circuit.

Does this adress my issue so i dont create similar PR?

[fguigou-dstny]

As a heads up, I'm currently working on a virtual circuit implementation (packaged in core, not as a plugin). Virtual circuits run on physical circuits or provider networks, but connect to interfaces and can have any arbitrary number of terminations, the idea being to allow cases like multiple endpoints connected to the same provider network.

[dejantep]

As a heads up, I'm currently working on a virtual circuit implementation (packaged in core, not as a plugin). Virtual circuits run on physical circuits or provider networks, but connect to interfaces and can have any arbitrary number of terminations, the idea being to allow cases like multiple endpoints connected to the same provider network.

Does this mean that circuits as we know them today will not change but there will be addition of virtual circuit on top of that which can be connected to any type of interface?

[fguigou-dstny]

As a heads up, I'm currently working on a virtual circuit implementation (packaged in core, not as a plugin). Virtual circuits run on physical circuits or provider networks, but connect to interfaces and can have any arbitrary number of terminations, the idea being to allow cases like multiple endpoints connected to the same provider network.

Does this mean that circuits as we know them today will not change but there will be addition of virtual circuit on top of that which can be connected to any type of interface?

That's the idea.

[bsavardmsk]

As a heads up, I'm currently working on a virtual circuit implementation (packaged in core, not as a plugin). Virtual circuits run on physical circuits or provider networks, but connect to interfaces and can have any arbitrary number of terminations, the idea being to allow cases like multiple endpoints connected to the same provider network.

Does this mean that circuits as we know them today will not change but there will be addition of virtual circuit on top of that which can be connected to any type of interface?

That's the idea.

Hello, i'm also looking for that feature have you been able to implement a plugin or write one that does the job ?