Using NTP on a Private Network

Apr 3, 2008

At work, I'm in charge of 20 individual build systems for one of our larger software project (18 Linux systems and 2 Windows systems). Every machine is connected to a private network that cannot see the outside world. As you might expect, the occasional "clock skew" warning would be thrown by gcc, since some of the source files had date stamps in the future. To fix this, I set out to learn about configuring NTP on a private network. As is typical of the Linux world, there was little useful documentation to be found. After gleaning little bits of information from a number of sources, I figured out how to do it, and I'm writing it down for everybody's benefit.

Creating the NTP Master Server

Our first step is to create a 'server' machine from which all of our other machines will get the time. In this tutorial, our master machine is a Linux box. Here's how to set things up:

Step 1: Edit ntp.conf
The first course of action is to edit the ntp.conf file in the /etc directory. Place the following lines in this file, removing any others that may exist (you may want to back up your existing ntp.conf file just in case):
# Use the local clock
server prefer
fudge stratum 10
driftfile /var/lib/ntp/drift
broadcastdelay 0.008

# Give localhost full access rights

# Give machines on our network access to query us
restrict mask nomodify notrap
You'll want to replace the highlighted sections with the private network address range that should be allowed to query this server, along with the corresponding mask, respectively. In this example, any machine on the network can query the master server for time updates.
Step 2: Restart the NTP daemon
Once the above changes have been made, the NTP daemon needs to be restarted. How to do this unfortunately differs among Linux distributions. Here are a few commands that I figured out for the OS families I care about:
  • RedHat: service ntpd restart
  • SLES 8/9: /etc/init.d/xntpd restart
  • SLES 10: /etc/init.d/ntp restart
Step 3: Configure NTP to start on reboot
Perhaps the most important step in this process is configuring the NTP daemon to start up on a reboot. Here's how to do it:
  • RedHat: chkconfig ntpd on
  • SLES 8/9: chkconfig xntpd on
  • SLES 10: chkconfig ntp on

Configuring the Client Machines

Step 1: Edit ntp.conf
Client machines must also have their ntp.conf file updated (again, in the /etc directory). Place the following lines in the configuration file:
# Point to our network's master time server

restrict default ignore
restrict mask nomodify notrap noquery

driftfile /var/lib/ntp/drift
Both of the highlighted sections above should point to the master server (in this case, with an IP address of
Step 2: Stop running NTP daemons
Use one of the following to stop any running NTP daemons:
  • RedHat: service ntpd stop
  • SLES 8/9: /etc/init.d/xntpd stop
  • SLES 10: /etc/init.d/ntp stop
Step 3: Force an update
We must force the client to update now, in case the offset is larger than 1000 seconds (the largest offset NTP allows). To do this, issue the following command:
ntpdate -u
Again, replace the highlighted section with the IP address of the master server. Note that you may need to do this forced update two or three times to make sure things are synchronized.
Step 4: Start the NTP daemon
Now that we've synced the client, we should restart the daemon:
  • RedHat: service ntpd start
  • SLES 8/9: /etc/init.d/xntpd start
  • SLES 10: /etc/init.d/ntp start
Step 5: Configure NTP to start on reboot
Finally, we need to make sure the daemon starts up at boot time (like we did for the server):
  • RedHat: chkconfig ntpd on
  • SLES 8/9: chkconfig xntpd on
  • SLES 10: chkconfig ntp on

Once you've set this up, all the client machines will keep their clocks synchronized with the master. If you update the master server time, the clients should follow (as long as the update isn't larger than 1000 seconds). I believe you can even point Windows systems to the master, though I have yet to try that.

Rahul Jain
7:07 AM on Oct 9, 2008
Thanks a lot.. i spent 12 hours to run ntp on my private wireless network. but after your webpage i able to slove this problem in 1 hour. i have one problem. after setting everything as described above when i ran command "ntpdate -u" i got an error proper server not found. but when i ping my other node from server. and ran comnabd "ntpdate -u" synchronization done. Thanks to u only.
9:54 AM on Oct 9, 2008
I'm assuming you were attempting to ping the server address (the 192 IP) from the server itself. If you have an external internet connection, you'll want your server to point to an external NTP location (there are a number of public pools to choose from). Otherwise, you'll have to manually update the time on the server (which is what I do, considering that my setup is on a private network). This is pretty easy to do:
date MMDDhhmmYYYY
hwclock --utc --systohc
For example:
date 100915302008
hwclock --utc --systohc
This would set the time to 3:30 PM, October 9, 2008.
5:20 AM on Nov 23, 2009
Hi! I have a trouble with NTP. I want a refresh my sistem clock (client) with a LAN Server each 5 minutes. I don't know any parameter of NTP protocol for this configuration. It's possible? The refresh it done usually, but takes a long time Thank you! PD: sorry for my poor english! :-)
10:11 AM on Nov 23, 2009
You could force an update using a crontab entry. Just issue ntpdate -u {IP_Address} as the command.
3:15 PM on Feb 14, 2010
hi nice ntp server tutorial I was lookingfor this for long time just a question you use this command to force an update with the NTP Server ntpdate -u LocalNTPServer ok my question is how frecuent the NTP daemon on the client query the NTP Server to update again? every hour? every day? is this automatic? I mean is it necessary to add this in cron "ntpdate -u LocalNTPServer" thanks a lot
7:24 PM on Feb 14, 2010
The call to ntpdate -u technically only needs to be done once. After you have synced to the master server, the NTP daemon should keep things in sync. I'm not sure what the update frequency is for NTP, though I've seen someone say that it will update every 64, 128, 256, 512, and 1024 seconds as it determines the reliability of both clocks. You should only need to add a crontab entry to force an update in extreme edge cases; namely, where the machine's hardware clock drifts more than 1000 seconds between NTP updates. I've only seen a few machines that are this bad, and its typically on really old hardware.
Add a Comment
Ignore this field:
Leave this blank:
Optional; will not be indexed
Ignore this field:
Both Markdown and a limited set of HTML tags are supported
Leave this empty: