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

Implement new mechanism for tracking end-to-end connections across cable paths #3896

New Issue
Closed
opened 2025-12-29 18:31:51 +01:00 by adam · 7 comments
adam commented 2025-12-29 18:31:51 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Jul 24, 2020).

Originally assigned to: @jeremystretch on GitHub.

Proposed Changes

NetBox tracks end-to-end connections over pass-through ports. When a cable is saved, traces are done in both directions, and if a complete path has been established, the peer termination information is recorded at either of its endpoints.

This proposal seeks to devise and implement a new mechanism for tracking these end-to-end paths separately from the cable termination models. It may be desirable to introduce a new model (e.g. CablePath) dedicated to holding this information. Although more research is needed to identify the ideal solution, I've opened this issue now so that we can start referencing it as a blocker.

Justification

The association of end-to-end path data with specific device components and circuit terminations has proved problematic and inefficient (see the linked issues for examples).

Originally created by @jeremystretch on GitHub (Jul 24, 2020). Originally assigned to: @jeremystretch on GitHub. ### Proposed Changes NetBox tracks end-to-end connections over pass-through ports. When a cable is saved, traces are done in both directions, and if a complete path has been established, the peer termination information is recorded at either of its endpoints. This proposal seeks to devise and implement a new mechanism for tracking these end-to-end paths separately from the cable termination models. It may be desirable to introduce a new model (e.g. CablePath) dedicated to holding this information. Although more research is needed to identify the ideal solution, I've opened this issue now so that we can start referencing it as a blocker. ### Justification The association of end-to-end path data with specific device components and circuit terminations has proved problematic and inefficient (see the linked issues for examples).
adam added the status: acceptedtype: housekeeping labels 2025-12-29 18:31:51 +01:00
adam closed this issue 2025-12-29 18:31:51 +01:00
adam commented 2025-12-29 18:31:52 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 29, 2020):

Although many of the details need to be refined, the high-level approach will be to model discrete cable paths individually for each connected object. For example, consider the following topology:

                1                           2
[Device 1] -----------+               +----------- [Device 2]
      Iface1          |               |          Iface2
                  FP1 |       3       | FP2
                  [Panel 1] ----- [Panel 2]
                  FP3 |   RP1   RP2   | FP4
      Iface3          |               |          Iface4
[Device 3] -----------+               +----------- [Device 4]
                4                           5

There are two end-to-end connections present, both via cable 3:

  • Iface 1 <---> Iface 2
  • Iface 3 <---> Iface 4

Currently, these connections are conveyed only on the four individual interfaces. A more robust approach would record each of the four unidirectional end-to-end connections individually, as:

  1. (Iface1, Cable 1, FP1, RP1, Cable 3, RP2, FP2, Cable 2, Iface2)
  2. (Iface2, Cable 2, FP2, RP2, Cable 3, RP1, FP1, Cable 1, Iface1)
  3. (Iface3, Cable 4, FP3, RP1, Cable 3, RP2, FP4, Cable 5, Iface4)
  4. (Iface4, Cable 5, FP4, RP2, Cable 3, RP1, FP3, Cable 4, Iface3)

This approach ensures that we can immediately query all potentially affected points along a path any time any single component within the path changes. For example, if cable 2 is deleted, we know immediately that paths 1 and 2 need to be updated.

@jeremystretch commented on GitHub (Sep 29, 2020): Although many of the details need to be refined, the high-level approach will be to model discrete cable paths individually for each connected object. For example, consider the following topology: ``` 1 2 [Device 1] -----------+ +----------- [Device 2] Iface1 | | Iface2 FP1 | 3 | FP2 [Panel 1] ----- [Panel 2] FP3 | RP1 RP2 | FP4 Iface3 | | Iface4 [Device 3] -----------+ +----------- [Device 4] 4 5 ``` There are two end-to-end connections present, both via cable 3: * Iface 1 <---> Iface 2 * Iface 3 <---> Iface 4 Currently, these connections are conveyed only on the four individual interfaces. A more robust approach would record each of the four unidirectional end-to-end connections individually, as: 1. (Iface1, Cable 1, FP1, RP1, Cable 3, RP2, FP2, Cable 2, Iface2) 2. (Iface2, Cable 2, FP2, RP2, Cable 3, RP1, FP1, Cable 1, Iface1) 3. (Iface3, Cable 4, FP3, RP1, Cable 3, RP2, FP4, Cable 5, Iface4) 4. (Iface4, Cable 5, FP4, RP2, Cable 3, RP1, FP3, Cable 4, Iface3) This approach ensures that we can immediately query all potentially affected points along a path any time any single component within the path changes. For example, if cable 2 is deleted, we know immediately that paths 1 and 2 need to be updated.
adam commented 2025-12-29 18:31:52 +01:00
Author
Owner
Copy Link

@steffann commented on GitHub (Sep 29, 2020):

I have experimented a bit with something similar: https://gist.github.com/steffann/b0cf1340fe0825bbffeba73822867d3b

Feel free to use!

@steffann commented on GitHub (Sep 29, 2020): I have experimented a bit with something similar: https://gist.github.com/steffann/b0cf1340fe0825bbffeba73822867d3b Feel free to use!
adam commented 2025-12-29 18:31:52 +01:00
Author
Owner
Copy Link

@seismiccollision commented on GitHub (Oct 1, 2020):

If reworking the path trace is planned I think it would also be useful to be able to make a logical connection between two end objects and then flesh out the front/rear ports to build the physical trace
I usually know what two things I intend to connect without knowing what patch panel path is free (or maybe the patch panels haven't been modeled yet) and then usually wait to model any of the connection until I know everything which hampers being able to take advantage of the logical connection when building configs

@seismiccollision commented on GitHub (Oct 1, 2020): If reworking the path trace is planned I think it would also be useful to be able to make a logical connection between two end objects and then flesh out the front/rear ports to build the physical trace I usually know what two things I intend to connect without knowing what patch panel path is free (or maybe the patch panels haven't been modeled yet) and then usually wait to model any of the connection until I know everything which hampers being able to take advantage of the logical connection when building configs
adam commented 2025-12-29 18:31:52 +01:00
Author
Owner
Copy Link

@bluikko commented on GitHub (Nov 23, 2020):

Are there plans to make trace work through circuits at some later time? We were relying on that feature in several locations. If the feature will not return then I guess we will need to re-work the data and somehow convert circuits to regular cables with some notes that those cables are actually circuits.

@bluikko commented on GitHub (Nov 23, 2020): Are there plans to make trace work through circuits at some later time? We were relying on that feature in several locations. If the feature will not return then I guess we will need to re-work the data and somehow convert circuits to regular cables with some notes that those cables are actually circuits.
adam commented 2025-12-29 18:31:52 +01:00
Author
Owner
Copy Link

@oskaregils commented on GitHub (Nov 24, 2020):

I understand that there are some major changes regarding circuits in rel 2.10
I am hoping for some fixes to what I feel lacking in my current version ( 2.8.1)

When viewing a circuit and in overview of each termination side A&Z on the right hand side of the screen.
The terminated device/interface is not always shown, sometimes only cable ID.
This depends on in what order things where registered in Netbox

When viewing a device interface it shows the far-end device it is connected to with a trace option.
I would be interested in seeing at a glance if (and hopefully then what) circuit is involved, with a globe icon for example.
This is for example the case if the interface is only terminated to a single side circuit. ( you get a globe icon and circuit ID)

Can the trace window flag/indicate circuit differently :-)
Pictures attached for clarity...

image
image
image

@oskaregils commented on GitHub (Nov 24, 2020): I understand that there are some major changes regarding circuits in rel 2.10 I am hoping for some fixes to what I feel lacking in my current version ( 2.8.1) When viewing a circuit and in overview of each termination side A&Z on the right hand side of the screen. The terminated device/interface is not always shown, sometimes only cable ID. This depends on in what order things where registered in Netbox When viewing a device interface it shows the far-end device it is connected to with a trace option. I would be interested in seeing at a glance if (and hopefully then what) circuit is involved, with a globe icon for example. This is for example the case if the interface is only terminated to a single side circuit. ( you get a globe icon and circuit ID) Can the trace window flag/indicate circuit differently :-) Pictures attached for clarity... ![image](https://user-images.githubusercontent.com/42591935/100099618-99a9b300-2e57-11eb-8787-c8cc9328d40f.png) ![image](https://user-images.githubusercontent.com/42591935/100099996-10df4700-2e58-11eb-9414-67f0a523a1a8.png) ![image](https://user-images.githubusercontent.com/42591935/100101008-91eb0e00-2e59-11eb-9981-0c269f5a1be9.png)
adam commented 2025-12-29 18:31:52 +01:00
Author
Owner
Copy Link

@bluikko commented on GitHub (Nov 24, 2020):

@oskaregils In 2.10 circuits will not be traversed by trace if I have understood correctly, from the release notes: "As part of this change, cable traces will no longer traverse circuits: A circuit termination will be considered the origin or destination of an end-to-end path." - if you feel that it should trace through circuits then please add a reaction to my post above https://github.com/netbox-community/netbox/issues/4900#issuecomment-731927355

@bluikko commented on GitHub (Nov 24, 2020): @oskaregils In 2.10 circuits will not be traversed by trace if I have understood correctly, from the release notes: "As part of this change, cable traces will no longer traverse circuits: A circuit termination will be considered the origin or destination of an end-to-end path." - if you feel that it should trace through circuits then please add a reaction to my post above https://github.com/netbox-community/netbox/issues/4900#issuecomment-731927355
adam commented 2025-12-29 18:31:52 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 24, 2020):

Please be aware that this issue is closed; no new work will be done under #4900. If you'd like to propose a change base on testing of the v2.10 beta, please do so by opening a new feature request.

Also note that no work will be done on v2.8: You'll need to upgrade to the latest v2.9 release.

@jeremystretch commented on GitHub (Nov 24, 2020): Please be aware that this issue is closed; no new work will be done under #4900. If you'd like to propose a change base on testing of the v2.10 beta, please do so by opening a _new_ feature request. Also note that _no_ work will be done on v2.8: You'll need to upgrade to the latest v2.9 release.
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 status: accepted type: housekeeping
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#3896
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?