search

netbox-community / netbox-topology-views

A netbox plugin that draws topology views
Apache License 2.0
765 stars 65 forks source link

Display Critical Cable Path for Logical Connection #405

Open theherox opened 1 year ago

theherox commented 1 year ago

NetBox version

3.6.3

Topology Views version

3.8.0

Feature type

New functionality

Proposed functionality

Add an option to the Filters view to only display cables in the Critical Cable Path between devices with a Logical Connection. I would define a Critical Cable Path as the cables that are active in a Logical Connection between two Devices. Most importantly, the Critical Path excludes all other cables connected to a Device that are not used to form the Logical Connection.

image

Use case

Viewing a topology with many patch panels quickly gets cluttered with an excess number of Rear Port to Rear Port connections, many of which are unused.

A prime example is the Rear Port to Rear Port connections between two patch panels. A 48 port patch panel with all Rear Ports connected results in 47 extra links per patch panel which must be rendered when trying to view a simple connection through a patch panel. This results in a messy topology and slow loading times, especially when there are many patch panels in the topology.

Using the Critical Cable Path, the topology in the image below would only show a single cable between each device and omit the extra cables with are not involved in the logical connection between the power device on the left and the switch on the top. The extra cables between the Patch Panels would be omitted, as would the extra connections between the switch and its neighboring patch panel. This would result in a cleaner and more useable topology and also render faster.

image

External dependencies

I believe this could be achieved without adding any additonal dependencies.

andrei-korshikov commented 1 year ago

Yep. When there are dozens of 48-port patch panels, things become ugly. I would like to have ability to somehow group all these parallel links and display them as one (independently on Logical Connection presence).

I think this feature request is quite similar to https://github.com/mattieserver/netbox-topology-views/issues/122

theherox commented 1 year ago

Yep. When there are dozens of 48-port patch panels, things become ugly. I would like to have ability to somehow group all these parallel links and display them as one (independently on Logical Connection presence).

I think this feature request is quite similar to #122

I read that request and debated combining this with it, but I thought it was a different enough ask that it made sense to request it separately. I believe #122 is written more with the intent of consolidating multiple links that would ultimately be redundant Logical Connections, but my request is more geared towards ignoring unused connections. I'd love to see both solved, but I suspect the logic required will be slightly different for the two issues.

andrei-korshikov commented 1 year ago

Thank you for the clarification!

So, there are three types of links in question:

By the way, what if you configure copper patch panel as fiber one? I mean with one rear port? I would personally prefer to document patch panels interconnection not as 48 distinct cables, but as one cable assembly (which in turn consists of 48 UTP CAT5e cables). So we could mimic fiber optics, with single rear port with 48 positions. In fiber optics (I'm talking about that lengthy cables between buildings, or cities, not about data center patch-cords) it is crucial to document not only general type (for ex. Single Mode, or OM3, or FDDI), but more precise "model" of cable, or at least number of strands. I see no differences between fiber strands and UTP "strands" in this sense.

Anyway, cable type documentation in NetBox is not as precise as device type. I mean, in NetBox we have for example "CAT5e" cable. But in real world we have cable manufacturer name and this very cable partnumber. That's like the difference between "48 port access switch" and "Cisco WS-C2960+48TC-L". So, I create Custom Field Choice "Cable model" with appropriate fiber cable models and UTP cable "assembly" variants (for example, UTP CAT5e x 48), then I create Custom Field "Model" with Object Types "dcim | cable", Type "Selection" and Choise Set "Cable model". Now my patch panels can have single 48-position rear ports. If you want to set status on front port (for example set front port as "failed" in case of UTP cable or fiber strand failure), you can create another Custom Field.

theherox commented 1 year ago

@andrei-korshikov First of all, thank you so much for your thoughtful response. Happy to provide clarification! I think you're spot on with your description of the link types in question.

By the way, what if you configure copper patch panel as fiber one? I mean with one rear port? I would personally prefer to document patch panels interconnection not as 48 distinct cables, but as one cable assembly (which in turn consists of 48 UTP CAT5e cables). So we could mimic fiber optics, with single rear port with 48 positions. In fiber optics (I'm talking about that lengthy cables between buildings, or cities, not about data center patch-cords) it is crucial to document not only general type (for ex. Single Mode, or OM3, or FDDI), but more precise "model" of cable, or at least number of strands. I see no differences between fiber strands and UTP "strands" in this sense.

Hmmm... I hadn't considered modeling copper that way before! I've been using a multi-position single rear port for MPO fiber patch panels because it matches the physical topology but that feature was released long after I started documenting copper patch panels. I definitely see a use case for doing it this way.

I think this approach would work exceptionally well when all of the patch panels are mapped 1:1, but some translation would be required in environments where a single patch panel may be split between multiple remote devices. If a 24 port patch panel had ports 1-12 run to one panel and ports 13-24 run to another, the positions on each of the Rear Ports would be :1-12 for both, even though we're physically talking about ports 13-24. Depending on the physical layout of the patch panel, the split may even be 1-6,13-18 to one and 7-12,19-24 to the other which adds to the confusion. That's not to say it's not possible but definitely prone to human error and makes templating patch panels with pre-mapped front-to-rear ports more difficult depending on the environment.

With that in mind, would a user of the product want to change their entire configuration simply to have it display differently in the topology view? I see pros and cons to each method and personally it's something I have to roll around in my head for a bit and do some experimentation to see how easily I could make the modifications in bulk within my environment.

Finally, changing the Rear Port configuration for a patch panel doesn't address the additional cables connected to a switch that we're not interested in when considering the "Critical Cable Path" between a pair of devices. Using the example image above, you would still see a number of cables between the switch and patch panel, even though we only care about the path between the power device and the switch. Ideally, these extra cables would be omitted because they're not part of a logical connection between filtered devices.

dreng commented 1 year ago

I'm afraid, I don't get the point here. Why don't you just omit the patch panels in your example? That should show you just the other two devices, connected with a yellow dotted line.

theherox commented 1 year ago

I could omit the patch panels, but that doesn't help if I want to generate a topology view that includes the patch panel information. If I'm planning a deployment and I want to hand off a topology drawing to the on-site engineer who would be physically connecting the equipment, it would be nice to cut out the extra noise.

Another example would be if I'm asked for a topology of X, Y, and Z systems and all of their associated components, I could use a critical path feature to quickly show a simplified view of the connections instead of including all the additonal parallel links that aren't associated with those systems. In most cases, this would eliminate the need for me to export the topology to something like draw.io to clean up the view before handing it off.

For now, I'm half way through implementing the solution proposed by @andrei-korshikov using a single backhaul connection between copper patch panels to simplify the topology, but it still doesn't address the issue of additonal parallel links between a patch panel and a switch so I still think there's value in this feature.

dreng commented 1 year ago

Thank you for the clarification. I think, I get your point now.

If I understand correctly, you'd like to have two features:

  1. You'd like to combine all connections between two devices. This has been requested before in #122.
  2. You'd like to show only devices that are involved in logical connections. To put it another way: You'd like to show only complete traceable paths (as they are defined to have interface endpoints, which, in fact, are logical connections here).

How would you expect the workflow to be?

  1. Take all filtered devices, perform a trace for every device and add endpoints, if necessary.
  2. Take all filtered devices, check for logical connections between them and add devices in the cable path, if necessary.
  3. Take alle filtered devices, check for logical connections, check if the device filter contains all devices in the cable path and show only paths for which this is the case.
  4. Something else.
andrei-korshikov commented 1 year ago

Take all filtered devices, perform a trace for every device and add endpoints, if necessary.

Do I understand it correctly, this option is like "show me all the stuff (including cables, patch panels, and active devices) between filtered devices"? If so, it may sounds attractive, but it is infeasible. Imagine the network with redundant physical connections. Interim devices (which interconnect filtered devices) may be interconnected physically, but not logically. VLAN pruning, routing policies, MPLS RSVP-TE tunnels and so on. So, if we want "map of service propagation" (like "show me all devices involved into VLAN A" or "show me the traffic path from client to server"), I think using tags on all interim cables, patch panels and network devices is the only way.

a topology of X, Y, and Z systems and all of their associated components

I mean "associated components" can't be determined by physical connections only, but by combination of physical connectivity and internal (logical) device configuration. So, in my opinion, tags (or may be custom fields) are inevitable.

theherox commented 1 year ago
  1. You'd like to combine all connections between two devices. This has been requested before in Combine redundant connections #122.

No, I'd like to preserve the physical connections between devices. If I have a LAG comprised of two physical pathways, I'd still like to display both physical cable paths. This is a good way to visualize that there are redundant physical connections in place, even if they do ultimately result in one logical link.

  1. You'd like to show only devices that are involved in logical connections. To put it another way: You'd like to show only complete traceable paths (as they are defined to have interface endpoints, which, in fact, are logical connections here).

Yes, almost exactly but I'm more concerned about cables than devices. To clarify further, I'd like to omit any cables that are not contained within the traceable path. I believe the filtering of the devices should be left to the user.

How would you expect the workflow to be?

  1. Take all filtered devices, perform a trace for every device and add endpoints, if necessary.
  2. Take all filtered devices, check for logical connections between them and add devices in the cable path, if necessary.
  3. Take alle filtered devices, check for logical connections, check if the device filter contains all devices in the cable path and show only paths for which this is the case.
  4. Something else.

Point 2 would be awesome for a future revision, but I believe Point 3 is closest to what I'm currently envisioning. Given a filtered set of devices, show only the cables (and their associated devices currently contained by the filter) that are actively involved in a logical connection.

Here's what I would propose: Take all filtered devices, check for logical connections > omit any cables not actively participating in a logical connection between filtered devices.