Best Practice to model multi-core fibres & patching

[arcticash]

Looking for some advice here that i cant seem to find in the docs, I'm testing out Netbox as part of a POC to improve our documentation and looking for the best way to model fibre infrastructure.

Typical Deployment & questions:

1. Switch has a single SFP connecting to a paired LC connector on the patch panel (should this be multi-termination connection?)
2. LC patch panel has 12 pairs for standard use, but 24 cores should this typically be modelled as 12 or 24 connections?
3. 24c cable connects between two patch panels ... should I model all the cores individually (eg. port 5 on the A panel goes to port 5 at the B panel), or can this be done as a single cable while still retaining the ability to do a cable trace?
4. If all cores are modelled individually, is there an easy way to document which connections are part of the same cable/duct etc. (use case being if a multi-core fibre was to get cut and I want to know everything that was using it)

[candlerb]

• Switch has a single SFP connecting to a paired LC connector on the patch panel (should this be multi-termination connection?)

Yes: the cable can have one termination at the switch end, and two terminations at the patch panel end.

• LC patch panel has 12 pairs for standard use, but 24 cores should this typically be modelled as 12 or 24 connections?

It's up to you. If you always use the fibres in pairs, then you can consider a pair of LCs as one "frontport" - and that was the only sensible way to do it in older version of Netbox.

But if you might in the future ever have any single strand connections (e.g. BiDi or GPON) then you should model them as 24 connections.

• 24c cable connects between two patch panels ... should I model all the cores individually (eg. port 5 on the A panel goes to port 5 at the B panel), or can this be done as a single cable while still retaining the ability to do a cable trace?

You can do either. To do the latter case (single rear connection), your patch panel has 1 "rear port" and 24 "front ports" which are linked to "positions" 1-24 of the shared rear port. Then you make a single connection between the rear port of one patch panel, to the rear port of another. Cable tracing works fine through this.

However if your patch panels aren't connected in this simple linear fashion, then you'll have to fall back to separate cables. You can use a custom script to help create all these connections.

(Note: in reality, it's common that the pairs are swapped: 1-2 goes to 2-1, 3-4 goes to 4-3 etc. Since Netbox doesn't make any distinction between the "transmit" and "receive" legs, then you don't care about this when using normal SFPs. But if you ever start using BiDi SFPs, then you will care about this: e.g. a connection plugged into port 5 on patch panel 1 will come out as port 6 on patch panel 2. One way to model this is by having different frontport-to-rearport position mappings at each end, but I've never tried that)

• If all cores are modelled individually, is there an easy way to document which connections are part of the same cable/duct etc. (use case being if a multi-core fibre was to get cut and I want to know everything that was using it)

The only way I know to bundle Netbox "cables" together into a logical entity like a bundle is to use some sort of naming convention on the labels, or to add custom fields.