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

Disassociate between interface FHRP group assignment options and interface IP address #10927

New Issue
Closed
opened 2025-12-29 21:37:52 +01:00 by adam · 1 comment
adam commented 2025-12-29 21:37:52 +01:00
Owner
Copy Link

Originally created by @hzc12321 on GitHub (Mar 21, 2025).

Proposed Changes

In other words, deprecate "only FHRP groups with a related IP address assigned are displayed as options" when assigning FHRP groups to interfaces

I'm using FHRP groups to represent the mapping between F5 load-balanced service VIPs and the actual servers behind it, and noticed this behaviour complicated everything.
Reference :

I have encountered a similar issue, but this : https://github.com/netbox-community/netbox/issues/8435 explained it. Seems like once the interface has an IP address assigned, only FHRP groups with a related IP address assigned are displayed as options. While this makes sense in some use case, it becomes an obstacle for certain use cases.

In my use case, the FHRP group maps between a load balanced VIP and the real IPs on the VM interfaces. Once I have the FHRP group ready, I must first assign FHRP group before assigning real IP to the interface, if not, and if the VIP and real IP do not belong to the same subnet (related), the FHRP group option will disappear.

I would suggest this behaviour to be removed, as it is not a globally applicable scenario, it brings inconvenience to other use cases while bringing convenience to certain use cases. Plus, the purpose of "Avoiding the user from having to select from hundreds of potential groups" is already achieved by allowing user to type and quick search within the column.

Originally posted by @hzc12321 in #18696

Justification

It assumed too much details about the use case, and brings restrictions based on that assumption, but the assumption is not globally appplicable and unnecessary.

It can get worse :
Whenever when there is a need to assign a new FHRP group to an interface with existing IP address and FHRP group assigned, I have to first unassign all the IP addresses which are not under the same parent prefix as the new FHRP group. Then, after assigning the FHRP group to the interface, assign all the IPs back to the interface.

Due to this behaviour, issues like these are likely to be raised repeatedly by different persons over time:
https://github.com/netbox-community/netbox/issues/8435
https://github.com/netbox-community/netbox/issues/18696

It's not a must that each interface's IP address is under the same parent prefix as the FHRP group's VIP, there could be additional mechanisms like NAT or ARP proxying in the middle. Plus, it occurs frequently.

Impact

  • Users are now free to decide which FHRP group to assign to an interface, without considering IP addresses assigned on that interface.
  • In case if there are hundreds of FHRP groups, the user can type and quick search during FHRP group assignment, and therefore does not affect the overall usability.
Originally created by @hzc12321 on GitHub (Mar 21, 2025). ### Proposed Changes In other words, deprecate "only FHRP groups with a related IP address assigned are displayed as options" when assigning FHRP groups to interfaces I'm using FHRP groups to represent the mapping between F5 load-balanced service VIPs and the actual servers behind it, and noticed this behaviour complicated everything. Reference : > I have encountered a similar issue, but this :[ https://github.com/netbox-community/netbox/issues/8435](https://github.com/netbox-community/netbox/issues/8435) explained it. Seems like once the interface has an IP address assigned, only FHRP groups with a related IP address assigned are displayed as options. While this makes sense in some use case, it becomes an obstacle for certain use cases. > > In my use case, the FHRP group maps between a load balanced VIP and the real IPs on the VM interfaces. Once I have the FHRP group ready, I must first assign FHRP group before assigning real IP to the interface, if not, and if the VIP and real IP do not belong to the same subnet (related), the FHRP group option will disappear. > > I would suggest this behaviour to be removed, as it is not a globally applicable scenario, it brings inconvenience to other use cases while bringing convenience to certain use cases. Plus, the purpose of "Avoiding the user from having to select from hundreds of potential groups" is already achieved by allowing user to type and quick search within the column. _Originally posted by @hzc12321 in [#18696](https://github.com/netbox-community/netbox/issues/18696#issuecomment-2716784512)_ ### Justification It assumed too much details about the use case, and brings restrictions based on that assumption, but the assumption is not globally appplicable and unnecessary. It can get worse : Whenever when there is a need to assign a new FHRP group to an interface with existing IP address and FHRP group assigned, I have to first unassign all the IP addresses which are not under the same parent prefix as the new FHRP group. Then, after assigning the FHRP group to the interface, assign all the IPs back to the interface. Due to this behaviour, issues like these are likely to be raised repeatedly by different persons over time: https://github.com/netbox-community/netbox/issues/8435 https://github.com/netbox-community/netbox/issues/18696 It's not a must that each interface's IP address is under the same parent prefix as the FHRP group's VIP, there could be additional mechanisms like NAT or ARP proxying in the middle. Plus, it occurs frequently. ### Impact - Users are now free to decide which FHRP group to assign to an interface, without considering IP addresses assigned on that interface. - In case if there are hundreds of FHRP groups, the user can type and quick search during FHRP group assignment, and therefore does not affect the overall usability.
adam added the type: deprecationstatus: revisions needed labels 2025-12-29 21:37:52 +01:00
adam closed this issue 2025-12-29 21:37:52 +01:00
adam commented 2025-12-29 21:37:53 +01:00
Author
Owner
Copy Link

@arthanson commented on GitHub (Mar 28, 2025):

@hzc12321 can you please re-open this as a feature request as this is really a change in existing functionality, it is also not really clear what the issue / proposed solution is here.

@arthanson commented on GitHub (Mar 28, 2025): @hzc12321 can you please re-open this as a feature request as this is really a change in existing functionality, it is also not really clear what the issue / proposed solution is here.
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: revisions needed type: deprecation
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#10927
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?