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

Problem with cable trace system #4588

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

Originally created by @Pelt10 on GitHub (Feb 24, 2021).

Environment

  • Python version: Python 3.7.3
  • NetBox version: 2.10.4

Steps to Reproduce

  1. Insert all objects(via Import)
Manufacturers 
name,slug
Unknown,unknown
Sites 
name,slug
UNKNOWN,unknown
Racks 
site,group,name,facility_id,tenant,status,role,type,serial,asset_tag,width,u_height,desc_units,outer_width,outer_depth,outer_unit,comments
UNKNOWN,,test_rack,,,active,,,,,19,42,,,,,
Device Types 
manufacturer: Unknown
model: INTERFACE-DUPLEX
slug: interface-duplex
part_number: ''
u_height: 0
is_full_depth: false
subdevice_role: ''
comments: ''
front-ports:
- name: Fiber 1
  type: sc
  rear_port: output
  rear_port_position: 1
- name: Fiber 2
  type: sc
  rear_port: output
  rear_port_position: 2
rear-ports:
- name: output
  type: lc
  positions: 2
---
manufacturer: Unknown
model: Router
slug: router
part_number: ''
u_height: 1
is_full_depth: true
subdevice_role: ''
comments: ''
interfaces:
- name: SFP+1
  type: 10gbase-x-sfpp
  mgmt_only: false
---
manufacturer: Unknown
model: PatchPannel
slug: patchpannel
part_number: ''
u_height: 1
is_full_depth: true
subdevice_role: ''
comments: ''
front-ports:
- name: A1
  type: lc
  rear_port: output
  rear_port_position: 1
- name: A2
  type: lc
  rear_port: output
  rear_port_position: 2
- name: A3
  type: lc
  rear_port: output
  rear_port_position: 3
- name: A4
  type: lc
  rear_port: output
  rear_port_position: 4
- name: A5
  type: lc
  rear_port: output
  rear_port_position: 5
- name: A6
  type: lc
  rear_port: output
  rear_port_position: 6
- name: A7
  type: lc
  rear_port: output
  rear_port_position: 7
- name: A8
  type: lc
  rear_port: output
  rear_port_position: 8
- name: A9
  type: lc
  rear_port: output
  rear_port_position: 9
- name: A10
  type: lc
  rear_port: output
  rear_port_position: 10
- name: A11
  type: lc
  rear_port: output
  rear_port_position: 11
- name: A12
  type: lc
  rear_port: output
  rear_port_position: 12
rear-ports:
- name: output
  type: sc
  positions: 12
Device Roles 
name,slug,color,vm_role,description
UNKNOW,unknow,9e9e9e,,
Devices 
name,device_role,tenant,manufacturer,device_type,platform,serial,asset_tag,status,site,rack,position,face,comments
PatchPannel A-Side,UNKNOW,,Unknown,PatchPannel,,,,active,UNKNOWN,test_rack,3,front,
PatchPannel Z-Side,UNKNOW,,Unknown,PatchPannel,,,,active,UNKNOWN,test_rack,2,front,
Router A-Side,UNKNOW,,Unknown,Router,,,,active,UNKNOWN,test_rack,4,front,
Router Z-side,UNKNOW,,Unknown,Router,,,,active,UNKNOWN,test_rack,1,front,
INTERFACE-DUPLEX A-Side,UNKNOW,,Unknown,INTERFACE-DUPLEX,,,,active,UNKNOWN,test_rack,,,
INTERFACE-DUPLEX Z-Side,UNKNOW,,Unknown,INTERFACE-DUPLEX,,,,active,UNKNOWN,test_rack,,,
Cables 
side_a_device,side_a_type,side_a_name,side_b_device,side_b_type,side_b_name
Router A-Side,dcim.interface,SFP+1,INTERFACE-DUPLEX A-Side,dcim.rearport,output
INTERFACE-DUPLEX A-Side,dcim.frontport,Fiber 1,PatchPannel A-Side,dcim.frontport,A1
INTERFACE-DUPLEX A-Side,dcim.frontport,Fiber 2,PatchPannel A-Side,dcim.frontport,A2
PatchPannel A-Side,dcim.rearport,output,PatchPannel Z-Side,dcim.rearport,output
INTERFACE-DUPLEX Z-Side,dcim.frontport,Fiber 2,PatchPannel Z-Side,dcim.frontport,A1
INTERFACE-DUPLEX Z-Side,dcim.frontport,Fiber 1,PatchPannel Z-Side,dcim.frontport,A2
Router Z-side,dcim.interface,SFP+1,INTERFACE-DUPLEX Z-Side,dcim.rearport,output

Screenshot 2021-02-24 at 17 55 14

  1. Try to follow SFP+1 of "Router A-Side", you get this :
    Screenshot 2021-02-24 at 19 10 44

  2. Click on "Fiber 1"

Expected Behavior

Show the cable trace following "Fiber 1"

Observed Behavior

Screenshot 2021-02-24 at 19 11 45

I try to use :

./manage.py trace_paths
# and
./manage.py trace_paths --force

without any changes

Originally created by @Pelt10 on GitHub (Feb 24, 2021). ### Environment * Python version: Python 3.7.3 * NetBox version: 2.10.4 <!-- Describe in detail the exact steps that someone else can take to reproduce this bug using the current stable release of NetBox. Begin with the creation of any necessary database objects and call out every operation being performed explicitly. If reporting a bug in the REST API, be sure to reconstruct the raw HTTP request(s) being made: Don't rely on a client library such as pynetbox. --> ### Steps to Reproduce 1. Insert all objects(via Import) <details> <summary>Manufacturers</summary> ```csv name,slug Unknown,unknown ``` </details> <details> <summary>Sites</summary> ```csv name,slug UNKNOWN,unknown ``` </details> <details> <summary>Racks</summary> ```csv site,group,name,facility_id,tenant,status,role,type,serial,asset_tag,width,u_height,desc_units,outer_width,outer_depth,outer_unit,comments UNKNOWN,,test_rack,,,active,,,,,19,42,,,,, ``` </details> <details> <summary>Device Types</summary> ```yaml manufacturer: Unknown model: INTERFACE-DUPLEX slug: interface-duplex part_number: '' u_height: 0 is_full_depth: false subdevice_role: '' comments: '' front-ports: - name: Fiber 1 type: sc rear_port: output rear_port_position: 1 - name: Fiber 2 type: sc rear_port: output rear_port_position: 2 rear-ports: - name: output type: lc positions: 2 --- manufacturer: Unknown model: Router slug: router part_number: '' u_height: 1 is_full_depth: true subdevice_role: '' comments: '' interfaces: - name: SFP+1 type: 10gbase-x-sfpp mgmt_only: false --- manufacturer: Unknown model: PatchPannel slug: patchpannel part_number: '' u_height: 1 is_full_depth: true subdevice_role: '' comments: '' front-ports: - name: A1 type: lc rear_port: output rear_port_position: 1 - name: A2 type: lc rear_port: output rear_port_position: 2 - name: A3 type: lc rear_port: output rear_port_position: 3 - name: A4 type: lc rear_port: output rear_port_position: 4 - name: A5 type: lc rear_port: output rear_port_position: 5 - name: A6 type: lc rear_port: output rear_port_position: 6 - name: A7 type: lc rear_port: output rear_port_position: 7 - name: A8 type: lc rear_port: output rear_port_position: 8 - name: A9 type: lc rear_port: output rear_port_position: 9 - name: A10 type: lc rear_port: output rear_port_position: 10 - name: A11 type: lc rear_port: output rear_port_position: 11 - name: A12 type: lc rear_port: output rear_port_position: 12 rear-ports: - name: output type: sc positions: 12 ``` </details> <details> <summary>Device Roles</summary> ```csv name,slug,color,vm_role,description UNKNOW,unknow,9e9e9e,, ``` </details> <details> <summary>Devices</summary> ```csv name,device_role,tenant,manufacturer,device_type,platform,serial,asset_tag,status,site,rack,position,face,comments PatchPannel A-Side,UNKNOW,,Unknown,PatchPannel,,,,active,UNKNOWN,test_rack,3,front, PatchPannel Z-Side,UNKNOW,,Unknown,PatchPannel,,,,active,UNKNOWN,test_rack,2,front, Router A-Side,UNKNOW,,Unknown,Router,,,,active,UNKNOWN,test_rack,4,front, Router Z-side,UNKNOW,,Unknown,Router,,,,active,UNKNOWN,test_rack,1,front, INTERFACE-DUPLEX A-Side,UNKNOW,,Unknown,INTERFACE-DUPLEX,,,,active,UNKNOWN,test_rack,,, INTERFACE-DUPLEX Z-Side,UNKNOW,,Unknown,INTERFACE-DUPLEX,,,,active,UNKNOWN,test_rack,,, ``` </details> <details> <summary>Cables</summary> ```csv side_a_device,side_a_type,side_a_name,side_b_device,side_b_type,side_b_name Router A-Side,dcim.interface,SFP+1,INTERFACE-DUPLEX A-Side,dcim.rearport,output INTERFACE-DUPLEX A-Side,dcim.frontport,Fiber 1,PatchPannel A-Side,dcim.frontport,A1 INTERFACE-DUPLEX A-Side,dcim.frontport,Fiber 2,PatchPannel A-Side,dcim.frontport,A2 PatchPannel A-Side,dcim.rearport,output,PatchPannel Z-Side,dcim.rearport,output INTERFACE-DUPLEX Z-Side,dcim.frontport,Fiber 2,PatchPannel Z-Side,dcim.frontport,A1 INTERFACE-DUPLEX Z-Side,dcim.frontport,Fiber 1,PatchPannel Z-Side,dcim.frontport,A2 Router Z-side,dcim.interface,SFP+1,INTERFACE-DUPLEX Z-Side,dcim.rearport,output ``` ![Screenshot 2021-02-24 at 17 55 14](https://user-images.githubusercontent.com/7582586/109043727-ee1c3300-76d1-11eb-98a1-18b300f580c5.png) </details> 2. Try to follow SFP+1 of "Router A-Side", you get this : ![Screenshot 2021-02-24 at 19 10 44](https://user-images.githubusercontent.com/7582586/109045548-02f9c600-76d4-11eb-8d01-016b3bef1e9f.png) 3. Click on "Fiber 1" <!-- What did you expect to happen? --> ### Expected Behavior Show the cable trace following "Fiber 1" <!-- What happened instead? --> ### Observed Behavior ![Screenshot 2021-02-24 at 19 11 45](https://user-images.githubusercontent.com/7582586/109045902-6f74c500-76d4-11eb-8f05-364908c6de9a.png) I try to use : ```bash ./manage.py trace_paths # and ./manage.py trace_paths --force ``` without any changes
adam closed this issue 2025-12-29 18:38:01 +01:00
adam commented 2025-12-29 18:38:02 +01:00
Author
Owner
Copy Link

@Pelt10 commented on GitHub (Feb 25, 2021):

I have try with Netbox 2.10.5, same problem.

@Pelt10 commented on GitHub (Feb 25, 2021): I have try with Netbox 2.10.5, same problem.
adam commented 2025-12-29 18:38:02 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Feb 25, 2021):

Thank you for opening a bug report. It seems that the described functionality is intended behavior. If you meant to open a feature request instead, please close this issue and open a new one using the feature request template. Otherwise, please revise your post above to elaborate on why you believe the observed behavior is flawed.

More detail:

This is expect as you are connecting to a rear port with 2 or more mapped front ports, we cannot know which path you are going to take. I suspect you are attempting to model SFP's which is unsupported currently.

@DanSheps commented on GitHub (Feb 25, 2021): Thank you for opening a bug report. It seems that the described functionality is intended behavior. If you meant to open a feature request instead, please close this issue and open a new one using the [feature request template](https://github.com/netbox-community/netbox/issues/new?template=feature_request.md). Otherwise, please revise your post above to elaborate on why you believe the observed behavior is flawed. More detail: This is expect as you are connecting to a rear port with 2 or more mapped front ports, we cannot know which path you are going to take. I suspect you are attempting to model SFP's which is unsupported currently.
adam commented 2025-12-29 18:38:02 +01:00
Author
Owner
Copy Link

@Pelt10 commented on GitHub (Feb 25, 2021):

Thank's Dan for your reply.
Goal of "INTERFACE-DUPLEX" device type is an attempt to model SFP, it's work fine since many versions(I have upgrade from v2.8.6 to v2.10.5).

I report this as a bug, because, when I use "Trace Fiber 1" button on the trace page of the SFP+1 interface, I get "blank" trace report . I was expecting to trace from Front port "Fiber 1" like on version 2.8.6.

@Pelt10 commented on GitHub (Feb 25, 2021): Thank's Dan for your reply. Goal of "INTERFACE-DUPLEX" device type is an attempt to model SFP, it's work fine since many versions(I have upgrade from v2.8.6 to v2.10.5). I report this as a bug, because, when I use "Trace Fiber 1" button on the trace page of the SFP+1 interface, I get "blank" trace report . I was expecting to trace from Front port "Fiber 1" like on version 2.8.6.
adam commented 2025-12-29 18:38:02 +01:00
Author
Owner
Copy Link

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

Goal of "INTERFACE-DUPLEX" device type is an attempt to model SFP
This is not proper use of the device type model. NetBox does not recognize optics/transceivers within the context of path tracing. You need to create just the interfaces on the actual devices, and attach cables between them.

@jeremystretch commented on GitHub (Mar 4, 2021): > Goal of "INTERFACE-DUPLEX" device type is an attempt to model SFP This is not proper use of the device type model. NetBox does not recognize optics/transceivers within the context of path tracing. You need to create just the interfaces on the actual devices, and attach cables between them.
adam commented 2025-12-29 18:38:03 +01:00
Author
Owner
Copy Link

@Pelt10 commented on GitHub (Mar 4, 2021):

Yes, it's not a good usage of device type model, but we don't have other way actually to modeling duplex situation.
It's an old "problem", that have been resolved with this sort of device type during long time. You can't remove this without offer an alternative.
Do you have an other idea to modeling this ?

@Pelt10 commented on GitHub (Mar 4, 2021): Yes, it's not a good usage of device type model, but we don't have other way actually to modeling duplex situation. It's an old "problem", that have been resolved with this sort of device type during long time. You can't remove this without offer an alternative. Do you have an other idea to modeling this ?
adam commented 2025-12-29 18:38:03 +01:00
Author
Owner
Copy Link

@xkilian commented on GitHub (Mar 4, 2021):

(corrected, incorrectly inserted something about optics)
Maybe after 2.11 it might be interesting to revisit this issue at the root to see if the core model could be improved or how the tracing could be improved to handle Y types and different other useful cases without causing bugs/issues/problems/maintainability issues with the cable tracing logic.
I have read through the various threads.
I am also involved/responsible with an in-house product that does this at large scale, so this is a topic dear to me.
Jeremy has been clear that at this point it is not part of the current product and the tracing logic has been changed, that it no longer handles that use case ( Y connexions) and tracing through circuits.

@xkilian commented on GitHub (Mar 4, 2021): (corrected, incorrectly inserted something about optics) Maybe after 2.11 it might be interesting to revisit this issue at the root to see if the core model could be improved or how the tracing could be improved to handle Y types and different other useful cases without causing bugs/issues/problems/maintainability issues with the cable tracing logic. I have read through the various threads. I am also involved/responsible with an in-house product that does this at large scale, so this is a topic dear to me. Jeremy has been clear that at this point it is not part of the current product and the tracing logic has been changed, that it no longer handles that use case ( Y connexions) and tracing through circuits.
adam commented 2025-12-29 18:38:03 +01:00
Author
Owner
Copy Link

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

To be clear, it never handled modeling optics as part of the tracing logic.

@jeremystretch commented on GitHub (Mar 4, 2021): To be clear, it _never_ handled modeling optics as part of the tracing logic.
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
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#4588
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?