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 #7350

New Issue
Closed
opened 2025-12-29 20:22:11 +01:00 by adam · 1 comment
adam commented 2025-12-29 20:22:11 +01:00
Owner
Copy Link

Originally created by @aleheux-tc on GitHub (Dec 13, 2022).

NetBox version

v3.3.9

Feature type

Change to existing functionality

Proposed functionality

Make the list or roles completely configurable.

Every platform, every network, every situation has unique requirements and there is no one fixed list that could possibly 1. make sense and 2. be useful.

I would comment on https://github.com/netbox-community/netbox/issues/9000 but that's been locked.

Use case

This is not the first time this is requested:

https://github.com/netbox-community/netbox/issues/9000

That issue was closed with a comment of "I'm going to close this as the proposal conflicts with an intentional design choice". The design choice being to limit the roles to an arbitrary list because "they [the roles] are not arbitrary"

Let's examine the current list:

Loopback - This is a role that's attributed to interfaces, not IPs. Any IP assigned to a loopback interface is a loopback IP. No IP assigned to a different interface is ever a loopback IP. This is not even arbitrary, this doesn't even make any sense.

Secondary - Some platforms (Cisco) have the concept of Secondary IPs on interfaces. Other platforms (Juniper) have the opposite, some IPs on an interface can be marked as Primary. Other platforms (*nix) have neither. Why include Secondary but not Primary? Arbitrary.

Anycast - IPs are not "anycast". Anycast is a routing design pattern. This is even worse than "loopback"

VIP - Ok, IPs can be Virtual IPs and on some platforms this is a useful distinction to make, like in the case of VRRP. Although to properly define VRRP on an interface one needs a lot more than just a "VIP" tag on an IP address.

VRRP - Wait. Didn't we already have a VIP role? Now what?

This shows that the existing list is completely arbitrary. It's possible that the current list makes sense on some platform out there or in some specific network, but it's not at all generic or in any way a standard list of roles.

Allowing the list of role to be customized would make this field actually usable for its intended purpose.

Database changes

No response

External dependencies

No response

Originally created by @aleheux-tc on GitHub (Dec 13, 2022). ### NetBox version v3.3.9 ### Feature type Change to existing functionality ### Proposed functionality Make the list or roles completely configurable. Every platform, every network, every situation has unique requirements and there is no one fixed list that could possibly 1. make sense and 2. be useful. I would comment on https://github.com/netbox-community/netbox/issues/9000 but that's been locked. ### Use case This is not the first time this is requested: https://github.com/netbox-community/netbox/issues/9000 That issue was closed with a comment of "I'm going to close this as the proposal conflicts with an intentional design choice". The design choice being to limit the roles to an arbitrary list because "they [the roles] are not arbitrary" Let's examine the current list: Loopback - This is a role that's attributed to interfaces, not IPs. Any IP assigned to a loopback interface is a loopback IP. No IP assigned to a different interface is ever a loopback IP. This is not even arbitrary, this doesn't even make any sense. Secondary - Some platforms (Cisco) have the concept of Secondary IPs on interfaces. Other platforms (Juniper) have the opposite, some IPs on an interface can be marked as Primary. Other platforms (*nix) have neither. Why include Secondary but not Primary? Arbitrary. Anycast - IPs are not "anycast". Anycast is a routing design pattern. This is even worse than "loopback" VIP - Ok, IPs can be Virtual IPs and on some platforms this is a useful distinction to make, like in the case of VRRP. Although to properly define VRRP on an interface one needs a lot more than just a "VIP" tag on an IP address. VRRP - Wait. Didn't we already have a VIP role? Now what? This shows that the existing list is completely arbitrary. It's possible that the current list makes sense on _some_ platform out there or in _some_ specific network, but it's not at all generic or in any way a standard list of roles. Allowing the list of role to be customized would make this field actually usable for its intended purpose. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: featurestatus: duplicate labels 2025-12-29 20:22:11 +01:00
adam closed this issue 2025-12-29 20:22:12 +01:00
adam commented 2025-12-29 20:22:12 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 13, 2022):

This topic has already been beaten to death, and I'm not going to rehash the discussion every time someone takes issue with it. The available roles are clearly documented, and each serves a distinct purpose. If you're not happy with the available choices, you're free to fork NetBox and make whatever changed you'd like to meet your needs.

@jeremystretch commented on GitHub (Dec 13, 2022): This topic has already been beaten to death, and I'm not going to rehash the discussion every time someone takes issue with it. The available roles are [clearly documented](https://docs.netbox.dev/en/stable/models/ipam/ipaddress/#role), and each serves a distinct purpose. If you're not happy with the available choices, you're free to fork NetBox and make whatever changed you'd like to meet your needs.
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 status: duplicate 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#7350
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?