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

Allow config context assign by manufacturer #8957

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

Originally created by @BirknerAlex on GitHub (Dec 13, 2023).

NetBox version

v3.6.5

Feature type

Change to existing functionality

Proposed functionality

Requesting the availability to assign specific config contexts by using specific manufacturers. It would be great if we can select manufacturers for their specifics instead using values like Platforms since that makes it hard to maintain.

Use case

For example, different SSH ports on switches by vendor.

Database changes

No response

External dependencies

No response

Originally created by @BirknerAlex on GitHub (Dec 13, 2023). ### NetBox version v3.6.5 ### Feature type Change to existing functionality ### Proposed functionality Requesting the availability to assign specific config contexts by using specific manufacturers. It would be great if we can select manufacturers for their specifics instead using values like Platforms since that makes it hard to maintain. ### Use case For example, different SSH ports on switches by vendor. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: feature label 2025-12-29 20:43:21 +01:00
adam closed this issue 2025-12-29 20:43:21 +01:00
adam commented 2025-12-29 20:43:21 +01:00
Author
Owner
Copy Link

@ultrapista commented on GitHub (Feb 20, 2024):

In our current infrastructure, we employ a wide array of device types across various series families, encompassing different platforms and vendors. For instance:

  1. Cisco C9000 series
    • 9200-24T,48T,24P,48P
    • 9200L-24T-4X,24P-4X,48T-4X,48P-4X
    • 9500
    • etc.
  2. Cisco C2960X series
  3. HP ProCurve series
  4. Juniper SRX series
  5. etc.

In our operational environment, we aim to utilize config contexts to facilitate Zabbix monitoring setup with templates tailored to each vendor. However, the current config context settings necessitate the manual addition of every individual device type and platform. This process can pose challenges in managing configurations whenever new device models are acquired or firmware versions are upgraded.

We would like to see this change introduced as well.

@ultrapista commented on GitHub (Feb 20, 2024): In our current infrastructure, we employ a wide array of device types across various series families, encompassing different platforms and vendors. For instance: 1. Cisco C9000 series - 9200-24T,48T,24P,48P - 9200L-24T-4X,24P-4X,48T-4X,48P-4X - 9500 - etc. 3. Cisco C2960X series 4. HP ProCurve series 5. Juniper SRX series 6. etc. In our operational environment, we aim to utilize config contexts to facilitate Zabbix monitoring setup with templates tailored to each vendor. However, the current config context settings necessitate the manual addition of every individual device type and platform. This process can pose challenges in managing configurations whenever new device models are acquired or firmware versions are upgraded. We would like to see this change introduced as well.
adam commented 2025-12-29 20:43:21 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 20, 2024):

Configuration contexts are bound to platforms rather than manufacturers because it is the platform which determines the appropriate configuration, not the hardware manufacturer. For example, consider Cisco IOS vs. Cisco NX-OS: Same manufacturer, wildly different platforms and thus different configuration requirements.

However, the current config context settings necessitate the manual addition of every individual device type and platform.

This is not a unique requirement of using config contexts; it is how NetBox is architected to accurately model networks.

@jeremystretch commented on GitHub (Feb 20, 2024): Configuration contexts are bound to platforms rather than manufacturers because it is the platform which determines the appropriate configuration, not the hardware manufacturer. For example, consider Cisco IOS vs. Cisco NX-OS: Same manufacturer, wildly different platforms and thus different configuration requirements. > However, the current config context settings necessitate the manual addition of every individual device type and platform. This is not a unique requirement of using config contexts; it is how NetBox is architected to accurately model networks.
adam commented 2025-12-29 20:43:22 +01:00
Author
Owner
Copy Link

@ultrapista commented on GitHub (Feb 20, 2024):

Configuration contexts are bound to platforms rather than manufacturers because it is the platform which determines the appropriate configuration, not the hardware manufacturer. For example, consider Cisco IOS vs. Cisco NX-OS: Same manufacturer, wildly different platforms and thus different configuration requirements.

Indeed, this is the manner in which we delineate platform specifications within our system. Initially, the platform name commences with the identification of the platform type, followed by the inclusion of the firmware version. For instance:

  • ios-xe 17.6.2
  • nxos 10.2(5)
  • ios 15.2(7)E8

The platform documentation enumerates the versions of these platforms, exemplified by the statement: "Note that two devices of the same type may be assigned different platforms: For example, one Juniper MX240 might run Junos 14 while another runs Junos 15."

To clarify, IOS, IOS-XE, or NX-OS are designated as the platform types, and the specific instances of these versioned platform types should be denoted as Platforms.

Is there an option to implement platform types to NetBox and assign them to config contexts?

@ultrapista commented on GitHub (Feb 20, 2024): > Configuration contexts are bound to platforms rather than manufacturers because it is the platform which determines the appropriate configuration, not the hardware manufacturer. For example, consider Cisco IOS vs. Cisco NX-OS: Same manufacturer, wildly different platforms and thus different configuration requirements. Indeed, this is the manner in which we delineate platform specifications within our system. Initially, the platform name commences with the identification of the platform type, followed by the inclusion of the firmware version. For instance: - ios-xe 17.6.2 - nxos 10.2(5) - ios 15.2(7)E8 The platform documentation enumerates the versions of these platforms, exemplified by the statement: "Note that two devices of the same type may be assigned different platforms: For example, one Juniper MX240 might run Junos 14 while another runs Junos 15." To clarify, IOS, IOS-XE, or NX-OS are designated as the platform types, and the specific instances of these versioned platform types should be denoted as Platforms. Is there an option to implement platform types to NetBox and assign them to config contexts?
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#8957
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?