Cable lanes

[jeremystretch]

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-an-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

[sleepinggenius2]

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 #18036 (comment) 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.