Maybe there's an ntp expert out there who can help me with this. I have an
NTP server serving our local network. It is
set up to use pool.ntp.org servers for it's upstream sync. ntpq -p reveals
that the server is stuck on stratum 16,
which I understand means "not synced". The clients are unable to sync
with my local server because of this. Here's the
output of ntpq -p along with my ntp.conf file:
[root at ntpserver /root]# ntpq -p
remote refid st t when poll reach delay offset disp
=============================================================================
echo.sureproxy. 0.0.0.0 16 u 29 64 0 0.00 0.000 16000.0
nist.netservice 0.0.0.0 16 u 19 64 0 0.00 0.000 16000.0
ntp.your.org 0.0.0.0 16 u 19 64 0 0.00 0.000 16000.0
ntp.pbx.org 0.0.0.0 16 u 19 64 0 0.00 0.000 16000.0
# NTP cluster configuration file
server 0.rhel.pool.ntp.org
server 1.rhel.pool.ntp.org
server 2.rhel.pool.ntp.org
server 3.rhel.pool.ntp.org
#
# Drift file. Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
#
driftfile /etc/ntp/drift
#multicastclient # listen on default 224.0.1.1
broadcastdelay 0.008
#
# Authentication delay. If you use, or plan to use someday, the
# authentication facility you should make the programs in the auth_stuff
# directory and figure out what this number should be on your machine.
#
authenticate no
# by default, don't trusst and not allow modifications
restrict default notrust nomodify
# These machines are trusted for time, but no modifications allowed
restrict 10.1.0.0 mask 255.255.0.0 nomodify
restrict 10.100.0.0 mask 255.255.0.0 nomodify
# The local host is unrestricted
restrict 127.0.0.1
#
# Keys file. If you want to diddle your server at run time, make a
# keys file (mode 600 for sure) and define the key number to be
# used for making requests.
#
keys /etc/ntp/keys
trustedkey 65535
requestkey 65535
controlkey 65535
enable monitor
In article <478E3BC6.3000505 at gmail.com>, Sean Carolan <scarolan at gmail.com> wrote:> Maybe there's an ntp expert out there who can help me with this. I have an NTP server > serving our local network. It is > set up to use pool.ntp.org servers for it's upstream sync. ntpq -p reveals that the server > is stuck on stratum 16, > which I understand means "not synced". The clients are unable to sync with my local server > because of this. Here's the > output of ntpq -p along with my ntp.conf file: > > [root at ntpserver /root]# ntpq -p > remote refid st t when poll reach delay offset disp > =============================================================================> echo.sureproxy. 0.0.0.0 16 u 29 64 0 0.00 0.000 16000.0 > nist.netservice 0.0.0.0 16 u 19 64 0 0.00 0.000 16000.0 > ntp.your.org 0.0.0.0 16 u 19 64 0 0.00 0.000 16000.0 > ntp.pbx.org 0.0.0.0 16 u 19 64 0 0.00 0.000 16000.0The zeros in the "reach" column indicate that the server has been unable to receive any packets from the upstream servers. Is your server inside a firewall? If so, perhaps it is blocking NTP traffic. You need to have it allow UDP port 123 in both directions. You don't need port forwarding from outside to in, since all incoming packets will be replies to outgoing packets. If it is not inside a firewall, perhaps you have iptables on the server itself blocking UDP port 123 traffic. Cheers Tony -- Tony Mountifield Work: tony at softins.co.uk - http://www.softins.co.uk Play: tony at mountifield.org - http://tony.mountifield.org
On Wed, 16 Jan 2008, Sean Carolan wrote:> Maybe there's an ntp expert out there who can help me with this. I > have an NTP server serving our local network. It is set up to use > pool.ntp.org servers for it's upstream sync. ntpq -p reveals that > the server is stuck on stratum 16, which I understand means "not > synced". The clients are unable to sync with my local server > because of this. Here's the output of ntpq -p along with my > ntp.conf file: > > [root at ntpserver /root]# ntpq -p > remote refid st t when poll reach delay offset > disp > =============================================================================> echo.sureproxy. 0.0.0.0 16 u 29 64 0 0.00 0.000 > 16000.0 > nist.netservice 0.0.0.0 16 u 19 64 0 0.00 0.000 > 16000.0 > ntp.your.org 0.0.0.0 16 u 19 64 0 0.00 0.000 > 16000.0 > ntp.pbx.org 0.0.0.0 16 u 19 64 0 0.00 0.000 > 16000.0Name resolution is working correctly, but, yeah, there's no sync-ing happening.> # Drift file. Put this in a directory which the daemon can write to. > # No symbolic links allowed, either, since the daemon updates the file > # by creating a temporary in the same directory and then rename()'ing > # it to the file. > # > driftfile /etc/ntp/driftThis is almost certainly incorrect unless you're running a very, very old RHEL/CentOS release. I believe /var/lib/ntp is the canonical directory for the drift file in 4.x and 5.x. I doubt ntpd is allowed to write to /etc/ntp, especially if SELinux is enabled. Have you tried shutting down ntpd and relaunching it manually with the "don't fork and give me lots of debugging output" switches (-n -ddd) enabled? Alternatively (or additionally), you might try wrapping ntpd in strace to see if any system calls are being thwarted. -- Paul Heinlein <> heinlein at madboa.com <> http://www.madboa.com/