NTPD on opensuse13.2 not locking onto a server

English Network/Internet
1

Hi,
I have a server running opensuse 13.2 (it was a fresh install, not upgraded from a previous release) which doesn’t appear to lock onto a time server. Other servers in the network sync without a problem (the others are running either SLES11 or OES). I have another server running opensuse 13.2 on a different network where ntp is configured and running normally & I can’t see any difference Between the two of them.

ntpq -p gives the following output: remote refid st t when poll reach delay offset jitter

127.127.1.0 .LOCL. 1 l 49 64 377 0.000 0.000 0.000
10.253.238.1 10.253.100.31 2 u 51 64 377 2.193 40.565 8.804
10.61.40.158 10.253.238.1 3 u 59 64 377 0.143 52.677 11.745
10.253.238.2 10.253.100.31 2 u 36 64 377 2.118 47.244 27.450

I never get any * or + or anything else in the first column to indicate ntp has locked onto any server and nothing in the log:
journalctl -u ntpd.service-- Logs begin at Sat 2016-05-07 11:49:18 ACST, end at Thu 2016-05-12 12:31:29 ACST. –
May 12 10:13:16 hamdns01 ntpd[3057]: ntpd 4.2.6p5@1.2349-o Mon Apr 20 13:45:41 UTC 2015 (1)
May 12 10:13:16 hamdns01 ntpd[3058]: proto: precision = 0.105 usec
May 12 10:13:16 hamdns01 ntpd[3058]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
May 12 10:13:16 hamdns01 ntpd[3058]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
May 12 10:13:16 hamdns01 start-ntpd[3046]: Starting network time protocol daemon (NTPD)
May 12 10:13:16 hamdns01 ntpd[3058]: Listen and drop on 1 v6wildcard :: UDP 123
May 12 10:13:16 hamdns01 ntpd[3058]: Listen normally on 2 lo 127.0.0.1 UDP 123
May 12 10:13:16 hamdns01 ntpd[3058]: Listen normally on 3 enp0s25 10.61.40.49 UDP 123
May 12 10:13:16 hamdns01 ntpd[3058]: peers refreshed
May 12 10:13:16 hamdns01 ntpd[3058]: Listening on routing socket on fd #20 for interface updates

(I restarted ntpd today, prior to that the log had no ntpd entries at all)

Even if it couldn’t sync to the other servers, I would have expected 127.127.1.0 to have a * against it. From what I’ve read, the 377 in the reach column indicates that the previous 8 exchange attempts with that host succeeded, so it must be communicating, just not syncing. Other servers can sync with those hosts quite happily and it doesn’t seem to matter what servers I try to sync with, nothing works!

Here is my ntp.conf:driftfile /var/lib/ntp/drift/ntp.drift
logfile /var/log/ntp
tos orphan 1
server 127.127.1.0
fudge 127.127.1.0 stratum 1
keys /etc/ntp.keys
trustedkey 1
requestkey 1
server 10.253.238.1 iburst
server 10.61.40.158 iburst prefer
server 10.253.238.2 iburst

I’ve run out of ideas at this point, hoping someone can suggest something!

Cheers,
Ian

2
  1. What’s your localhost address?
  2. Assuming the 127.127.1.0 really is your localhost then, you should fudge it to Stratum 12 (Only need it if the NTP servers disappear.)
  3. Is your /etc/ntp.keys file valid? – You may need to regenerate it.
  4. Are you sure that the “key (6) for accessing server variables” ‘controlkey 1’ entry in ntp.conf ] is not needed?
  5. NTP orphan mode: really use Stratum 1?

Orphan Mode allows a group of ntpd processes to automonously select a leader in the event that all real time sources become unreachable (i.e. are inaccessible).

Orphan Mode is enabled by adding the line tos orphan N anywhere in ntp.conf. The N specifies the stratum at which this ntpd will switch to Orphan Mode. For example, an ntpd using tos orphan 6 will not switch to Orphan Mode as long as a time source of strata 1 through 5 is reachable. The recommended value for N is 2 more than the worst-case externally-reachable source of time.

In addition to the tos orphan line all members of the Orphan Mode group must be configured in a mesh (i.e. they must all be clients / peers of each other). Any NTP association mode may be used to set up this mesh.

3

Further more, openSUSE 13.2 with IPv6 and ntp-4.2.6p5 could possibly us an ntp.conf which includes the following lines:


# NTP 4.2.6, visible to the Internet
#

restrict -4 default nomodify nopeer noquery notrap
restrict -6 default nomodify nopeer noquery notrap
# if your machine has IPv6 connectivity
# restrict 224.0.1.1 mask 255.255.255.255 nomodify # if you are using multicast (most folks are not)
restrict 127.0.0.1
restrict ::1
restrict 192.168.0.0 mask 255.255.255.0
# Use your network address and mask

# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust
4

Thanks for your help - it seems that the stratum 1 setting for orphan mode was the problem, I changed it to 10 and now it’s syncing to the other servers.
It’s odd - I used Yast to do the initial ntp setup and then added servers later on by hand, but I’m pretty sure I never touched the orphan stratum setting lines at all. The other 13.2 server I was looking at has it set to 10, but it was upgraded from 13.1.

Cheers,
Ian

5

And, I have to admit to an error in my initial post:

server 127.127.t.u [prefer] [mode int] [minpoll int] [maxpoll int]

is of course one of the Reference Clock commands . . .
[HR][/HR]However, I still have at least one issue with the “problem” configuration:
Reference Clock type “1” is the Undisciplined Local Clock: the text in the NTP documentation is quite old (they praise the hardware clock of the DEC machines but not that of the Sun machines . . . ) but, is still valid:

  • Do your servers have a reasonably stable hardware clock? – Of course an oven-controlled oscillator or even a rubidium standard would be almost perfect but, that’s not at all usual for NTP-Client servers.

Assuming that, the server in question is only an NTP-Client and regardless of the hardware clock stability, everything that is “server 127.127.1.u” should be fudged to Stratum 15 (covers the absolute worst case: the server is the last machine on the LAN and has to rely on it’s own [miserable] hardware clock).

If however, other machines on the LAN are using the server in question as an NTP-Server then:

  1. Do not use the “Undisciplined Local Clock”.
  2. The “Orphan Mode” should be used to manage the fallback scenarios related to server outages (see the NTP documentation related to “Association Management”).

[HR][/HR]And, if the server in question is really only an NTP-Client then, it should be set-up to ignore any NTP requests from other machines which believe that the server in question is an NTP-Server:


###############################################################################
## /etc/ntp.conf

#######################################
## NTP 4.2.6, 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
##
## Allow NTP messages from the loopback address (useful for debugging):
restrict 127.0.0.1
restrict ::1
##
#######################################

[HR][/HR]With the NTP version 4.2.6p5-25.12.1 currently valid for 13.2 and also later versions, you could consider the following:

  1. Set-up the local NTP-Servers as a pool with the “Orphan Mode” looking after the outage scenarios.
  2. The NTP-Clients then only need to use a single "pool <pool-address> iburst prefer
    " statement to sync to all the local NTP-Servers. 1. If the local NTP-Servers are set-up to use the “Broadcast Mode” then the NTP-Clients only need a "broadcastclient
    " statement.

Caveat: the LAN needs to have a strong Firewall in the direction of the ISP: no NTP Broadcasts to the outside world; no NTP Request from the outside world.