starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-13 13:53:31 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Cable lanes #11718

New Issue
Closed
opened 2025-12-29 21:48:57 +01:00 by adam · 2 comments
adam commented 2025-12-29 21:48:57 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Oct 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:
Image
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:

Image

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 GitHub (Oct 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
adam added the type: featurestatus: under reviewnetboxcomplexity: high labels 2025-12-29 21:48:57 +01:00
adam closed this issue 2025-12-29 21:48:57 +01:00
adam commented 2025-12-29 21:48:57 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Oct 13, 2025):

For a multi-strand fiber cable, you could easily exceed the proposed limit of 256. In fact, we have shifted for most new builds from 144F to 288F cables, which would already exceed this limit, and some markets have cables with thousands of strands for trunk connections.

How would this proposal interoperate with front and rear ports that can have multiple positions? For example, MPO cables are very challenging today, as they often get rolled between both ends, so position 1 on A goes to position 12 on B and so forth. Being able to cross-connect not just interfaces, but positions with a connector on either end of the cable would also be extremely useful. See https://github.com/netbox-community/netbox/discussions/18036#discussioncomment-11340225 for some additional discussion on modeling multi-strand cables in this way.

Unfortunately, the current proposal still does not solve the typical breakout challenge for devices with a single interface at the optical layer and multiple "child" interfaces representing each of the lanes. For example, on Cisco NCS devices, you might have Optics0/0/0/0 for your optics controller interface where your 4x10G-MLR QSFP+ is inserted, then TenGigE0/0/0/0/0-3 for each of the Ethernet lanes, which take 2 fibers (positions on the MPO-12 port) for each. So, the cable terminates on one interface, but each of the lanes terminate on another. In order to get around this today and allow for proper tracing, we create a rear port with 12 positions and 8 front ports corresponding to each of the lit fibers on each end, then create fake cables from each of the breakout interfaces to the two front ports for their TX and RX fibers. Unfortunately, using a vanilla NetBox install does not then allow those breakout interfaces to be children on their optical interface and a custom script needs to be run on every such module instantiation to automatically create the fake cables. We are finding that the number of 4x10G and now 4x100G optics that are needing to be installed is increasing due to the architecture of newer devices.

This type of installation can involve a patch panel in between with MPO terminations. So, a lane between two interfaces is not necessarily contained within a single cable, but may span multiple cables along a single cable path.

@sleepinggenius2 commented on GitHub (Oct 13, 2025): For a multi-strand fiber cable, you could easily exceed the proposed limit of 256. In fact, we have shifted for most new builds from 144F to 288F cables, which would already exceed this limit, and some markets have cables with thousands of strands for trunk connections. How would this proposal interoperate with front and rear ports that can have multiple positions? For example, MPO cables are very challenging today, as they often get rolled between both ends, so position 1 on A goes to position 12 on B and so forth. Being able to cross-connect not just interfaces, but positions with a connector on either end of the cable would also be extremely useful. See https://github.com/netbox-community/netbox/discussions/18036#discussioncomment-11340225 for some additional discussion on modeling multi-strand cables in this way. Unfortunately, the current proposal still does not solve the typical breakout challenge for devices with a single interface at the optical layer and multiple "child" interfaces representing each of the lanes. For example, on Cisco NCS devices, you might have Optics0/0/0/0 for your optics controller interface where your 4x10G-MLR QSFP+ is inserted, then TenGigE0/0/0/0/0-3 for each of the Ethernet lanes, which take 2 fibers (positions on the MPO-12 port) for each. So, the cable terminates on one interface, but each of the lanes terminate on another. In order to get around this today and allow for proper tracing, we create a rear port with 12 positions and 8 front ports corresponding to each of the lit fibers on each end, then create fake cables from each of the breakout interfaces to the two front ports for their TX and RX fibers. Unfortunately, using a vanilla NetBox install does not then allow those breakout interfaces to be children on their optical interface and a custom script needs to be run on every such module instantiation to automatically create the fake cables. We are finding that the number of 4x10G and now 4x100G optics that are needing to be installed is increasing due to the architecture of newer devices. This type of installation can involve a patch panel in between with MPO terminations. So, a lane between two interfaces is not necessarily contained within a single cable, but may span multiple cables along a single cable path.
adam commented 2025-12-29 21:48:58 +01:00
Author
Owner
Copy Link

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

Closing this out in favor of the more robust implementation proposed in FR #20788.

@jeremystretch commented on GitHub (Nov 11, 2025): Closing this out in favor of the more robust implementation proposed in FR #20788.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label complexity: high netbox status: under review type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#11718
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?