Configuration changes with override enabled - FGCP HA

[Konnan]

Hello!

I'm setting up override on my cluster and I saw this article: Primary unit selection with override enabled | FortiGate / FortiOS 6.0.0 | Fortinet Document Library

It says that we lose configuration changes if the primary goes down, we do changes on secondary (that is going to be temporarily primary), primary comes back up, negociates to get his primary status back and overwrite the changes made on the secondary (who lost his temporary primary status).

By using the setting that the end of the article: set override-wait-time

Can we avoid losing configuration changes if the override-wait-time is long enough?

Does the secondary will have time to overwrite the primary configuration before primary negociates to get his status back?

I know that setting is there to smoothen the transition, but was wondering if it could have that nice side effect.

Thanks!

Konnan

[Shashwati]

Hello

This override-wait-timer option configured under HA setting, it makes the former master unit wait for number of second before taking back the master role, this is to ensure that all the sessions and routing tables have been completely synced. Please refer to the document

https://community.fortinet.com/t5/FortiGate/Technical-Tip-HA-override-wait-timer/ta-p/196568

[Konnan]

Hello Shashwati,

Maybe I wasn't clear enough, I know that part, that's not what I'm looking after. I know the main usage, it's to sync the sessions and routing tables.

I wonder if it would have a side effect of allowing the temporary master to sync the latest configuration changes with the former master, before it negociates to get his master status again.

Let say you put a timer of 15 minutes, that should be plenty to sync any policy change done on the temporary master to the former master? But then again, maybe it would not work in that case.

Thanks!

Konnan

[Toshi_Esumi · Accepted solution]

Direct answer would be no, there is no easy solution like flipping a setting to avoid configuration loss (or configuration override [not HA override]) when those situations happen.

The key is if the HA connection between the member units are up or down when the lower priority unit is the primary. As long as it's up config sync happens, like when the highest priority unit's monitored interface went down.

In case the highest priority unit dies, of course the config sync can't happen. But that case, you most likely get a new/RMA unit and bring it up as a "secondary", not the primary. Only after the config has synced you would set the priority higher.

In other words, when you bring up the faulted primary unit and put it back in the cluster, you need to be aware of the config status on all member units and control when/which unit becomes the primary and avoid taking over traffic by shutting down those in/out interfaces on the switch side.

This is not only when you set "override" but also in the non-override HA setting.

Toshi

[Konnan]

Hello Toshi_Esumi,

Thanks for that thorough answer! You are right that when you lose a primary, you have to be very careful. I'm still wondering because even you said that "as long as it's up config sync happens" which still leaves a small "possibility" that setting up a long timer "might" allow config sync to happen before the override setting force the former master to become master again.

I was wondering about that side effect, because the settings says that during that timer, the former master priority is effectively 0, so that would make it the lowest priority unit so sync "could" work, before it negociates to get master status again and the highest priority.

But then again, as you said, even if it does work, since you will probably have to do a manual intervention anyway, might as well avoid using that setting and do it right instead.

Thanks!

Konnan

[Toshi_Esumi]

Relying on a timer is very dangerous. The config sync might take quite longer if it's starting from scratch and the config is larger/complicated/multi-vdoms. While you should check the sync status with "get sys ha status" regardless before you re-introduce the highest priority device.

Toshi

[Konnan]

Hello again Toshi_Esumi,

Agreed, it is very dangerous, it would be better to have something in the override that says "wait until sync is done then take back primary role". In fact, I wonder why it's not the default behavior because I do not see much use cases that you want the oldest configuration to be kept, there's already backups for that.

I've taken enough of your time, I've accepted your previous post as a solution.

Thanks!

Konnan