Cannot install module with placeholder values in a module bay tree 2 in tree but 1 placeholders given.

[Stingo77]

NetBox Edition

NetBox Community

NetBox Version

v.4.4.2

Python Version

3.11

Steps to Reproduce

1. Create device with module bay Gi0/0/[1-24] position [1-24] for sfp module with intarface {module} and one module bay "Rear card slot" Position 1 for rear card.
2. Create rear card with module bay Gi0/1/[1-4] position [1-4] for sfp module.
3. Insert rear card into device.
4. Insert sfp module in slot rear card.

Expected Behavior

The module will be inserted into the raer card and interface will be added. Gi0/0/1 — — — — Gi0/0/1 Gi0/0/2 — — — — Gi0/0/2 Gi0/0/3 — — — — Gi0/0/3 Rear card slot — Generic-card-sfp — 1 Gi0/1/1 — — — — Gi0/1/1 Gi0/1/2 — — — — Gi0/1/2

Observed Behavior

The module is not added, an error is returned "Cannot install module with placeholder values in a module bay tree 2 in tree but 1 placeholders given."

[arthanson]

@Stingo77 can you please expand on these steps (more details) esp step 1 "Create device with module bay Gi0/0/[1-24] position [1-24] for sfp module with intarface {module} and one module bay "Rear card slot" Position 1 for rear card." is not clear, but all the steps could use further detail.

[Stingo77]

@Stingo77 can you please expand on these steps (more details) esp step 1 "Create device with module bay Gi0/0/[1-24] position [1-24] for sfp module with intarface {module} and one module bay "Rear card slot" Position 1 for rear card." is not clear, but all the steps could use further detail.

I've created a sw-test device with module bay "Rear card slot" (1) and module bays Gi/0/1- Gi0/0/8. I've created a module Generic-card-sfp with module bays Gi/1/1- Gi0/1/4. Installed the module into the device sw-test. I've created a module Generic-SFP-1 with interface name {module}.

And then I insert the Generic-SFP-1 module into the module bay Gi/1/1 and get an error. This is necessary to account for sfp modules, as suggested in the use case "Modeling Pluggable Transceivers"

[PortableProgrammer]

I have run into this as well with nested module bays. In my example, I was modeling a Dell PowerEdge R340 with a PCIe riser (Riser 1) containing two PCIe slots (Riser {module}/PCIe [1-2]), each of which contained a dual-port SFP+ NIC. I did not model the SFPs, but instead modeled interfaces directly on the NIC, using the interface name {module}/[1-2]. Upon inserting the NIC into a PCIe slot located on a riser, I received the same error.

I worked around this by inserting another {module} token into the interface name: {module}/{module}/[1-2], which resulted in interfaces 1/2/1 and 1/2/2. This means, though, that I must now model two versions of this NIC, one for risers and one for no risers, since the two-token version will produce a similar error when inserted into a module bay one level higher.

In my use case, it would be easy enough to not model the risers and just model the resultant PCIe slots directly, since that's not a configuration item that changes frequently, but I hope it helps further illustrate the issue.

[jonzey0]

We're essentially treating this issue as a blocker for us to migrate from using inventory items to module bays for SFPs. Until this is rectified, we're not going to be able to make the relevant changes from Inventory Items to Module Bays for transceivers at the scale needed.

In our environment we're looking at tracking the same SFPs across a number of devices, which may be line cards, or may be plugged directly into a device.

One of the things we'll be using is some automated tooling to pull some of these SFP details and having to account whether the SFPs is in a single line card, a nested line card, or plugged in directly would essentially require us to model three clones of the exact same SFP, defeating the purpose.

[adparis99]

I concur with @jonzey0. I had planned to start using the suggested SFP modeling with some new equipment that is coming in, but it won't be feasible unless this works.

[jeremystretch]

@Stingo77 @PortableProgrammer @jonzey0 @adparis99 I've opened this for an owner. Would one of you like to volunteer a fix?

[jonzey0]

I suspect at least some of the changes would need to be in the common.py file. At a start, changing the MODULE_TOKEN count from being an exact match

if len(module_bays) != template.name.count(MODULE_TOKEN):

to checking that you're not trying to install, say, a 2-level module in a 1-level bay

if len(module_bays) < template.name.count(MODULE_TOKEN):

At least allows the module to be installed in the above scenario (where you have a 1-Position Level Module going into a 2-Position Level Module bay).

The only problem though is this creates the interface with only the parent module position, and not the fully resolved set of positions. In the above case, you'd be able to install the first SFP, but the second SFP would violate the unique interface name constraint.

Example of what this currently looks like:-

My test device

My test modules

Line card template, where the naming of the card and the child interfaces is relative to the position

SFP where the port name is relative to the position

First populate the Line Cards and the SFPs going directly into the device (the current as-is setup)

Now with the above code change, I'm able to install an SFP into position "1/1"

However the Interface is named "1" rather than "1/1", which will mean if I try to install a second SFP in position 1/2, it will fail the validation

If my Test SFP Module has the Interface named {module}/{module}, this will be named "1/2" if populated into that slot. However this is the problem we're already looking at today (the same SFP type needing to be duplicated depending on whether it is in a line card or not)

Tried poking around to see whether I could find how to get the interface name to take the full name, but didn't have any luck.

I suspect it’s something to do with merging multiple positions together when you have an instance like this, but not sure how you’d handle it.

[NSpikings-dB]

@jonzey0 Has the possibility of using {module} in the position field been looked at as an option for this? We've also encountered this issue when attempting to model switches with line cards with SFPs as modules.

As an example of this:

I've created a device type for the chassis:

And a module type for the line card where I've included {module} in the position field:

And an SFP with the interface name relative to the position:

Then I create a Device using these:

Obviously, the position value has not replaced {module}, but ideally, it would have used {module} in the same way as the name value. eg:

When installing an SFP, this would then simply take the 1/1 etc. position value, and look something like this:

[jonzey0]

@NSpikings-dB I suspect that this issue is somewhat intertwined with https://github.com/netbox-community/netbox/issues/20467 in the resolving of the position fields. With that being addressed, maybe the fix above would then be viable.

[NSpikings-dB]

@jonzey0 Yes, I think you're right. It looks like we would need both the work you have done, along with resolving {module} in the position field, to resolve this issue.

This is definitely a blocker for modelling several of our core devices at the moment unfortunately.

[Alex-Ignatov]

Facing the same issue when trying to follow this modeling strategy: https://netboxlabs.com/docs/netbox/best-practices/modeling-pluggable-transceivers/#modeling-strategy