In an Active-Active FGCP cluster, only the primary unit answers ARP requests using the HA virtual MAC address, while subordinate units retain their own physical/real MAC addresses.When the primary load-balances a session to a subordinate unit, could you confirm:Is the packet handed off to the subordinate over the same data/LAN interface (addressed to the subordinate's real MAC), or over the dedicated HA heartbeat link? Since the subordinate never responds to ARP requests, how does the upstream switch learn/populate its MAC table entry for the subordinate's physical MAC — is this purely through standard source-MAC learning when the subordinate transmits traffic (e.g., forwarding the processed packet to its next hop), or is there an additional FortiGate-specific mechanism (e.g., periodic announcement frames) to keep the switch's table populated? Does the subordinate's return/outbound traffic exit directly through its own interface to the destination, or does it always route back through the primary first?Appreciate clarification with reference to current FortiOS documentation/version behavior.

New Member

Question

Active-Active HA — MAC address resolution for subordinate unit during load-balanced sessions

6 replies
92 views

In an Active-Active FGCP cluster, only the primary unit answers ARP requests using the HA virtual MAC address, while subordinate units retain their own physical/real MAC addresses.

When the primary load-balances a session to a subordinate unit, could you confirm:

Is the packet handed off to the subordinate over the same data/LAN interface (addressed to the subordinate's real MAC), or over the dedicated HA heartbeat link?
Since the subordinate never responds to ARP requests, how does the upstream switch learn/populate its MAC table entry for the subordinate's physical MAC — is this purely through standard source-MAC learning when the subordinate transmits traffic (e.g., forwarding the processed packet to its next hop), or is there an additional FortiGate-specific mechanism (e.g., periodic announcement frames) to keep the switch's table populated?
Does the subordinate's return/outbound traffic exit directly through its own interface to the destination, or does it always route back through the primary first?

Appreciate clarification with reference to current FortiOS documentation/version behavior.

High Availability

funkylicious

SuperUser

https://docs.fortinet.com/document/fortigate/7.6.7/administration-guide/966077

"jack of all trades, master of none"

Toshi_Esumi

SuperUser

“ Subordinate unit interfaces retain their actual MAC addresses” doesn’t necessarily means it would put the actual MAC address as the source MAC address when the subordinate unit sends a ethernet frame directly to the client. It has to be the virtual MAC.

Toshi

osoleimani

Staff

Hi,

I think the distinction here is between the HA virtual MAC used by the primary and the physical MAC of the subordinate interface.

According to the current FortiOS documentation, in an FGCP Active-Active cluster the primary unit is associated with the cluster IP addresses and HA virtual MAC addresses. The subordinate unit interfaces retain their actual MAC addresses, and the primary communicates with the selected subordinate using those MAC addresses.

Once the session has been handed to the subordinate, Fortinet states that packets processed by the subordinate proceed directly to their destination and do not pass through the primary.

Fortinet's documented Active-Active TCP handshake example also illustrates this behavior: the primary uses its virtual MAC when communicating with the client/server side, while the traffic handed to the secondary is addressed to the secondary's physical interface MAC. The secondary then forwards the traffic toward the destination.

So I would separate the two concepts:

Client/upstream gateway → Primary/HA VMAC → Primary load-balances the session → Subordinate physical MAC → Subordinate processes the session → Subordinate exits directly toward the destination.

This also explains why the upstream switch does not need an ARP entry for the subordinate as the gateway. The cluster presents the HA VMAC as the gateway identity, while the subordinate's physical MAC is used internally for the load-balanced traffic path.

Therefore, the fact that the subordinate retains its physical MAC does not conflict with the cluster using a virtual MAC for the gateway. They serve different purposes in the Active-Active packet flow.

Hope this helps clarify the MAC-address behavior.

Toshi_Esumi

SuperUser

If the subordinate sends out packets with its own MAC to either the server or client side, wouldn’t it screw up ARP table on the server or client?

Toshi

osoleimani

Staff

That's a good point, Toshi.

The important distinction is between the HA VMAC used as the gateway identity and the MAC used for the Ethernet forwarding path. The FortiGate HA architecture maintains the VMAC for the cluster gateway, while the subordinate retains its own physical interface MAC.

Therefore, the subordinate's physical MAC being present in the Ethernet forwarding path does not mean that the client's/server's ARP entry for the gateway is changed from the HA VMAC.

In other words, the gateway identity and the forwarding interface MAC serve different purposes in the Active-Active HA packet flow.

Hope this clarifies the distinction.

Sign up

Login with SSO

Login to the community

Login with SSO