Treat circuit terminations as pass-through terminations when tracing cables

[jeremystretch]

NetBox version

v2.10.8

Feature type

Change to existing functionality

Proposed functionality

NetBox v2.10 introduced a significant overhaul to its cable tracing functionality to address several long-standing bugs. One of the most significant changes is that a trace now halts when it encounters a circuit termination. This change was made to ensure that traces which end at a circuit whose far end termination is not defined do not display as open-ended paths.

This issue proposes altering the behavior of a cable trace to treat circuit termination as pass-through nodes (e.g. like front and rear pass-through ports) instead of terminating at them. NetBox v2.11 introduces a new cloud model (see #5986) which can be used to represent the boundary of an unknown network. In NetBox v2.11, a circuit termination can attach directly to either a site or to a cloud, which should address the original concern of unterminated traces for single-termination circuits.

The ramifications of the proposed change are discussed in greater detail below.

Use case

Making this change will allow NetBox to trace a complete end-to-end path across both cables and circuits.

Database changes

Remove the _path field from the circuits.CircuitTermination model

External dependencies

No response

The drawing below illustrates four distinct topologies in which a circuit can be connected.

In scenario A, two complete cable paths are built: one from interface 1 to interface 2, and one from interface 2 to interface 1. Tracing from either origin point or from any intermediate node will show a complete end-to-end path.

In scenarios B and C, only a single cable path is built: from interface 1 to the cloud or site attached to the far end circuit termination. When tracing from interface 1, the cloud or site will be show as the terminating endpoint. Note that this is also true when viewing device A's interface list: The far end termination for interface 1 will show the cloud or site object, not the intermediate circuit.

In scenario D, only a single partial path is built. Interface 1 will show no terminating endpoint. (This is the situation that the current implementation avoids by treating all circuit terminations as path endpoints.)

It should be noted that this approach does not allow for the direct association of an originating interface to a circuit or circuit termination. If adopted, it will no longer be possible to show, for example, all connected circuits when viewing a device's interface list. Instead, users would be encouraged to always attach a second termination to every circuit utilizing the cloud model. This would at least convey the connected network if not the circuit by which it is reached.

[networkhorse]

I think calling it a "Cloud" is a bit misleading, but I agree with the concept.

I wouldn't consider, for example, LINX or LONAP as "Clouds", but those are some examples of where this is particularly useful.

Perhaps we consider them as External Services we connect to? There must be some better terminology for this I think.

I would also say that C is not optimal, at least in our case. Ideally if we have control of both sites, we should be able to trace a cable from A to Z, seeing all intermediate connections.

[jeremystretch]

I think calling it a "Cloud" is a bit misleading, but I agree with the concept.

It's definitely an overloaded term. "Network" might be more apt, but of course that's even more overloaded. Provider Network, maybe?

I would also say that C is not optimal, at least in our case. Ideally if we have control of both sites, we should be able to trace a cable from A to Z, seeing all intermediate connections.

There's nothing preventing you from doing so: This is just the case wherein a user has not defined anything beyond the site for a circuit termination. Connecting it via a cable will permit tracing through to the endpoint.

[networkhorse]

It's definitely an overloaded term. "Network" might be more apt, but of course that's even more overloaded. Provider Network, maybe?

I like this.

There's nothing preventing you from doing so: This is just the case wherein a user has not defined anything beyond the site for a circuit termination. Connecting it via a cable will permit tracing through to the endpoint.

Sounds great to me. Perhaps someone might have customers as Tenants, sites as their building, then give them fibre and nothing more. That would be neat since you don't need to care about what they connect then.

[jeremystretch]

FYI I've renamed Cloud to ProviderNetwork in d572223.

[tyler-8]

I have all 4 scenarios in my environment, and many many of the B and D scenarios, so this seems like a reasonable approach. I also agree with the renaming to ProviderNetwork.

[dejantep]

i welcome end-to-end visibility but loosing option to connect circuit to an interface is unfortunate. In an environment where you connect unknown devices to interfaces this is essential to keep track of used ports.

[sdktr]

i welcome end-to-end visibility but loosing option to connect circuit to an interface is unfortunate. In an environment where you connect unknown devices to interfaces this is essential to keep track of used ports.

I second this. Can you explain what will be visible on the interface level, when it connects to(through?) a circuit? Will we see the ProviderNetwork instead?

[jeremystretch]

The best way to familiarize yourself with the new behavior is to help test the v2.11 beta when it is released. (Edit: We have a public beta instance now at https://beta.netbox.dev)

[sliddjur]

Does a circuit have to have two terminations?
For me, a circuit is usually a leased dark fiber in which we have control over both endpoints.

I connect two rear ports to each other, so in a sense my circuits are more like a "cable". But I still want the information that I can get from a circuit object. (Provider, circuit ID, etc)

In your example each circuit needs two cables, but I want to visualize each circuit with one cable connected to my rear ports.

[jeremystretch]

Does a circuit have to have two terminations?

No; you can have a circuit with the far connected to a cable, a site, a provider network, or nothing.

[sliddjur]

What I meant is, I see no way to make a connection between two rear ports, - over a circuit - to be only one cable.
I expected the part with cable 132 and cable 133 to be one single cable.

Another thing is that the cable trace only worked if one end was connected to a interface.

Tested on https://beta.netbox.dev/dcim/front-ports/1547/trace/ 2.11 beta.

[jeremystretch]

You can connect rear ports directly with a cable, yes. If you want to use a circuit, each end of the circuit needs to have its own cable attached.

[sliddjur]

Ok, so Netbox sees a circuit more like a device with termination endpoints, than a cable? I was hoping for the latter, because I wanted the circuit information to appear on the cable itself.