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.

[sigprof]

If the naming is purely hierarchical, just using {module} as the SFP module interface name in the single interface case could work even with intermediate modules after fixing #20467, so that the intermediate module could have its Position field set to incorporate the slot number where that module is installed, and then the SFP module could use the name supplied by the module bay in that intermediate module. However, if the SFP module can itself have multiple interfaces, the interface name would also need to contain a separator ({module}:0, {module}:1, …), and those separators would probably be different between router vendors (and there is also the 0 vs 1-based numbering issue).

Maybe it could be possible to add more attributes to the Module Bay objects:

• subordinate_separator — the separator character which should be used when the module has multiple interfaces;
• subordinate_base — the base value for numbering the module interfaces.

Then the templates which currently accept only {module} could be extended to accept also {module:N} (where N is a decimal number), which would expand to f"{bay.position}{bay.subordinate_separator}{bay.subordinate_base+N}".

Finally, the multi-interface SFP module would set the interface name to something like {module:[0-3]}, which would expand to a series of interface names like {module:0}, {module:1}, …, which would then expand to the appropriate interface names according to the above rule.

Although this scheme might have difficulties when multiple interfaces on the SFP module are supported not by adding another hierarchical numbering level, but by reserving some range of numbers on the same level (no idea whether there are devices which behave like that though). It could be possible to support even that by adding another module bay attribute to be used instead of position if the {module:N} syntax is used, so that {module} would expand to f"{bay.position}" as it does now, but {module:N} would expand to f"{bay.subordinate_position}{bay.subordinate_separator}{bay.subordinate_base+N}"; although in this case subordinate_separator could just be integrated into subordinate_position instead of having it as a separate attribute (but this might be more verbose to configure than having an explicit separator and also having subordinate_position default to position).

This still won't help if there are devices out there for which the prefix of the interface name (gi, te, …) actually changes with the type of the SFP module instead of being determined only by the SFP slot type (so that, e.g., for an SFP+ slot you would get te1/0/1 if you insert a 10G SFP+ module, but gi1/0/1 if you insert a 1G SFP module into the same slot; no idea whether some real devices behave like that). Not sure what to do with this case in a generic way, because the interface names would be specific to the device vendor, but need to be determined accordingly to the SFP module type (which ideally should not need to be changed according to the device it's inserted into).

[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.

[CADbloke]

Uh oh can of worms: the Device Type Library has many modules that are modular Devices with many interfaces which, according to the new modelling, should be modules. An example: https://github.com/netbox-community/devicetype-library/blob/master/module-types/Juniper/EX4400-EM-4Y.yaml

[sigprof]

There is also a (maybe minor) issue with modeling various DAC cables (which exist in both 1-to-1 and 1-to-N varieties — e.g., 40G to 4×10G or 100G to 4×25G breakouts):

Although the DAC cable is a single asset which has a single serial number and also a single asset tag, the NetBox model for it would consist of multiple objects (N+1 module objects for SFP “transceivers” and N cable objects for an 1-to-N cable), and at least the “asset tag” attribute cannot be duplicated on those module objects (and cable objects don't have those attributes at all). At most a single module object must be chosen to contain the asset tag for the DAC cable in the corresponding attribute; other module objects for the same DAC cable would need to have the “asset tag” attribute empty (although it could be possible to stuff the asset tag into some other field, so that the search for that value could still find it somewhere). Alternatively, the asset tag would need to have some extension suffix added to it, so that multiple module objects corresponding to the same DAC cable would technically have different asset tag values. Both variants are somewhat annoying to use for 1-to-1 cables, because such cables don't have a definite “main” end (for 1-to-N cables the obvious solution is to put the proper asset tag on the module object corresponding to the higher speed connector).

Although given the overall stance of “NetBox is not an asset management system”, maybe this issue should just be ignored.

[sigprof]

There are also some even more weird devices in the SFP form factor — E1 to IP gateways, which look like copper SFP modules, but actually contain a whole embedded system inside with an own IP address:

• https://www.terratel.eu/sip-pri-gateway-sfp.html — this one has some description in English; apparently it provides SIP on the IP side and cannot function just as a virtual E1 wire;
• https://www.nsc-com.com/productions/telecommunications/sprinter-tx-sfp (sorry, the page and docs are only in Russian) — a pair of such devices may be used as a virtual E1 wire to connect, e.g., a PBX with E1 uplink to the phone service provider over IP network. These devices support some standard protocols like SAToP (RFC 4553) or CESoPSN (RFC 5086).

I suppose that the way to model such devices in NetBox would be:

1. The module object which represents the SFP plug:
   1. The interface object which represents the SFP interface on the switch side.
2. The device object which represents the E1-to-IP gateway:
   1. The interface object which represents the IP interface of the gateway.
   2. The interface object which represents the E1 port of the gateway.
3. The cable object which connects the interfaces (1i) and (2i) mentioned above.

As with DAC cables, the resulting structure seems to represent the network management side of the configuration correctly (you can even pretend that the internal connection is either copper or optical, depending on which one the gateway emulates); the only thing which is not represented in NetBox is the fact that all those objects (module, device and cable) are actually the same physical device and asset.

Reconnecting such SFP to a different switch (or even to a different SFP slot on the same switch) can be cumbersome too — NetBox does not allow moving an existing module between module bays (even on the same device), so the module must be removed (which also removes the cable termination for the internal cable object) and added again in the new location, and then the cable termination needs to be restored manually (going from the existing cable object — just connecting the interface of the newly created module does not work, because the old cable still exists and occupies the IP interface on the device object).

The device for the E1-to-IP gateway also appears as unracked (it can be associated with the same rack as the switch, but not with the unit occupied by the switch). Although it could possible to pretend that the gateway device is installed in a device bay in the corresponding switch, NetBox does not allow adding device bays to arbitrary devices unless the corresponding device type allows that, so if that solution is to be used, device types for all devices with SFP slots must be marked as “Parent”, so that the device instances can have device bays added manually if needed. This solution also does not represent the hierarchy correctly (ideally the device bay should be inside the corresponding module, but NetBox does not allow modules to contain device bays).