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

Split cables between multi-position rear ports and multiple front ports break tracing #7374

New Issue
Closed
opened 2025-12-29 20:22:34 +01:00 by adam · 3 comments
adam commented 2025-12-29 20:22:34 +01:00
Owner
Copy Link

Originally created by @jahknem on GitHub (Dec 16, 2022).

NetBox version

v3.4.0

Python version

3.10

Steps to Reproduce

  1. Create a Site "Testsite"
  2. Create a manufacturer "Test"
  3. Create Device Role "Testrole"
  4. Create a device type "2in1" from manufacturer "Test"
  5. Add 1 rear port with 2 positions to "2in1"
  6. Add 2 front ports which refer to 1 rear port to "2in1"
  7. Create device type "client from manufacturer "Test"
  8. Add interface to device type client
  9. Instantiate two devices of type client "Client 1" & "Client 2" at "Testsite", using "Testrole"
  10. Instantiate 3 devices of type "2in1" A, B and C at "Testsite", using "Testrole"
  11. Connect Client 1 to front port 1 of A and Client 2 to front port of C
  12. Connect rear port of A to both front ports of B using multipoint cables
  13. Connect rear port of B to rear port of C
  14. Trace from interface of Client 1 and from interface of Client 2

This essentially would look like this ascii art:

[Client 1]----|f A r|---|f B r|---|r C f|---[Client 2]
            x-|f    | \-|f    |   |    f|-x

Expected Behavior

The full trace from the interface of client 1 to the interface of client 2 should be shown. The path should not be split.

Observed Behavior

The trace complains about a split path, even though it actually isn't. The split of the multipoint cable between A and B gets combined by the front to rear port assignment inside B.
"Why is this relevant?" you may ask. For example, if I were to model a CWDM System which has multiple front ports and one rear port, but the cable attached to the rear port gets split up on a E2000 Patch Panel, and then combined again on the rear side (which may not make a difference logically, but physically it does), to then be attached to the remote CWDM System, I would not be able to trace it correctly.

Edit1: Clear up hopyfully any possible confusions about how many ports and cables are meant.

Originally created by @jahknem on GitHub (Dec 16, 2022). ### NetBox version v3.4.0 ### Python version 3.10 ### Steps to Reproduce 1. Create a Site "Testsite" 2. Create a manufacturer "Test" 3. Create Device Role "Testrole" 4. Create a device type "2in1" from manufacturer "Test" 5. Add 1 rear port with 2 positions to "2in1" 6. Add 2 front ports which refer to 1 rear port to "2in1" 7. Create device type "client from manufacturer "Test" 8. Add interface to device type client 9. Instantiate two devices of type client "Client 1" & "Client 2" at "Testsite", using "Testrole" 10. Instantiate 3 devices of type "2in1" A, B and C at "Testsite", using "Testrole" 11. Connect Client 1 to front port 1 of A and Client 2 to front port of C 12. Connect rear port of A to both front ports of B using multipoint cables 13. Connect rear port of B to rear port of C 14. Trace from interface of Client 1 and from interface of Client 2 This essentially would look like this ascii art: ``` [Client 1]----|f A r|---|f B r|---|r C f|---[Client 2] x-|f | \-|f | | f|-x ``` ### Expected Behavior The full trace from the interface of client 1 to the interface of client 2 should be shown. The path should not be split. ### Observed Behavior The trace complains about a split path, even though it actually isn't. The split of the multipoint cable between A and B gets combined by the front to rear port assignment inside B. "Why is this relevant?" you may ask. For example, if I were to model a CWDM System which has multiple front ports and one rear port, but the cable attached to the rear port gets split up on a E2000 Patch Panel, and then combined again on the rear side (which may not make a difference logically, but physically it does), to then be attached to the remote CWDM System, I would not be able to trace it correctly. Edit1: Clear up hopyfully any possible confusions about how many ports and cables are meant.
adam added the type: bug label 2025-12-29 20:22:34 +01:00
adam closed this issue 2025-12-29 20:22:34 +01:00
adam commented 2025-12-29 20:22:35 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 16, 2022):

I might be misinterpreting your instructions above, but it sounds like you're connecting multiple cables in parallel. If this is the case, then NetBox is correct detecting a split path: Once a path diverges across multiple cables (or circuits), it is considered split, even if the two paths eventually re-converge.

@jeremystretch commented on GitHub (Dec 16, 2022): I might be misinterpreting your instructions above, but it sounds like you're connecting multiple cables in parallel. If this is the case, then NetBox is correct detecting a split path: Once a path diverges across multiple cables (or circuits), it is considered split, even if the two paths eventually re-converge.
adam commented 2025-12-29 20:22:35 +01:00
Author
Owner
Copy Link

@jahknem commented on GitHub (Dec 16, 2022):

What I meant is the following: Cable 148 splits up into two ports: front 1 & front 2. These front ports are both attached to the same rear port, meaning the split ends at the rear port. I've attached a picture and added an ascii representation to the original issue
If this is considered split, then why is this a use case mentioned in the wiki under https://docs.netbox.dev/en/stable/features/devices-cabling/#cables ? And how would I go about modeling it in a way that I can trace the path, while still modeling the physical infrastructure with the physical ports?
from_client_1

@jahknem commented on GitHub (Dec 16, 2022): What I meant is the following: Cable 148 splits up into two ports: front 1 & front 2. These front ports are both attached to the same rear port, meaning the split ends at the rear port. I've attached a picture and added an ascii representation to the original issue If this is considered split, then why is this a use case mentioned in the wiki under https://docs.netbox.dev/en/stable/features/devices-cabling/#cables ? And how would I go about modeling it in a way that I can trace the path, while still modeling the physical infrastructure with the physical ports? ![from_client_1](https://user-images.githubusercontent.com/33702431/208197921-1ae93a60-eba0-4266-893a-07a293120883.svg)
adam commented 2025-12-29 20:22:35 +01:00
Author
Owner
Copy Link

@jahknem commented on GitHub (Jan 5, 2023):

Misunderstood the intended behavior. As many issues already exist which would like to change this behaviour, I will close this issue.

@jahknem commented on GitHub (Jan 5, 2023): Misunderstood the intended behavior. As many issues already exist which would like to change this behaviour, I will close this issue.
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#7374
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?