Identify NTP clients using the server

With only one NTP server configured, the algorithm isn't entirely sure who to trust. Even though, stratum is lower with the remote host, I bet the algorithm thinks local time is more trustworthy.

Try using the prefer keyword with your server statement to set that as a preferential time source.

EDIT -

So, it looks like this is a duplicate of This question, but I don't feel that poster got a sufficient answer, so I would still like to know why the local time is being preferred over the server.

For a truly sufficient answer, you are going to be digging into the bowels of a very complex algorithm. The documentation doesn't even get too specific but I am sure there's a white paper or specification out there.

If I do remove all of the "local" lines in the config as the answer to the other question suggest, what will happen if the server is unreachable? Does NTP die or does it just keep trying?

The NTP daemon doesn't die or stop, but it does quit synchronizing time after it fails to reach the remote server. This is why best practices will suggest minimum of three remote servers and not to use the LCL unless you are disconnected from the network. Three servers are suggested because when there are only two, and they disagree, which will it choose? The third server should help the algorithm eliminate the bogus server.

Lastly, I just noticed that you do not define a driftfile. This might help?

I feel quite strongly that two local servers, which everyone else binds to, is the right way to go. NTP is designed to work that way, and it minimises the load on the public/pool servers.

I run an NTP pool server. Even in areas with well-populated pools the load is still significant (I'm running at an annualised average of 25 client requests per second, which means about 2.5 million a day). In some parts of the world, the pools are so small that the few people who run pool servers are getting quite overwhelmed.

Edit: Aaron Copley makes the excellent point that two servers will both be rejected by clients if only one of them is out-of-sync but still thinks it's correct (see, eg, this question), and that having two (instead of just one) simply doubles the single-point-of-failure. He is absolutely right that three would be better, and in a larger production network I would agree that it is appropriate for this usage case. In my experience, however, properly-configured NTPd works a lot more often than it fails, and the risk of a single server being unavailable and client clocks getting too far out of sync to recover automatically much outweighs the risk of one server advertising a faulty time and invalidating both.

For me, two is the right number of upstream-synced servers for this network - but there is definitely a legitimate discussion to be had around the issue, and I'm grateful to Aaron for raising the point.