During this season of giving, you can show your support for the NTP Project by making a donation to Network Time Foundation.
AccessRestrictions needs a section dealing with adding restrict lines for time sources such as unicast, multicast and broadcast servers.

-- SteveKostecke - 10 May 2005

Problems with 'notrust' option on a LAN

Recently I've added an NTP server to my local network to maintain consistent time on each machine. Some problems arose as none of the systems on the local network were recieving replies from the local time server. By running all the servers in debug mode, it was apparent that requests were being sent out, and were also being received by the server, though no replies were being returned. This eventually led to frustration as any available discussions on similar topics that were found on Google seemed to suggest using the notrust configuration option, which ultimately was the cause of the problem in the first place. Here as an example of the working configuration file currently in use:

# Our time servers
server ntp1.example.invalid iburst
server ntp2.example.invalid iburst

# Ignore all NTP connections by default
restrict      default ignore

# Give full accessiblity to the local host

# Give full accessiblity to the two servers listed above.
# (use IP instead of domain name)
# NOTE: these IP address are *not* valid time servers

# Give accessiblity to the internal network, but don't let them change
# the settings of our NTP server.
restrict mask nomodify

# Set driftfile.
driftfile /etc/ntp/drift

Of particular interest here is the restrict line for the local network, This is where most discussions found with Google suggested using the notrust option. When this option was enabled in the current configuration, replies were no longer returned to any local client making a request, and instead requests were simply dropped by the server. It seems a minor configuration option, but if others are having the same issue I hope this will provide some insight.
Topic revision: r2 - 17 Jan 2007, SteveKostecke
Copyright © by the contributing authors.Use of this website indicates your agreement with, and acceptance of, the PrivacyPolicy, the WikiDisclaimer, and the PrivateWebPolicy.