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

Add FortiGate FGCP to FHRP Group Protocol Choices #8259

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

Originally created by @hexa2k9 on GitHub (Jun 28, 2023).

NetBox version

v3.5.4

Feature type

Change to existing functionality

Proposed functionality

The FHRP Group Protocols currently include the Standard Cases like VRRP, CARP or Cisco/Checkpoint Specific Protocols. There's probably a magnitude of other Protocols out there so in best case this would be configurable. In our current case we're lacking the FortiGate Clustering Protocol - in short FGCP, which would be a pretty quick addition I think.

The FortiOS 5.4 Docs have "the best docs" on this:

FGCP active-active HA uses a technique similar to unicast load balancing in which the primary unit is associated with the cluster HA virtual MAC addresses and cluster IP addresses. The primary unit is the only cluster unit to receive packets sent to the cluster. The primary unit then uses a load balancing schedule to distribute sessions to all of the units in the cluster (including the primary unit). Subordinate unit interfaces retain their actual MAC addresses and the primary unit communicates with the subordinate units using these MAC addresses. Packets exiting the subordinate units proceed directly to their destination and do not pass through the primary unit first.

More recent versions of Documentation mention FGCP only for active-passive HA setups, but the idea remains the same.

I've prepared a changeset which I'd open a PR for once there's positive feedback on this.

Use case

The Use case is to document our setup we're running with an active-active HA Setup on a pair of FortiGates. Currently we use "Other" as Protocol which still "fits the documentation needs" but it doesn't reflect reality on a devices "interfaces" section for the FHRP Group.

Database changes

No response

External dependencies

No response

Originally created by @hexa2k9 on GitHub (Jun 28, 2023). ### NetBox version v3.5.4 ### Feature type Change to existing functionality ### Proposed functionality The FHRP Group Protocols currently include the Standard Cases like VRRP, CARP or Cisco/Checkpoint Specific Protocols. There's probably a magnitude of other Protocols out there so in best case this would be configurable. In our current case we're lacking the FortiGate Clustering Protocol - in short FGCP, which would be a pretty quick addition I think. The FortiOS 5.4 Docs have "the best docs" on this: > FGCP active-active HA uses a technique similar to unicast load balancing in which the primary unit is associated with the cluster HA virtual MAC addresses and cluster IP addresses. The primary unit is the only cluster unit to receive packets sent to the cluster. The primary unit then uses a load balancing schedule to distribute sessions to all of the units in the cluster (including the primary unit). Subordinate unit interfaces retain their actual MAC addresses and the primary unit communicates with the subordinate units using these MAC addresses. Packets exiting the subordinate units proceed directly to their destination and do not pass through the primary unit first. More recent versions of Documentation mention FGCP only [for active-passive](https://docs.fortinet.com/document/fortigate/6.4.0/ports-and-protocols/564712/fgcp-fortigate-clustering-protocol) HA setups, but the idea remains the same. I've [prepared a changeset](https://github.com/hexa2k9/netbox/commit/547dd2fd2db6065b603c81c06d3c5ae5051947a2) which I'd open a PR for once there's positive feedback on this. ### Use case The Use case is to document our setup we're running with an active-active HA Setup on a pair of FortiGates. Currently we use "Other" as Protocol which still "fits the documentation needs" but it doesn't reflect reality on a devices "interfaces" section for the FHRP Group. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: feature label 2025-12-29 20:34:25 +01:00
adam closed this issue 2025-12-29 20:34:25 +01:00
adam commented 2025-12-29 20:34:26 +01:00
Author
Owner
Copy Link

@pobradovic08 commented on GitHub (Jun 29, 2023):

The main question is is FGCP a FHRP? The current FHRP definition (from Netbox docs) says:

A first-hop redundancy protocol (FHRP) enables multiple physical interfaces to present a virtual IP address (VIP) in a redundant manner.

My thoughts on this are:

  • All of the current protocols have a VIP address (even ClusterXL, which is not really a FHRP), while Fortigate uses the same (one) IP on both nodes and has no VIP.
  • FHRP can be defined on interface pair basis, while FGCP and ClusterXL are on a device level
  • FGCP and ClusterXL are clustering protocols that handle more than just first hop redundancy.

To me this looks more like a Virtual chassis usecase, but I agree that group ID and authentication is missing in Virtual chassis.

@pobradovic08 commented on GitHub (Jun 29, 2023): The main question is is FGCP a FHRP? The current FHRP definition (from Netbox docs) says: > A first-hop redundancy protocol (FHRP) enables multiple physical interfaces to present a virtual IP address (VIP) in a redundant manner. My thoughts on this are: - All of the current protocols have a VIP address (even ClusterXL, which is not really a FHRP), while Fortigate uses the same (one) IP on both nodes and has no VIP. - FHRP can be defined on interface pair basis, while FGCP and ClusterXL are on a device level - FGCP and ClusterXL are clustering protocols that handle more than just first hop redundancy. To me this looks more like a Virtual chassis usecase, but I agree that group ID and authentication is missing in Virtual chassis.
adam commented 2025-12-29 20:34:26 +01:00
Author
Owner
Copy Link

@hexa2k9 commented on GitHub (Jun 29, 2023):

From the quoted documentation part I think this is a fit.

I have to admit I'm not a "FortiGate Pro", and It certainly is true that FGCP does more than just providing HA for an IP to a pair of Interfaces in the Cluster and that a VC might be the more appropriate use case.

But in the case of doing the FortiGate Cluster as a VC (which is configured anyway for the instances we're running) it would have missing Interfaces from the VC members which IP Addresses (in this case in a n:1 relationship) can be assigned to to reflect the fact the IP is (or can be) active on more than one device (while only the primary unit processes traffic for the IP) and the devices itself - at least in our case - don't have individual IP Addresses assigned.

I could create 2 individual IP Addresses of let's say 11.22.33.44/29 and assign them to Interfaces on 2 individual Devices, but I think this doesn't reflect reality as it's actually the same IP Address assigned to 2 devices.

The lack of FGCP made me configure it as a FHRP of type "Other" which did let me assign the related IP Addresses and have this assigned to more than one Device/Interface pair.

@hexa2k9 commented on GitHub (Jun 29, 2023): From the quoted documentation part I think this is a fit. I have to admit I'm not a "FortiGate Pro", and It certainly is true that FGCP does more than just providing HA for an IP to a pair of Interfaces in the Cluster and that a VC might be the more appropriate use case. But in the case of doing the FortiGate Cluster as a VC (which is configured anyway for the instances we're running) it would have missing Interfaces from the VC members which IP Addresses (in this case in a n:1 relationship) can be assigned to to reflect the fact the IP is (or can be) active on more than one device (while only the primary unit processes traffic for the IP) and the devices itself - at least in our case - don't have individual IP Addresses assigned. I could create 2 individual IP Addresses of let's say 11.22.33.44/29 and assign them to Interfaces on 2 individual Devices, but I think this doesn't reflect reality as it's actually the same IP Address assigned to 2 devices. The lack of FGCP made me configure it as a FHRP of type "Other" which did let me assign the related IP Addresses and have this assigned to more than one Device/Interface pair.
adam commented 2025-12-29 20:34:26 +01:00
Author
Owner
Copy Link

@jsenecal commented on GitHub (Jul 7, 2023):

What about using 'other' for these obscure proprietary protocols?

@jsenecal commented on GitHub (Jul 7, 2023): What about using 'other' for these obscure proprietary protocols?
adam commented 2025-12-29 20:34:27 +01:00
Author
Owner
Copy Link

@hexa2k9 commented on GitHub (Jul 11, 2023):

That's what we currently do, yes. As there seems to be consensus about not adding FGCP I will close this request.

@hexa2k9 commented on GitHub (Jul 11, 2023): That's what we currently do, yes. As there seems to be consensus about not adding FGCP I will close this request.
adam commented 2025-12-29 20:34:27 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Jul 11, 2023):

While something like Checkpoint's ClusterXL does appear to be a FHRP, FGCP appears to be more the control protocol for the cluster/HA itself then just a FHRP.

The Cisco (HSRP, GLBP) protocol is most definitely a FHRP, and Checkpoint (ClusterXL) protocol does appear to fit the description itself, so I don't think anything needs to happen in regards to those.

I am not against adding Fortigate's protocol, but I don't think it is really a FHRP myself.

@DanSheps commented on GitHub (Jul 11, 2023): While something like Checkpoint's ClusterXL does appear to be a FHRP, FGCP appears to be more the control protocol for the cluster/HA itself then just a FHRP. The Cisco (HSRP, GLBP) protocol is most definitely a FHRP, and Checkpoint (ClusterXL) protocol does appear to fit the description itself, so I don't think anything needs to happen in regards to those. I am not against adding Fortigate's protocol, but I don't think it is really a FHRP myself.
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#8259
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?