starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-12 05:20:31 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Cable trace will not work when rearports between devices are different number wise #11409

New Issue
Closed
opened 2025-12-29 21:44:52 +01:00 by adam · 3 comments
adam commented 2025-12-29 21:44:52 +01:00
Owner
Copy Link

Originally created by @cazure-n00b on GitHub (Jul 23, 2025).

Deployment Type

Self-hosted

NetBox Version

v4.2.6

Python Version

3.10

Steps to Reproduce

  1. Create device#1 with 1 interface port.
  2. Create device#2 with 8 front ports and 8 rear ports which are connected to each other.
  3. Create device#3 with 24 front ports and 24 rear ports which are connected to each other.
  4. Make sure that device#2 8 rear ports are connected to the rear ports 11-18 of device#3
  5. Create device#4 with 24 interface ports
  6. Now make the connection as follows;
  7. device#1, interface port 1 >> device#2 front port 7
  8. device#2, rear port 7 >> device#3 rear port 17
  9. device#3, front port 17 >> device#4 interface port 17
  10. Open device#1 and open Interface port 1, click on cable trace.
  11. The cable trace will stop at the Rear port 17 of device#3
  12. Open device#4 and select the cable trace of interface port 17
  13. The cable trace will stop at the Rear port 17 of device#2

See image below where we start the cable trace from device#1

Image

See image below where we start the cable trace from device#4

Image

Expected Behavior

The below image is my expectation

Image

Observed Behavior

If I would start the cable trace from IN_07, it will stop halfway (IN_01 > FP_07 x RP_07 > RP_17)
If I would start the cable trace from IN_17, it will stop halfway (RP_07 < RP_17 x FP_17 < IN_17)

But.. if I would change the connection to go through device#3 on Rear port and front port 07, then it will work. See image attached below;

Image
Originally created by @cazure-n00b on GitHub (Jul 23, 2025). ### Deployment Type Self-hosted ### NetBox Version v4.2.6 ### Python Version 3.10 ### Steps to Reproduce 1. Create device#1 with 1 interface port. 2. Create device#2 with 8 front ports and 8 rear ports which are connected to each other. 3. Create device#3 with 24 front ports and 24 rear ports which are connected to each other. 4. Make sure that device#2 8 rear ports are connected to the rear ports 11-18 of device#3 5. Create device#4 with 24 interface ports 6. Now make the connection as follows; 7. device#1, interface port 1 >> device#2 front port 7 8. device#2, rear port 7 >> device#3 rear port 17 9. device#3, front port 17 >> device#4 interface port 17 10. Open device#1 and open Interface port 1, click on cable trace. 11. The cable trace will stop at the Rear port 17 of device#3 12. Open device#4 and select the cable trace of interface port 17 13. The cable trace will stop at the Rear port 17 of device#2 See image below where we start the cable trace from device#1 <img width="561" height="845" alt="Image" src="https://github.com/user-attachments/assets/7fa35610-b6e0-46ac-8a2e-146ac634532f" /> See image below where we start the cable trace from device#4 <img width="460" height="733" alt="Image" src="https://github.com/user-attachments/assets/f87df02d-a5bd-448b-bf02-d9483b4c4ab8" /> ### Expected Behavior The below image is my expectation <img width="467" height="1044" alt="Image" src="https://github.com/user-attachments/assets/b394c860-1747-448b-afa0-83476c46c538" /> ### Observed Behavior If I would start the cable trace from IN_07, it will stop halfway (IN_01 > FP_07 x RP_07 > **RP_17**) If I would start the cable trace from IN_17, it will stop halfway (**RP_07** < RP_17 x FP_17 < IN_17) But.. if I would change the connection to go through device#3 on Rear port and front port 07, then it will work. See image attached below; <img width="448" height="1047" alt="Image" src="https://github.com/user-attachments/assets/79da112d-834d-4b2d-8315-2e7dbc22a4c4" />
adam added the netbox label 2025-12-29 21:44:52 +01:00
adam closed this issue 2025-12-29 21:44:53 +01:00
adam commented 2025-12-29 21:44:53 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Jul 24, 2025):

  • device#2, rear port 7 >> device#3 rear port 17

Lets look at this from a fiber standpoint. How does strand 7 on one end magically change to strand 17 on the other end?

This is working as intended. On rear ports, position 1 needs to map to position 1 on the peer. Position 100 needs to map to position 100 on the peer.

@DanSheps commented on GitHub (Jul 24, 2025): > * device#2, rear port 7 >> device#3 rear port 17 Lets look at this from a fiber standpoint. How does strand 7 on one end magically change to strand 17 on the other end? This is working as intended. On rear ports, position 1 needs to map to position 1 on the peer. Position 100 needs to map to position 100 on the peer.
adam commented 2025-12-29 21:44:54 +01:00
Author
Owner
Copy Link

@cazure-n00b commented on GitHub (Aug 27, 2025):

  • device#2, rear port 7 >> device#3 rear port 17

Lets look at this from a fiber standpoint. How does strand 7 on one end magically change to strand 17 on the other end?

This is working as intended. On rear ports, position 1 needs to map to position 1 on the peer. Position 100 needs to map to position 100 on the peer.

I don't understand what you mean here. We're not talking fiber, we're talking the connection between ports on different patchpanels.

We're dealing with a specific setup here where we have a 19" rack with 24 UTP front ports, which are connected to rear ports. These rearports are connected to smaller localized patch panels which have 8 ports in total.

These 19" patchpanels inside a 19" rack are divided over these smaller patch panels.

So, in this case we have 1-24 in a patchpanel.
Where 1-8 are connected through rearport to rearport with 1-8 on the 1st smaller patchpanel.
Then 9-16 which are connected rearport to rearport with 1-8 on the 2nd smaller patchpanel.
Then 17-24 which are connected rearport to rearport with 1-8 on the 3rd smaller patchpanel.

See image attached

Image
@cazure-n00b commented on GitHub (Aug 27, 2025): > > * device#2, rear port 7 >> device#3 rear port 17 > > Lets look at this from a fiber standpoint. How does strand 7 on one end magically change to strand 17 on the other end? > > This is working as intended. On rear ports, position 1 needs to map to position 1 on the peer. Position 100 needs to map to position 100 on the peer. I don't understand what you mean here. We're not talking fiber, we're talking the connection between ports on different patchpanels. We're dealing with a specific setup here where we have a 19" rack with 24 UTP front ports, which are connected to rear ports. These rearports are connected to smaller localized patch panels which have 8 ports in total. These 19" patchpanels inside a 19" rack are divided over these smaller patch panels. So, in this case we have 1-24 in a patchpanel. Where 1-8 are connected through rearport to rearport with 1-8 on the 1st smaller patchpanel. Then 9-16 which are connected rearport to rearport with 1-8 on the 2nd smaller patchpanel. Then 17-24 which are connected rearport to rearport with 1-8 on the 3rd smaller patchpanel. See image attached <img width="1457" height="455" alt="Image" src="https://github.com/user-attachments/assets/ee9ead27-be79-4e9d-8c97-d71731f7058a" />
adam commented 2025-12-29 21:44:54 +01:00
Author
Owner
Copy Link

@cazure-n00b commented on GitHub (Aug 27, 2025):

Also, I did the following: "On rear ports, position 1 needs to map to position 1 on the peer."

This won't work either. When all ports (front & rear) are set on the same position number, it will still not go completely through.
I do think that it seems like a bug and do not see the logic of the fiber standpoint in this particular case.

@cazure-n00b commented on GitHub (Aug 27, 2025): Also, I did the following: _"On rear ports, position 1 needs to map to position 1 on the peer."_ This won't work either. When all ports (front & rear) are set on the same position number, it will still not go completely through. I do think that it seems like a bug and do not see the logic of the fiber standpoint in this particular case.
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 netbox
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#11409
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?