Treat circuit terminations as pass-through terminations when tracing cables

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.

[jeremystretch]

FYI I’ve renamed Cloud to ProviderNetwork in d5722232.

[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.