starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Support Firmware Tracking for Modules #11298

New Issue
Closed
opened 2025-12-29 21:43:13 +01:00 by adam · 9 comments
adam commented 2025-12-29 21:43:13 +01:00
Owner
Copy Link

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

NetBox version

v4.3.2

Feature type

Data model extension

Proposed functionality

In many modern hardware deployments, especially in high-density, modular switch and router platforms, transceivers and interface modules (e.g., SFP, SFP+, SFP28, QSFP28, CFP, and DWDM pluggables) often have upgradable and trackable firmware.

NetBox currently supports firmware version tracking for devices, but not for modules, which limits visibility and lifecycle tracking of critical hardware components installed in modular systems.

Use case

Network operators need to audit and validate firmware versions on pluggable transceivers and line cards.
Tracking firmware across devices is important for:
Security patching
Compatibility with switch OS versions
Vendor recall tracking
Without this, users must maintain external firmware inventories or overload custom fields or tags.

Database changes

No response

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 many modern hardware deployments, especially in high-density, modular switch and router platforms, transceivers and interface modules (e.g., SFP, SFP+, SFP28, QSFP28, CFP, and DWDM pluggables) often have upgradable and trackable firmware. NetBox currently supports firmware version tracking for devices, but not for modules, which limits visibility and lifecycle tracking of critical hardware components installed in modular systems. ### Use case Network operators need to audit and validate firmware versions on pluggable transceivers and line cards. Tracking firmware across devices is important for: Security patching Compatibility with switch OS versions Vendor recall tracking Without this, users must maintain external firmware inventories or overload custom fields or tags. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: feature label 2025-12-29 21:43:13 +01:00
adam closed this issue 2025-12-29 21:43:13 +01:00
adam commented 2025-12-29 21:43:14 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 20, 2025):

This sounds like a great use case for the new module profile types feature introduced in NetBox v4.3. This way, users will be able to set a firmware only for applicable modules.

@jeremystretch commented on GitHub (Jun 20, 2025): This sounds like a great use case for the new [module profile types](https://netboxlabs.com/docs/netbox/models/dcim/moduletypeprofile/) feature introduced in NetBox v4.3. This way, users will be able to set a firmware only for applicable modules.
adam commented 2025-12-29 21:43:14 +01:00
Author
Owner
Copy Link

@0lini commented on GitHub (Jun 21, 2025):

Is it possible to use already defined platforms in modules using those profile types?

@0lini commented on GitHub (Jun 21, 2025): Is it possible to use already defined platforms in modules using those profile types?
adam commented 2025-12-29 21:43:14 +01:00
Author
Owner
Copy Link

@jonzey0 commented on GitHub (Jun 27, 2025):

This sounds like a great use case for the new module profile types feature introduced in NetBox v4.3. This way, users will be able to set a firmware only for applicable modules.

This would work well if all the modules are on the same baseline, because you're effectively setting the firmware at the Module Type level.

Not sure whether this would work in larger environments, where you may (for example) have a large quantity of the same line card across your environment, and you may not be upgrading every single one to the same baseline for various technical, budgetary or other reasons. We often have the same line card across our setups with a few variations of firmware for that reason. Hardware wise, they're the same card, but running on different firmware levels.

@jonzey0 commented on GitHub (Jun 27, 2025): > This sounds like a great use case for the new [module profile types](https://netboxlabs.com/docs/netbox/models/dcim/moduletypeprofile/) feature introduced in NetBox v4.3. This way, users will be able to set a firmware only for applicable modules. This would work well if all the modules are on the same baseline, because you're effectively setting the firmware at the Module Type level. Not sure whether this would work in larger environments, where you may (for example) have a large quantity of the same line card across your environment, and you may not be upgrading every single one to the same baseline for various technical, budgetary or other reasons. We often have the same line card across our setups with a few variations of firmware for that reason. Hardware wise, they're the same card, but running on different firmware levels.
adam commented 2025-12-29 21:43:15 +01:00
Author
Owner
Copy Link

@0lini commented on GitHub (Jul 7, 2025):

That's exactly why I requested this.

@0lini commented on GitHub (Jul 7, 2025): That's exactly why I requested this.
adam commented 2025-12-29 21:43:15 +01:00
Author
Owner
Copy Link

@0lini commented on GitHub (Jul 7, 2025):

In my use case, we deploy the same type of sfp modules with different firmware on them (to support different manufacturers).

@0lini commented on GitHub (Jul 7, 2025): In my use case, we deploy the same type of sfp modules with different firmware on them (to support different manufacturers).
adam commented 2025-12-29 21:43:15 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 7, 2025):

NetBox currently supports firmware version tracking for devices

NetBox has a platform model, which can be specified for device and virtual machines; is that what you mean? Is the proposal here to add a platform field on the Module model as well? That seems like it would be confusing.

I'm not clear on what the proposed implementation is.

@jeremystretch commented on GitHub (Aug 7, 2025): > NetBox currently supports firmware version tracking for devices NetBox has a platform model, which can be specified for device and virtual machines; is that what you mean? Is the proposal here to add a `platform` field on the Module model as well? That seems like it would be confusing. I'm not clear on what the proposed implementation is.
adam commented 2025-12-29 21:43:16 +01:00
Author
Owner
Copy Link

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

Hi @jeremystretch yeah I was talking about the platform model. Modules should be able to be assigned platforms as well.

@0lini commented on GitHub (Aug 8, 2025): Hi @jeremystretch yeah I was talking about the platform model. Modules should be able to be assigned platforms as well.
adam commented 2025-12-29 21:43:16 +01:00
Author
Owner
Copy Link

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

Or there could be another model similar to platforms that does firmware tracking.

@0lini commented on GitHub (Aug 8, 2025): Or there could be another model similar to platforms that does firmware tracking.
adam commented 2025-12-29 21:43:16 +01:00
Author
Owner
Copy Link

@arthanson commented on GitHub (Sep 11, 2025):

In this case we would recommend using a custom field to enable this functionality which should work.

Per Jeremy's comment adding platform to the Module model would be confusion. If you feel there should still be a separate feature request for this, a more detailed proposed solution should be outlined as it's not clear what the proposed implementation is.

@arthanson commented on GitHub (Sep 11, 2025): In this case we would recommend using a custom field to enable this functionality which should work. Per Jeremy's comment adding platform to the Module model would be confusion. If you feel there should still be a separate feature request for this, a more detailed proposed solution should be outlined as it's not clear what the proposed implementation is.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#11298
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?