Treat circuit terminations as pass-through terminations when tracing cables #4712

New Issue

adam · 2025-12-29T19:19:44+01:00

adam commented

2025-12-29 19:19:44 +01:00

Originally created by @jeremystretch on GitHub (Mar 30, 2021).

Originally assigned to: @jeremystretch on GitHub.

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.

Originally created by @jeremystretch on GitHub (Mar 30, 2021). Originally assigned to: @jeremystretch on GitHub. ### 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. ![Cable traces](https://user-images.githubusercontent.com/13487278/113048936-11268080-9171-11eb-8b8e-e8a2e5ce5d4c.png) 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.

adam added the status: accepted type: feature labels 2025-12-29 19:19:44 +01:00

adam closed this issue

2025-12-29 19:19:44 +01:00

adam commented

2025-12-29 19:19:45 +01:00

@networkhorse commented on GitHub (Mar 31, 2021):

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.

@networkhorse commented on GitHub (Mar 31, 2021): 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.

adam commented

2025-12-29 19:19:45 +01:00

@jeremystretch commented on GitHub (Mar 31, 2021):

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.

@jeremystretch commented on GitHub (Mar 31, 2021): > 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.

adam commented

2025-12-29 19:19:45 +01:00

@networkhorse commented on GitHub (Mar 31, 2021):

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.

@networkhorse commented on GitHub (Mar 31, 2021): > 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.

adam commented

2025-12-29 19:19:46 +01:00

@jeremystretch commented on GitHub (Apr 1, 2021):

FYI I've renamed Cloud to ProviderNetwork in d5722232.

@jeremystretch commented on GitHub (Apr 1, 2021): FYI I've renamed Cloud to ProviderNetwork in d5722232.

adam commented

2025-12-29 19:19:46 +01:00

@tyler-8 commented on GitHub (Apr 1, 2021):

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.

@tyler-8 commented on GitHub (Apr 1, 2021): 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.

adam commented

2025-12-29 19:19:46 +01:00

@dejantep commented on GitHub (Apr 1, 2021):

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.

@dejantep commented on GitHub (Apr 1, 2021): 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.

adam commented

2025-12-29 19:19:46 +01:00

@sdktr commented on GitHub (Apr 2, 2021):

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?

@sdktr commented on GitHub (Apr 2, 2021): > 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?

adam commented

2025-12-29 19:19:47 +01:00

@jeremystretch commented on GitHub (Apr 2, 2021):

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)

@jeremystretch commented on GitHub (Apr 2, 2021): 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)

adam commented

2025-12-29 19:19:47 +01:00

@sliddjur commented on GitHub (Apr 7, 2021):

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.

@sliddjur commented on GitHub (Apr 7, 2021): 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.

adam commented

2025-12-29 19:19:47 +01:00

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

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.

@jeremystretch commented on GitHub (Apr 7, 2021): > 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.

adam commented

2025-12-29 19:19:47 +01:00

@sliddjur commented on GitHub (Apr 7, 2021):

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.

@sliddjur commented on GitHub (Apr 7, 2021): 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. ![image](https://user-images.githubusercontent.com/10002057/113888621-cb963300-97c2-11eb-9b4a-8c702e0bdd6c.png)

adam commented

2025-12-29 19:19:48 +01:00

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

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.

@jeremystretch commented on GitHub (Apr 7, 2021): 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.

adam commented

2025-12-29 19:19:48 +01:00

@sliddjur commented on GitHub (Apr 7, 2021):

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.

@sliddjur commented on GitHub (Apr 7, 2021): 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.

Sign in to join this conversation.

Branches Tags

main

21142-device-component-graphql-filters

21050-device-oob-ip-may-become-orphaned

21102-fix-graphiql-explorer

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#4712