FAQ
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@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

Search Discussions

  • Tony Mountifield at Jan 16, 2008 at 5:32 pm
    In article <478E3BC6.3000505@gmail.com>,
    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@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
    The 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@softins.co.uk - http://www.softins.co.uk
    Play: tony@mountifield.org - http://tony.mountifield.org
  • Sean Carolan at Jan 16, 2008 at 5:38 pm

    The 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.
    Fantastic, Tony. This is the information I needed. Our ISP does in fact
    block UDP packets and I suspect this is why the sync is failing.

    One question though - how come I can use ntpdate servername to update them by
    hand? Shouldn't that be blocked as well?
  • Tony Mountifield at Jan 17, 2008 at 9:55 am
    In article <478E40FF.4070708@gmail.com>,
    Sean Carolan wrote:
    The 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.
    Fantastic, Tony. This is the information I needed. Our ISP does in fact
    block UDP packets and I suspect this is why the sync is failing.

    One question though - how come I can use ntpdate servername to update them by
    hand? Shouldn't that be blocked as well?
    That depends. The ntpdate on my system uses a non-privileged UDP port as the
    source port, and 123 as the destination. That means the reply from the external
    server will be coming back to a non-privileged port (above 1024). The ntpd
    daemon however uses 123 as both source and destination port, and therefore so
    will replies to it.

    Maybe the ISP allows incoming UDP packets to non-privileged ports but not to
    low port numbers like 123.

    Cheers
    Tony
    --
    Tony Mountifield
    Work: tony@softins.co.uk - http://www.softins.co.uk
    Play: tony@mountifield.org - http://tony.mountifield.org
  • Paul Heinlein at Jan 16, 2008 at 5:35 pm

    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@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
    Name 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/drift
    This 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@madboa.com <> http://www.madboa.com/
  • Sean Carolan at Jan 16, 2008 at 5:50 pm

    This 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.
    Good observation, Paul. That configuration is in fact from an ancient version
    of Red Hat which I plan to upgrade this week.
    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.
    I learned today that our ISP is blocking UDP traffic. I am going to ask them
    to make an exception for port 123 to fix this.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcentos @
categoriescentos
postedJan 16, '08 at 5:15p
activeJan 17, '08 at 9:55a
posts6
users3
websitecentos.org
irc#centos

People

Translate

site design / logo © 2022 Grokbase