Created on 09-14-2018 07:32 AM Edited on 02-26-2024 06:40 AM By Kate_M
Hi!
I am configured HA on my Fortigate 100E running 5.6.
The CLI command get system ha status shows that it looks ok .
HA Health Status: OK
Serial number Device 1(updated 3 seconds ago): in-sync Serial number Device 2(updated 2 seconds ago): in-sync
Master: Primary , FG100E4Q170444845, cluster index = 0 Slave : Secondry , FG100E4Q17044540, cluster index = 1
But on GUI the status is showing as Not Synchronized.
One more thing is that I used device priority for my selection of primary. I know that up time comes before the priority but my thought was that once I set higher priority then it will take that as first option of choice or I am missing point here.
Thanks
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
No, the sequence which parameters are looked at for a HA master decision is not changed by setting those parameters. Nor will a decision process be started.
The only way to alter the sequence is to set 'HA override' on one unit.
Please search the forums for this topic and/or re-read the HA chapter in the Handbook if you want to be sure.
Personally, I would not bother too much about the GUI display. If the info in the CLI tells you the cluster is in-sync then all is good. You could change an unimportant setting in the CLI and watch the sync status to change, and stableize again.
I saw this issue in 5.6.4 and 6.0.1. When I joined the HA cluster, I wait 5 minutes and the GUI still shows that it's unsynced. But when I look at the checksums in the CLI it's synced. I rebooted the primary and confirmed that HA sync correctly. When the primary came back up the GUI showed the correct sync status. I have a feeling it's a GUI bug.
@capricorn80:
HA override does not influence performance in any way. It just changes the sequence of parameters.
But, as you've noticed, it only adds a second short interruption if the master fails which IMHO is unnecessary. HA priority should be set identically then.
Session pickup is off by default, for a reason. Not all sessions can be preserved (e.g. not IPsec), not all traffic is stateful (e.g. UDP), some protocols rely on frequent, short sessions (e.g. HTTP) but for the rest it does make a difference. It costs performance, and bandwidth on the HA link(s). YMMV.
Additionally, monitoring ports is advisable. Without it, the cluster will only fail over on device failure. Port monitoring adds link failure protection which might be more probable.
No, the sequence which parameters are looked at for a HA master decision is not changed by setting those parameters. Nor will a decision process be started.
The only way to alter the sequence is to set 'HA override' on one unit.
Please search the forums for this topic and/or re-read the HA chapter in the Handbook if you want to be sure.
Personally, I would not bother too much about the GUI display. If the info in the CLI tells you the cluster is in-sync then all is good. You could change an unimportant setting in the CLI and watch the sync status to change, and stableize again.
Browser refresh CTRL + F5 should display the right status in GUI.
For me this works after every cluster update.
perhaps for you too.
Fortigate 500E HA Fortimail 200 Fortimanager
FortiEMS
FortiSandbox 1000D
FortiSwitch Network Some other Models in use :-) ---------------------------------------------------- FCSE ----------------------------------------------------
The checksum is same as well.
is_manage_master()=1, is_root_master()=1 debugzone global: 80 06 4e 98 1e 6a 5d d3 4d d6 4b fc 83 6f e7 2d root: 80 e0 7e 6b a7 38 0b ec 3d fc 9d 99 f7 65 36 41 all: 1f 49 d0 3e 48 91 b8 85 fb b2 7d 73 c3 1c 30 76
checksum global: 80 06 4e 98 1e 6a 5d d3 4d d6 4b fc 83 6f e7 2d root: 80 e0 7e 6b a7 38 0b ec 3d fc 9d 99 f7 65 36 41 all: 1f 49 d0 3e 48 91 b8 85 fb b2 7d 73 c3 1c 30 76
1. connected monitored interface - I am not monitoring any interface 2. Age - Depends on monitored interface and is the amount of time since the interface disconnected so I am not using the monitored interface. Age also means the up time so the FW which is up from long time will become Master. This is happening in my case. 3. Priority: I set it to 250 but Age is taking over.
So if I restart my primary one then the secondary will take over as its up time will be more than the primary one.
I read couple of threads and people dont use HA override as it will create performance issue and also when the primary comes back online then it will take over that means that few seconds delay.
I think for me it doesnt matter as they are both the same firewall so as long as they are working.
One more thing is the session pickup. I am reading about it but its disable in my case so does that mean if my primary goes down then I will loose all sessions and every session will start again?
Refresh and Crtl + F5 doesnt help.
I saw this issue in 5.6.4 and 6.0.1. When I joined the HA cluster, I wait 5 minutes and the GUI still shows that it's unsynced. But when I look at the checksums in the CLI it's synced. I rebooted the primary and confirmed that HA sync correctly. When the primary came back up the GUI showed the correct sync status. I have a feeling it's a GUI bug.
@capricorn80:
HA override does not influence performance in any way. It just changes the sequence of parameters.
But, as you've noticed, it only adds a second short interruption if the master fails which IMHO is unnecessary. HA priority should be set identically then.
Session pickup is off by default, for a reason. Not all sessions can be preserved (e.g. not IPsec), not all traffic is stateful (e.g. UDP), some protocols rely on frequent, short sessions (e.g. HTTP) but for the rest it does make a difference. It costs performance, and bandwidth on the HA link(s). YMMV.
Additionally, monitoring ports is advisable. Without it, the cluster will only fail over on device failure. Port monitoring adds link failure protection which might be more probable.
Enabling override changes the order of primary unit selection. As shown below, if override is enabled, primary unit selection considers device priority before age and serial number. This means that if you set the device priority higher on one cluster unit, with override enabled this cluster unit becomes the primary unit even if its age and serial number are lower than other cluster units. Similar to when override is disabled, when override is enabled primary unit selection checks for connected monitored interfaces first. So if interface monitoring is enabled, the cluster unit with the most disconnected monitored interfaces cannot become the primary unit, even of the unit has the highest device priority. If all monitored interfaces are connected (or interface monitoring is not enabled) and the device priority of all cluster units is the same then age and serial number affect primary unit selection.
Ashu
After few days its showing the status fine on the GUI without making any changes.
Hello,
clearing the browser cache or using a different browser will restore the GUI to the expected synced state.
Thanks
Pavan
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.