Now that the issues I reported in the post <https://forums.opensuse.org/showthread.php/513081-NTP-daemon-not-always-using-all-the-defined-servers> have been resolved, I’ve noticed the following (new) NTP issue:
- If the configuration command “pool de.pool.ntp.org iburst prefer” is used in place of a list of “server x
.de.pool.ntp.org iburst” commands, only at most one NTP server is used.
Is anyone else noticing this issue?
[HR][/HR]My current solution is to use the following /etc/ntp.conf content:
#######################################
## Undisciplined Local Clock:
server 127.127.1.0
fudge 127.127.1.0 stratum 15
#######################################
# pool de.pool.ntp.org iburst prefer
## See restrict source above.
# broadcastclient
server 0.de.pool.ntp.org iburst prefer
server 1.de.pool.ntp.org iburst
server 2.de.pool.ntp.org iburst
server 3.de.pool.ntp.org iburst
server fritz.box iburst
[HR][/HR]Yes, there’s some “restrict” entries needed for NTP Clients using NTP versions including and later than 4.2.7:
################################################################################
## /etc/ntp.conf
##
## Paket 4.2.8p7-21.1 x86_64
#######################################
## NTP 4.2.7 or later, Client-only.
##
## By default act only as a basic NTP client.
restrict -4 default nomodify nopeer noquery notrap
restrict -6 default nomodify nopeer noquery notrap
# restrict source nomodify noquery notrap
## Don't use nopeer with pool servers
##
# restrict 224.0.1.1 mask 255.255.255.255 nomodify
## If you are using multicast (most folks are not).
##
## Allow NTP messages from the loopback address (useful for debugging):
restrict 127.0.0.1
restrict ::1
##
#######################################
## Clients from this subnet have unlimited access, but only if
## cryptographically authenticated:
# restrict 192.168.178.0 mask 255.255.255.0 notrust
## Clients from this subnet have unlimited access:
# restrict 192.168.178.0 mask 255.255.255.0
[HR][/HR]And, there are also some “key” entries needed these days:
##
## Authentication stuff
##
keys /etc/ntp.keys
## path for keys file
##
trustedkey 1
## define trusted keys
## The key ID(s) which are trusted for the purposes of authenticating peers with
## symmetric key cryptography.
##
requestkey 1
## key (7) for accessing server variables
## The key ID for the ntpdc utility program.
##
# controlkey 15
controlkey 1
## key (6) for accessing server variables
## The key ID for the ntpq utility.
Thanks arvidjaar! (I missed that in the NTP documents!)
[HR][/HR]But, the ‘ntp.conf’ man page is a little bit unclear/ambiguous about this point, despite referencing the “Server Pool Scheme” description in the “Automatic Server Discovery Schemes” section of the NTP documentation.
[HR][/HR]And, there was an NTP version recently where a single ‘ntp.conf’ “pool” command resulted in a list of NTP servers being referenced.
- This confused me and I missed the point made by arvidjaar.
What I’m currently seeing seems to be another issue.
[HR][/HR]With the following ‘ntp.conf’ commands:
pool de.pool.ntp.org iburst prefer
pool 0.de.pool.ntp.org iburst
pool 1.de.pool.ntp.org iburst
pool 2.de.pool.ntp.org iburst
“# ntpq -p” issues the following status:
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
LOCAL(0) .LOCL. 15 l 572 64 0 0.000 0.000 0.000
de.pool.ntp.org .POOL. 16 p - 64 0 0.000 0.000 0.000
0.de.pool.ntp.o .POOL. 16 p - 64 0 0.000 0.000 0.000
1.de.pool.ntp.o .POOL. 16 p - 64 0 0.000 0.000 0.000
2.de.pool.ntp.o .POOL. 16 p - 64 0 0.000 0.000 0.000
*fritz.box 144.76.115.197 3 u 28 64 377 0.279 0.292 0.078
#
Diving deeper into ntpq and examining the associations, an “ntpq” ‘pstats’ commands reveal the following information:
# ntpq
ntpq> apeers
remote refid assid st t when poll reach delay offset jitter
==============================================================================
LOCAL(0) .LOCL. 4512 15 l 745 64 0 0.000 0.000 0.000
de.pool.ntp.org .POOL. 4513 16 p - 64 0 0.000 0.000 0.000
0.de.pool.ntp.o .POOL. 4514 16 p - 64 0 0.000 0.000 0.000
1.de.pool.ntp.o .POOL. 4515 16 p - 64 0 0.000 0.000 0.000
2.de.pool.ntp.o .POOL. 4516 16 p - 64 0 0.000 0.000 0.000
*fritz.box 904c73c5 4517 3 u 65 64 377 0.279 0.292 0.138
ntpq> pstats 4513
associd=4513 status=8811 conf, bcast, sel_reject, 1 event, mobilize,
remote host: 0.0.0.0:0
local address: 0.0.0.0:0
time last received: 756
time until next send: 29
reachability change: 756
packets sent: 12
packets received: 0
bad authentication: 0
bogus origin: 0
duplicate: 0
bad dispersion: 0
bad reference time: 0
candidate order: 0
ntpq> pstats 4514
associd=4514 status=8811 conf, bcast, sel_reject, 1 event, mobilize,
remote host: 0.0.0.0:0
local address: 0.0.0.0:0
time last received: 762
time until next send: 29
reachability change: 762
packets sent: 12
packets received: 0
bad authentication: 0
bogus origin: 0
duplicate: 0
bad dispersion: 0
bad reference time: 0
candidate order: 0
ntpq> pstats 4517
associd=4517 status=963a conf, reach, sel_sys.peer, 3 events, sys_peer,
remote host: fritz.box:123
local address: xxxx.fritz.box:123
time last received: 20
time until next send: 47
reachability change: 765
packets sent: 17
packets received: 17
bad authentication: 0
bogus origin: 0
duplicate: 0
bad dispersion: 0
bad reference time: 0
candidate order: 6
ntpq> q
#
In other words, it seems that “de.pool.ntp.org” doesn’t want to respond to NTP clients configured to use the “pool” command. 
Oops!!
I forgot to remove a comment from the “I’m an NTP Client and not an NTP Server” ‘ntp.conf’ command block:
restrict source nomodify noquery notrap
The “ntpq -p” status is now:
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
LOCAL(0) .LOCL. 15 l 123m 64 0 0.000 0.000 0.000
de.pool.ntp.org .POOL. 16 p - 64 0 0.000 0.000 0.000
+fritz.box 37.120.191.245 3 u 84 512 377 0.374 0.090 0.271
*schubhart.de 131.188.3.222 2 u 146 512 377 26.420 0.389 0.165
-wotan.tuxli.ch 211.172.242.174 3 u 193 1024 377 25.947 0.447 0.180
-176.9.253.75 (n 188.2.166.125 3 u 86 512 377 25.915 0.726 0.176
-x.ns.gin.ntt.ne 249.224.99.213 2 u 218 1024 377 21.976 -7.671 13.203
+ntp2.m-online.n 212.18.1.106 2 u 174 512 377 20.745 -0.510 0.213
-news02.nierle.c 192.53.103.104 2 u 48 1024 377 26.092 3.469 0.116
-ghost-networks. 130.149.17.8 2 u 29 1024 377 24.879 1.879 0.202
#
The ‘ntp.conf’ “server/pool” commands are:
#######################################
## Undisciplined Local Clock:
server 127.127.1.0
fudge 127.127.1.0 stratum 15
#######################################
pool de.pool.ntp.org iburst prefer
server fritz.box iburst
# broadcastclient
# Don't use broadcast mode if you cannot monitor your client servers.
[HR][/HR]The “only one NTP pool server” issue was with the ntp package version 4.2.8p7.
It seems to have been repaired with the 4.2.8p8 patches which arrived after the 30th of May 2016.
The version 4.2.6p5 didn’t suffer from the “only one NTP pool server” issue.