Modeling fiber plants by using interface naming to distiguish RX/TX

[xkilian]

Without changing the interface model, would it be viable to simply name interfaces with the folloing nomenclature:
1/1/1rx
1/1/1tx

The obvious drawback is to what interface assign the IP when an IP is required. At each end, this would become complicated as RX are crossed.
If, at a minimum netbox had some way to assign IPs to multiple interfaces, that might make it a viable method?

But this permits modeling individual fibers end to end.
This still permits creating LAGs (1/1/1rx, 1/1/1tx, 1/1/2rx, 1/1/2tx)

It comes down to naming conventions of the interfaces. Same for QSFPs with breakout cables and on.

Are there any other major gotchas with this approach?

Our current system models fibers individually, so it is pretty much the same. I am trying to get a feel if it is worth investing the time and money to modify the core netbox to support interfaces (full design, approval by the netbox team, etc.) whcih can have multiple terminations (rx/tx) or simply naming them differently and add a minor netbox feature to be done.

[candlerb]

However you do it in Netbox today, it will be ugly.

I would be inclined go the other way: model the interface as taking a single fibre cable, connect it to one ODF port, and then mark the adjacent ODF port as "connected" in order to reserve the extra fibre through the patching. This keeps it more like other cables, where there are multiple conductors but only one "connection".

If you want use separate "interfaces" for tx and rx, then I suppose you could make a third interface "1/1/1" as a LAG, with 1/1/1rx and 1/1/1tx as member ports. Then you can put the IP address on "1/1/1" as expected. But this is really an abuse of LAGs. Also remember that whether you need 1/1/1tx and 1/1/1rx depends on what type of SFP you put in: if it's a copper SFP or a bidi SFP, then you only need one interface. Therefore these spurious ports can't be part of the device type; every time you insert a duplex SFP you'll have to add new interfaces to the device. That sounds like a lot of work to me, for not much benefit.

I don't think assigning IPs to multiple interfaces is a good idea either, because these aren't separate interfaces; there's one interface which requires multiple physical connections to work (depending on the SFP used).

This has been discussed in the past on various issue tickets, but no consensus reached. A complete solution needs to be able to support things like QSFP+ ports, where an SFP+ module could present 8 fibres. Locally it may appear as either 1 x 40G interface or 4 x 10G interfaces. It can also breakout into 4 separate connections (fibre pairs) to 4 different remote endpoints.

[davidgwatkins]

What about introducing parent-child relationships for cables? Allow creation of child cable(s) and enable them to reuse the same (and only the same) interfaces (or children of the parent interface) as the parent cable. Would seem to be the easiest solution to model both physical and logical connectivity on breakouts without getting into MPO pinouts and pairs.

[candlerb]

The situation has changed for Netbox 3.3

Now you would create a single interface (e.g. "1/1/1"), and connect a single "cable" to it, but at the other end (i.e. the patch panel) you can connect to two different patch panel ports, for the TX and RX strands.

It's still not an entirely accurate representation, as it doesn't enforce that a connection into a particular interface must have two fibres, nor does it distinguish which is TX and which is RX; but it's a step in the right direction.

[davidgwatkins]

Apologies @candlerb , I went a bit off topic to "mapping logical interfaces on a breakout." Deserves its own discussion -- seems to have been a frequently requested feature.

[iunderwood]

The only time I have ever modeled single-strand fibers in my environment are the few places that I find I have to run BiDi optics. I'll add those strands as singles after my duplex links, which is not foolproof, but it does make the connection model work.

One thing I have done with some serial consoles over a structured cable riser is to simply do my connection on the first pair of the four that I use. For example, I'll have a link between floors, which technically uses pairs 51-54, but the connection will only be terminated on pair 51. A riser cable itself will account for all 100 pairs, even though for my part, it'll only show 25% of the actual utilization.

The cable model would need to be considerably adapted to count a number of front ports for use with a single interface.

[eronlloyd]

Ever since we got the improvements in 3.3, the potential to begin properly modeling optical networks in Netbox has improved substantially. I'm working on a project/plugin to begin incorporating proper duplex, PON, DWDM, etc. circuit modeling and testing, and would love to collaborate.

I'm still in the planning/experimentation phase, but the progress is visible in my repo: https://github.com/telecomcraft/netbox-optical