Problem synchronizing server time with ntpd

Question

I am trying to ntp sync one machine with another. both runs Debian lenny, and I installed the ntp package in both. I configured the server to synchronize with an external machine by putting

server IP.ADDRESS iburst

in it's /etc/ntp.conf file.

I configured the client to sync with the serve by putting only the server in /etc/ntp.conf of the client.

however, they do not seem to be synchronizing. ntpq shows that the state is INIT which - according to the docs - indicates that "The association has not yet synchronized for the first time"

# ntpq -n
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.99.84.134    .INIT.          16 u  665 1024    0    0.000    0.000   0.000

ntpq -> as shows 'reject' in the condition line:

# ntpq
ntpq> as

ind assID status  conf reach auth condition  last_event cnt
===========================================================
  1 40102  8000   yes   yes  none    reject

Any idea how to solve this? (I would rather not use ntpdate).

Solution 1

The problem was that the server itself was not able to synchronize with it's upstream server. the solution was to change the server configuration like this:

re-enabled the Debian pool servers instead of my single hard coded server.

server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst

I added a local clock reference, this makes the server appear synchronized to clients even when it's not, which is the desired behavior for my setup.

server 127.127.1.0
fudge 127.127.1.0 stratum 10

Once I made those changes, the server managed to synchronize itself and then the clients managed to sync with the server.

Solution 2

Many distributions these days are configuring ntpd to restrict access. If restrict lines are present in your server's /etc/ntp.conf, only hosts/networks matching those lines will be permitted to connect to ntpd. You probably need to add additional restrict lines for the hosts or networks you want to allow to sync to your server. For example, to let the client you mentioned sync, add one of the following lines:

# allow just this host
restrict 10.99.84.134 nomodify notrap

# or allow the whole /24 segment
restrict 10.99.84.0 mask 255.255.255.0 nomodify notrap

After that, restart ntpd, and your clients should be able to sync.

Solution 3

You can also say there's some sort of connectivity problem because the "reach" is still 0.

Turn off ntp for a moment, and try running ntpdate to sync it once:

ntpdate 10.99.84.134

If that fails, you definitely have a connectivity problem:

1. verify that the two machines can talk to each other via ICMP (ping)
2. if they can, verify that there's not a firewall setting on 10.99.84.134 preventing the connection to ntp

3. If there's no firewall problems, verify on 10.99.84.134 that ntp is listening

   netstat -tapn | grep 123

Comments

[Omry]

ntpdate can't syncrhonize. the machines can talk to one another, tested pings, and even tested netcat (sent a udp package on port 123 and it passed well). netstat shows that the server listens (but I needed to remove the -t option because ntp listens on udp port 123 and not tcp).

[Omry]

added the output of ntpq -> as to the question.

[Greeblesnort]

While I originally suspected a local firewall to be the problem, it certainly sounds like ntp itself is the culprit (per James' answer) sorry about the wrong netstat line, lizard brain sometimes types things without me noticing it's the wrong thing.

[Greeblesnort]

glad you got it sorted, although I don't know that I'm a fan of using iburst...do the debian pool servers have restriction statements elsewhere in the config?

[Marki555]

iburst sends burst of packets only on startup, so it is considered polite to the upstream servers. burst on the other hand sends burst of packets every time upstream server is contacted and so is considered abuse by some ntp server operators.