Module Bay Profile Support #1472

New Issue

MrUnknownDE · 2026-04-06T02:05:04+02:00

MrUnknownDE commented

2026-04-06 02:05:04 +02:00

Originally created by @bitcollector1 on 8/12/2025

NetBox version

v4.3.5

Feature type

New functionality

Proposed functionality

A single device type can have multiple SFP module profiles depending on the config applied or it's place in the network. For instance I have a switch that supports the following breakouts, each requiring a unique module profile.

64 800Gb OSFP Ports
128 400Gb OSFP Ports
256 200Gb OSFP Ports
512 100Gb OSFP Ports

It's very time consuming to recreate these in the GUI and I have not gotten around to scripting this new functionality up yet.

Here's an example:

Description:  (64) 800GbE OSFP Ports
Name: Ethernet[0,8,16,24,32,40,48,56,64,72,80,88,96,104,112,120,128,136,144,152,160,168,176,184,192,200,208,216,224,232,240,248,256,264,272,280,288,296,304,312,320,328,336,344,352,360,368,376,384,392,400,408,416,424,432,440,448,456,464,472,480,488,496,504]
Label:       Eth[1-64]/1
Position:    [1-64]

Description:    (2) SFP28 Ports
Name:           Ethernet[512,513]
Label:          Eth[65,66]/1
Position:       [65,66]

Description:  (128) 400Gbps OSFP ports
Name: Ethernet[0,4,8,12,16,20,24,28,32,36,40,44,48,52,56,60,64,68,72,76,80,84,88,92,96,100,104,108,112,116,120,124,128,132,136,140,144,148,152,156,160,164,168,172,176,180,184,188,192,196,200,204,208,212,216,220,224,228,232,236,240,244,248,252,256,260,264,268,272,276,280,284,288,292,296,300,304,308,312,316,320,324,328,332,336,340,344,348,352,356,360,364,368,372,376,380,384,388,392,396,400,404,408,412,416,420,424,428,432,436,440,444,448,452,456,460,464,468,472,476,480,484,488,492,496,500,504,508]
Label:       Eth[1-64]/[1-2]
Position:    [1-64]/[1-2]

Description:    (2) SFP28 Ports
Name:           Ethernet[512,513]
Label:          Eth[65,66]/1
Position:       [65,66]

Description: (256) 200Gbps OSFP ports
Name: Ethernet[0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46,48,50,52,54,56,58,60,62,64,66,68,70,72,74,76,78,80,82,84,86,88,90,92,94,96,98,100,102,104,106,108,110,112,114,116,118,120,122,124,126,128,130,132,134,136,138,140,142,144,146,148,150,152,154,156,158,160,162,164,166,168,170,172,174,176,178,180,182,184,186,188,190,192,194,196,198,200,202,204,206,208,210,212,214,216,218,220,222,224,226,228,230,232,234,236,238,240,242,244,246,248,250,252,254,256,258,260,262,264,266,268,270,272,274,276,278,280,282,284,286,288,290,292,294,296,298,300,302,304,306,308,310,312,314,316,318,320,322,324,326,328,330,332,334,336,338,340,342,344,346,348,350,352,354,356,358,360,362,364,366,368,370,372,374,376,378,380,382,384,386,388,390,392,394,396,398,400,402,404,406,408,410,412,414,416,418,420,422,424,426,428,430,432,434,436,438,440,442,444,446,448,450,452,454,456,458,460,462,464,466,468,470,472,474,476,478,480,482,484,486,488,490,492,494,496,498,500,502,504,506,508,510]
Label:       Eth[1-64]/[1-4]
Position:    [1-64]/[1-4]

Description:    SFP28 Ports
Name:           Ethernet[512,513]
Label:          Eth[65,66]/1
Position:       [65,66]

Description: (512) 100Gbps OSFP ports
Name:        Ethernet[0-511]
Label:       Eth[1-64]/[1-8]
Position:    [1-64]/[1-8]

Description:    SFP28 Ports
Name:           Ethernet[512,513]
Label:          Eth[65,66]/1
Position:       [65,66]

(Module Type) Name:  Port{module}    --> Added as an Interface to the SFP Module Types

Use case

NetBox users can store multiple SFP profiles for a given switch and apply one depending on the config that has been applied, or even the place in the network the device resides.

Currently it's very time consuming and confusing for new users to figure this all out.

Database changes

I would envision a change needed to tie the module profiles to a given device type.

External dependencies

No clue

*Originally created by @bitcollector1 on 8/12/2025* ### NetBox version v4.3.5 ### Feature type New functionality ### Proposed functionality A single device type can have multiple SFP module profiles depending on the config applied or it's place in the network. For instance I have a switch that supports the following breakouts, each requiring a unique module profile. - 64 800Gb OSFP Ports - 128 400Gb OSFP Ports - 256 200Gb OSFP Ports - 512 100Gb OSFP Ports It's very time consuming to recreate these in the GUI and I have not gotten around to scripting this new functionality up yet. Here's an example: ``` Description: (64) 800GbE OSFP Ports Name: Ethernet[0,8,16,24,32,40,48,56,64,72,80,88,96,104,112,120,128,136,144,152,160,168,176,184,192,200,208,216,224,232,240,248,256,264,272,280,288,296,304,312,320,328,336,344,352,360,368,376,384,392,400,408,416,424,432,440,448,456,464,472,480,488,496,504] Label: Eth[1-64]/1 Position: [1-64] Description: (2) SFP28 Ports Name: Ethernet[512,513] Label: Eth[65,66]/1 Position: [65,66] ``` --- ``` Description: (128) 400Gbps OSFP ports Name: Ethernet[0,4,8,12,16,20,24,28,32,36,40,44,48,52,56,60,64,68,72,76,80,84,88,92,96,100,104,108,112,116,120,124,128,132,136,140,144,148,152,156,160,164,168,172,176,180,184,188,192,196,200,204,208,212,216,220,224,228,232,236,240,244,248,252,256,260,264,268,272,276,280,284,288,292,296,300,304,308,312,316,320,324,328,332,336,340,344,348,352,356,360,364,368,372,376,380,384,388,392,396,400,404,408,412,416,420,424,428,432,436,440,444,448,452,456,460,464,468,472,476,480,484,488,492,496,500,504,508] Label: Eth[1-64]/[1-2] Position: [1-64]/[1-2] Description: (2) SFP28 Ports Name: Ethernet[512,513] Label: Eth[65,66]/1 Position: [65,66] ``` --- ``` Description: (256) 200Gbps OSFP ports Name: Ethernet[0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46,48,50,52,54,56,58,60,62,64,66,68,70,72,74,76,78,80,82,84,86,88,90,92,94,96,98,100,102,104,106,108,110,112,114,116,118,120,122,124,126,128,130,132,134,136,138,140,142,144,146,148,150,152,154,156,158,160,162,164,166,168,170,172,174,176,178,180,182,184,186,188,190,192,194,196,198,200,202,204,206,208,210,212,214,216,218,220,222,224,226,228,230,232,234,236,238,240,242,244,246,248,250,252,254,256,258,260,262,264,266,268,270,272,274,276,278,280,282,284,286,288,290,292,294,296,298,300,302,304,306,308,310,312,314,316,318,320,322,324,326,328,330,332,334,336,338,340,342,344,346,348,350,352,354,356,358,360,362,364,366,368,370,372,374,376,378,380,382,384,386,388,390,392,394,396,398,400,402,404,406,408,410,412,414,416,418,420,422,424,426,428,430,432,434,436,438,440,442,444,446,448,450,452,454,456,458,460,462,464,466,468,470,472,474,476,478,480,482,484,486,488,490,492,494,496,498,500,502,504,506,508,510] Label: Eth[1-64]/[1-4] Position: [1-64]/[1-4] Description: SFP28 Ports Name: Ethernet[512,513] Label: Eth[65,66]/1 Position: [65,66] ``` --- ``` Description: (512) 100Gbps OSFP ports Name: Ethernet[0-511] Label: Eth[1-64]/[1-8] Position: [1-64]/[1-8] Description: SFP28 Ports Name: Ethernet[512,513] Label: Eth[65,66]/1 Position: [65,66] ``` --- ``` (Module Type) Name: Port{module} --> Added as an Interface to the SFP Module Types ``` ### Use case NetBox users can store multiple SFP profiles for a given switch and apply one depending on the config that has been applied, or even the place in the network the device resides. Currently it's very time consuming and confusing for new users to figure this all out. ### Database changes I would envision a change needed to tie the module profiles to a given device type. ### External dependencies No clue

MrUnknownDE closed this issue

2026-04-06 02:05:04 +02:00

Sign in to join this conversation.

Branches Tags

main

21455-sql-indexes-audit

21357-register-model-actions

feature

20924-plugin-ui-components

21766-improve-test-coverage-for-sortable-table-columns

21157-export-template-public-models

21025-pre-render-config-contexts

21364-swagger

feature-ip-prefix-link

20911-dropdown-3

fix_module_substitution

21160-filterset

20911-dropdown-2

20044-elevation-stuck-lightmode

7604-filter-modifiers-v3

20660-script-load

19724-graphql

14884-script

19720-macaddress-interface-generic-relation

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

No Label status: revisions needed status: revisions needed status: revisions needed status: revisions needed status: revisions needed status: revisions needed status: revisions needed status: revisions needed status: revisions needed status: revisions needed status: revisions needed status: revisions needed status: revisions needed status: revisions needed status: revisions needed status: revisions needed status: revisions needed status: revisions needed status: revisions needed status: revisions needed status: revisions needed status: revisions needed status: revisions needed status: revisions needed status: revisions needed status: revisions needed status: revisions needed type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/netbox#1472