Cable profiles and connector/position mapping

[jeremystretch]

NetBox version

v4.4.6

Feature type

Data model extension

Proposed functionality

This FR supersedes #20562 and expands upon the core idea it proposes. In conjunction with FR #20564, its goal is to support modeling complex cabling in NetBox. There are two components in play here: cable profiles and connector/position tracking for cable terminations.

Cable termination connector & position

A cable termination represents the association of one end of a cable (A or B) with a particular object (e.g. an interface or console port). This FR would add two new pieces of data to the CableTermination model, to better represent real-world connections:

• Connector grouping: A numeric ID grouping cable terminations delivered via a common connector. For example, a 12-strand MPO fiber connector typically delivers up to six discrete connections (one fiber pair per connection).
• Connector position: The position of a termination within a connector relative to its peers. Continuing the MPO example above, available positions would be 1 through 6. This enables us to correlate a particular "lane" on the cable between two ends.

Cable profile

A cable profile holds the connector/position mapping between A- and B-side terminations. For example, a profile representing a 4x10GE breakout cable would look like this:

A connector	A position	B connector	B position
1	1	1	1
1	2	2	1
1	3	3	1
1	4	4	1

(Note that this concept of mapping positions is intentionally very similar to the approach proposed in FR #20564.)

A profile would be assigned to a cable via a ChoiceField on the Cable model. The current intent is for profiles to be declared statically and live in-memory, rather than being customizable: It is expected that a limited number of such real-world profiles exist. However, that may be reconsidered if additional flexibility is needed.

Use case

While NetBox is capable of modeling complex cabling (cables which provide more than two endpoints) to a limited degree, it does not possess sufficient context to accurately trace these connections end-to-end. By associating explicit connector & positioning details with each termination, as well as a mapping profile with the cable itself, NetBox will be able to trace end-to-end paths across complex cables with precision.

Database changes

On the dcim.Cable model, introduce a new optional CharField to associate the cable profile. Cables without a profile assigned will not support complex tracing.

class Cable(...):
    profile = models.CharField(
        choices=CableProfileChoices,
        blank=True,
        null=True,
    )
)

One the dcim.CableTermination model, add two integer fields to track connector and position:

class CableTermination(...):
    connector = models.PositiveSmallIntegerField()
    position = models.PositiveSmallIntegerField()

(We'll either make these fields nullable or default to 1; whichever is found to work best once the implementation is fleshed out.)

External dependencies

N/A

[NSpikings-dB]

This proposal looks good to me. Making the mapping customisable, as you’ve mentioned, will be incredibly useful and far more future-proof.

In an example of one of my use cases, it’s not uncommon for us to have a mix of simplex and duplex connectors on a single multicore cable. The exact arrangement and quantities of simplex vs duplex connectors vary on a case by case basis.

In an example below with just 12 cores (simplex in orange and duplex in blue), you can see the level of variation that could easily and quickly be encountered.

As this can be extrapolated to cables with an even higher core count, allowing users to create their own mappings flexibly would allow users to model their facility and infrastructure more accurately.

Customisability would also avoid the risk of missing particular breakout cable types that might not be initially captured, such as MMC-24 to 3x MTP-8, and of course, custom cable splices.