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

Trace Splits 1:1 connections using front-port to front-port jump on same patch panel #5629

New Issue
Closed
opened 2025-12-29 19:30:17 +01:00 by adam · 4 comments
adam commented 2025-12-29 19:30:17 +01:00
Owner
Copy Link

Originally created by @mlongo4290 on GitHub (Nov 8, 2021).

NetBox version

v3.0.8

Python version

3.8

Steps to Reproduce

  1. Configure devices representing the following connections:
    interface<-> cable <-> front port (patch panel 1) <-> rear port (patch panel 1) <-> cable <-> rear port 1 (patch panel 2) <-> front port 1 (patch panel 2) <-> cable <-> front port 2 (patch panel 2) <-> rear port 2 (patch panel 2) <-> cable <-> rear port (patch panel 3) <-> front port (patch panel 3) <-> cable <-> interface

In my case I have only single mode fiber optic connections from an interface on a server room through two network racks.
the first patch panel is in the server room, the second is in the first rack and the last one plus the ending device are in the third rack.
This is similar to Issue #4548 but with a new jump on the front face of the second patch panel.
I'd expect a trace of the connection from either of the Interfaces.

Expected Behavior

The full connection is traced from end to end.

Observed Behavior

The trace is not complete, it stop on the rear port of the second patch panel.
immagine

A ‘Trace Split’ error is produced after the first cable, but the list only contains a single option for continuing the trace.
immagine

Clicking the available link for trace gives no result
immagine

Cable connection between the two front ports on the second patch panel is correctly shown
immagine

Originally created by @mlongo4290 on GitHub (Nov 8, 2021). ### NetBox version v3.0.8 ### Python version 3.8 ### Steps to Reproduce 1. Configure devices representing the following connections: interface<-> cable <-> front port (patch panel 1) <-> rear port (patch panel 1) <-> cable <-> rear port 1 (patch panel 2) <-> front port 1 (patch panel 2) <-> cable <-> front port 2 (patch panel 2) <-> rear port 2 (patch panel 2) <-> cable <-> rear port (patch panel 3) <-> front port (patch panel 3) <-> cable <-> interface In my case I have only single mode fiber optic connections from an interface on a server room through two network racks. the first patch panel is in the server room, the second is in the first rack and the last one plus the ending device are in the third rack. This is similar to Issue #4548 but with a new jump on the front face of the second patch panel. I'd expect a trace of the connection from either of the Interfaces. ### Expected Behavior The full connection is traced from end to end. ### Observed Behavior The trace is not complete, it stop on the rear port of the second patch panel. ![immagine](https://user-images.githubusercontent.com/7711073/140791060-46bac715-437e-44e2-8ed1-22d93647a0fe.png) A ‘Trace Split’ error is produced after the first cable, but the list only contains a single option for continuing the trace. ![immagine](https://user-images.githubusercontent.com/7711073/140791111-d87706b5-c638-4fae-8b9b-07c8da18c877.png) Clicking the available link for trace gives no result ![immagine](https://user-images.githubusercontent.com/7711073/140791172-934e8794-06ad-4106-aa95-8e1a39b29112.png) Cable connection between the two front ports on the second patch panel is correctly shown ![immagine](https://user-images.githubusercontent.com/7711073/140791582-a119fbd1-90c1-4c66-b7b4-9ee707e95f23.png)
adam added the type: bug label 2025-12-29 19:30:17 +01:00
adam closed this issue 2025-12-29 19:30:17 +01:00
adam commented 2025-12-29 19:30:18 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 9, 2021):

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 (Nov 9, 2021): 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.
adam commented 2025-12-29 19:30:18 +01:00
Author
Owner
Copy Link

@mlongo4290 commented on GitHub (Nov 10, 2021):

Hi @jeremystretch and thank you for the feedback,
Actually I followed your suggestion and tried to replicate my setup on a clean install with no data and it worked.
However my production server has no configuration changes, only more data. I'll investigate more and let you know.
Just in case anyone wants to try this case, these are the steps to replicate my configuration:

  1. create site SITE A
  2. create device role SWITCH
  3. create device role PATCH PANEL
  4. create manufacturer SWITCH MANUFACTURER
  5. create manufacturer PATCH PANLE MANUFACTURER
  6. create device type
    • manufacturer: SWITCH MANUFACTURER
    • model: SWITCH MODEL
    • height: 1
  7. add interface to device type:
    • name: int1
    • type: SFP+ (10GE)
  8. create device type
    • manufacturer: PATCH PANEL MANUFACTURER
    • model: PATCH PANEL MODEL
    • height: 1
  9. add 2 rear ports to device type:
    • name: rear[1-2]
    • type: LC
    • positions: 1
  10. add 2 front ports to device type:
    • name: front[1-2]
    • type: LC
    • rear ports: [rear1:1, rear2:1]
  11. create device SWITCH A:
    • device role: SWITCH
    • device type: SWITCH MODEL
    • site: SITE A
  12. create device SWITCH B:
    • device role: SWITCH
    • device type: SWITCH MODEL
    • site: SITE A
  13. create devices PATCH PANEL A, PATCH PANEL B and PATCH PANEL C:
    • device role: PATCH PANEL
    • device type: PATCH PANEL MODEL
    • site: SITE A
  14. connect interface int1 of SWITCH A to front port front1 of PATCH PANEL A
  15. connect rear port rear1 of PATCH PANEL A to rear port rear1 of PATCH PANEL C
  16. connect front port front1 of PATCH PANEL C to front port front2 of PATCH PANEL C
  17. connect rear port rear2 of PATCH PANEL C to rear port rear1 of PATCH PANEL B
  18. connect interface int1 of SWITCH B to front port front1 of PATCH PANEL B

Tracing the connections is successful on the clean, empty netbox
immagine

The steps are the same on my production environment, I changed only the names of devices,port and interfaces.
I'll let you know if I find something else that can help
Thank you

@mlongo4290 commented on GitHub (Nov 10, 2021): Hi @jeremystretch and thank you for the feedback, Actually I followed your suggestion and tried to replicate my setup on a clean install with no data and it worked. However my production server has no configuration changes, only more data. I'll investigate more and let you know. Just in case anyone wants to try this case, these are the steps to replicate my configuration: 1. create site SITE A 2. create device role SWITCH 3. create device role PATCH PANEL 4. create manufacturer SWITCH MANUFACTURER 5. create manufacturer PATCH PANLE MANUFACTURER 6. create device type - manufacturer: SWITCH MANUFACTURER - model: SWITCH MODEL - height: 1 7. add interface to device type: - name: int1 - type: SFP+ (10GE) 8. create device type - manufacturer: PATCH PANEL MANUFACTURER - model: PATCH PANEL MODEL - height: 1 9. add 2 rear ports to device type: - name: rear[1-2] - type: LC - positions: 1 10. add 2 front ports to device type: - name: front[1-2] - type: LC - rear ports: [rear1:1, rear2:1] 11. create device SWITCH A: - device role: SWITCH - device type: SWITCH MODEL - site: SITE A 12. create device SWITCH B: - device role: SWITCH - device type: SWITCH MODEL - site: SITE A 13. create devices PATCH PANEL A, PATCH PANEL B and PATCH PANEL C: - device role: PATCH PANEL - device type: PATCH PANEL MODEL - site: SITE A 14. connect interface **int1** of **SWITCH A** to front port **front1** of **PATCH PANEL A** 15. connect rear port **rear1** of **PATCH PANEL A** to rear port **rear1** of **PATCH PANEL C** 16. connect front port **front1** of **PATCH PANEL C** to front port **front2** of **PATCH PANEL C** 17. connect rear port **rear2** of **PATCH PANEL C** to rear port **rear1** of **PATCH PANEL B** 18. connect interface **int1** of **SWITCH B** to front port **front1** of **PATCH PANEL B** Tracing the connections is successful on the clean, empty netbox ![immagine](https://user-images.githubusercontent.com/7711073/141076479-aa2f65b8-a02a-4906-bfae-5fd25b3e0e1b.png) The steps are the same on my production environment, I changed only the names of devices,port and interfaces. I'll let you know if I find something else that can help Thank you
adam commented 2025-12-29 19:30:18 +01:00
Author
Owner
Copy Link

@mlongo4290 commented on GitHub (Nov 16, 2021):

Hi,
I've completely deleted all the cables and recreated the connection chain from end-to-end interfaces and now it works,
probably I've done some edit during the data entry and broke something.
The issue can be closed since it's sufficient to re-create the cables to solve the problem.
Sorry if I made you losing time and thank you again!

@mlongo4290 commented on GitHub (Nov 16, 2021): Hi, I've completely deleted all the cables and recreated the connection chain from end-to-end interfaces and now it works, probably I've done some edit during the data entry and broke something. The issue can be closed since it's sufficient to re-create the cables to solve the problem. Sorry if I made you losing time and thank you again!
adam commented 2025-12-29 19:30:19 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 16, 2021):

No worries, thanks for following up!

@jeremystretch commented on GitHub (Nov 16, 2021): No worries, thanks for following up!
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 type: bug
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#5629
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?