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

Add part number field to DeviceType #214

New Issue
Closed
opened 2025-12-29 16:19:33 +01:00 by adam · 5 comments
adam commented 2025-12-29 16:19:33 +01:00
Owner
Copy Link

Originally created by @ryanmerolle on GitHub (Jul 14, 2016).

I know that this tool will use RPC (ssh/netconf/etc.) instead of SNMP when interacting with devices, but with other DCIM I have seen issues with model numbers polled do not even resemble the official model numbers. As such, this has forced the need for model names, model numbers, an aliases for when odd SNMP model numbers are presented.

Regardless, I am just thinking about how we can enhance this object. Furthermore, how should we handle the various variations of switch like the Catalyst 3750? What are your thoughts on:

  • device type alias (to handle model numbers as well as potentially variations)
  • model/part number to handle the technical part number (normally hyphenated) - This would force you to create a device type for every variation of a model (not necessarily bad given the port count and speed variations)
Originally created by @ryanmerolle on GitHub (Jul 14, 2016). I know that this tool will use RPC (ssh/netconf/etc.) instead of SNMP when interacting with devices, but with other DCIM I have seen issues with model numbers polled do not even resemble the official model numbers. As such, this has forced the need for model names, model numbers, an aliases for when odd SNMP model numbers are presented. Regardless, I am just thinking about how we can enhance this object. Furthermore, how should we handle the various variations of switch like the Catalyst 3750? What are your thoughts on: - device type alias (to handle model numbers as well as potentially variations) - model/part number to handle the technical part number (normally hyphenated) - This would force you to create a device type for every variation of a model (not necessarily bad given the port count and speed variations)
adam closed this issue 2025-12-29 16:19:33 +01:00
adam commented 2025-12-29 16:19:33 +01:00
Author
Owner
Copy Link

@bellwood commented on GitHub (Jul 14, 2016):

For my cisco switches I do a show version and use say:

-WS-C3750E-24
-WS-C4948-10GE
-WS-C3750E-48

I don't have any POE models and am agnostic to IPbase vs IPservices so I don't bother to store the bits after that typically indicate the licensing included, POE, or other - but - if I did I would include them - there are though as you say so many variations that it's not (in my application) worth tracking it that granularly.

Each of these are their own device type with corresponding interfaces pre-set (sans VLANs)

@bellwood commented on GitHub (Jul 14, 2016): For my cisco switches I do a `show version` and use say: -WS-C3750E-24 -WS-C4948-10GE -WS-C3750E-48 I don't have any POE models and am agnostic to IPbase vs IPservices so I don't bother to store the bits after that typically indicate the licensing included, POE, or other - but - if I did I would include them - there are though as you say so many variations that it's not (in my application) worth tracking it that granularly. Each of these are their own device type with corresponding interfaces pre-set (sans VLANs)
adam commented 2025-12-29 16:19:34 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 14, 2016):

How should we handle the various variations of switch like the Catalyst 3750?

Each variation is its own device type. Even a minimal difference between models (e.g. PoE versus non-PoE) is still a difference and needs to be accounted for. At most we might introduce the concept of a series to group similar devices, but that would just be for convenience.

@jeremystretch commented on GitHub (Jul 14, 2016): > How should we handle the various variations of switch like the Catalyst 3750? Each variation is its own device type. Even a minimal difference between models (e.g. PoE versus non-PoE) is still a difference and needs to be accounted for. At most we might introduce the concept of a series to group similar devices, but that would just be for convenience.
adam commented 2025-12-29 16:19:34 +01:00
Author
Owner
Copy Link

@ryanmerolle commented on GitHub (Jul 14, 2016):

Yea I'm with you on series for connivence, its really not absolutely needed. But what are your thoughts on model / part number. IE Part Name (Catalyst 3750X 48T-S) vs the official part number (WS-C3750X-48T-S).

@ryanmerolle commented on GitHub (Jul 14, 2016): Yea I'm with you on series for connivence, its really not absolutely needed. But what are your thoughts on model / part number. IE Part Name (Catalyst 3750X 48T-S) vs the official part number (WS-C3750X-48T-S).
adam commented 2025-12-29 16:19:34 +01:00
Author
Owner
Copy Link

@bellwood commented on GitHub (Jul 14, 2016):

I can see value in having a field for part/model.

We have some Cisco 3500 series switches that all say on the chassis they are WS-3500-something but show version could be a WS-3524 or WS-3548, etc

So it becomes, do I make a type for each based on show verison or do I stick with what the chassis shows and notate it elsewhere.

Not sure how other manufacturers stack up but another use case to validate would be great otherwise we're essentially storing redundant information.

@bellwood commented on GitHub (Jul 14, 2016): I can see value in having a field for part/model. We have some Cisco 3500 series switches that all say on the chassis they are `WS-3500-something` but show version could be a WS-3524 or WS-3548, etc So it becomes, do I make a type for each based on `show verison` or do I stick with what the chassis shows and notate it elsewhere. Not sure how other manufacturers stack up but another use case to validate would be great otherwise we're essentially storing redundant information.
adam commented 2025-12-29 16:19:34 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 20, 2016):

Intending to implement this as a new (optional) free-form part_number field on DeviceType.

@jeremystretch commented on GitHub (Jul 20, 2016): Intending to implement this as a new (optional) free-form `part_number` field on `DeviceType`.
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
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#214
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?