topic Re: Maestro SMO asg diag verify > clock fail in Hyperscale Firewall (Maestro)

Maestro SMO asg diag verify > clock fail

todd — Fri, 23 Dec 2022 08:18:08 GMT

Hi,

When I connect to the SMO via ssh, MOTD displayed the following message:

Warning: System diagnostics failed on the following tests: Clock, ARP Consistency.

Then I found 3 SGM clock was different.

1_01:
Fri Dec 23 15:49:58 2022 CST

1_02:
Fri Dec 23 15:52:04 2022 CST

1_03:
Fri Dec 23 15:50:33 2022 CST

Can I know how big the time difference between SGM will affect the operation ?

Thanks!

Todd

Re: Maestro SMO asg diag verify > clock fail

Danny — Fri, 23 Dec 2022 08:34:23 GMT

I haven't found anything in the docs nor SKs regarding how much time difference as acceptable.

sk172245 - Network Time Protocol (NTP) on Maestro
sk179385 - Time is not synchronised between Security Group Members although NTP is used

Re: Maestro SMO asg diag verify > clock fail

todd — Fri, 23 Dec 2022 09:22:21 GMT

Hi Danny,

NTP information is very helpful.

Thank you.

Todd

Re: Maestro SMO asg diag verify > clock fail

Sven_Glock — Tue, 27 Dec 2022 12:36:56 GMT

Hi Todd,

I experienced the same behavior after upgrade from R80.30SP to R81.10.
Did it happen in the same context on your side?

Cheeers
Sven

Re: Maestro SMO asg diag verify > clock fail

Timothy_Hall — Tue, 27 Dec 2022 14:39:20 GMT

Good question, always wondered about that. Poking around in the documentation, older code versions seem to indicate that the clock must be matched within one second for proper functionality which is clearly not correct; this statement has been softened in later versions. I have personally seen operational cluster members that were several hours off from each other and it didn't seem to have an adverse effect.

Here is a sampling of what the documentation says:

R76 Multi-Domain Admin Guide:
Multi-Domain Server (including dedicated Multi-Domain Log Servers) system clocks must be synchronized to the nearest second. When adding another Multi-Domain Server to your deployment, synchronize its clock with the other Multi-Domain Server before installing the Multi-Domain Security Management package.

R77 ClusterXL Guide:
For VPN cluster members, synchronize member clocks accurately to within one second of each other. If these members are constantly up and running it is usually enough to set the time once. More reliable synchronization can be achieved using NTP or some other time synchronization services supplied by the operating system. Cluster member clock synchronization is not applicable for non VPN cluster functionality.

R81.20 ClusterXL Guide:
Features, such as VPN, only function properly when the clocks of all of the Cluster Members are synchronized.

sk41513:
SIC failures can occur if the firewall and management module clocks are not correctly synchronized. The clocks do not have to match exactly, but they should match within a few minutes. Both your management module and firewall module should synchronize to an external time source via NTP.

Quantum Spark R80.20.40 CLI Reference:

set vpn site-to-site advanced-settings period-before-crl-valid <threshold>

Configures the time (in seconds), during which a certificate is considered valid prior to the time set by the Certificate Authority. This is to allow a wider window for CRL validity in case of mismatch in clock on the VPN sites.

Re: Maestro SMO asg diag verify > clock fail

todd — Wed, 28 Dec 2022 02:08:24 GMT

Hi Sven,

We haven't try to set NTP because customer is very cautious about changing the setting. Currently, we will use manual setting of the clock.

Todd

Re: Maestro SMO asg diag verify > clock fail

Sven_Glock — Fri, 10 Mar 2023 13:03:54 GMT

Just for completion: In my case the root cause of sgms running out of time sync is caused by a bug fixed in R81.10 JHF93 (PRJ-43601,PRJ-43213)

Re: Maestro SMO asg diag verify > clock fail

todd — Sat, 11 Mar 2023 11:05:18 GMT

Thanks for your information!

Todd