Fortigate HA - interface speed for heartbeat link ?

[ffischer]

Hi all,

regarding interface speed, is there a recommendation what kind of interfaces to use

for the HA/heartbeat/state-Link between two FGT cluster members ?

With Cisco PIX/ASA High Availability there is a (sometimes overseen) design rule that

the HA-link transferring the state table information

is at least as fast as the fastest data interface...

I suppose this is an approach to have the bandwidth needed for syncing state tables

lower than the bandwidth of the transferred data itself.

Is there a similar recommendation from Fortinet ?

Would it be acceptable to to use two 1GB links for HA on an A-P cluster of two 1500D

even if I have a 4x10GB  802.3ad aggregate with VLANs for the Data traffic ?

Will the state tables and other cluster information sync fast enough through 2x1G ?

Thanks&BR,

Frank

[ede_pfau]

You should be fine with a GE link. Actually, I don't see a direct relation between data speed and HA data volume. Only state and config changes will be synchronized and this can be quite small. (Yes, and the UTM databases will be shared after an update - worst case: extreme database).

BTW, you should be aware that using multiple HA links is a good idea for redundancy but IMHO has no influence on the bandwidth available. The worst nightmare in a cluster would be the break of the HA link so it's always a best practise to create redundancy here.

Additionally, you are using an active/passive HA pair; if the HA sync would lag it would only be detrimental if the cluster would break during this lag (i.e., not all the time). This is definitively different in an A/A cluster (which has it's advantages but is generally seen as not as stable as A/P).

[ffischer]

> I don't see a direct relation between data speed and HA data volume.

Well...

Imagine you could have some odd applications sending lots of small UDP Packets

from changing source ports into the network.

This would yield to a very high setup rate for UDP pseudo connections in the state table.

Now, if all is synced to the passive cluster member you will need more bandwith for the updates,

compared to another network where we have more long lasting tcp connection transferring

data in large packets.

In other words, a 40G Link saturated with small 60 bytes UDP packets

may need more than 2G to sync state tables ;)

but.. I agree..

first, this scenario is really hypothetical and there may hardly a real network exist having that traffic profile.

and second,

if FortiOS just ignores state syncs loss, this will only have an affect in very rare case of a failover.

And yes.. I planned a A-P HA for 2 reasons:

- as the client does not want performance degration in case of failure if one box,

   one machine has to have enough throughput to handle load anyway

- deterministic flows through the components for easier troubleshooting & debugging

If A-P design increases stability as well, this will a side effect thats welcome ;)

Thanks,

Frank

[neonbit]

If you find that the HA link is getting saturated with the session syncs it may start delaying heartbeat packets which is not good. You could always separate the session synchronisation and heartbeat traffic using the following:

config system ha

set session-sync-dev <portx> <porty>...

end

[Toshi_Esumi]

I don't know exactly what's exchanged over the heartbeat connections to be honest. But one of our HA clusters in a-p mode is getting traffic 100-150Mbps/70-80M on the main internet interface over this weekend while the heartbeat connection is constantly carrying about 4Mbps in a->p direction. And I would guess this amount is decided by the number of active sessions, not by the amount of traffic all sessions are sending&receiving.