starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-13 22:03:32 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Create CablePaths for FrontPorts and RearPorts #8791

New Issue
Closed
opened 2025-12-29 20:41:14 +01:00 by adam · 1 comment
adam commented 2025-12-29 20:41:14 +01:00
Owner
Copy Link

Originally created by @cpmills1975 on GitHub (Nov 1, 2023).

NetBox version

v3.6.4

Feature type

Data model extension

Proposed functionality

It would be helpful if CablePaths could be created for all paths through cabling infrastructure regardless of whether front ports are terminated to an Interface (or presumably a Console or ConsoleServer port).

Passive FrontPorts associated with RearPorts, that are connected to other RearPorts (and perhaps onwards through patch cables and further 'passive' infrastructure) should produce CablePaths that can be queried and cable traces produced even when neither end is connected to an interface.

Use case

Structured cabling (copper or fibre plant) often exists even though it may not currently be used, but it is currently difficult to see available end-to-end routes through existing plant without connecting an interface to at least one end of the cable run.

Take for example a fibre patch panel with six pairs of LC connectors on the front connected to a single MPO12 port on the rear. If this rear port is connected to a similar rear port on another panel with a cable, it could be said that all six pairs have a possible CablePath between the the two panels, but as far as I can tell, CablePath objects do not get created until such time as an Interface is connected to the ports.

In our environment, we engage with a third party cabling provider to deliver structured cabling routes between data centres. For a given project, we may request more capacity than is strictly needed and the provider will deliver us multiple cable paths between origin and destination panels via a route of their choice and potentially a number of intermediate panels and we will then record these connections in our NetBox instance. At present, we can only visualise/trace cable routes when we have an interface connected to all of the ports. We cannot trace routes for ports that are not connected to interfaces even though a path between origin and destination ports on panels physically exist.

Database changes

None.

External dependencies

None

Originally created by @cpmills1975 on GitHub (Nov 1, 2023). ### NetBox version v3.6.4 ### Feature type Data model extension ### Proposed functionality It would be helpful if CablePaths could be created for all paths through cabling infrastructure regardless of whether front ports are terminated to an Interface (or presumably a Console or ConsoleServer port). Passive FrontPorts associated with RearPorts, that are connected to other RearPorts (and perhaps onwards through patch cables and further 'passive' infrastructure) should produce CablePaths that can be queried and cable traces produced even when neither end is connected to an interface. ### Use case Structured cabling (copper or fibre plant) often exists even though it may not currently be used, but it is currently difficult to see available end-to-end routes through existing plant without connecting an interface to at least one end of the cable run. Take for example a fibre patch panel with six pairs of LC connectors on the front connected to a single MPO12 port on the rear. If this rear port is connected to a similar rear port on another panel with a cable, it could be said that all six pairs have a possible CablePath between the the two panels, but as far as I can tell, CablePath objects do not get created until such time as an Interface is connected to the ports. In our environment, we engage with a third party cabling provider to deliver structured cabling routes between data centres. For a given project, we may request more capacity than is strictly needed and the provider will deliver us multiple cable paths between origin and destination panels via a route of their choice and potentially a number of intermediate panels and we will then record these connections in our NetBox instance. At present, we can only visualise/trace cable routes when we have an interface connected to all of the ports. We cannot trace routes for ports that are not connected to interfaces even though a path between origin and destination ports on panels physically exist. ### Database changes None. ### External dependencies None
adam added the type: feature label 2025-12-29 20:41:14 +01:00
adam closed this issue 2025-12-29 20:41:15 +01:00
adam commented 2025-12-29 20:41:15 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 3, 2023):

This idea has been discussed in previous issues, however no actual implementation has ever been proposed to my knowledge. There are myriad challenges to what you are describing. You (or anyone else) are certainly welcome to experiment with a potential solution and present it for discussion, however we're not able to accept any feature requests for this functionality that don't include at least a high-level implementation strategy.

@jeremystretch commented on GitHub (Nov 3, 2023): This idea has been discussed in previous issues, however no actual implementation has ever been proposed to my knowledge. There are myriad challenges to what you are describing. You (or anyone else) are certainly welcome to experiment with a potential solution and present it for discussion, however we're not able to accept any feature requests for this functionality that don't include at least a high-level implementation strategy.
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: feature
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#8791
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?