Problem with cable trace system

[Pelt10]

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

2. Try to follow SFP+1 of "Router A-Side", you get this :
   

3. Click on "Fiber 1"

Expected Behavior

Show the cable trace following "Fiber 1"

Observed Behavior

I try to use :

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

without any changes

[Pelt10]

I have try with Netbox 2.10.5, same problem.

[DanSheps]

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.

[Pelt10]

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.

[jeremystretch]

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.

[Pelt10]

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 ?

[xkilian]

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

[jeremystretch]

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