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
In article 478E3BC6.3000505@gmail.com, Sean Carolan scarolan@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@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
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?
In article 478E40FF.4070708@gmail.com, Sean Carolan scarolan@gmail.com 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
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.
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.
-
Paul Heinlein -
Sean Carolan -
tony＠softins.clara.co.uk