Recommended approach for modelling fibre cassettes

[jacobw]

I'm trying to determine if there is an 'offical' recommended method of modelling modular fibre cassettes that sit inside a parent enclosure. As an example, I typically see a 1U enclosure at the top of a compute rack, that holds 3 cassettes. Each cassettes is a 6 to 12 port LC on the front, and single MPO on the back.

The main question is should fibre cassettes be modelled as devices or modules in bays. The documentation doesn't seem to cover this scenario as there are no management planes, and all of the examples are routers and servers. The community appears to do both, with maybe a preference for devices in device bays.

As this is a pretty common scenario (I think), I though a common approach would be helpful, so there is consistency among organisations. Additionally, if there were changes to Netbox in the future, it would be good if there was alignment on this use case.

[candlerb]

I'm not sure there's an obvious "best practice" here: it depends whether you consider the enclosure or the cassette to be the main unit, and what your naming scheme is.

I use device bays mainly because it was the only option before module bays came along. The child device name becomes the unique identifier for the cassette, and I find it useful to make a naming scheme that associates each end. For example, if I have a cassette in rack s18 that connects to a cassette in rack s15, then it's mod-lc-s18-s15 at one end and mod-lc-s15-s18 at the other end. With module bays I wouldn't have to invent these names, but I'd also have to look at rear ports to see where things connect.

The upside of using module bays is that you can see all the connections from the entire patch panel in one screen. However, you need to ensure all the front ports and rear ports have unique IDs, like F{module}/[1-12] and R{module}

If your naming scheme numbers the front ports linearly from 1-144 or whatever, then either way you're going to have to renumber the ports after installing each module or child device. I suppose in that case modules would make more sense, so you can see ports 1-144 all in one screen.

[jacobw]

Thanks for the feedback. I'd seen some of you previous comments, interesting to understand that's based on a time before modules existed.

Yes I've tried both ways and feel like I have in invent less names with modules. And yes, you need to use {module} to avoid conflicts, but that seems to work ok.

In my use case, I'm not constrained by and existing naming scheme, so that's not a specific factor.

It sounds like you are saying modules would be easier to manage, rather than lots of individual devices for each cassette?

[candlerb]

Maybe. If I were starting afresh today I'm not sure which way I'd go - and it's too much work to change now anyway. Without having tried the modules approach, it's hard to know if there would be significant annoyances in practice.

I imagine the main problem would be when making a new connection from a device to a front port. Today, if I want to make a connection from a device in rack s18 (say) to a remote device in rack s15 (say), then I create a cable with the s18 device's interface as A-end. I select mod-lc-s18-s15 as the B-end device and pick a free port from F1-12. At the other end I select mod-lc-s15-s18 as the B-end device and the same port number. Easy.

If the patch panels were using modules, then for the B end I would get a long list of front ports, 1/1..12, 2/1..12, 3/1..12 etc, and I would have to know which module is the one which connects to s15 - probably by opening the list of rear ports on the patch panel. Then, once I've connected the device to 3/7 (say), I'd also have to remember what the corresponding module number was at the far end, before I could make the connection on that side to Y/7.

This is an area where a drag-and-drop way of adding cables could make life easier. Perhaps Netbox could implement this UI :-)