Cable trace does not build up after patchpanel redocumentation #9233

Closed
opened 2025-12-29 20:47:19 +01:00 by adam · 5 comments
Owner

Originally created by @betadrome on GitHub (Feb 12, 2024).

Deployment Type

Self-hosted

NetBox Version

v3.7.2

Python Version

3.11

Steps to Reproduce

  1. document the following connection: device <--> patch panel <--> patch panel <--> device
  2. re-document the patch panel connections between the patch panels, e.g. changing the positions of the rear connectors
  3. run python3 netbox/manage.py trace_paths to recreate the trace paths
  4. problem: trace path only works if I disconnect and reconnect all devices from the patchpanel

Expected Behavior

The trace is built again, recognizes its route via the patch fields and displays a complete trace

Observed Behavior

The trace no longer builds up, only when the cables up to the patchpanel have been deleted and recreated do you have a proper trace again. In addition, you have to re-document all end points, if you only re-document one, you can only see the complete path from that side, from the other side it will not find the absolute end point.

Originally created by @betadrome on GitHub (Feb 12, 2024). ### Deployment Type Self-hosted ### NetBox Version v3.7.2 ### Python Version 3.11 ### Steps to Reproduce 1. document the following connection: device <--> patch panel <--> patch panel <--> device 2. re-document the patch panel connections between the patch panels, e.g. changing the positions of the rear connectors 3. run `python3 netbox/manage.py trace_paths` to recreate the trace paths 4. problem: trace path only works if I disconnect and reconnect all devices from the patchpanel ### Expected Behavior The trace is built again, recognizes its route via the patch fields and displays a complete trace ### Observed Behavior The trace no longer builds up, only when the cables up to the patchpanel have been deleted and recreated do you have a proper trace again. In addition, you have to re-document all end points, if you only re-document one, you can only see the complete path from that side, from the other side it will not find the absolute end point.
adam closed this issue 2025-12-29 20:47:19 +01:00
Author
Owner

@jeremystretch commented on GitHub (Feb 12, 2024):

Thank you for opening a bug report. Unfortunately, the information you have provided is not sufficient for someone else to attempt to reproduce the reported behavior. Remember, each bug report must include detailed steps that someone else can follow on a clean, empty NetBox installation to reproduce the exact problem you're experiencing. These instructions should include the creation of any involved objects, any configuration changes, and complete accounting of the actions being taken. Also be sure that your report does not reference data on the public NetBox demo, as that is subject to change at any time by an outside party and cannot be relied upon for bug reports.

@jeremystretch commented on GitHub (Feb 12, 2024): Thank you for opening a bug report. Unfortunately, the information you have provided is not sufficient for someone else to attempt to reproduce the reported behavior. Remember, each bug report must include detailed steps that someone else can follow on a clean, empty NetBox installation to reproduce the exact problem you're experiencing. These instructions should include the creation of any involved objects, any configuration changes, and complete accounting of the actions being taken. Also be sure that your report does not reference data on the public NetBox demo, as that is subject to change at any time by an outside party and cannot be relied upon for bug reports.
Author
Owner

@betadrome commented on GitHub (Feb 13, 2024):

I did some more research and tested the problem a lot more. The problem is a bit bigger than I thought. In principle, it occurs when updating from 3.5.x to 3.7.x. Since v3.6.3 the problem: "cable with multiple connections can't cross module front/rear ports" has been fixed. Since then, two parallel cables can be routed between the same patch panel. This also works perfectly, but only for newly created cables. This means that it does not yet recognize the absolute connection for old cable traces. Only when the cable has been newly created from the first and last active component is the trace properly displayed again for both interface end points. Funnily enough, as soon as the connection between an interface and the first passive element has been re-documented, you can see the complete trace from this interface, but not yet from the other side. As soon as you have recreated the cable from the other side, you can see it from both sides. As already mentioned, this problem no longer occurs to this extent after v3.6.3.

Here again step-by-step:

NetBox Version

Update from 3.5.x to 3.7.x, the problem probably also exists between v3.5.x and 3.6.x but not sure

Steps to reproduce

  1. [v3.5.x] Create new devices named like patchpanel1 and patchpanel2, 24 rear ports mapped to 24 front ports (1 to 1 connection)
  2. [v3.5.x] Create new devices named like switch1 and switch2, each device has e.g. 1 interface
  3. [v3.5.x] Create connection between switch1 and patchpanel1
  4. [v3.5.x] Create connection between switch2 and patchpanel2

INFO: before the update parallel cables over a patchpanel where not supported (#11079). Conversely, this means that there were no absolute cable traces between to interfaces with passive cabeling.

  1. [v3.7.x] Update NetBox to newer version
  2. Cable trace is still broken, after deleting the cables between the first and last active component, the cable trace is displayed properly again

The problem no longer occurs as of v3.6.3, i.e. it only affects connections that were documented before v3.6.3 with multi-termination cabling and parallel cables via patch panels.

Here are some pictures from the problem and what it should look like:
v3-5-x-problem
(v3.5.x before update)

v3-7-x-problem
(v3.7.x after update, before recreate cables)

v3-7-xsolved
(v3.7.x after update, after recreate cables)

@betadrome commented on GitHub (Feb 13, 2024): I did some more research and tested the problem a lot more. The problem is a bit bigger than I thought. In principle, it occurs when updating from 3.5.x to 3.7.x. Since v3.6.3 the problem: "cable with multiple connections can't cross module front/rear ports" has been fixed. Since then, two parallel cables can be routed between the same patch panel. This also works perfectly, but only for newly created cables. This means that it does not yet recognize the absolute connection for old cable traces. Only when the cable has been newly created from the first and last active component is the trace properly displayed again for both interface end points. Funnily enough, as soon as the connection between an interface and the first passive element has been re-documented, you can see the complete trace from this interface, but not yet from the other side. As soon as you have recreated the cable from the other side, you can see it from both sides. As already mentioned, this problem no longer occurs to this extent after v3.6.3. Here again step-by-step: #### NetBox Version Update from 3.5.x to 3.7.x, the problem probably also exists between v3.5.x and 3.6.x but not sure #### Steps to reproduce 1. [v3.5.x] Create new devices named like patchpanel1 and patchpanel2, 24 rear ports mapped to 24 front ports (1 to 1 connection) 2. [v3.5.x] Create new devices named like switch1 and switch2, each device has e.g. 1 interface 3. [v3.5.x] Create connection between switch1 and patchpanel1 4. [v3.5.x] Create connection between switch2 and patchpanel2 **INFO**: before the update parallel cables over a patchpanel where not supported (#11079). Conversely, this means that there were no absolute cable traces between to interfaces with passive cabeling. 5. [v3.7.x] Update NetBox to newer version 6. Cable trace is still broken, after deleting the cables between the first and last active component, the cable trace is displayed properly again The problem no longer occurs as of v3.6.3, i.e. it only affects connections that were documented before v3.6.3 with multi-termination cabling and parallel cables via patch panels. Here are some pictures from the problem and what it should look like: ![v3-5-x-problem](https://github.com/netbox-community/netbox/assets/110609354/df00d976-4d72-4f87-be3b-9476b7a34832) (v3.5.x before update) ![v3-7-x-problem](https://github.com/netbox-community/netbox/assets/110609354/1fbc63c4-b4d6-4c06-86a3-42e4feb44865) (v3.7.x after update, before recreate cables) ![v3-7-xsolved](https://github.com/netbox-community/netbox/assets/110609354/d1ed2c87-ec00-4176-aca2-5bebceb6a894) (v3.7.x after update, after recreate cables)
Author
Owner

@jeremystretch commented on GitHub (May 28, 2024):

@opensourceXnetbox would you like to take ownership of this issue and submit a PR?

@jeremystretch commented on GitHub (May 28, 2024): @opensourceXnetbox would you like to take ownership of this issue and submit a PR?
Author
Owner

@github-actions[bot] commented on GitHub (Apr 24, 2025):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Apr 24, 2025): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/main/CONTRIBUTING.md).
Author
Owner

@github-actions[bot] commented on GitHub (May 25, 2025):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (May 25, 2025): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#9233