Gaia 81.10/Quantum 6200: The gateway's clock is not synchronizing automatically to my NTP servers

[pizzaprophet]

I use two Windows Server 2022 servers as NTP servers.

In Gaia, time settings:
Primary server: 10.20.60.40, version 3
Secondary server: 10.20.60.41, version 3

But it's not synchronizing.

However,  I am able to sync manually using ntpupdate 10.20.60.40

Troubleshooting below. Note that ntpq outputs "condition = reject" ??

[Expert@mygw:0]# ntpq
ntpq> peers
remote refid st t when poll reach delay offset jitter
==============================================================================
MYDC02 10.20.60.41 6 u 35 64 7 0.291 316.958 79.300
MYDC01 10.20.60.40 6 u 34 64 7 0.315 562.887 86.161
ntpq> as

ind assid status conf reach auth condition last_event cnt
===========================================================
1 52604 9024 yes yes none reject reachable 2
2 52605 9024 yes yes none reject reachable 2
ntpq>

ntpq> rv 52604
associd=52604 status=9024 conf, reach, sel_reject, 2 events, reachable,
srcadr=MYDC02, srcport=123, dstadr=10.20.60.3, dstport=123, leap=00,
stratum=6, precision=-23, rootdelay=29.053, rootdisp=1620.941,
refid=10.50.1.1,
reftime=eada2897.a5178989 Sat, Nov 9 2024 19:29:43.644,
rec=eada290d.de71be67 Sat, Nov 9 2024 19:31:41.868, reach=377,
unreach=0, hmode=3, pmode=4, hpoll=6, ppoll=6, headway=315,
flash=400 peer_dist, keyid=0, offset=604.183, delay=0.429,
dispersion=0.981, jitter=246.417, xleave=0.004,
filtdelay= 0.43 0.34 0.44 0.41 0.32 0.36 0.29 0.45,
filtoffset= 604.18 497.14 406.08 356.85 324.11 310.55 316.96 347.25,
filtdisp= 0.00 1.02 2.03 3.05 4.07 5.10 6.11 7.14

[oa_munich]

What's your 'show configuration ntp' showing?
NTP commonly gets status rejected if time is too far off, but since you've synched manually this should not be the case.

I have also noticed strange NTP behavior when NTP client could not ping the server - maybe check if the gateway is trying to ping and the packets get dropped?

[pizzaprophet]

mygw> show configuration ntp
set ntp active on
set ntp server primary 10.20.60.40 version 3
set ntp server secondary 10.20.60.41 version 3

[Chris_Atkinson]

NTP stratum 6 is indicating the setup is not ideal...

Flash code 400 = Distance threshold exceeded

[pizzaprophet]

Not ideal... But exactly why is it being rejected though?

[Chris_Atkinson]

I imagine it isn't liking the root dispersion value which seems a common factor with Windows when used as an NTP time source.

[oa_munich]

Try on your Windows server
w32tm /query /status /verbose

If Root Dispersion is close to or greater than 1, as @Chris_Atkinson is suggesting, the root dispersion is too high.

[pizzaprophet]

on MYDC02 (10.20.60.41):

C:\Windows\system32>w32tm /query /status /verbose
Leap Indicator: 0(no warning)
Stratum: 6 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0289341s
Root Dispersion: 0.0949771s
ReferenceId: 0x0ADCA954 (source IP: 10.50.1.1)
Last Successful Sync Time: 10.11.2024 15:41:34
Source: masterntpserver01
Poll Interval: 6 (64s)

Phase Offset: 0.0006467s
ClockRate: 0.0156249s
State Machine: 2 (Sync)
Time Source Flags: 0 (None)
Server Role: 576 (Reliable Time Service)
Last Sync Error: 0 (The command completed successfully.)
Time since Last Good Sync Time: 12.1491947s

on MYDC01 (10.20.60.40):

C:\Windows\system32>w32tm /query /status /verbose
Leap Indicator: 0(no warning)
Stratum: 6 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0293165s
Root Dispersion: 0.6521668s
ReferenceId: 0x0ADCA954 (source IP: 10.50.1.1)
Last Successful Sync Time: 10.11.2024 15:36:40
Source: masterntpserver01
Poll Interval: 10 (1024s)

Phase Offset: -0.3063846s
ClockRate: 0.0156226s
State Machine: 2 (Sync)
Time Source Flags: 0 (None)
Server Role: 576 (Reliable Time Service)
Last Sync Error: 0 (The command completed successfully.)
Time since Last Good Sync Time: 445.0699060s

on masterntpserver01 (10.50.1.1, which syns to time.windows.com): Root Dispersion is 0.053s

[oa_munich]

If memory serves me right, on Windows the value of LocalClockDispersion is set to 10 by default 
https://ss64.com/nt/w32tm.html

You can try setting it to 0, restarting the w32tm service and see if this fixes the issue.

[Chris_Atkinson]

@_Val_ @PhoneBoy could you please check if replies for @pizzaprophet are being caught by spam / moderation?

Despite the notifications the posts don't display here...

[_Val_]

Spam filtering engine does not like special symbols much. Released now

[pizzaprophet]

now it suddely works again, without me having done anything. Note that the root dispersion is now much lower (117.996 vs 1620.941).

[Expert@mygw:0]# ntpq
ntpq> peers
remote refid st t when poll reach delay offset jitter
==============================================================================
+MYDC02 10.20.60.3 6 u 154 1024 377 0.286 -0.657 2.946
*MYDC01 10.20.60.3 6 u 347 1024 377 0.281 1.986 0.479

ntpq> as

ind assid status conf reach auth condition last_event cnt
===========================================================
1 42585 9424 yes yes none candidate reachable 2
2 42586 963a yes yes none sys.peer sys_peer 3

ntpq> rv 42585
associd=42585 status=9424 conf, reach, sel_candidate, 2 events, reachable,
srcadr=MYDC02, srcport=123, dstadr=10.20.60.3, dstport=123, leap=00,
stratum=6, precision=-23, rootdelay=29.236, rootdisp=117.996,
refid=10.220.169.84,
reftime=eadf5bda.6debaf10 Wed, Nov 13 2024 18:09:46.429,
rec=eadf5bdb.c63096de Wed, Nov 13 2024 18:09:47.774, reach=377,
unreach=0, hmode=3, pmode=4, hpoll=10, ppoll=10, headway=0, flash=00 ok,
keyid=0, offset=-0.657, delay=0.286, dispersion=15.116, jitter=2.946,
xleave=0.009,
filtdelay= 0.29 0.35 0.34 0.27 0.34 0.33 0.32 0.33,
filtoffset= -0.66 2.23 2.24 2.17 1.49 1.37 3.00 3.08,
filtdisp= 0.00 15.47 31.34 47.06 63.11 79.34 95.30 111.32
ntpq>

@oa_munich 

[the_rock]

I know once I had this issue, I had customer follow below sk.

Andy

https://support.checkpoint.com/results/sk/sk92602

[Chris_Atkinson]

Root dispersion and jitter are improved.

[oa_munich]

I played around with a couple of ntp servers today.

In my region (Germany), the nslookup of time.windows.com resolves to CNAME twc.trafficmanager.net, which would suggest it's load balancer. So, I've done several manual resyncs, and found that depending on what the load balancer connects you to, you get connected to stratum 5, 4 and very rarely to stratum 3. This results in VASTLY different root dispersion, ranging from 0.172 to over 2(!) - after giving enough time for the root dispersion to go down after the initial sync.

So, it would seem that your masterntpserver01 was technically synching to different servers, and got lucky recently, and synched to the one, which has better stratum and managed to get better root dispersion.

I never sync to time.windows.com - my equivalent of your master ntp server syncs to stratum 2 servers:

https://support.ntp.org/Servers/StratumTwoTimeServers