Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
suthomas1
New Contributor

failed HA device

Hello Everyone, We have a fortigate 3600 in active-passive mode. the active has encountered failure & will be replaced. We are looking at some steps on how to replace this faulty unit & make sure the configurations etc are in sync for failover pair to work properly. Appreciate all help
Suthomas
Suthomas
6 REPLIES 6
emnoc
Esteemed Contributor III

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.

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
rwpatterson
Valued Contributor III

Also make sure that the firmware levels match.

Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com

Bob - self proclaimed posting junkie!See my Fortigate related scripts at: http://fortigate.camerabob.com
Maik
New Contributor II

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...
ede_pfau
SuperUser
SuperUser

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

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 ?
ede_pfau
SuperUser
SuperUser

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 :)

Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
Labels
Top Kudoed Authors