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

I'm trying to setup NTP on a local network that has no (and never will) internet connection. The main priority is that the machines on the network are synced with each other, even if the time they're synced at isn't 100% accurate.

We also have a requirement to use an NTP hierarchy in order to replicate the setup of a deployed system. What I want to do is have a hierarchy of machines like this:

Moon  (Main Server running Windows) (10.1.3.10)
|____Earth   (Linux x64 client) (10.1.3.1)
|____Mars    (Linux x64 client) (10.1.3.2)
|____Saturn  (Linux x64 client) (10.1.3.3)
|____RackCard23   (Linux x64 client and server to the two machines below)  (10.1.3.23)
     |___RackCard21   (Linux x64 client) (10.1.4.21)
     |___RackCard22   (Linux x64 client) (10.1.4.22)

Note that the RackCards have two ethernet ports, one connected to the 10.1.3.x network and one on the 10.1.4.x network. RackCard23, which syncs off the master server Moon will do so on the 10.1.3.x network and the RackCard22/23 will connect to RackCard23 on the 10.1.4.x network. This is because I don't want the RackCards22/23 leaving their network to sync the time and because it replicates a final deployed system.

So far I have managed to get everything that should by syncing off Moon to sync correctly (including RackCard23).

But I am having difficulty getting RackCard22 and 23 to sync off RackCard23.

[root@RackCard23]# cat /etc/ntp.conf
# NTP Deamon Configuration File "ntp.conf"
# Created on 27/04/2010
# Original backed-up as "ntp.conf.backup"

server 10.1.3.10 iburst minpoll 4 maxpoll 4 prefer #This is what we want to happen
fudge   127.127.1.0 stratum 2   #Not sure about these two lines, was trying to force it to be a stratum 2 server
fudge   127.127.0.1 stratum 2

# 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 /var/lib/ntp/drift
restrict 10.1.3.10 mask 255.255.255.255 nomodify notrap noquery

#Attempt to get to act as an NTP Server
broadcast 10.1.4.255

restrict 10.1.3.21 mask 255.255.255.255 nomodify notrap
restrict 10.1.4.21 mask 255.255.255.255 nomodify notrap

This is the output from ntptrace:

[rootRackCard23]# /usr/sbin/ntptrace
localhost.localdomain: stratum 16, offset 0.000000, synch distance 0.000030

As you can see the machine is reporting itself as a stratum 16 server, despite it having been synced to a "stratum 1" server (Moon):

[root@RackCard23 awd]# /usr/sbin/ntpdate -d 10.1.3.10
21 Jun 13:55:09 ntpdate[19410]: ntpdate 4.2.2p1@1.1570-o Tue May 19 13:57:56 UTC 2009 (1)
Looking for host 10.1.3.10 and service ntp
host found : 10.1.3.10
transmit(10.1.3.10)
receive(10.1.3.10)
transmit(10.1.3.10)
receive(10.1.3.10)
transmit(10.1.3.10)
receive(10.1.3.10)
transmit(10.1.3.10)
receive(10.1.3.10)
transmit(10.1.3.10)
server 10.1.3.10, port 123
stratum 1, precision -6, leap 00, trust 000
refid [LOCL], delay 0.04135, dispersion 0.00383
transmitted 4, in filter 4
reference time:    cfc99402.e010624d  Mon, Jun 21 2010  8:32:18.875
originate timestamp: cfc9dfad.48000000  Mon, Jun 21 2010 13:55:09.281
transmit timestamp:  cfc9dfad.47e27179  Mon, Jun 21 2010 13:55:09.280
filter delay:  0.04155  0.04155  0.04137  0.04135
         0.00000  0.00000  0.00000  0.00000
filter offset: -0.01448 0.000781 0.000537 0.000394
         0.000000 0.000000 0.000000 0.000000
delay 0.04135, dispersion 0.00383
offset 0.000394

21 Jun 13:55:09 ntpdate[19410]: adjust time server 10.1.3.10 offset 0.000394 sec

The configuration of the clients (RackCard21/22) looks like this:

[root@RackCard21]# cat /etc/ntp.conf
# NTP Deamon Configuration File "ntp.conf"
# Created on 27/04/2010
# Original backed-up as "ntp.conf.backup"

server 10.1.4.23 iburst minpoll 4 maxpoll 4 prefer

server 127.127.1.0
fudge   127.127.1.0 stratum 10

# 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 /var/lib/ntp/drift

# restrict 127.0.0.1

restrict None mask 255.255.255.255 nomodify notrap noquery

And ntptrace gives this:

[root@RackCard21]# /usr/sbin/ntpdate -d 10.1.4.23
21 Jun 14:04:34 ntpdate[14381]: ntpdate 4.2.2p1@1.1570-o Tue May 19 13:57:56 UTC 2009 (1)
Looking for host 10.1.4.23 and service ntp
host found : 10.1.4.23
transmit(10.1.4.23)
receive(10.1.4.23)
transmit(10.1.4.23)
receive(10.1.4.23)
transmit(10.1.4.23)
receive(10.1.4.23)
transmit(10.1.4.23)
receive(10.1.4.23)
transmit(10.1.4.23)
10.1.4.23: Server dropped: strata too high
server 10.1.4.23, port 123
stratum 16, precision -20, leap 11, trust 000
refid [10.1.4.23], delay 0.02568, dispersion 0.00000
transmitted 4, in filter 4
reference time:    00000000.00000000  Thu, Feb  7 2036  6:28:16.000
originate timestamp: cfc9dfef.12b79516  Mon, Jun 21 2010 13:56:15.073
transmit timestamp:  cfc9e1e2.aeae7d56  Mon, Jun 21 2010 14:04:34.682
filter delay:  0.02573  0.02571  0.02568  0.02568
         0.00000  0.00000  0.00000  0.00000
filter offset: -499.609 -499.609 -499.609 -499.609
         0.000000 0.000000 0.000000 0.000000
delay 0.02568, dispersion 0.00000
offset -499.609286

21 Jun 14:04:34 ntpdate[14381]: no server suitable for synchronization found

So it can't find a suitable server because the server I'm trying to use is reporting that it is a stratum 16 server (which I believe means non-synchronized). This is despite the fact that it is synchronized.

So I need to somehow make RackCard23 a higher stratum (Ideally stratum 2). How do I go about doing that?

Any help is much appreciated as I have been trying to get this to work for days now!

EDIT:

Hi Christopher,

I have been restarting the ntpd, yes ;)

All the linux boxes are running CentOS 5.4.

This is the output from the commands you suggested. Firstly from the server:

[root@RackCard23]# /usr/sbin/ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.1.3.10       .INIT.          16 u    -   16    0    0.000    0.000   0.000
 10.1.4.255      .BCST.          16 u    -   64    0    0.000    0.000   0.001

[root@RackCard23]# /usr/sbin/ntpdc -c monlist
remote address          port local address      count m ver code avgint  lstint
===============================================================================
localhost.localdomain  34566 127.0.0.1              1 7 2      0      0       0
10.1.4.21                123 10.1.4.23              5 3 4    180      5       1
10.1.4.22                123 10.1.4.23              7 3 4      0      2       2

And then from client:

[root@RackCard21]# /usr/sbin/ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.1.4.23       .INIT.          16 u   10   16    0    0.000    0.000   0.000
 LOCAL(0)        .LOCL.          10 l   44   64    1    0.000    0.000   0.001
share|improve this question
    
If you don't have an internet connection what is your time source, did I miss it somewhere? –  dbasnett Jun 23 '10 at 19:37
    
The time source doesn't really matter, we're not after 100% accurate time. What we do want is that all the machines are in sync with each other, even if that means their times are 10+ minutes off the actual time. So we are using a random machine on the network as a master time source - i.e. just its internal clock. Which we know and accept is unreliable, but as long as things sync it's OK for us. In the real deployed system we will be syncing to a time source on another system that we have no control over, which may or may not be more accurate. –  fwgx Jun 24 '10 at 8:36
add comment

3 Answers 3

As Chris mentioned, the stratum 16 indicates a server hasn't actually sync'd with a server. Just to be certain, you did restart the ntp services, right? (service ntpd restart) I'm not trying to insinuate you miss the easy stuff, but I always do!

Can you post the output of a few more commands to help diagnose?

ntpq -p on the client & server. Should show what servers it has configured, as well as stats for those servers.
ntpdc -c monlist on the server. Should show the clients connected.

Also, since you didn't mention an OS, I'm running with RHEL style commands. Let me know if you've got something different.

EDIT after further info
OK, seeing your output, here's your problem: You don't have a stratum 1 server. In fact, the "Moon" is using it's local clock. It's reporting itself as a stratum 16 server. For your reference, a Stratum1 server would have a local GPS or atomic clock. Do you have one of those? Otherwise, Moon needs to synchronize it's clock with ANOTHER ntp server. If it doesn't have network access, you'll need to fudge its stratum. (This requires you not to care too much about 'true' time. Which you don't, but anyone else reading this should note that.)

On Moon, add the following line to your ntp.conf file: fudge 127.127.1.0 stratum 10. This will make it report its local clock as stratum 10. Which will make all the other servers use it over their local stratum 16 clock.

--Christopher Karel

share|improve this answer
    
added results to main question post. –  fwgx Jun 21 '10 at 15:14
    
agreeing with Christopher. a lot of misconceptions about Strata ntp.org/ntpfaq/NTP-s-algo.htm –  dbasnett Jun 22 '10 at 13:42
add comment

NTPd will set it's own stratum according to:

  1. If the local clock's drift has not been assessed, set stratum to 16. This process takes about 15 minutes on a normal server, after which it proceeds to the next step.
  2. Connect to all configured time servers, assess which ones are reliable (and therefor preferred), set local stratum to the lowest reliable server's stratum plus one. So if the lowest reliable server found is 1, then local will be 2.

(This is not necessarily the order of the events, but the order in which they are processed for the purposes of setting the local stratum.)
(Also, stratum 16 does not necessarily mean it's unsynchronized).

share|improve this answer
1  
Could it be that because Moon is a Windows XP Pro x64 machine using the default W32Time NTP service which is actually Simple NTP (SNTP), that RackCard23 doesn't see it as a proper NTP server, so will never set its stratum to anything other than 16? –  fwgx Jun 21 '10 at 15:26
    
D'oh, I didn't see this before editing my post. This is pretty likely. Any reason not to use a proper ntp client on the top of your hierarchy? (Either Windows, or Unix based) –  Christopher Karel Jun 21 '10 at 16:06
add comment

As a kind of aside, I'll include some analysis of your ntpq output. Just to help generic troubleshooting in the future, for yourself and others.

First, from your server:

[root@RackCard23]# /usr/sbin/ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.1.3.10       .INIT.          16 u    -   16    0    0.000    0.000   0.000
 10.1.4.255      .BCST.          16 u    -   64    0    0.000    0.000   0.001

The first column indicates the two servers this machine is configured to sync to. Notable is the lack of * or + that would indicate a synchronized peer, or secondary candidates. This means your server isn't going to be using the entries here, but it is at least checking in with them.

Column three, "st", indicates the stratum of those servers. In this case, that indicates that both those machines are using their local clock. (default stratum of 16) The last three columns would indicate how far off the two clocks are. Either in a "seconds difference in clocks" value, or the latency between the two machines, to the difference in that latency. Here, higher numbers are worse.

The reason for non-sync'd entries like this can depend on some factors: If the offset in clocks is too much, then ntp won't even try, since it would introduce too big a jump in the local time. If jitter gets to bad, the client will desync, until things stabilize. (This is usually temporary, and yet, reoccuring) Alternately, as in your case, if the configured servers have equal or higher stratum values, indicating they are less reliable as time sources, then the client won't use them.

--Christopher Karel

share|improve this answer
add comment

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.