Proper NTP configuration for a few servers

Solution 1:

  1. Am I a noticeable burden to the pool? I.e. does it make any noticeable difference to the pool if I'm hitting from 20 servers or from 2?

Given that the pool is in constant need of servers for many years (see [1]) I would say that although 2 or 20 servers don't really make a difference you should always remember that you are not alone. So you better be thinking about say 1000 admins in which case we're talking 2000 or 20000 servers and this does make a difference.

  1. If it does make a difference what's the setup/configuration that will keep my subnet synced and the pool under light load?

You must sync two[2] servers in your network with the pool (let's call them Primary NTP Servers) and then sync all other servers to those two. This method also has the advantage that the time between all your servers will be more closely matched (within less than 1msec). This is in accordance to IETF best practices.

1) The configuration for the Primary NTP Servers

Replace the server and restrict lines of your ntp[d].conf with the following and keep the rest to your distribution defaults[3]:

peer 10.11.12.1  iburst
#      ^^^^^^^^^^^
#      The LAN IP of the _other_ Primary NTP server 
server 0.europe.pool.ntp.org 
server 1.europe.pool.ntp.org 
server 2.europe.pool.ntp.org 
server 3.europe.pool.ntp.org 
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1

Please note that this configuration also permits hosts from all over the Internet to query your host time via NTP queries. Use your firewall if you don't want to. In my example 10.11.12.1 and 10.11.12.2 are the IPs of the Primary NTP Servers (they have two network cards one facing the public internet and one the local 10.11.12.x subnet). Each Primary NTP Server has the other one declared as a peer (peer basically means both server and client - you use the other host as a time source and the other host uses you as a time source also). So adjust the IP on the 1st line so that the configuration of each Primary NTP Server points to the other one as a peer. See [4] regarding my choice to use 4 servers.

2) The configuration for all other servers

2A) If you have two network interfaces

You better use the 2nd interface to create a local subnet (e.g. 10.11.12.0/24) and use that for NTP queries. In that case the restrict lines can be more tight. So again replace the server and restrict lines of your ntp[d].conf with the following and keep the rest to your distribution defaults[3]:

restrict -4 default ignore
restrict -6 default ignore
restrict 10.0.0.0 mask 255.0.0.0 kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1

# Only use our Primary NTP Servers
server 10.11.12.1 iburst
server 10.11.12.2 iburst
#      ^^^^^^^^^^
#      The IPs of your 2 Primary NTP Servers

2B) If you don't have two network interfaces

You should use the bellow restrict lines (and read the note about using your firewall to block access to your NTP servers above). So again replace the server and restrict lines of your ntp[d].conf with the following and keep the rest to your distribution defaults[3]:

restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1

# Only use our Primary NTP Servers
server 10.11.12.1 iburst
server 10.11.12.2 iburst
#      ^^^^^^^^^^
#      The IPs of your 2 Primary NTP Servers

Notes

[1] From 2006 to 2012 they constantly ask for more servers to join: the 2006 request, the 2009 one and the 2012 one. Check www.pool.ntp.org for updates on current status.

[2] Two Primary NTP Servers are only suggested as a simple way to have redundancy without complicated High Availability arrangements. You may opt for 3 or 4 for other reasons (again read the IETF best practices)

[3] In practice and no matter your distribution the only other thing you need to include in your ntpd configuration is a line defining a directory to put a drift file and a name for it -- e.g. driftfile /var/lib/ntp/ntp.drift. I've tested my solution in CentOS, Debian and Ubuntu. I guess it works in most other distros.

[4] I've configured 4 pool servers following best practices. Configuring more than 4 servers is technically accepted but you'll increase the load to the NTP pool for a questionable gain in availability so don't do it. In the best practices I see that "starting with ntp-4.2.6, the 'pool' directive will spin up "enough" associations to provide robust time service" so if you use .pool. addresses as I do here and ntp >=4.2.6 the exact number of server lines probably doesn't matter.

Rant Oh! I hate NTP (except that I like that it works). The official documentation is full of obsolete information and they have "how do I use it?" information mixed with scientific details about the internals. And I also hate how restrict 127.0.0.1 really means allow everything for 127.0.0.1


History of updates

I've removed the iburst option from the configuration of the Local NTP Servers because their friendliness to the pool is debatable. (see comments). Removing them only adds a couple of minutes of waiting time to the first synchronization.


Credits

Comments and answers from SF users Marki and Sven provided a good starting point for this answer. Thanks to both of them. Also thanks to SF user BACON a serious mistake was corrected after many years (ndemou's law: "given enough eyeballs and infinite time, all bugs are shallow")

Solution 2:

The usual approach for this is to use a tiered setup - you sync one or two servers in your network with the pool and then use those as your local time source. This levels are called strata in NTP lingo.

Also, think about it: If you do this like you desccribed, it won't be really noticeable, but if 1000 sites your size start this, you end up with 20k mostly unnecessary requests and at some point, it gets noticeable.

Read http://en.wikipedia.org/wiki/Network_Time_Protocol

Tags:

Ntp