NTP issues

[Colin_Campbell1]

HI,

Just thought I'd share an experience I had recently trying to get NTP working. The gateway is running in Azure and I tried setting up NTP to use 0.pool.ntp.org and 1.pool.ntp.org. While tcpdump showed packets coming and going, ntpd just sat there in .INIT. state. After a bit of reading I checked the associations and found the servers in state "reject" - ntpd found them "too far away" to be considered reliable sources. Restarting ntpd only really changed the servers being accessed (DNS returned different answers each time).  Eventually I found that ntp.checkpoint.com and ntp2.checkpoint.com were acceptable and the system started syncing. Coincidence?

After some more research I found a couple of things:

• systems running as VMs don't really have a "stable" CPU so clock ticks wander and can even stop. This plays havoc with NTP
• Microsoft actually recommends against using NTP ins Azure, offering several alternatives. See 

  https://docs.microsoft.com/en-us/azure/virtual-machines/linux/time-sync

I'm not sure if AWS or even VMWare have the same issue as I have systems on both platforms running ntpd quite happily.

If you get stuck in .INIT., use ntpq to check using the subcommands, "peers", "associations" and "rv", eg, from my now working setup:

# ntpq
ntpq> peers
remote refid st t when poll reach delay offset jitter
==============================================================================
+nomi.checkpoint 194.29.36.22 3 u 908 1024 377 269.716 -0.474 0.959
*us-ntp1.us.chec 84.168.88.243 2 u 322 1024 377 141.242 -0.067 0.132
ntpq> associations

ind assid status conf reach auth condition last_event cnt
===========================================================
1 6260 943a yes yes none candidate sys_peer 3
2 6261 963a yes yes none sys.peer sys_peer 3
ntpq> rv 6260
associd=6260 status=943a conf, reach, sel_candidate, 3 events, sys_peer,
srcadr=nomi.checkpoint.com, srcport=123, dstadr=10.82.11.7, dstport=123,
leap=00, stratum=3, precision=-22, rootdelay=1.755, rootdisp=56.076,
refid=194.29.36.22,
reftime=e47509bb.91a81a16 Thu, Jun 17 2021 9:37:31.568,
rec=e4750d88.3149bbb6 Thu, Jun 17 2021 9:53:44.192, reach=377,
unreach=0, hmode=3, pmode=4, hpoll=10, ppoll=10, headway=0, flash=00 ok,
keyid=0, offset=-0.474, delay=269.716, dispersion=15.507, jitter=0.959,
xleave=0.056,
filtdelay= 269.72 273.56 269.65 270.49 269.60 269.16 273.14 269.64,
filtoffset= -0.47 1.57 -0.53 -0.12 -0.50 -0.69 0.97 -0.43,
filtdisp= 0.00 15.95 32.22 48.29 64.50 80.70 96.50 112.70
ntpq>

When it wasn't working "peers" would show .INIT., "associations" would show "reject" under the "condition" column and "rv" would show, amongst other things "flash=400 peer-dist". This "peer-dist" is telling you that after the calculations ntpd carries out, the time source exceeds the 1.5 second (default) threshold and is therefore considered unreliable and rejects it.

At present ntpd is still running but I may have to look at alternatives, especially for VMs to which I may soon be migrating a bunch of gateways. One of Microsoft's suggestions is to use "chrony" which isn't part of R80.40.

Anyone else have any similar experiences, comments, thoughts?

Colin

[PhoneBoy]

It might better to use periodic "ntpdate" commands (via cron) to resync the clock versus using ntpd in this situation.
At least this is what I've done in the past.