Time synchronization between orchestrator and its SGMs - does it matter?

[T_Letts]

Hello Maestro Community

I would welcome any thoughts on an issue we are currently trying to fathom with Check Point partners and TAC.

We should have a dual site set up each having a single MHO140 with 2 attached 7000 gateways. At the moment the sync between the 2 sites is down, so we are effectively running in a production / disaster recovery mode which requires manual intervention to switch between sites.

As it happens we had a problem with the production site last Monday and had to flip over to the disaster recovery site.

We need to determine what went wrong with the  production site. However this needs to be done without bringing up the production orchestrator services as this causes a split brain situation which affects our users. So the production orchestrator has had an 'orchd stop' executed on it.

TAC has logged in and has taken away some logs to analyse.

Whilst they are doing this, I've noticed that the system time on the production orchestrator is showing as 4th January 2009.  It was rebooted trying to resolve our issue when it happened. The boot time shows as 00:00 1 Jan 2009. Even though NTP is set up, I expect this difference in time is much too big to be resolved by NTP adjustments.

The system time of the SGMs is correct - 17th October 2025.

At last here's the question. 

Would this massive time difference between the orchestrator and its attached gateways matter? And would it prevent the SMS from seeing the SMO - as this is what I'm told was happening after the incident and before flipping over to the DR site.

Thanks in advance 

[the_rock]

From my knowledge, that matters regardless of the system/hardware. Its related to policy install, cluster, vpn...

[Lesley · Accepted solution]

If you have trouble seeing the SMO from Smart Console it is related to SIC. Communication between SMO and SMS is via SIC connection. 

All Security Management Servers and managed Security Gateways must synchronize their system clocks.

This is important for these reasons:

• SIC

   trust can fail if devices are not synchronized correctly.

• ClusteR

   synchronization requires precise clock synchronization between members.

• SmartEvent Correlation uses time stamps that must be synchronized to approximately one a second.

• To make sure that cron jobs run at the correct time.

• To do certificate validation for applications based on the correct time.

The SGM sync the time between them. Note on SGM there is no ntpd running:

On a Security Group, the ntpd daemon does not run. Instead, the cpd daemon runs a scheduled task called UpdateTimeViaNTP. This task runs a special shell script called $SMODIR/scripts/asg_ntp_update_time.

Also what you state is correct, if the time difference is to big between the NTP server and local time a NTP sync will not happen. Change the time manually, like 5 minutes before or after real current time. Configure NTP and then check if it changes.

[the_rock]

Sounds logical!

[emmap]

I don't know that it matters too much between MHOs and SGMs, but it might matter between MHOs. It certainly does in R82 because the MHOs set up trust between themselves with certificates, so if the time is wildly out their self-generated certs won't be valid between each other. For whatever reason, MHOs out of the box have their clocks set wildly back and need to be manually set before NTP can take over to manage. Always good to check the time zone too, it defaults to New York and is commonly not changed, and NTP doesn't set the time zone.

MHO time won't affect SMO/SMS comms, the SGMs handle time by themselves, and are generally pretty good out of the box. That said, SIC required time to be pretty close, as Lesley has explained, so NTP is always a good idea for any CP device.