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

Trace without interface #5900

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

Originally created by @PaulR282 on GitHub (Jan 7, 2022).

NetBox version

v3.1.4

Feature type

Change to existing functionality

Proposed functionality

Currently, you can only trace cables when at least one interface is connected to one side. It would be nice to be able to trace without an interface.

Use case

When you have cables through multiple segments you would be able to trace those to see all the points where the cable is going through without virtual connection to e.g. a switch.

Database changes

No response

External dependencies

No response

Originally created by @PaulR282 on GitHub (Jan 7, 2022). ### NetBox version v3.1.4 ### Feature type Change to existing functionality ### Proposed functionality Currently, you can only trace cables when at least one interface is connected to one side. It would be nice to be able to trace without an interface. ### Use case When you have cables through multiple segments you would be able to trace those to see all the points where the cable is going through without virtual connection to e.g. a switch. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: featurestatus: needs ownerpending closure labels 2025-12-29 19:34:00 +01:00
adam closed this issue 2025-12-29 19:34:00 +01:00
adam commented 2025-12-29 19:34:01 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 7, 2022):

It is already possible to trace cables from both terminations (e.g. interfaces) and pass-through ports. What are you trying to do?

@jeremystretch commented on GitHub (Jan 7, 2022): It is already possible to trace cables from both terminations (e.g. interfaces) and pass-through ports. What are you trying to do?
adam commented 2025-12-29 19:34:01 +01:00
Author
Owner
Copy Link

@PaulR282 commented on GitHub (Jan 7, 2022):

I have some points where I don´t like how the cable trace is being built:

  1. I think it would be good to trace cable paths where no interface is connected
  2. (#8276) This may be fixed with the first point, but when you have something like interface -> front-port1 -> rear-port1 -> rear-port2 -> front-port2, you can´t click the trace button (when you are in the front-port overview in the device of front-port2) of front-port2
  3. -> adding changelog to contact assignments (#8275)
@PaulR282 commented on GitHub (Jan 7, 2022): I have some points where I don´t like how the cable trace is being built: 1. I think it would be good to trace cable paths where no interface is connected 2. (#8276) This may be fixed with the first point, but when you have something like interface -> front-port1 -> rear-port1 -> rear-port2 -> front-port2, you can´t click the trace button (when you are in the front-port overview in the device of front-port2) of front-port2 3. -> #8275
adam commented 2025-12-29 19:34:02 +01:00
Author
Owner
Copy Link

@emjemj commented on GitHub (Jan 18, 2022):

We have a considerable fiber plant documented in netbox and not having the ability to trace without connecting an interface to the path is a real problem. We have thousands of pairs of pre-installed cables and currently I see two options for tracing a "non-used" circuit.

  1. Go hop-by-hop on the odf front/rear ports until you get at the other end.
  2. Create a dummy tracer-device to which you can connect the front-port of the odf port you are tracing enabling the cable trace functionality to work.

Neither of these methods are practical nor elegant. We would really appreciate this functionality.

@emjemj commented on GitHub (Jan 18, 2022): We have a considerable fiber plant documented in netbox and not having the ability to trace without connecting an interface to the path is a real problem. We have thousands of pairs of pre-installed cables and currently I see two options for tracing a "non-used" circuit. 1. Go hop-by-hop on the odf front/rear ports until you get at the other end. 2. Create a dummy tracer-device to which you can connect the front-port of the odf port you are tracing enabling the cable trace functionality to work. Neither of these methods are practical nor elegant. We would really appreciate this functionality.
adam commented 2025-12-29 19:34:02 +01:00
Author
Owner
Copy Link

@xkilian commented on GitHub (Jan 21, 2022):

This is very pertinent for teams modelling fiber plant installations, as the fiber runs are typically installed and documented by one team and the connecting of devices to the fiber front-ports is done by another team. Both teams need to be able to validate paths that are not yet connected by an end device.
As a constraint, such a trace would require that the far end by a connected interface or a front port termination. IMO.

@xkilian commented on GitHub (Jan 21, 2022): This is very pertinent for teams modelling fiber plant installations, as the fiber runs are typically installed and documented by one team and the connecting of devices to the fiber front-ports is done by another team. Both teams need to be able to validate paths that are not yet connected by an end device. As a constraint, such a trace would require that the far end by a connected interface or a front port termination. IMO.
adam commented 2025-12-29 19:34:02 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 21, 2022):

Currently, we only store in the database paths which have a concrete originating point, i.e. an interface or similar terminating object. (These are stored as CablePath instances.) While it might be feasible to relax this constraint and maintain a CablePath instance for all partial paths, doing so would require a good amount of work to ensure paths are adjusted appropriately as additional cables are installed and removed.

If someone would like to own this initiative and devise an implementation, I'll happily assign it. (However, given the almost certain change to the data model, it implementation would probably need to be assigned a release milestone.)

@jeremystretch commented on GitHub (Jan 21, 2022): Currently, we only store in the database paths which have a concrete originating point, i.e. an interface or similar terminating object. (These are stored as [CablePath](https://github.com/netbox-community/netbox/blob/69eb6b11d0ee288b41d6b905e890b5995273e092/netbox/dcim/models/cables.py#L303) instances.) While it might be feasible to relax this constraint and maintain a CablePath instance for all partial paths, doing so would require a good amount of work to ensure paths are adjusted appropriately as additional cables are installed and removed. If someone would like to own this initiative and devise an implementation, I'll happily assign it. (However, given the almost certain change to the data model, it implementation would probably need to be assigned a release milestone.)
adam commented 2025-12-29 19:34:02 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Mar 23, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Mar 23, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:34:03 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Apr 22, 2022):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Apr 22, 2022): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
adam commented 2025-12-29 19:34:03 +01:00
Author
Owner
Copy Link

@fablabo commented on GitHub (Apr 25, 2022):

Last time I checked, in 2.5.13 it was possible to perform cable traces without an interface connected on either end. It's great that newer versions of netbox provide support for modeling WDM etc but it seems that this came with a huge loss.

@fablabo commented on GitHub (Apr 25, 2022): Last time I checked, in 2.5.13 it was possible to perform cable traces without an interface connected on either end. It's great that newer versions of netbox provide support for modeling WDM etc but it seems that this came with a huge loss.
adam commented 2025-12-29 19:34:03 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Jul 12, 2022):

Cable traces without interface were removed a long time ago when we had to revamp the cable model.

@DanSheps commented on GitHub (Jul 12, 2022): Cable traces without interface were removed a long time ago when we had to revamp the cable model.
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 pending closure status: needs owner 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#5900
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?