Cable lanes #1081

New Issue

MrUnknownDE · 2026-04-05T20:24:39+02:00

MrUnknownDE commented

2026-04-05 20:24:39 +02:00

Originally created by @jeremystretch on 10/13/2025

NetBox version

v4.4.2

Feature type

Data model extension

Proposed functionality

This FR introduces the concept of discrete physical "lanes" within a cable, each of which forms a connection between a pair of terminations at either end of the cable. Note that a lane is not synonymous with a fiber or copper pair within a cable. (A Cat6 UTP cable, for example, is considered to have only one lane.) This FR builds upon the general idea proposed in #20085 but takes a different approach in the modeling.

Each cable will have a single lane by default, to ensure backward compatibility with existing connections, and may support up to 256 lanes (the presumed practical maximum). The individual terminations at either end of a cable can be associated with individual lanes, and the terminations assigned to the same lane are considered connected. For example, here are four pairs of interfaces connected through a 12-strand fiber cable:

The additional context provided by the cable lane allows us to track that e.g. interface C on the left is connected only to interface G on the right, which is not possible in the current implementation.

The total number of terminations supported by a cable shall be informed by the number of lanes it has, if more than one. For example, the 12-stand cable above can be presumed to have six total lanes; it can support two more terminations on either end.

When creating a new cable with multiple lanes, terminations added at either end will be assigned lanes in the order they are listed. This may require enabling Tom-Select's drag-and-drop functionality to allow reordering interfaces within the multi-select list.

Additionally, the from_origin() method of the CablePath model will need to be extended to recognize and honor lane assignments within a cable.

It should be possible to permit many-to-one associations using cable lanes similar to what we currently support for pass-through port assignments. This would allow for modeling e.g. several breakout connections on either end of a topology comprising multiple multi-stand cables connected in series.

Use case

It's not currently possible to separate individual physical connections which share a common cable. For example, here's what we get when attempting to trace interface A in the diagram above:

The interface appears to be connected to all of the far-end interfaces, which is not correct. With the introduction and assignment of discrete lanes, each of the four interfaces can be traced to its direct peer.

(There may be some real-world use case where retaining this behavior is desired, in which case the cable should be defined as having only one lane which is shared b all terminations.)

Database changes

1. Add a `lanes` field to the Cable model

This field indicates how many lanes are supported by the cable. In theory, this could also be inferred from the cable type, but we need to be careful about maintaining backward compatibility for existing cable connections.

class Cable:
    lanes = models.PositiveSmallIntegerField(
        default=1,
        validators=[MaxValueValidator(256)],
    )

2. Add a `lane` ID to the CableTermination model

This field indicates the lane with which the termination is associated. Lanes are numbered 0-255, with a presumed maximum of 256 lanes per cable. All terminations will default to lane 0 (the first or only lane).

class CableTermination:
    lane = models.PositiveSmallIntegerField(
        default=0,
        validators=[MaxValueValidator(255)],
    )

External dependencies

N/A

*Originally created by @jeremystretch on 10/13/2025* ### NetBox version v4.4.2 ### Feature type Data model extension ### Proposed functionality This FR introduces the concept of discrete physical "lanes" within a cable, each of which forms a connection between a pair of terminations at either end of the cable. Note that a lane is _not_ synonymous with a fiber or copper pair within a cable. (A Cat6 UTP cable, for example, is considered to have only one lane.) This FR builds upon the general idea proposed in #20085 but takes a different approach in the modeling. Each cable will have a single lane by default, to ensure backward compatibility with existing connections, and may support up to 256 lanes (the presumed practical maximum). The individual terminations at either end of a cable can be associated with individual lanes, and the terminations assigned to the same lane are considered connected. For example, here are four pairs of interfaces connected through a 12-strand fiber cable: <img width="1200" height="520" alt="Image" src="https://github.com/user-attachments/assets/b85263e3-99a9-464f-865a-154904a56409" /> The additional context provided by the cable lane allows us to track that e.g. interface C on the left is connected only to interface G on the right, which is not possible in the current implementation. The total number of terminations supported by a cable shall be informed by the number of lanes it has, if more than one. For example, the 12-stand cable above can be presumed to have six total lanes; it can support two more terminations on either end. When creating a new cable with multiple lanes, terminations added at either end will be assigned lanes in the order they are listed. This may require enabling Tom-Select's [drag-and-drop](https://tom-select.js.org/plugins/drag-drop/) functionality to allow reordering interfaces within the multi-select list. Additionally, the `from_origin()` method of the CablePath model will need to be extended to recognize and honor lane assignments within a cable. It should be possible to permit many-to-one associations using cable lanes similar to what we currently support for pass-through port assignments. This would allow for modeling e.g. several breakout connections on either end of a topology comprising multiple multi-stand cables connected in series. ### Use case It's not currently possible to separate individual physical connections which share a common cable. For example, here's what we get when attempting to trace interface A in the diagram above: <img width="400" height="393" alt="Image" src="https://github.com/user-attachments/assets/a0cc9ccc-dbb8-4444-b65b-992dcebb65de" /> The interface appears to be connected to _all_ of the far-end interfaces, which is not correct. With the introduction and assignment of discrete lanes, each of the four interfaces can be traced to its direct peer. (There may be some real-world use case where retaining this behavior is desired, in which case the cable should be defined as having only one lane which is shared b all terminations.) ### Database changes #### 1. Add a `lanes` field to the Cable model This field indicates how many lanes are supported by the cable. In theory, this could also be inferred from the cable type, but we need to be careful about maintaining backward compatibility for existing cable connections. ```python class Cable: lanes = models.PositiveSmallIntegerField( default=1, validators=[MaxValueValidator(256)], ) ``` #### 2. Add a `lane` ID to the CableTermination model This field indicates the lane with which the termination is associated. Lanes are numbered 0-255, with a presumed maximum of 256 lanes per cable. All terminations will default to lane 0 (the first or only lane). ```python class CableTermination: lane = models.PositiveSmallIntegerField( default=0, validators=[MaxValueValidator(255)], ) ``` ### External dependencies N/A

MrUnknownDE closed this issue

2026-04-05 20:24:39 +02:00

Sign in to join this conversation.

Branches Tags

main

21455-sql-indexes-audit

21357-register-model-actions

feature

20924-plugin-ui-components

21766-improve-test-coverage-for-sortable-table-columns

21157-export-template-public-models

21025-pre-render-config-contexts

21364-swagger

feature-ip-prefix-link

20911-dropdown-3

fix_module_substitution

21160-filterset

20911-dropdown-2

20044-elevation-stuck-lightmode

7604-filter-modifiers-v3

20660-script-load

19724-graphql

14884-script

19720-macaddress-interface-generic-relation

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

No Label complexity: high complexity: high complexity: high complexity: high complexity: high complexity: high complexity: high complexity: high complexity: high complexity: high complexity: high complexity: high complexity: high complexity: high complexity: high complexity: high complexity: high netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox status: under review status: under review status: under review status: under review status: under review status: under review status: under review status: under review status: under review status: under review status: under review status: under review status: under review status: under review status: under review type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/netbox#1081

Cable lanes #1081