failed HA device

Just rebuild the HA members and other parameters ( cluster id, parameters, password ). Once the units are reconnected, the new RMA unit will sync the cfgs. Pretty straight forward, should be a 5min or less task.

HA members and other parameters

make sure that the priority is lower and " set override" is set to disabled. otherwise you could sync your empty configuration to the other one...

Agreed, everything can run smoothly IF you watch out for some traps. 1. Usually you will have to DOWNgrade the replacement unit to match the firmware build of the remaining unit. If you do that (and esp. if coming down from v5) it could not harm to do a ' exec formatlogdisk' on the new FGT. 2. Then, set the hostname (!!!) on the new unit to some meaningful string - this can be quite clumsy to do after forming the cluster. 3. If available, set the Remote cluster member management port (a dedicated port with an IP address which will not be sync' ed). This allow you for instance to SNMP monitor each member of the cluster. 4. After that, configure identical values for cluster_ID (most important). This determines the virtual MAC addresses of the cluster ports. 5. I' ve never used a password on the HA communications but if you do then copy that as well. 6. Switch off all port monitoring, on both units. You can enable that after the cluster is running stable. This is to avoid unnecessary failing over during setup, cabling etc. 7. Next, HA priority on the new unit should be at the default of 128. Make sure (!) that your running FGT has a higher priority, or even has ' HA override' enabled. Just imagine seeing a production unit being blanked out by a replacement unit when clustering because the sync went the wrong way around. I' ve even restored the current config onto the replacement just to make sure. 8. Watch the messages on the (old) primary unit' s console port. 9. Power off the replacement, connect all cables, and power on. 10. After 2-3 minutes, the ' cluster member out of sync' messages should be past ' phase 4' and be ready. You can check that the configs are finally synchronized with ' diag sys ha showcsum' . 11. You can get to the secondary unit either via the dedicated Remote Mgmt interface, or via the primary' s CLI: ' exec ha manage 1' . While on the secondary unit, the prompt changes (that' s why the hostname is important). Here, you can run ' diag sys ha showcsum' to compare checksums. Ain' t too complicated. I will do that on Monday as well. Good luck!

2. Then, set the hostname (!!!) on the new unit to some meaningful string - this can be quite clumsy to do after forming the cluster.

Just curious, what is the problem with changing the hostname after the cluster is formed besides that you have to manage the slave from the cli ?

Just that. It' s not obvious for everybody how to get to the slave' s CLI. But of course, it' s no magic. I' ve set up a cluster yesterday and it helped to see an unambiguous identifier in every spot (widgets, HA page, CLI etc.) which tells you which machine you are working on at the moment. It' s just one of the things you prepare in advance like the other parameters (group ID, ...). Funny enough, when the cluster was up and running I pushed my customer to deliberately fail one of the units (i.e. to switch it off). You only know that you have a backup if you try to restore...and when switching it on again, the unit complained (in other words) " Different hdisk equipment. Cannot form cluster. Shutting down." And I didn' t see that on the console for a while - just stared at a powered-on but not running Fortigate. The thing was that while upgrading to 4.3.15 one of the units already had the internal flash disk formatted while the other didn' t. Formatted the disk and the cluster formed. Easy in hindsight :)