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!
Ede Kernel panic: Aiee, killing interrupt handler!