Cable profiles and connector/position mapping #11826

New Issue

adam · 2025-12-29T21:50:19+01:00

adam commented

2025-12-29 21:50:19 +01:00

Originally created by @jeremystretch on GitHub (Nov 11, 2025).

Originally assigned to: @jeremystretch on GitHub.

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

Originally created by @jeremystretch on GitHub (Nov 11, 2025). Originally assigned to: @jeremystretch on GitHub. ### 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. ```python 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: ```python 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

adam added the status: accepted type: feature netbox complexity: high labels 2025-12-29 21:50:19 +01:00

adam closed this issue

2025-12-29 21:50:20 +01:00

adam commented

2025-12-29 21:50:20 +01:00

@NSpikings-dB commented on GitHub (Nov 12, 2025):

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.

@NSpikings-dB commented on GitHub (Nov 12, 2025): 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. <img width="988" height="779" alt="Image" src="https://github.com/user-attachments/assets/8b55549b-c81c-4de6-b691-47b20953226a" /> 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.

adam commented

2025-12-29 21:50:21 +01:00

@jeremystretch commented on GitHub (Nov 14, 2025):

@NSpikings-dB the intent of this FR is to better model cables at the interface level; specifically breakout and "shuffle" cables which split fiber pairs in a predictable manner. The use case you cite seems to fall more in the territory of fiber plant management, which is a different topic entirely.

@jeremystretch commented on GitHub (Nov 14, 2025): @NSpikings-dB the intent of this FR is to better model cables at the interface level; specifically breakout and "shuffle" cables which split fiber pairs in a predictable manner. The use case you cite seems to fall more in the territory of fiber plant management, which is a different topic entirely.

adam commented

2025-12-29 21:50:21 +01:00

@sleepinggenius2 commented on GitHub (Nov 17, 2025):

I think being able to customize the profiles would really help for a more future-proof solution. We frequently seem to run into proprietary cable configurations from different vendors and being able to model them accurately in NetBox would be extremely helpful. While I can't think of a situation where we have a mix of simplex and duplex terminated cables as demonstrated above, I have seen a variety of different configurations just within MPO cables. For example, our ROADM gear uses MPO-12 and MPO-24 cables, but it uses the middle fibers instead of the outside fibers, like MLR optics do, and thus it cannot use an MPO-8 cable. It also has interfaces to address each fiber, instead of each "lane" created by a pair of fibers, as we see on the MLR side. There is one particular cable that has an MPO-24 connector (16 positions used) on one end with grouped TX and RX that breaks out to 2 x MPO-12 connectors (8 positions used in each) with interleaved TX and RX on the other. This would also be incredibly helpful for documenting console cables, as we have a number of custom ones that we have to create to account for different vendors' specific pinouts when connecting devices to our console servers. By far the most common cable type for us is going to be LC/UPC duplex to 2 x SC/APC simplex for connecting to an OSP fiber panel, so one way or another I would certainly push for that to be available out of the gate.

You mentioned better modeling cables at the interface level, but it's not clear to me how connections get mapped to breakout interfaces in this proposal, especially when sometimes its a single strand per interface or a pair of strands per interface, and the cable would typically terminate on one interface, but each connection/lane on a different interface. For example, Optics0/0/0/0 (QSFP+ (40GE) or QSFP28 (100GE) interface type) for the cable termination and TenGigE0/0/0/0/0-3 for each of the 10GBASE-LR interfaces for the TX/RX fiber pair lane terminations for an ONS-QSFP-4X10-MLR or QSFP-4X10G-LR-S optic in a Cisco NCS device.

@sleepinggenius2 commented on GitHub (Nov 17, 2025): I think being able to customize the profiles would really help for a more future-proof solution. We frequently seem to run into proprietary cable configurations from different vendors and being able to model them accurately in NetBox would be extremely helpful. While I can't think of a situation where we have a mix of simplex and duplex terminated cables as demonstrated above, I have seen a variety of different configurations just within MPO cables. For example, our ROADM gear uses MPO-12 and MPO-24 cables, but it uses the middle fibers instead of the outside fibers, like MLR optics do, and thus it cannot use an MPO-8 cable. It also has interfaces to address each fiber, instead of each "lane" created by a pair of fibers, as we see on the MLR side. There is one particular cable that has an MPO-24 connector (16 positions used) on one end with grouped TX and RX that breaks out to 2 x MPO-12 connectors (8 positions used in each) with interleaved TX and RX on the other. This would also be incredibly helpful for documenting console cables, as we have a number of custom ones that we have to create to account for different vendors' specific pinouts when connecting devices to our console servers. By far the most common cable type for us is going to be LC/UPC duplex to 2 x SC/APC simplex for connecting to an OSP fiber panel, so one way or another I would certainly push for that to be available out of the gate. You mentioned better modeling cables at the interface level, but it's not clear to me how connections get mapped to breakout interfaces in this proposal, especially when sometimes its a single strand per interface or a pair of strands per interface, and the cable would typically terminate on one interface, but each connection/lane on a different interface. For example, Optics0/0/0/0 (QSFP+ (40GE) or QSFP28 (100GE) interface type) for the cable termination and TenGigE0/0/0/0/0-3 for each of the 10GBASE-LR interfaces for the TX/RX fiber pair lane terminations for an ONS-QSFP-4X10-MLR or QSFP-4X10G-LR-S optic in a Cisco NCS device.

adam referenced this issue

2025-12-29 23:21:19 +01:00

[PR #11976] [MERGED] Closes #11826: RSS feed widget #13879

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#11826