Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
todd
Contributor
Jump to solution

Maestro SMO asg diag verify > clock fail

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

0 Kudos
2 Solutions

Accepted Solutions
Danny
Champion Champion
Champion

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

View solution in original post

Timothy_Hall
Legend Legend
Legend

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.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com

View solution in original post

7 Replies
Danny
Champion Champion
Champion

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
todd
Contributor

Hi Danny,

NTP information is very helpful.

Thank you.

Todd

0 Kudos
Sven_Glock
Advisor

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

todd
Contributor

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

0 Kudos
Timothy_Hall
Legend Legend
Legend

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.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
Sven_Glock
Advisor

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)

0 Kudos
todd
Contributor

Thanks for your information!

Todd

0 Kudos