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

FHRP: identify by group ID is insufficient to select one for assignment #5689

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

Originally created by @candlerb on GitHub (Nov 19, 2021).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v3.1-beta1

Python version

3.8

Steps to Reproduce

I use VRRP group ID 1 across all layer 2 networks. For example, on the Nexus L3 switch at the core I have:

interface Vlan3
  ip address 192.168.3.2/24
  vrrpv3 1 address-family ipv4
    priority 200
    address 192.168.3.1 primary

interface Vlan5
  ip address 192.168.5.2/24
  vrrpv3 1 address-family ipv4
    priority 200
    address 192.168.5.1 primary

interface Vlan6
  ip address 192.168.6.2/24
  vrrpv3 1 address-family ipv4
    priority 200
    address 192.168.6.1 primary
... etc

All these are VRRP group ID 1. They're separate layer 2 domains, so there's no need to use different IDs between them - this keeps the config much simpler, and reduces the risk of conflicts with server FHRP groups (everyone knows that group ID 1 is the gateway, on all networks)

Now model this in Netbox:

  1. IPAM > FHRP Group > Add
  2. Select Protocol VRRPv3, group ID 1, address 192.168.3.1/24, status Active, Create & add another
  3. Repeat for 192.168.5.1/24
  4. Repeat for 192.168.6.1/24
  5. Go to a device interface, and try to select the correct FHRP group

Expected Behavior

I should be able to distinguish between the FHRP group objects.

Preferably this would be by seeing the IP(s) associated with them, and being able to search by IP address (same as when assigning a single IP address to an interface)

At worst, this should be done by showing the Netbox internal ID, which would be necessary if the FHRP group has no address, or when multiple FHRP groups have the same address assigned.

  • FHRP ID 1 (192.168.3.1/24) (1)
  • FHRP ID 1 (192.168.5.1/24) (2)
  • FHRP ID 1 (192.168.6.1/24) (3)

Observed Behavior

It's impossible to select the right FHRP group, as they all appear identical.

image

Originally created by @candlerb on GitHub (Nov 19, 2021). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v3.1-beta1 ### Python version 3.8 ### Steps to Reproduce I use VRRP group ID 1 across all layer 2 networks. For example, on the Nexus L3 switch at the core I have: ``` interface Vlan3 ip address 192.168.3.2/24 vrrpv3 1 address-family ipv4 priority 200 address 192.168.3.1 primary interface Vlan5 ip address 192.168.5.2/24 vrrpv3 1 address-family ipv4 priority 200 address 192.168.5.1 primary interface Vlan6 ip address 192.168.6.2/24 vrrpv3 1 address-family ipv4 priority 200 address 192.168.6.1 primary ... etc ``` All these are VRRP group ID 1. They're separate layer 2 domains, so there's no need to use different IDs between them - this keeps the config much simpler, and reduces the risk of conflicts with server FHRP groups (everyone knows that group ID 1 is the gateway, on all networks) Now model this in Netbox: 1. IPAM > FHRP Group > Add 2. Select Protocol VRRPv3, group ID 1, address 192.168.3.1/24, status Active, Create & add another 3. Repeat for 192.168.5.1/24 4. Repeat for 192.168.6.1/24 5. Go to a device interface, and try to select the correct FHRP group ### Expected Behavior I should be able to distinguish between the FHRP group objects. Preferably this would be by seeing the IP(s) associated with them, and being able to search by IP address (same as when assigning a single IP address to an interface) At worst, this should be done by showing the Netbox internal ID, which would be necessary if the FHRP group has no address, or when multiple FHRP groups have the same address assigned. * FHRP ID 1 (192.168.3.1/24) (1) * FHRP ID 1 (192.168.5.1/24) (2) * FHRP ID 1 (192.168.6.1/24) (3) ### Observed Behavior It's impossible to select the right FHRP group, as they all appear identical. ![image](https://user-images.githubusercontent.com/44789/142585247-e9acf71d-ce42-4b96-9bef-ab91cffd4472.png)
adam added the type: bugstatus: acceptedbeta labels 2025-12-29 19:31:31 +01:00
adam closed this issue 2025-12-29 19:31:32 +01:00
adam commented 2025-12-29 19:31:32 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 19, 2021):

Now model this in Netbox:

There are two recommended approaches here.

  1. Rather than pre-creating each FHRP group, you can create them directly from the interface view (by clicking the "Create Group" button in the FHRP Groups panel). This is the fastest, most convenient way to create FHRP groups. Granted, this only works for the first member interface.

  2. Start by assigning the regular IPs to the member interfaces first. Create interface Vlan3 and assign it an IP address of 192.168.3.2/24, then click "Assign Group." You'll see that only the first FHRP group (with 192.168.3.1/24 assigned to it) is listed as an available choice, because NetBox is returning only groups with an IP address which corresponds with one of the interface's assigned IPs.

Preferably this would be by seeing the IP(s) associated with them

In designing the data model for FHRP groups, I've erred on the side of permitting maximum flexibility, which means that each FHRP group can be assigned multiple IP addresses. We generally avoid trying to pull in related objects (especially those which rely on a generic foreign key) because of the additional overhead, but it might be worth the sacrifice in this case. Including the group's primary key is trivial but also not super helpful to the user.

Unfortunately, the nature of FHRP groups (which are significant only within an L2 domain) just doesn't allow us much to work with. We faced similar challenges with VLANs: VLAN groups helped considerably with organizing these, but I don't think a similar approach would make sense for FHRP groups.

@jeremystretch commented on GitHub (Nov 19, 2021): > Now model this in Netbox: There are two recommended approaches here. 1) Rather than pre-creating each FHRP group, you can create them directly from the interface view (by clicking the "Create Group" button in the FHRP Groups panel). This is the fastest, most convenient way to create FHRP groups. Granted, this only works for the first member interface. 2) Start by assigning the regular IPs to the member interfaces first. Create interface Vlan3 and assign it an IP address of 192.168.3.2/24, then click "Assign Group." You'll see that only the first FHRP group (with 192.168.3.1/24 assigned to it) is listed as an available choice, because NetBox is returning only groups with an IP address which corresponds with one of the interface's assigned IPs. > Preferably this would be by seeing the IP(s) associated with them In designing the data model for FHRP groups, I've erred on the side of permitting maximum flexibility, which means that each FHRP group can be assigned multiple IP addresses. We generally avoid trying to pull in related objects (_especially_ those which rely on a generic foreign key) because of the additional overhead, but it might be worth the sacrifice in this case. Including the group's primary key is trivial but also not super helpful to the user. Unfortunately, the nature of FHRP groups (which are significant only within an L2 domain) just doesn't allow us much to work with. We faced similar challenges with VLANs: VLAN groups helped considerably with organizing these, but I don't think a similar approach would make sense for FHRP groups.
adam commented 2025-12-29 19:31:32 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Nov 19, 2021):

Create interface Vlan3 and assign it an IP address of 192.168.3.2/24, then click "Assign Group." You'll see that only the first FHRP group (with 192.168.3.1/24 assigned to it) is listed as an available choice, because NetBox is returning only groups with an IP address which corresponds with one of the interface's assigned IPs.

That does work. However in the drop-down it would still be useful to see some confirmation of the address assigned to the group, e.g.

  • VRRPv3 ID 1 (192.168.3.1)

I take your point that there's a join required, but in the drop-down you've already done a join to restrict the queryset to the FHRP IP's which match the interface IPs, in which case the data is already available as part of that query.

I also note that if I browse the interfaces on the device here, there's no indication of whether the interface has a FHRP group assigned - there doesn't seem to be a table column to add this. (Including the linked FHRP group IP addresses in the 'ip addresses' column would be sufficient - again that's a join, but you're already following the direct join to IP addresses)

In designing the data model for FHRP groups, I've erred on the side of permitting maximum flexibility, which means that each FHRP group can be assigned multiple IP addresses.

Yes, I think that is important. I have used pfSense CARP groups with multiple aliases on them.

@candlerb commented on GitHub (Nov 19, 2021): > Create interface Vlan3 and assign it an IP address of 192.168.3.2/24, then click "Assign Group." You'll see that only the first FHRP group (with 192.168.3.1/24 assigned to it) is listed as an available choice, because NetBox is returning only groups with an IP address which corresponds with one of the interface's assigned IPs. That does work. However in the drop-down it would still be useful to see some confirmation of the address assigned to the group, e.g. * VRRPv3 ID 1 (192.168.3.1) I take your point that there's a join required, but in the drop-down you've already done a join to restrict the queryset to the FHRP IP's which match the interface IPs, in which case the data is already available as part of that query. I also note that if I browse the interfaces on the device [here](https://beta-demo.netbox.dev/dcim/devices/1/interfaces/), there's no indication of whether the interface has a FHRP group assigned - there doesn't seem to be a table column to add this. (Including the linked FHRP group IP addresses in the 'ip addresses' column would be sufficient - again that's a join, but you're already following the direct join to IP addresses) > In designing the data model for FHRP groups, I've erred on the side of permitting maximum flexibility, which means that each FHRP group can be assigned multiple IP addresses. Yes, I think that is important. I have used pfSense CARP groups with multiple aliases on them.
adam commented 2025-12-29 19:31:32 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 19, 2021):

there doesn't seem to be a table column to add this

I've opened #7884 as an FR to add a column for FHRP groups. FWIW I'm much more relaxed with regard to potential performance impact on table columns because the prefetching is added/removed automatically and the user always has the option to remove columns if they're causing problems.

@jeremystretch commented on GitHub (Nov 19, 2021): > there doesn't seem to be a table column to add this I've opened #7884 as an FR to add a column for FHRP groups. FWIW I'm much more relaxed with regard to potential performance impact on table columns because the prefetching is added/removed automatically and the user always has the option to remove columns if they're causing problems.
adam commented 2025-12-29 19:31:33 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 19, 2021):

@candlerb I've pushed this change to the beta demo, let me know what you think.

Screenshot_2021-11-19 Add a new FHRP group assignment NetBox

@jeremystretch commented on GitHub (Nov 19, 2021): @candlerb I've pushed this change to the beta demo, let me know what you think. ![Screenshot_2021-11-19 Add a new FHRP group assignment NetBox](https://user-images.githubusercontent.com/13487278/142658965-59a98aa0-eea9-44b5-9f6f-961365ca6044.png)
adam commented 2025-12-29 19:31:33 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Nov 19, 2021):

That looks spot on, thank you! I see the extra column in interfaces too.

@candlerb commented on GitHub (Nov 19, 2021): That looks spot on, thank you! I see the extra column in interfaces too.
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 beta status: accepted type: bug
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#5689
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?