/etc/ntp.conf

March 8th, 2007 | by jg3 |

I don’t exactly know why it was so hard to get right, but I’m glad it is finally done. For the last couple of days I’ve knocked against a frustrating problem getting my network time protocol (ntp) server and clients to work together. I had worked it all out once before and that config carried me for something like six years. Now that I’ve done it again I want to save these notes and hopefully save someone, maybe me, some time (no pun intended) in the future. What follows are my quick notes on what works and maybe a pointer or two and maybe a bit about what doesn’t work.

Here’s the server’s /etc/ntp.conf:

# Thanks to VT Blacksburg — Go Hokies
server 198.82.1.201
server 198.82.1.202
server 198.82.1.203 burst prefer
server 198.82.1.204

# Turn off all IPv6 services:
restrict -6 default ignore

# Turn on all access from localhost:
# (this permits ntpdc and ntpq, too)
restrict 127.0.0.1 mask 255.255.255.255
restrict -6 ::1

# restriction for the local networks
# nomodify prevents those hosts from reconfig’ing time service
restrict 32.64.128.192 mask 255.255.255.248 nomodify

# “default” entry for the internet at large
# noquery prevents remote ntpq and ntpdc monitoring, does not break time service
restrict default nomodify noquery notrap nopeer kod

Here’s the clients’ /etc/ntp.conf:

server ntp.example.net burst prefer
restrict default nomodify noquery

Here’s a more paranoid client /etc/ntp.conf:

server ntp.example.net burst prefer
restrict -4 127.0.0.1
restrict -6 ::1
restrict -4 default nomodify noquery notrap nopeer kod
restrict -6 default ignore

Points to note:

  • Using “burst” on a server makes the initial time synch much faster. This makes troubleshooting easier because it doesn’t take ten minutes each time you restart the daemon (more like thirty seconds). Be aware that this means you’re shooting a lot more traffic at the servers.
  • If you ignore all IPv6 you will break ntpq and ntpdc from localhost, so you must explicitly allow that traffic.
  • The client restrictions should probably be kept tight to prevent leaking information about the OS, etc. Don’t “restrict default ignore” (IPv4) unless you also add explicit restrict lines to permit communication with your servers..
  • Here’s a good site to help guide you in working out the restrict lines: http://ntp.isc.org/bin/view/Support/AccessRestrictions#Section_6.5.1.1.3.
  • Make liberal use of these commands: nptq -c associations and ntpdc -c peers
  • Immediately after restarting the ntpd process your ntpq -c associations output will show “reject” in the “condition” column. Wait a minute or so (if you used “burst prefer”) or ten minutes or so (if you didn’t) and once it gets synched it will say something like “sys.peer” or “candidat”. The number in the “poll” column of ntpdc -c peers needs to get up to 128 or so (I think) before “sys.peer” and “candidat” relationships are established.
Filed under: , ,

Related stuff

You must be logged in to post a comment.