0

I have a chrony NTP client where a local chrony NTP server which is present in the same LAN is configured as the preferred server. For resiliency, I have added the Ubuntu NTP pool as a fallback server. I have used the prefer directive to give priority to the local time server.

When I run the client where only the local time server is configured, it is syncing with the local time server. However, when I add the Ubuntu NTP pool as a fallback server and restart chrony client, the client is always syncing with the Ubuntu NTP pool instead of preferring the local time server.

Chrony client config


server 192.168.210.88 iburst prefer
pool ntp.ubuntu.com iburst maxsources 4

keyfile /etc/chrony/chrony.keys

driftfile /var/lib/chrony/chrony.drift

logdir /var/log/chrony

log measurements statistics tracking

maxupdateskew 100.0

rtcsync

makestep 1 3

chrony server config

confdir /etc/chrony/conf.d

pool ntp.ubuntu.com iburst maxsources 4 pool 0.ubuntu.pool.ntp.org iburst maxsources 1 pool 1.ubuntu.pool.ntp.org iburst maxsources 1 pool 2.ubuntu.pool.ntp.org iburst maxsources 2

allow 0.0.0.0/0

local stratum 1

sourcedir /run/chrony-dhcp

sourcedir /etc/chrony/sources.d

keyfile /etc/chrony/chrony.keys

driftfile /var/lib/chrony/chrony.drift

ntsdumpdir /var/lib/chrony

log tracking measurements statistics

logdir /var/log/chrony

maxupdateskew 100.0

rtcsync

makestep 1 3

leapsectz right/UTC

Note: For simplicity, I have removed the comments from the config file.

You can see that I have assigned a stratum of 1 to the server to increase its priority. I thought that the stratum of servers in the Ubuntu NTP pool might be lesser than that of the local server. But it didn't solve the issue.

I'm a beginner in time servers and NTP. Apart from troubleshooting this specific issue, I happily welcome suggestions on setting up a local time server for a LAN; a better way to do it.

Thank you for your time :)

1 Answers1

0

NTP daemons by design are best presented with a variety of upstream sources and will choose that which is deemed best: offset, jitter, reachability, etc. Don't try to game the selection.

If your system is routinely picking a public pool source, then I suspect at least one of the below is true:

  • Your local source isn't reachable -- iptables, ACLs, DNS, etc
  • Your local source isn't very good.

I would take out your maxsources bits.

In the end, why do you care which source is used? NTP network traffic is trivial.

What is 192.168.210.88 here? A network device? A GPS appliance? A VM?

VMs make lousy sources as virtualized clocks are generally not nearly stable enough.

If you want an inexpensive low-stratum local source, you can find various appliances on the net for as little as a couple hundred bucks. Set one up in a window with LoS to the sky and have your local distribution server include it as a source. If you only have a couple of local client systems you can point them directly at the appliance.

Configure a diversity of sources for resilience.