Proper way to model interfaces using SFPs as Module Types

[brianatlarge]

Let's say I have a switch with 4 fixed SFP slots. On the switch, these are represented by interface names:

Gi1/0/49-51

I create a module type profile called "SFP" and then create a module type called "GLC-SX-MMD", then on the device type for my switch, I add 4 Module Bays named:

Gi1/0/[49-51]

Then I create a new device for my actual switch.

As an example, my SFP is inserted into Gi1/0/51, so under module bays of the device, I add a module under my Gi1/0/51 module bay and select the GLC-SX-MMD module.

So now comes the question. Is this the appropriate way to model SFP interfaces? I'm guessing not because I have no way to model cable connections if I'm using modules to represent the SFP. Is there any guidance on the currently recommended way, since inventory items are deprecated as of v4.3.

[guliaka]

For what it worth, here is my two cents ))
In device type I would add module bays as Port [49-51] with positions [49-51]
Then in module type of "GLC-SX-MMD" I would add interface with name Gi1/0/{module} so it, when inserted into module bay will pull position in the module. This way you have interface named as in your switch only when module is present in module bay.

Hope it makes sense )) Good luck.

[fzs]

Which interface type would the interface on the SFP module have?
That is what is currently racking my brain. There is no interface type "lc" or "10gbase-sr". But type SFP seems inappropriate since this is the form factor of the module and module bay.

It seems to me that modeling SFPs with modules and module bays has not been fully thought through.

[RichardVReyden]

I have started to think about this. Netbox Labs has also posted a blog post on the topic: https://netboxlabs.com/blog/sfp-modeling-modules-over-inventory-items/

What I am struggling with is the naming of the interface, this is driven by the name of the SFP+ which is inserted into the module-bay.
But, an SFP_ can be inserted into different ports and have a different name, eg if it is inserted into a Cisco router port it could be TengigE0/0/0 and if in a Juniper router port it could be xe-0/0/0. The name is driven by the line card (parent module) rather than the transceiver.

Is there anyway to achieve getting the naming of the interface coming from the parent line card port?

[fzs]

As became apparent in #19918, naming the interfaces can be rather complex.
The blog article describes only the easy, straight-forward case. If this covers your use case, then you are in luck. This use case is that you only have a device with module bays for SFP modules: device - module bay - SFP module - interface. Easiest if the SFP only provides one interface,

What you can do is give the position of the module bay in your device type the name that the interface will have. Then just use {module} as the name of the interface on your SFP module type. For your Cisco router you can use TengigE0/0/0 as the position of your module bay and for the Juniper router xe-0/0/0, respectively.

It might get a tiny bit more complicated if the SFP module provides more than one interface. But it gets mighty more complicated (and that is what the blog article conviently left out), if you have more layers of nested modules, i.e.: device - module bay - module - module bay - module - interface. Because then you most likely cannot reuse your SFP module type that you created to directly insert into your device.

For multiple layers of module bays, each with their positions, you need to either ignore the position of the module bay in either the device or the intermittend module (e.g. the line card), which most likely will not make sense in most cases. Or you need to use an interface name like {module}-{module} on your SFP module type, referencing the position of the module bay in the device and the position of the module bay in the parent module. Which means you need to create a second module type for the exact same SFP transceiver, depending on where it is to be inserted to.

And that isn't even taking speed variations into account yet.

[jeremystretch]

I've finally found some time to dedicate to this topic, and after spending some time reviewing this and similar discussions I think I've identified a few discrete but related pain points.

1. Delineation between transceiver & interface depends on context

Conceptually, there's often no clear distinction between an interface on a switch or router and its pluggable transceiver; we often use the two term interchangeably. For instance, one might refer to an interface in practice as QSFP+, as 40GBASE-S4, or as 40 Gbps Ethernet. All of these may be accurate depending on the context, but individually none of these terms fully capture the complete interface definition.

2. Variable interface assignment

Consider a QSFP+ slot on a switch. How you model the interface(s) this slot provides in NetBox depends on the type of transceiver installed. Installing a 40GBase-C4 direct attach cable (DAC) or 40GBase-S4 will yield a single Ethernet interface operating at 40 Gbps:

Interface               Admin Link Proto    Local                 Remote
et-0/0/0                up    up
et-0/0/0.0              up    up   inet     192.168.1.2/31

However, if you were to remove that transceiver and install a breakout DAC terminating to four physically separate 10 Gbps transceivers on the far end, the local device will instead show four individual channelized interfaces:

et-0/0/0:0              up    up
et-0/0/0:0.0            up    up   inet     10.0.0.1/31
et-0/0/0:1              up    up
et-0/0/0:1.0            up    up   inet     10.0.0.3/31
et-0/0/0:2              up    down
et-0/0/0:3              up    up
et-0/0/0:3.0            up    up   inet     10.0.0.7/31

I think this is addressed by the new module-based approach: A 40GBase-S4 transceiver, for instance, would have only a single 40 Gbps Ethernet interface defined, whereas a breakout DAC would have four 10 Gbps Ethernet interfaces.

3. Variable interface naming

The matter of interface assignment is further complicated by platform as @RichardVReyden points out above:

But, an SFP can be inserted into different ports and have a different name, eg if it is inserted into a Cisco router port it could be TengigE0/0/0 and if in a Juniper router port it could be xe-0/0/0.

NetBox currently doesn't offer any mechanism to automatically alter the name of an interface on a device type or module type depending on the platform, and implementing such a mechanism would be a fairly complex undertaking. Maybe we could do something similar to the token-based approach we use for deriving a position from the parent module bay.

4. NetBox does not provide physical fiber interface types

Suppose you want to create the breakout DAC transceiver with four 10GE interfaces mentioned above. What type do you assign these? NetBox currently doesn't list an applicable option for the interface type, because historically the convention has been to treat the SFP slot as the interface. This can be easily remedied by adding the necessary physical media as interface types.

Edit: I've just submitted FR #20321 to propose adding a set of new interface types for this purpose.