Fibre Optic Cable with Tube modelling

[Etibru]

The aim of this discussion is to find a functional model (visual and database) to answer this issue : #18031

Proposed functionality

In many cases, the modeling of fiber cables in Netbox is not precise enough. It would be very interesting to model a fiber cable that contains tubes, which themselves contain fibers.
For example, in the vast majority of cases, a 48-fiber cable is made up of several different-colored tubes, each containing different-colored fibers.

Use case

In a datacenter, fiber rocades are positioned between the MMR (meet me room) and the IT rooms. Very often these are several cables with different optical fiber capacities (24, 48, 72, 128, ...) and at each end we have patch panels.
To be able to identify a particular fiber in a cable, you'd need to know that its position on a patch panel refers to the purple fiber in the blue tube of cable XXX.

[Etibru]

For the visual, I think that the representation of the tube (with color) could be done this way

In terms of object modeling, the cable in the cable could be a way of modeling it, a bit like adding a module to a device.

[DanSheps]

I will be honest, as someone with a decent fiber footprint in a small downtown area I have looked at a solution. I think multiple model extensions (be it full models or just additions) are required to do this properly:

• Vault (Similar to a location)
• Conduit
  • Conduit coordinate point (Map coordinate with a length from a designated end)
• Fiber Bundle
• Fiber Buffer
• Fiber Core
• Splice container (Similar to a Device)
• Splice Tray (Similar to a module)
• Splice

You can emulate a lot of this right now just using Front/Rear ports so there has been no driver to really expand on it.

[Etibru]

I agree! More complete and dedicated modeling would be best (Vault, Conduit, ...).

But right now, I can't modelize the red fiber of the green tube of a Multitube Cable 48F between two Splice containers.

## Multitube Cable 48F
- Fiber count : 48
- Fiber Type: G.652.D, G.657.A1, G.657.A2, G.655, G.656, OM1, OM2, OM2+, OM3, OM4, OM5
- Fiber color: Blue, Orange, Green, Brown, Grey, White, Red, Black, Yellow, Violet, Pink, Aqua
- Tube: Gel-Filled PBT buffer tube
- Tube color: Blue, Orange, Green, Brown

This kind of cable could be a cable within a cable (like module for devices)

[DanSheps]

But right now, I can't modelize the red fiber of the green tube of a Multitube Cable 48F between two Splice containers.

Why not?

Here is what I do:

Module: Splice Tray (I have multiple different module types for this, but the most common is a 12x1 (12 front ports 1 rear port)
Rear Port: your buffer tube (Cable label == your cable bundle, so all buffers within a bundle should have the same name)
Front Port: your strand

What is missing is the fiber bundle itself, however as mentioned if you label your rear cables the same, it isn't all that bad.

[DanSheps]

I wrote a "Howto" here: #10412

[Etibru]

Effectively, seen like that, it could work.
I'll see if this model can cover all cases on the datacenter side.

[sleepinggenius2]

A way to model multi-position cables in general would be nice, though fiber is definitely the largest portion of those within our network. We do have some panels that come pre-terminated with fiber pigtails, so we have modeled those with a rear port for each fiber cable and break out each strand into a front port, which works well. Where it gets trickier is when we have a panel that just has one-to-one connectors between the front and rear ports. We model those with one rear port and corresponding front port for each position, as they can have fiber cables of any size mixed and matched on the rear. Unfortunately, that means that we have to connect each rear port individually today with a cable and it's not obvious they they are all just strands in a single cable, not to mention all that extra overhead. We tried at first to just use a single cable with multiple terminations on each end, but we found that the trace would not recognize that the corresponding termination positions on each side were connected. This all gets even more complicated if you have a mix of the two panel types connected together.

The other big place where this comes up a lot is with MPO cables. We've started using more structured cabling in our sites, leveraging MPO cables and breakout panels, and they suffer from the same issue of not being able to represent the positions well with a single cable. This is especially frustrating when you have something like an MPO-8 connector on one end and an MPO-12 connector on the other, as we have to model both with 12 positions for the tracing to work right. We also run into trouble when we have a breakout optic, like 4x10G or 4x100G, which uses an MPO-connector connector that connects to an MPO connector (usually MPO-8) on a breakout panel, but has 4 interfaces to represent each of the TX/RX pairs. We've had to resort to some hacky modeling that uses a pluggable module with a single rear port and 8 front ports and an event rule that runs a script to create the corresponding interfaces and cable them to their respective front ports, so tracing works correctly. It's also really fun when you have a single MPO cable with 1 x MPO-24 on one end and 2 x MPO-12 on the other end, as we have yet to find any good way to model that without doing separate cables for each strand. MPO cables also often have different polarities on either end, so connecting a single cable where position 1 on one end and position 12 on the other end are connected doesn't trace properly in NetBox, as it doesn't know that.

The other place where we've started seeing multi-position cables is with DC power. It seems a lot more devices are starting to leverage a single multi-position connector on the device side that gets broken out into separate wires, which need to be terminated to multiple positions on the fuse panel. We've been finding it difficult to document for our field techs that, for example, the red cable goes to this terminal on the fuse panel and the black cable goes to this other one, when there is just a cable with one termination on one end and multiple on the other.

I would love to see a model added for cable types, where you can ideally specify connector types on either end and some ability to connect different positions on connectors together to more accurately model a real world cable that can trace properly. Each of those connections could be given an optional color and description. There could potentially be an option for two colors to represent the tube and strand for each connection. That way you could have the types that suit your environment and not be limited by the choices the way that they are defined today. You could even include standard cable types as a new type in the community device types library to ease onboarding. Here's a basic model of what I'm thinking:

• ConnectorType
  • name [string]
  • slug [string]
  • description [string, optional]
  • positions [positivesmallint, default=1]
  • color [color, optional]
• CableType
  • model [string]
  • slug [string]
  • description [string, optional]
  • color [color, optional]
  • manufacturer [FK(dcim.Manufacturer), optional]
  • part_number [string, optional]
  • length [positiveint, optional]
  • length_unit [string, optional]
• CableTypeConnector
  • cable_type [FK(CableType)]
  • connector_type [FK(ConnectorType)]
  • end [choice(dcim.CableEndChoices)]
• CableTypeStrand
  • connector_a [FK(CableTypeConnector)]
  • position_a [positivesmallint]
  • connector_b [FK(CableTypeConnector)]
  • position_b [positivesmallint]
  • color [color, optional]
  • tube_color [color, optional]

The type field on the dcim.Cable model can just be replaced by a foreign key to CableType. As part of the migration, CableType objects can be pre-populated for the existing dcim.CableTypeChoices and ConnectorType objects for the existing dcim.PortTypeChoices, dcim.PowerPortTypeChoices, dcim.PowerOutletTypeChoices, dcim.ConsolePortTypeChoices, and the modular types from dcim.InterfaceTypeChoices. The dcim.CableTermination model would also need to change: a connector field that is a foreign key to CableTypeConnector and limited by the CableType of the cable field would need to be added and the cable_end field could be removed, as it would be redundant. The UI/UX experience could actually be simplified in some ways, as terminations could be handled more like L2VPN or tunnel terminations, without the need for multi-select and all the issues we see with changing types and fields getting cleared correctly. It would be amazing to also add filtering so that only terminations with a type that is compatible with a connector can be selected. Some consideration would need to be made during migration for how to handle multiple terminations on one side of a cable, likely creating a CableType with multiple connectors on the appropriate end.

[Etibru]

I think this model is well suited to all situations ! 👍