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

Changing config while slave is active (master), will it sync when actual master is back?

Hi,

In an A-P HA cluster, with the Master down (Slave has become Master), what happens when I go and change config and the actual master comes back and takes over as master again? Will there be a config sync issue?

Thanks for any insight.

 

Bye,

Marki

1 Solution
emnoc
Esteemed Contributor III

NO the slave is your master and will sync withe 2nd unit when it comes back online. If preemption is enabled,  the former master will take ownership.

PCNSE 

NSE 

StrongSwan  

View solution in original post

PCNSE NSE StrongSwan
9 REPLIES 9
emnoc
Esteemed Contributor III

NO the slave is your master and will sync withe 2nd unit when it comes back online. If preemption is enabled,  the former master will take ownership.

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
Toshi_Esumi
Esteemed Contributor III

a quote from HA Handbook:

- Enable or disable preempt mode using the preempt option. In preempt mode a higher priority backup unit can preempt a lower priority master unit. This can happen if a master has failed, a backup unit has become the master unit, and the failed master is restarted. Since the restarted unit will have a higher priority, if preempt mode is enabled the restarted unit will replace the current master unit. Preempt mode is enabled by default.

 

ede_pfau
Esteemed Contributor III

Oh, oh.

 

First, @Toshi: the 'preempt' parameter is not part of the HA setup. It's used in the VRRP setup. OP is inquiring about a HA cluster.

 

Second, yes, if the prior primary unit comes online again, config changes that have taken place inbetween can be lost!

 

But, one requirement for this is that on all cluster units the HA override parameter is enabled, and that the priority of the joining unit is higher than the priority of the running unit.

Both of these are not set by default.

Only if you had the intention to always have the same unit be the master and set the override parameter and it's priority highest then you would lose config changes when reconnecting this unit.

 

Please read the relevant chapter in the Handbook about HA configuration to fully understand how and when a primary unit is selected. For instance, Handbook v5.0.7, ch. 9, pg. 1133 ff., especially page 1148 (regular selection process) and pg. 1157 (with override enabled).


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
emnoc
Esteemed Contributor III

Keep in mind you should execute ha sync if you are in doubt b4 you allow the new master.

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
ede_pfau
Esteemed Contributor III

exec ha sync start
will only trigger the synchronization process manually. You have to issue the command in the CLI of the slave unit, and it will update the slave's config to the master's.

 

 

You cannot influence the selection of the master unit of the cluster with this. If you're lucky (that is, if parameters are set accordingly) the current master will stay master when you join the second unit to the cluster. Synchronization will take place automatically within seconds, so synching manually will do no harm but won't be necessary either. The crucial point here is to make sure that the current master stays master, or current config changes will be lost.

 

Have a look at the flowcharts on the pages I've pointed to.


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
Toshi_Esumi
Esteemed Contributor III

In our experiences with a set of two FG1500Ds + a-p HA, age dictates most of the primary selection process. We don't set priority, means the same between both (I think 128 by default). Then every time we upgrade FortiOS on the cluster it upgrades the backup first and it takes over the control (becomes the primary), then upgrades the previous primary. And they never swap back because the previous backup rebooted first so the age is older.  

Toshi_Esumi
Esteemed Contributor III

And, to manipulate which unit to be the primary, we shut down those monitoring interfaces on the switch side, which triggers a new primary selection process and the unit we shut down the interfaces would not become the primary.

ede_pfau
Esteemed Contributor III

Exactly.

The selection sequence from top down is

- number of monitored interfaces which are 'up' (greater number wins)

- age = uptime (greater number wins)

- priority (greater number wins)

- serial number (greater number wins)

 

So, in your example, you force a switch to the other unit by pulling a monitored port's cable on the current master. This will decide it on the first check, regardless of age, priority or serial number.

 

But, as I've pointed out, setting the override option will change that sequence: priority will then come first, before age. So if override is enabled, and priority of the unit joining the cluster is higher, the joining's unit configuration will overwrite the current master's. That's the situation to be aware of.

 

@jmlux: are you reading this at all?


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
emnoc
Esteemed Contributor III

Also for the HA age you have a a diag command to reset the HA age time to help enforce master selections

 

diagnos sys ha reset-uptime

 

So you have numerous methods for controlling HA and sync between cluster units.

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
Labels
Top Kudoed Authors