[ntp:questions] Reference clock all messed up?

Adam Bolte bolad03 at ca.com
Mon Nov 5 08:21:36 UTC 2007


Howdy all,

I've got a problem that has been driving me nuts. Hopefully, somebody can
give me a clue.

I've been requested to configure an NTP server (192.168.2.1) for the local
subnets that I'm responsible for. Unfortunately, firewall rules prevent me
from accessing 123/UDP on the Internet, however there is a machine that
appears to be running NTP on 192.168.1.1 (outside subnets I administer but
internal to the company and accessible) which I would like to sync my server to.

On 192.168.2.1 I'm running FreeBSD 5.4-STABLE with ntpd "4.2.0-a Thu Jan 19
11:02:17 EST 2006". According to nmap, 192.168.1.1 might be FreeBSD 6.1 (86%
sure).

Note that we don't want all client NTP machines to access 192.168.1.1 -
otherwise, things would have been much easier.

--- /etc/ntp.conf on 192.168.2.1 ---
# /etc/ntp.conf

server 192.168.1.1

driftfile /var/db/ntpd.drift

# by default ignore all ntp packets
restrict default ignore

# allow localhost
restrict 127.0.0.1 mask 255.255.255.255

# accept packets from...
restrict 192.168.2.0 mask 255.255.255.0 nomodify notrap
restrict 192.168.3.0 mask 255.255.255.0 nomodify notrap
restrict 192.168.4.0 mask 255.255.255.0 nomodify notrap
restrict 192.168.5.0 mask 255.255.255.0 nomodify notrap
--- end /etc/ntp.conf on 192.168.2.1 ---

So I run the daemon:
$ /usr/sbin/ntpd -p /var/run/ntpd.pid -c /etc/ntp.conf

Using a client on one of the subnets I control, I run:
$ sudo ntpdate 192.168.2.1
 5 Nov 18:39:36 ntpdate[21310]: no server suitable for synchronization found

Seems odd, so I try:

$ sudo ntpdate -d 192.168.2.1
 5 Nov 18:41:24 ntpdate[21447]: ntpdate 4.2.4p0 at 1.1472-o Thu Oct  4 22:22:32
UTC 2007 (1)
transmit(192.168.2.1)
receive(192.168.2.1)
transmit(192.168.2.1)
receive(192.168.2.1)
transmit(192.168.2.1)
receive(192.168.2.1)
transmit(192.168.2.1)
receive(192.168.2.1)
transmit(192.168.2.1)
192.168.2.1: Server dropped: strata too high
server 192.168.2.1, port 123
stratum 16, precision -19, leap 11, trust 000
refid [192.168.2.1], delay 0.02597, dispersion 0.00000
transmitted 4, in filter 4
reference time:    00000000.00000000  Thu, Feb  7 2036 17:28:16.000
originate timestamp: cad947a4.ebce9575  Mon, Nov  5 2007 18:41:24.921
transmit timestamp:  cad947a4.f189ce4a  Mon, Nov  5 2007 18:41:24.943
filter delay:  0.02609  0.02597  0.02600  0.02600
         0.00000  0.00000  0.00000  0.00000
filter offset: -0.02255 -0.02258 -0.02260 -0.02260
         0.000000 0.000000 0.000000 0.000000
delay 0.02597, dispersion 0.00000
offset -0.022588

 5 Nov 18:41:24 ntpdate[21447]: no server suitable for synchronization found


I believe "leap 11" is key, possibly indicating that there is a time
difference too great between the server and client. That certainly looks to
be the case. Waiting almost an hour for 192.168.2.1 to sync to 192.168.1.1
made no difference - the year stayed at 2036.

Next up, I decided to verify that 192.168.1.1 is accurate. I don't have the
ability to administer this box as it is outside my control, but I have no
choice but to use it as a reference clock for 192.168.2.1.

Again on an NTP client box:
$ sudo ntpdate -d 192.168.1.1
 5 Nov 18:28:39 ntpdate[20392]: ntpdate 4.2.4p0 at 1.1472-o Thu Oct  4 22:22:32
UTC 2007 (1)
transmit(192.168.1.1)
receive(192.168.1.1)
transmit(192.168.1.1)
receive(192.168.1.1)
transmit(192.168.1.1)
receive(192.168.1.1)
transmit(192.168.1.1)
receive(192.168.1.1)
transmit(192.168.1.1)
server 192.168.1.1, port 123
stratum 4, precision -19, leap 00, trust 000
refid [192.168.1.1], delay 0.03151, dispersion 0.00143
transmitted 4, in filter 4
reference time:    cad94300.b36a1529  Mon, Nov  5 2007 18:21:36.700
originate timestamp: cad944a7.538d4049  Mon, Nov  5 2007 18:28:39.326
transmit timestamp:  cad944a7.60bbc2b9  Mon, Nov  5 2007 18:28:39.377
filter delay:  0.03151  0.03615  0.03386  0.03632
         0.00000  0.00000  0.00000  0.00000
filter offset: -0.05936 -0.05702 -0.05825 -0.05692
         0.000000 0.000000 0.000000 0.000000
delay 0.03151, dispersion 0.00143
offset -0.059360

 5 Nov 18:28:39 ntpdate[20392]: Debug mode --not changing the system date
 5 Nov 18:28:39 ntpdate[20392]: adjust time server 192.168.1.1 offset
-0.059360 sec
abolte at sphinx:~$

It looks okay, however the time is still around 7 minutes out. I believe
192.168.2.1 to be more accurate.

On a client, I run:
$ ntpdate 192.168.1.1
 5 Nov 18:46:47 ntpdate[21910]: adjust time server 192.168.1.1 offset
-0.014893 sec

It made such a small adjustment to the clock... if it really needed to catch
up some 7 minutes, I would have expected a bigger adjustment.

After running the "ntpdate -d" command a few times against 192.168.1.1, I
noticed that the time didn't seem stable. I wrote a basic script to put it
to the test, with the intention of running it from 192.168.2.1.

--- timemonitor.sh ---
#!/usr/local/bin/bash

# On a remote machine, run:
####################################
# while [ 1 ] ; do                 #
#       nc -l -p 5000 -e /bin/date #
# done                             #
####################################
# to prove that this machine is sane. Specify the machine's IP address as a
parameter.

if [ -n "$1" ] ; then
        remoteIP=$1
        remoteIPTime=$(nc ${remoteIP} 5000 | tr -s ' ' | cut -d ' ' -f 4 ||
exit 1)
fi

ntp_out=$(ntpdate -d isis.ca.com 2>&1 | grep time | head -n 2 | tr -s ' ' |
cut -d ' ' -f 8 || exit 1)
remoteTime=$(echo "$ntp_out" | sed -n -e 's/\..*//' -e '1p')
localTime=$(echo "$ntp_out" | sed -n -e 's/\..*//' -e '2p')

if [ -n "${remoteIP}" ] ; then
        echo "Remote time (${remoteIP}): ${remoteIPTime}"
fi

echo "Remote time: ${remoteTime}"
echo "Local time: ${localTime}"

localHour=${localTime%%:*}
remoteHour=${remoteTime%%:*}

localMin=${localTime%:*}
localMin=${localMin#*:}
remoteMin=${remoteTime%:*}
remoteMin=${remoteMin#*:}

localSec=${localTime##*:}
remoteSec=${remoteTime##*:}


echo "Difference: $(expr ${localHour} - ${remoteHour}) hours, $(expr
${localMin} - ${remoteMin}) minutes and $(expr ${localSec} - ${remoteSec})
seconds."

--- end timemonitor.sh ---

Note that the script will also compare against another machine using netcat
to pipe through the date command - that way when I run the script at
5-minute intervals, I can be sure which machine is the one that is unstable.

On a client machine (192.168.2.60), I run:
$ while [ 1 ] ; do nc -l -p 5000 -e /bin/date; done


Finally, on 192.168.2.1 I run:
$ while [ 1 ] ; do echo "---" ; ./timemonitor.sh 192.168.2.60; sleep 300;
done
---
Remote time (155.35.180.60): 17:04:39
Remote time: 16:47:35
Local time: 17:04:39
Difference: 1 hours, -43 minutes and 4 seconds.
---
Remote time (155.35.180.60): 17:09:40
Remote time: 17:04:39
Local time: 17:09:39
Difference: 0 hours, 5 minutes and 0 seconds.
---
Remote time (155.35.180.60): 17:14:40
Remote time: 17:04:39
Local time: 17:14:40
Difference: 0 hours, 10 minutes and 1 seconds.
---
Remote time (155.35.180.60): 17:19:40
Remote time: 17:04:39
Local time: 17:19:40
Difference: 0 hours, 15 minutes and 1 seconds.
---
Remote time (155.35.180.60): 17:24:41
Remote time: 17:21:46
Local time: 17:24:41
Difference: 0 hours, 3 minutes and -5 seconds.
---
Remote time (155.35.180.60): 17:29:41
Remote time: 17:21:46
Local time: 17:29:41
Difference: 0 hours, 8 minutes and -5 seconds.
---
Remote time (155.35.180.60): 17:34:41
Remote time: 17:21:46
Local time: 17:34:41
Difference: 0 hours, 13 minutes and -5 seconds.
---
Remote time (155.35.180.60): 17:39:42
Remote time: 17:38:50
Local time: 17:39:41
Difference: 0 hours, 1 minutes and -9 seconds.
---
Remote time (155.35.180.60): 17:44:42
Remote time: 17:38:50
Local time: 17:44:42
Difference: 0 hours, 6 minutes and -8 seconds.
---
Remote time (155.35.180.60): 17:49:42
Remote time: 17:47:24
Local time: 17:49:42
Difference: 0 hours, 2 minutes and 18 seconds.
---
Remote time (155.35.180.60): 17:54:42
Remote time: 17:47:24
Local time: 17:54:42
Difference: 0 hours, 7 minutes and 18 seconds.
---
Remote time (155.35.180.60): 17:59:42
Remote time: 17:47:24
Local time: 17:59:43
Difference: 0 hours, 12 minutes and 19 seconds.
---
Remote time (155.35.180.60): 18:04:43
Remote time: 18:04:31
Local time: 18:04:43
Difference: 0 hours, 0 minutes and 12 seconds.
---
Remote time (155.35.180.60): 18:09:43
Remote time: 18:04:31
Local time: 18:09:43
Difference: 0 hours, 5 minutes and 12 seconds.
---
Remote time (155.35.180.60): 18:14:43
Remote time: 18:04:31
Local time: 18:14:44
Difference: 0 hours, 10 minutes and 13 seconds.
---
Remote time (155.35.180.60): 18:19:44
Remote time: 18:04:31
Local time: 18:19:44
Difference: 0 hours, 15 minutes and 13 seconds.
---
Remote time (155.35.180.60): 18:24:44
Remote time: 18:21:36
Local time: 18:24:44
Difference: 0 hours, 3 minutes and 8 seconds.
^C
$

Either my understanding of the reference clock is wrong, or something crazy
is happening on this network! It would appear to explain why the 192.168.2.1
NTP server couldn't sync to 192.168.1.1 properly.

Any ideas - any at all would be greatly appreciated.

Thanks,

Adam





More information about the questions mailing list