Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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).

share|improve this question

4 Answers 4

up vote 1 down vote accepted

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.

share|improve this answer
    
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? –  Greeblesnort Sep 23 '09 at 4:54

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.

share|improve this answer
    
debian does not restrict time queries by default. –  Omry Sep 22 '09 at 8:22

Try to run tcpdump on the server to intercept all tcp and udp traffic that comes to and goes from port 123. Guess if the packets can reach the port without problems, they are blocked somehow on their way back, by a firewall of the client for example

share|improve this answer

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

share|improve this answer
    
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 Sep 21 '09 at 13:18
    
added the output of ntpq -> as to the question. –  Omry Sep 21 '09 at 13:20
    
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 Sep 21 '09 at 14:56

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.