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

IPAM - Custom "Roles" for IP addresses - similar to new custom status function in v3.2 #6273

New Issue
Closed
opened 2025-12-29 19:38:48 +01:00 by adam · 4 comments
adam commented 2025-12-29 19:38:48 +01:00
Owner
Copy Link

Originally created by @ITJamie on GitHub (Mar 30, 2022).

NetBox version

3.1.10

Feature type

Change to existing functionality

Proposed functionality

Allow custom IP Roles for ip address.
right now its limited to "loopback, secondary, anycast, vip, vrrp, hsrp, glbp, carp".
being able to add custom roles would be useful for internal usecases.
other usecases:

  • ptp - point to point links
  • primary - wanting to mark the primary ip of a pair of fw's
  • management - marking ips as mgmt ips

Use case

Other parts of netbox has customisable "role"types (racks,devices,contacts). ip-addresses does not.
considering https://github.com/netbox-community/netbox/issues/8054 has allowed the overwriting of built in status's, I think we should offer the same functionality to ip-addresses roles.

Having custom role functionality allows for clearer display of an ip's purpose. Otherwise this same data ends up in the large sea of custom fields.

Database changes

No response

External dependencies

No response

Originally created by @ITJamie on GitHub (Mar 30, 2022). ### NetBox version 3.1.10 ### Feature type Change to existing functionality ### Proposed functionality Allow custom IP Roles for ip address. right now its limited to "loopback, secondary, anycast, vip, vrrp, hsrp, glbp, carp". being able to add custom roles would be useful for internal usecases. other usecases: - ptp - point to point links - primary - wanting to mark the primary ip of a pair of fw's - management - marking ips as mgmt ips ### Use case Other parts of netbox has customisable "role"types (racks,devices,contacts). ip-addresses does not. considering https://github.com/netbox-community/netbox/issues/8054 has allowed the overwriting of built in status's, I think we should offer the same functionality to ip-addresses roles. Having custom role functionality allows for clearer display of an ip's purpose. Otherwise this same data ends up in the large sea of custom fields. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: feature label 2025-12-29 19:38:48 +01:00
adam closed this issue 2025-12-29 19:38:48 +01:00
adam commented 2025-12-29 19:38:49 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 30, 2022):

The role attribute choices aren't customizable because they're not arbitrary.

ptp - point to point links

Whether an IP address is suitable for use on a point-to-point link is a function of its mask. You would not designate a /24 IPv4 address as point-to-point.

primary - wanting to mark the primary ip of a pair of fw's

Primary for what? the designation of an IP as primary for anything depends on a context. If it's the primary IP for a device, then you designate it as such using the device's primary_ip attribute.

management - marking ips as mgmt ips

NetBox tracks this via the interface model: Interfaces can be designated as management interfaces, and any IP addresses associated with those interfaces are thus considered management IPs.

@jeremystretch commented on GitHub (Mar 30, 2022): The role attribute choices aren't customizable because they're not arbitrary. > ptp - point to point links Whether an IP address is suitable for use on a point-to-point link is a function of its mask. You would not designate a /24 IPv4 address as point-to-point. > primary - wanting to mark the primary ip of a pair of fw's Primary for what? the designation of an IP as primary for anything depends on a context. If it's the primary IP for a device, then you designate it as such using the device's `primary_ip` attribute. > management - marking ips as mgmt ips NetBox tracks this via the interface model: Interfaces can be designated as management interfaces, and any IP addresses associated with those interfaces are thus considered management IPs.
adam commented 2025-12-29 19:38:49 +01:00
Author
Owner
Copy Link

@bwm-digitalc commented on GitHub (Mar 30, 2022):

Jeremy, I'll provide an example that might help - I have a Nutanix cluster. They use a "floating" management IP for the cluster - it does not use HSRP or VRRP or CARP or any other listed methodology to handle the ownership of that IP, but it does dynamically move around between the cluster nodes.

It's not really a "secondary" IP, because it's intended as the main management interface for the cluster, although it is technically a "secondary" to the actual node's local IP.

What "IP Role" is that sort of device supposed to have, or should it just be left blank? In my head, it behaves somewhat like a VRRP IP, so I feel like some sort of "Role" should be defined... but the system I'm working with doesn't actually use any of the listed methods.

I feel like people might be less inclined to ask for customization here if it had a different name, too. I see "IP Role" and my mind goes to, "what is this address doing / being used for." Obviously you should be able to derive that from knowing what it is attached/assigned to... but some of us don't necessarily have the luxury of defining all of the equipment in all cases. In those instances, a way to define the address's "intended usage" is desirable and helpful.

@bwm-digitalc commented on GitHub (Mar 30, 2022): Jeremy, I'll provide an example that might help - I have a Nutanix cluster. They use a "floating" management IP for the cluster - it does **not** use HSRP or VRRP or CARP or any other listed methodology to handle the ownership of that IP, but it does dynamically move around between the cluster nodes. It's not really a "secondary" IP, because it's intended as the main management interface for the cluster, although it is technically a "secondary" to the actual node's local IP. What "IP Role" is that sort of device supposed to have, or should it just be left blank? In my head, it behaves somewhat like a VRRP IP, so I feel like some sort of "Role" should be defined... but the system I'm working with doesn't actually *use* any of the listed methods. I feel like people might be less inclined to ask for customization here if it had a different name, too. I see "IP Role" and my mind goes to, "what is this address doing / being used for." Obviously you should be able to derive that from knowing what it is attached/assigned to... but some of us don't necessarily have the luxury of defining all of the equipment in all cases. In those instances, a way to define the address's "intended usage" is desirable and helpful.
adam commented 2025-12-29 19:38:49 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 30, 2022):

What "IP Role" is that sort of device supposed to have, or should it just be left blank?

This would be a virtual IP (VIP), which is one of the available role choices.

@jeremystretch commented on GitHub (Mar 30, 2022): > What "IP Role" is that sort of device supposed to have, or should it just be left blank? This would be a virtual IP (VIP), which is one of the available role choices.
adam commented 2025-12-29 19:38:50 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 4, 2022):

I'm going to close this as the proposal conflicts with an intentional design choice.

@jeremystretch commented on GitHub (Apr 4, 2022): I'm going to close this as the proposal conflicts with an intentional design choice.
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#6273
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?