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

PortProfiles for Interfaces #11102

New Issue
Open
opened 2025-12-29 21:40:21 +01:00 by adam · 4 comments
adam commented 2025-12-29 21:40:21 +01:00
Owner
Copy Link

Originally created by @PieterL75 on GitHub (Apr 30, 2025).

NetBox version

v4.1.11

Feature type

New functionality

Proposed functionality

I would like to see a new feature (lets call it portprofile) that defines an interface configuration, and that is applied to an Interface.
Any change to the port profile would reflect to the configuration of the interface it is linked to.

Fields that (at the minimum) should be part of the profile

  • MTU
  • Status
  • Management Only
  • PoE mode
  • PoE type
  • 801.Q Mode
  • VLAN Group
  • Untagged VLAN
  • Tagged VLANs
  • Custom Fields that exists on the interfaces

I never used the VRF/Wireless part, so someone needs to see if those fields could be added to.

Fields that indicate the physical state of an interface are to be reviewed if it makes sense to add them. I don't think the Label/Type/Speed/Duplex/Description/Tags/MAC/WWN are eligible

When a profile is applied to an interface, the fields that are defined in the template should

  • become readonly in the edit field
  • (marked with an * in the list/model view) not sure if this is really needed

Use case

On our switches, we use 'port profiles' to create a single configuration view for multiple interfaces.
This ensures that all interfaces have the same settings.

The ability to define port-profiles in NetBox would also enable us to

  • keep interface configurations in sync
  • use these profiles for automation and create device configurations

Database changes

A new model PortProfile is needed
It needs to contain a relation to the dcim.interfaces it is applied to
It needs to contain all fields that are eligible for the portprofile, with the same restrictions/rules as the interface field has
Depending on the fleshout of this FR, the fields could change

External dependencies

No response

Originally created by @PieterL75 on GitHub (Apr 30, 2025). ### NetBox version v4.1.11 ### Feature type New functionality ### Proposed functionality I would like to see a new feature (lets call it portprofile) that defines an interface configuration, and that is applied to an Interface. Any change to the port profile would reflect to the configuration of the interface it is linked to. Fields that (at the minimum) should be part of the profile - MTU - Status - Management Only - PoE mode - PoE type - 801.Q Mode - VLAN Group - Untagged VLAN - Tagged VLANs - Custom Fields that exists on the interfaces I never used the VRF/Wireless part, so someone needs to see if those fields could be added to. Fields that indicate the physical state of an interface are to be reviewed if it makes sense to add them. I don't think the Label/Type/Speed/Duplex/Description/Tags/MAC/WWN are eligible When a profile is applied to an interface, the fields that are defined in the template should - become readonly in the edit field - (marked with an * in the list/model view) not sure if this is really needed ### Use case On our switches, we use 'port profiles' to create a single configuration view for multiple interfaces. This ensures that all interfaces have the same settings. The ability to define port-profiles in NetBox would also enable us to - keep interface configurations in sync - use these profiles for automation and create device configurations ### Database changes A new model PortProfile is needed It needs to contain a relation to the dcim.interfaces it is applied to It needs to contain all fields that are eligible for the portprofile, with the same restrictions/rules as the interface field has Depending on the fleshout of this FR, the fields could change ### External dependencies _No response_
adam added the type: featurenetboxstatus: backlogcomplexity: high labels 2025-12-29 21:40:21 +01:00
adam commented 2025-12-29 21:40:22 +01:00
Author
Owner
Copy Link

@chris240189 commented on GitHub (Apr 30, 2025):

I have written custom scripts that reset or prefill (copy from another interface) interface attributes of some sort.

Basically all you need is a custom script, that takes (a list of) interfaces as an argument and a drop down box to select your profile which then sets the attributes to your liking.

Thinking about how port profiles work on some network devices, they give you a base profile from which you can still deviate from (interface profile override). It can be messy though.

@chris240189 commented on GitHub (Apr 30, 2025): I have written custom scripts that reset or prefill (copy from another interface) interface attributes of some sort. Basically all you need is a custom script, that takes (a list of) interfaces as an argument and a drop down box to select your profile which then sets the attributes to your liking. Thinking about how port profiles work on some network devices, they give you a base profile from which you can still deviate from (interface profile override). It can be messy though.
adam commented 2025-12-29 21:40:22 +01:00
Author
Owner
Copy Link

@arthanson commented on GitHub (May 1, 2025):

This is an interesting idea, it should be made more generic as it could be used in other areas in NetBox, it is somewhat similar to DeviceTypes. This could potentially be made into a Plugin, but more research would be needed. Will keep it open but more research is needed.

@arthanson commented on GitHub (May 1, 2025): This is an interesting idea, it should be made more generic as it could be used in other areas in NetBox, it is somewhat similar to DeviceTypes. This could potentially be made into a Plugin, but more research would be needed. Will keep it open but more research is needed.
adam commented 2025-12-29 21:40:22 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (May 1, 2025):

The biggest difference with device types, is that changes made to the profile must reflect to all items linked to it.
A device type is only used to set the base to create a model.

@PieterL75 commented on GitHub (May 1, 2025): The biggest difference with device types, is that changes made to the profile must reflect to all items linked to it. A device type is only used to set the base to create a model.
adam commented 2025-12-29 21:40:22 +01:00
Author
Owner
Copy Link

@alehaa commented on GitHub (Jul 1, 2025):

I support this feature request because it would enhance configuration consistency. Currently, our instance manages approximately 16,000 interfaces, and depending on the specific requirements of our users, we need to configure several parameters. By utilizing port profiles, we can simplify the configuration process. Users would simply select a template for common types of interfaces, such as clients or printers, instead of manually configuring each interface (and potentially forgetting one).

I believe this can be implemented quite easily because there’s already an abstract Model in NetBox that covers many interface fields: BaseInterface. I propose reusing this model and the same logic as for RackType to clone fields as needed, thereby replicating changes into interfaces using this template.

I volunteer to draft a PR for review.

@alehaa commented on GitHub (Jul 1, 2025): I support this feature request because it would enhance configuration consistency. Currently, our instance manages approximately 16,000 interfaces, and depending on the specific requirements of our users, we need to configure several parameters. By utilizing port profiles, we can simplify the configuration process. Users would simply select a template for common types of interfaces, such as clients or printers, instead of manually configuring each interface (and potentially forgetting one). I believe this can be implemented quite easily because there’s already an abstract Model in NetBox that covers many interface fields: [BaseInterface](https://github.com/netbox-community/netbox/blob/main/netbox/dcim/models/device_components.py#L512). I propose reusing this model and the same logic as for `RackType` to clone fields as needed, thereby replicating changes into interfaces using this template. I volunteer to draft a PR for review.
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 complexity: high netbox status: backlog 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#11102
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?