Support multi-termination cabling through fiber modules

[shepherdjay]

Per comments in #13930 this is what I want to try to model where there is a modular fiber patch panel:

I actually do think this might be achievable without going too much into strands of the cable. I'm having trouble fully understanding the code but it appears terminations are submitted and stored as lists which are ordered.

So if you wanted to represent the above model you would create a cable like this:

A Side
Device: fiber1
terminations
a1-6 (positions 6), b1-6 (positions6)

B Side
Device: fiber2
terminations
a1-6 (positions 6), b1-6 (positions6)

And what if you needed to flip so that strands 13-24 connected to module A on fiber2 instead (basically having rolled the cable) you could reverse the order of the terminations

A Side
Device: fiber1
terminations
a1-6 (positions 6), b1-6 (positions6)

B Side
Device: fiber2
terminations
 b1-6 (positions6), a1-6 (positions 6)

In the event that there are mismatched number of positions that is where a path split condition could occur. This type of logic could only apply to cables whose terminations have positions in the first place such as rear ports.

[jeremystretch]

This is an unrelated tangent, but could you share how you created the topology diagram above? It looks like Mermaid, maybe?

[shepherdjay]

Yes this was using mermaid -- specifically https://mermaid.live/ -- which you can export to markdown and you can create the diagram as a link. If you click on it it will take you straight to the mermaid code.

[DanSheps]

This is cool, bookmarked, thanks!

[DanSheps]

@shepherdjay could you give the code you used to generate the above?

[shepherdjay]

@DanSheps -- Mobile at the moment but the image itself should be a hyperlink that will also take you right to the code used to generate it.

[DanSheps]

You are correct, thanks!

[DanSheps]

Unfortunately, what you are requesting is going to logistically be a nightmare to model.

In current model, you have Front Ports, Rear Ports and cables (going to ignore interfaces because they are not relevant here).

Rear Ports have positions (1, 6, 12, whatever) but is still a single object, the positions are a virtual concept.

Front Ports are always linked to a rear port (and virtually to a specific position on the rear port).

When you cable from a rear-port to a rear port, the positions are 1:1 mapped (position 1 on one side is position 1 on the other, 6 on one to 6 on the other).

Connecting ports, there is no concept of order of the ports (however typically it is ordered by PK), so if you have port a1 and b1 on one side a1 and b1 on another side of a cable, that doesn't mean a1 matches up with b1. You are better to model the "buffer tube" (the 12 strands) in this instance instead of the 24 cables.

I do want to point out something, very important. The "connecting multiple ports with 1 cable" was to solve the "duplex cable to interface" problem and really wasn't meant to connect two rear port sets together in this manner. This isn't really someothing you can do in real life either, if you view a cable in netbox "properly". A cable in netbox should be viewed as a single connenctor (simplex LC, duplex LC, MPO) and not multiple connectors bundled together (2 MPO-12 on a 24 strand fiber)

[shepherdjay]

I appreciate the very in-depth reply so I apologize in advance for my reply being short in comparison. My intent is not to dismiss your reply but I think on the whole it can be summarized very nicely with this statement.

You need to look at cables in NetBox in a similar manner in whichh you do in real life:

That's exactly what I'm doing. I think we just don't look at cables the same way 😃. Just as I don't view the 8 separate copper connectors in a cat 6 cable as 8 distinct cable paths, I don't really view the 24 strands as 24 distinct cable paths (or 2)... I'm certainly not labeling the individual strands or buffer tubes. At the end of the day for us it's a single cable coming out of the back of the tray. It happens that the tray is modular so I was trying to represent that accurately.

Ultimately it sounds like this is just a trade-off. I can either represent the cable how I view it.. or the modular fiber tray how I view it... but not both. Likely the simplest tradeoff is to just drop the modular fiber tray and have a 6, 12, 18, 24 position rear versions of the same fiber tray depending on how they have been populated.

[DanSheps]

That's exactly what I'm doing. I think we just don't look at cables the same way 😃. Just as I don't view the 8 separate copper connectors in a cat 6 cable as 8 distinct cable paths, I don't really view the 24 strands as 24 distinct cable paths (or 2)... I'm certainly not labeling the individual strands or buffer tubes. At the end of the day for us it's a single cable coming out of the back of the tray. It happens that the tray is modular so I was trying to represent that accurately.

The difference is the 8 strands are alll part of the same connector; with fiber you either have a single connector (LC-LC) for each strand or something like a MPO-4, MPO-8, MPO-12, MPO-16 going into a module.

I can either represent the cable how I view it.. or the modular fiber tray how I view it...

Why not both? You don't mention the tray, but I am just going to assume something like a FAP-12 in 2 bays. If it is a FAP-12 (or similar), you should ideally be modelling it as separate strands as they are separate connectors. However if you want to go simpler, you can model the "buffer tubes", so instead of 24 cables you are down to 2. You could even have a script to automate this for you.

Ultimately it sounds like this is just a trade-off

There is definitely room for improvement, however the cabling model is unlikely to change in the near future. But all the things I mentioned in my previous post could be better represented if the Cabling model was extended, however there is a trade-off of added complexity, both in code and in the manner in which you would connect things.

Take for example if we had a "cable", and that cable included the buffer tubes and strands. You could easily have the buffer tubes connect to a rear-port and then imply the position of the strand is the position of the cable, however what if at the other end you don't have a rear-port with multiple positions, you would then need to cable every single strand to a rear port.

While the cabling model right now is rather simplistic, it can somewhat accurately describe your cabling

[shepherdjay]

Why not both?

Because its not possible to model it in the way I see it.. your next statement states why. That it is either 24 separate cables, 12 separate duplex pairs, or 2 separate buffer tubes (one for each module) -- None of those three items is how I see the cable. None of those is how I would label the cable. I understand this is different from the way you or even possibly most people see this. But when I look at something like this https://www.lanshack.com/24-Strand-Indoor-Interlocking-Armor-Plenum-1040100-GIG-50125-OM4-Multimode-Fiber-Optic-Cable-by-the-Foot-P8740 coming out of the back of a fiber tray... this is one cable to me.

So if I want to display the cable as one cable in the trace. I have a couple of choices.

• Drop the modularity of the fiber tray in favor of specific fiber tray fill outs with either 6, 12, 18, or 24 rear positions along with every other possible combination as it ends up existing in our environment.
• Create a standin adapter that takes 2 front ports to 1 rear port with 2 positions. Possibly this can be created as an internal reference utilizing front/rear ports internally connected instead of separate device.

[DanSheps]

If you want to give me specific part numbers for the tray as well as the cassettes/bulkheads used I can probably come up with a way to properly model it, however whatever method I propose, you aren't going to view the cable as a "single cable" with "24 strands".

Drop the modularity of the fiber tray in favor of specific fiber tray fill outs with either 6, 12, 18, or 24 rear positions along with every other possible combination as it ends up existing in our environment.

I would argue, that mapping your buffer tubes as a cable to the 12 port rear position is more accurate then what you are doing now. You state you have 2 modules within your Fiber tray, with 24 strands. Guaranteed that there are 2 buffer tubes in the cable you specify. Now, lets say that somewhere down the line you want to drop a closet in the middle of that cable. You can mid-span that cable and pull out one of those buffer tubes and splice it into the new tray, you now don't have 1 cable you have 2. This is why you should at the bare minimum be using the buffer tubes as your "cables" instead of the whole 24/48/96/144/288 as a cable.

[shepherdjay]

If you want to give me specific part numbers for the tray as well as the cassettes/bulkheads used I can probably come up with a way to properly model it, however whatever method I propose, you aren't going to view the cable as a "single cable" with "24 strands".

Ha - I've been having a hard time with that as well. Its a Corning Lanscape type system.

I would argue, that mapping your buffer tubes as a cable to the 12 port rear position is more accurate then what you are doing now.

Almost certainly it is more accurate, just as modeling the 24 strands would be even more accurate. As would modeling the 8 copper strands on a cat6 would be more accurate in cases where those get converted to pots lines.

Now, lets say that somewhere down the line you want to drop a closet in the middle of that cable. You can mid-span that cable and pull out one of those buffer tubes and splice it into the new tray, you now don't have 1 cable you have 2. This is why you should at the bare minimum be using the buffer tubes as your "cables" instead of the whole 24/48/96/144/288 as a cable.

Meh... I try not to add a bunch of work or complexity for things that might happen in the future. When we run the 24 strand its because there are already 2 modules we are populating. We don't run those 24 strand ahead of time so its highly unlikely we would ever disconnect one of those modules and midspan it vs just running another cable.

Either way I think this idea still has merit though perhaps not enough use to justify any work at this point in time.