Add cable trace button to front/rear ports

[runeka]

Proposed Functionality

View trace on patchcable between patchpanels.

Use Case

When patching through multiple patch panels it is tricky to view the end device using the patch. Would it be possible to add a link to the trace of the entire path in the cable view?

[MarcHagen]

Just to be shure, the little blue stripe is a button. It leads to dcim/interfaces/<id>/trace/
Is this what you mean?

Just to clarify i found out about that because i was busy transforming Font Awesome to Material Design Icons.

There is a icon fa fa-share-alt in the button but due to a error of fault it's not displaying. Not even on there own website: https://fontawesome.com/v4.7.0/icons/ AdblockPlus yey...

[runeka]

Hi

That is from the device interface view I guess.
I mean from the cable view like: http://netbox.example.com/dcim/cables/201/ You can see where it is terminated, but not the end point interfaces and the entire trace. So if this patch cable is between two patch panels you will need to click through the panel path to view the path.

[MarcHagen]

Oke fair point we have indeed a trace per interface, not for a cable.
But i think it's the same page to view the trace, only there is missing a quick link to that page?
Just trying to help out :)

[DanSheps]

@runeka You can't do this with a cable, as a cable is a link between two devices. It looks like "front ports" and "rear ports" needs a cable trace like feature as well, but I am not sure how feasible that is to do. Couple questions for that:

1. Where do you stop the trace? At the last passthrough port? At the interface? At the last passthrough port of the same type?
2. Which direction do you go? If you click on "Front Port" do you go to the rear port first then travel along the rear port cable? What about clicking on the rear port trace?
3. Why do you need this?

The termination A and termination B is the full path for a "cable", there is nothing further to trace.

[runeka]

A cable is not necessary a link between two devices, and that is the point. When a cable is a link between two front ports it is confusing to see the device interfaces. Adding a quick link to the trace between the device interfaces, that the cable is part of would be perfect.
The reason I am asking for it is that I have some long patches like: DeviceInterface - Cable#144 - FrontPort - RearPorts - FrontPort - Cable#145 - FrontPort - RearPorts - FrontPort - Cable#146 - DeviceInterface. When searching in Netbox for cable that is physically labeled Cable#145 it is hard to see what device is using the cable and if it is in use or not. Cable#145 is connected to FrontPorts and seems to be in use, but might not be.
In my case I have a MeetMeRoom with a lot of labeled patch cables between FrontPorts, But there are no interfaces in that rack or room showing the trace. A trace on FrontPorts like there is on DeviceInterfaces would also do the trick.

[tb-killa]

From my point of view I agree @runeka here.
We also have several hops about patch fields in many places.

What is actually requested here is an extension of the "Trace" view with the possibility to perform a search or input with a jump into the trace.
Say: I have e.g. the Device XYZ with the interface XYZ and see the Trace view always in the complete path (if available!).
For example, if I am in the cable view, I can also click on a link and jump to the trace view and see the complete path (if available!).
At the first the interface is passed as search, at the second the cable-ID or the label.

Am I right here with my guess @runeka ??

[runeka]

You are right. The "Trace" button should be available for all FrontPorts and cables in the path.

[DanSheps]

The problem with this is how do you know when to stop? Do you stop at the first front port? Do you just go until you can't go any further? Do you let the user choose?

This could be potentially incredibly burdensome on the server when trying to calculate the interface graph.

[tb-killa]

See my Post above, from my point of view it should display the same results as given by the search of an interface as start point. Maybe this could be some sort of modal box who use ajax request to generate the result display.

Maybe we could do something with html5 (svg) if the Rack Rendering is implemented to bring the calculation of complete path on client side themselve.

[runeka]

I agree, the exact same view as when clicking the trace on an interface. I thought this was an easy task, but I am not a software engineer.

[DanSheps]

You guys still are not answering, how do you determine the stop point? If you are not taking interfaces into account, how do you know when to stop? What if you loop a connection together and create a ring, you could have an infinite loop so there has to be protection in there.

[tjdavis3]

It stops when it hits an interface.

[DanSheps]

@tjdavis3 There might not always be an interface, that is what I am saying. With a interface, there is a clear defined end, because an interface cannot loop onto itself, you cannot have weird splitting networks either. IF you are just using front ports and rear ports, you can do all sorts of crazy things.

[tb-killa]

@DanSheps
After review the closed issue there is a implementation for this type included and closed: Fixes #2721: Detect loops when tracing front/rear ports.

We need a simple test but this would help to close one of your arguments.

[tvberlin]

@jeremystretch thanks for implementing!