Support Port Type Definitions for Module Bays #11297

New Issue

adam · 2025-12-29T21:43:13+01:00

adam commented

2025-12-29 21:43:13 +01:00

Originally created by @0lini on GitHub (Jun 20, 2025).

NetBox version

v4.3.2

Feature type

Data model extension

Proposed functionality

In modular hardware platforms, module bays serve as receptacles for various types of modules (e.g., transceivers, line cards, PCIe expansion cards, disk interposers). However, not all bays accept the same kind of modules — for example:
A 25G SFP28 cage accepts SFP28 or SFP+ transceivers.
A PCIe slot accepts a specific form factor (x4, x8, x16).
A SAS/SATA backplane port may expect a storage controller module.

Today, module bays in NetBox are generic containers with no way to define or communicate what type of module they support. This limits the ability to:
Validate module compatibility
Inform users about expected hardware
Improve module auto-assignment workflows

Use case

Model a network switch with SFP28 ports and enforce that only SFP-compatible transceivers are added.
Define that a specific slot in a server accepts a PCIe card, not a network transceiver.
Help automation tools or provisioning systems determine correct modules for each bay type.

Database changes

A new field would be needed that includes the predefined port/bay types, like SFP, SFP+ and SFP28. All types of PCIe Interfaces 2x, 4x, OCP and so on.

External dependencies

No response

Originally created by @0lini on GitHub (Jun 20, 2025). ### NetBox version v4.3.2 ### Feature type Data model extension ### Proposed functionality In modular hardware platforms, module bays serve as receptacles for various types of modules (e.g., transceivers, line cards, PCIe expansion cards, disk interposers). However, not all bays accept the same kind of modules — for example: A 25G SFP28 cage accepts SFP28 or SFP+ transceivers. A PCIe slot accepts a specific form factor (x4, x8, x16). A SAS/SATA backplane port may expect a storage controller module. Today, module bays in NetBox are generic containers with no way to define or communicate what type of module they support. This limits the ability to: Validate module compatibility Inform users about expected hardware Improve module auto-assignment workflows ### Use case Model a network switch with SFP28 ports and enforce that only SFP-compatible transceivers are added. Define that a specific slot in a server accepts a PCIe card, not a network transceiver. Help automation tools or provisioning systems determine correct modules for each bay type. ### Database changes A new field would be needed that includes the predefined port/bay types, like SFP, SFP+ and SFP28. All types of PCIe Interfaces 2x, 4x, OCP and so on. ### External dependencies _No response_

adam added the type: feature netbox needs milestone status: backlog complexity: high labels 2025-12-29 21:43:13 +01:00

adam commented

2025-12-29 21:43:13 +01:00

@sleepinggenius2 commented on GitHub (Jun 23, 2025):

I would suggest that instead of introducing just a field for this, that a new ModuleBayType model be introduced instead (additionally a DeviceBayType or a common BayType that could be used for both would be useful too). With all the manufacturers and bay types out there, I don't think it would be practical to try to create an exhaustive list of choices in the core and even allowing it to be customizable would be cumbersome. That would then also allow for further extension by defining a many-to-many relationship between module types and module bay types, which would allow for defining rudimentary compatibility and limiting the module type selector list when adding a module to a bay. Having that for device types and device bays would be useful as well, but I can see where that could be a separate feature request.

Due to the potentially large number of bay types and common names between different manufacturers, as well as standard types not specific to a particular manufacturer, I think the ModuleBayType should allow for optionally associating it with a manufacturer, which could be used in selectors in a similar way to how platforms are handled today. That would also allow for setting an additional uniqueness constraint on the name to include the manufacturer. In fact, I think it should be modeled exactly like Platform minus the Config template field.

@sleepinggenius2 commented on GitHub (Jun 23, 2025): I would suggest that instead of introducing just a field for this, that a new `ModuleBayType` model be introduced instead (additionally a `DeviceBayType` or a common `BayType` that could be used for both would be useful too). With all the manufacturers and bay types out there, I don't think it would be practical to try to create an exhaustive list of choices in the core and even allowing it to be customizable would be cumbersome. That would then also allow for further extension by defining a many-to-many relationship between module types and module bay types, which would allow for defining rudimentary compatibility and limiting the module type selector list when adding a module to a bay. Having that for device types and device bays would be useful as well, but I can see where that could be a separate feature request. Due to the potentially large number of bay types and common names between different manufacturers, as well as standard types not specific to a particular manufacturer, I think the `ModuleBayType` should allow for optionally associating it with a manufacturer, which could be used in selectors in a similar way to how platforms are handled today. That would also allow for setting an additional uniqueness constraint on the name to include the manufacturer. In fact, I think it should be modeled exactly like `Platform` minus the Config template field.

adam commented

2025-12-29 21:43:14 +01:00

@0lini commented on GitHub (Aug 9, 2025):

Since using module bays for SFP ports is now best practice, this has gained more relevance in my opinion.

@0lini commented on GitHub (Aug 9, 2025): Since using module bays for SFP ports is now best practice, this has gained more relevance in my opinion.

adam commented

2025-12-29 21:43:14 +01:00

@sigprof commented on GitHub (Dec 7, 2025):

That would then also allow for further extension by defining a many-to-many relationship between module types and module bay types

I think that the many-to-many relationship between module types and module bay types would be needed from the start to make the feature actually useful (and also a many-to-many relationship between module bays and module bay types). Basically, both the module bay and the module type should be associated with sets of compatible module bay types, and the module type should be considered compatible with the module bay only if those sets have at least one element in common, or (for compatibility) if any of those sets is empty.

E.g., see the situation with lower speed SFP/SFP+ modules — various switches may support the following speed options in various combinations (sometimes with different sets of speeds supported on different slots):

SFP 100 Mbps
SFP 1 Gbps
SFP+ 2.5 Gbps (or is that still SFP? not sure)
SFP+ 5 Gbps (again, not sure about “+” here)
SFP+ 10 Gbps

In the SFP case the transceiver itself often supports only a single speed, so the set of compatible module bay types for the module type would probably contain just a single element, but the set of compatible module bay types for the module bay may contain multiple elements. The number of supported options looks manageable in this case.

If we go to higher speed SFP variants, there could also be restrictions on channelization (e.g., 40 Gbps → 4×10 Gbps, 100 Gbps → 2×50 Gbps or 4×25 Gbps; on some devices only some ports may support some particular variants). So just having, e.g., a single “QSFP28 40 Gbps” module bay type would not be enough — a breakout to 4×10 Gbps would need to specify “QSFP28 4x10 Gbps”, and the module bay would need to declare support for that too. Some higher end switches may support lots of possible configurations here, but there does not seem to be any way around specifying all supported variants if we want to have proper compatibility checking.

Another example could be M.2 slots and SSDs. In this case the slot (= module bay) can have only a single key (B or M for slots which could accept SSDs), but the M.2 SSD could have compatibility with only M slots, only B slots (does not really exist in practice), or both B and M slots. In this case, unlike SFP, the set of compatible module bay types for the module type would need to contain multiple elements.

But actually the M.2 compatibility issues are more than that — the slot may support only SATA, only PCIe, or both, and the SSD would support only a single kind of interface (either SATA or PCIe). If we want to support such compatibility restrictions while using the “at least one element in common is enough” logic, we would need to define module bay types like:

SATA B-key
SATA M-key
PCIe B-key (there were some lower end SSDs like that)
PCIe M-key

But if we want to include the M.2 dimensions (2230, 2242, 2260, 2280, 22110) in the compatibility check too, the list would grow from 4 to 20 possible variations.

For normal PCIe slots the situation could be even more complicated — there are at least 4 mostly independent attributes:

Number of lanes (1x, 2x, 4x, 8x, 16x). In this case the module would be compatible with a module bay which supports the same or higher number of lanes (although there is also the issue that the electrical number of lanes might not be the same as the mechanical size of the connector, and apparently there are some cards which outright refuse to work when the number of lanes is too low).
- Transfer rate (≈PCIe generation) — not sure whether this needs to be actually included in the compatibility check (in most cases the devices just fall back to a lower rate).
Length (full = 312mm, three-quarter = 254mm, half = 167.65mm). In this case the module would be compatible with a module bay which supports the same or higher length.
Height (full = 111.15mm, half = 68.90mm). In this case the module may be compatible with a module bay which supports the same or higher width, except in some weird cases when the module comes with a low profile bracket, and a full height bracket is not available for some reason.
Width (single slot, dual slot, triple slot). Again, the module would be compatible with a module bay which supports the same or higher width, but there is also the issue of blocking adjacent slots if they are present — however, checking for that is probably too much to expect from NetBox.

The problem here is that we would get 5×3×2×3 = 90 combinations of parameters, and large compatibility sets for both the module types and module bays, so including all of those parameters would become problematic if we use just the “at least one element in common is enough” logic.

Maybe for now we could ignore the combinatorial explosion issues with complicated cases like PCIe slot variants, and focus on more network-relevant things like SFP modules?

@sigprof commented on GitHub (Dec 7, 2025): > That would then also allow for further extension by defining a many-to-many relationship between module types and module bay types I think that the many-to-many relationship between module types and module bay types would be needed from the start to make the feature actually useful (and also a many-to-many relationship between module bays and module bay types). Basically, both the module bay and the module type should be associated with sets of compatible module bay types, and the module type should be considered compatible with the module bay only if those sets have at least one element in common, or (for compatibility) if any of those sets is empty. E.g., see the situation with lower speed SFP/SFP+ modules — various switches may support the following speed options in various combinations (sometimes with different sets of speeds supported on different slots): - SFP 100 Mbps - SFP 1 Gbps - SFP+ 2.5 Gbps (or is that still SFP? not sure) - SFP+ 5 Gbps (again, not sure about “+” here) - SFP+ 10 Gbps In the SFP case the transceiver itself often supports only a single speed, so the set of compatible module bay types for the module type would probably contain just a single element, but the set of compatible module bay types for the module bay may contain multiple elements. The number of supported options looks manageable in this case. If we go to higher speed SFP variants, there could also be restrictions on channelization (e.g., 40 Gbps → 4×10 Gbps, 100 Gbps → 2×50 Gbps or 4×25 Gbps; on some devices only some ports may support some particular variants). So just having, e.g., a single “QSFP28 40 Gbps” module bay type would not be enough — a breakout to 4×10 Gbps would need to specify “QSFP28 4x10 Gbps”, and the module bay would need to declare support for that too. Some higher end switches may support lots of possible configurations here, but there does not seem to be any way around specifying all supported variants if we want to have proper compatibility checking. Another example could be M.2 slots and SSDs. In this case the slot (= module bay) can have only a single key (B or M for slots which could accept SSDs), but the M.2 SSD could have compatibility with only M slots, only B slots (does not really exist in practice), or both B and M slots. In this case, unlike SFP, the set of compatible module bay types for the module type would need to contain multiple elements. But actually the M.2 compatibility issues are more than that — the slot may support only SATA, only PCIe, or both, and the SSD would support only a single kind of interface (either SATA or PCIe). If we want to support such compatibility restrictions while using the “at least one element in common is enough” logic, we would need to define module bay types like: - SATA B-key - SATA M-key - PCIe B-key (there were some lower end SSDs like that) - PCIe M-key But if we want to include the M.2 dimensions (2230, 2242, 2260, 2280, 22110) in the compatibility check too, the list would grow from 4 to 20 possible variations. For normal PCIe slots the situation could be even more complicated — there are at least 4 mostly independent attributes: - Number of lanes (1x, 2x, 4x, 8x, 16x). In this case the module would be compatible with a module bay which supports the same or higher number of lanes (although there is also the issue that the electrical number of lanes might not be the same as the mechanical size of the connector, and apparently there are some cards which outright refuse to work when the number of lanes is too low). - Transfer rate (≈PCIe generation) — not sure whether this needs to be actually included in the compatibility check (in most cases the devices just fall back to a lower rate). - Length (full = 312mm, three-quarter = 254mm, half = 167.65mm). In this case the module would be compatible with a module bay which supports the same or higher length. - Height (full = 111.15mm, half = 68.90mm). In this case the module may be compatible with a module bay which supports the same or higher width, except in some weird cases when the module comes with a low profile bracket, and a full height bracket is not available for some reason. - Width (single slot, dual slot, triple slot). Again, the module would be compatible with a module bay which supports the same or higher width, but there is also the issue of blocking adjacent slots if they are present — however, checking for that is probably too much to expect from NetBox. The problem here is that we would get 5×3×2×3 = 90 combinations of parameters, and large compatibility sets for both the module types and module bays, so including all of those parameters would become problematic if we use just the “at least one element in common is enough” logic. Maybe for now we could ignore the combinatorial explosion issues with complicated cases like PCIe slot variants, and focus on more network-relevant things like SFP modules?

adam referenced this issue

2025-12-29 23:20:41 +01:00

[PR #11324] [MERGED] 11297 have custom field form display content-type instead of model #13767

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#11297