out of sync in HA

[djpk05]

I'm pretty new to a Fortigate FW and I am running into an issue with HA secondary unit not syncing.

HA Health Status:     WARNING: xxxxxx has session sync dev down;     WARNING: xxxxxx has session sync dev down; has mondev down; Configuration Status:     xxxxxx(updated 1 seconds ago): in-sync     xxxxxx(updated 0 seconds ago): out-of-sync It seems like the secondary unit was rebooted few days ago.  Any suggestions?

Thanks.

Peter

[lobstercreed]

I really thought I had some notes that would help and I can't find it, so I'm trying to re-Google what I did when I ran into this a while back.  Try these links:

https://kb.fortinet.com/kb/documentLink.do?externalID=FD36176 

https://kb.fortinet.com/kb/documentLink.do?externalID=FD45183

[Toshi_Esumi]

Are you using a dedicated session-sync interface in addition to a heart-beat connection(s) with "set session-sync-dev <interface>"? If so, that connection seems to be down. I'm not sure if that causes directly "out-of-sync" if the config is in sync. To check conf sync status, compare the checksum for both unit to see if they're matching.

https://kb.fortinet.com/k....do?externalID=FD45183

[djpk05]

I was able to fix the issue comparing checksum between two FWs.  Somehow, there were few configs that weren't copied over to slave unit.  I forced to sync manually and it didn't work.  So, I had to remove the config from master since the config were just test.  As far as  "set session sync-dev" goes, we have configured port 12 and 14.  However, port 12 are not connected at the moment.  Should I remove port 12 from the config?  Thanks for all your help.    

[Toshi_Esumi]

As long as they're in sync and continue to update the backup side, you probably don't care those errors in "get sys ha status". I noticed "mondev" down on the standby(?) side as well, which you must have disconnected too. As long as one link is up for session sync, you should be fine. Just make sure new changes get copied over automatically. The particular config mismatch you found likely had some illegal component on the standby side, so when it tried to fix it by copying from the master it errored out. So it had to be removed first then it could be copied.

I've seen it on our a-p HA clusters time to time and sometimes the standby needs to be rebooted first to get it copied properly. Even with our 6.0.10, this happens and seem to be one of those "readers-writers problems". When it happens, you need to check checksums to isolate the problem config and fix it one way or the other like you just did. The last resort is to default the standby and let it re-sync from scratch.

[SmokeyMountian_Tech]

Are you HA ethernet jumpers still in place?