Other NTP Considerations
The following are information modules regarding NTP. They are used here as a FYI.
Clients
An NTP client can have a number of servers, and broadcast and
There are several points to consider for various client configurations. Normal NTP clients are set up with the server keyword, while broadcast and multicast clients are setup with the broadcastclient and multicastclient keywords. There is no client keyword.
Setting up a computer as an NTP client requires adding several lines to the ntp.conf file and restarting ntpd.
For example, configure the NTP client to synchronize with a couple of alternate NTP servers in the event the primary NTP server is unavailable. This is important since an failure of the primary NTP server is unlikely to be noticed promptly.
The client servers should be as independent as possible. The dependency chain of an NTP server can be determined by running the ntptrace command with each server. If possible, servers should not share common NTP parents. To identify a server as preferred, enter the keyword “prefer” to the right of the server name/IP address. A preferred server will be used as a synchronization source if it meets a minimum accuracy level, even if there are other more accurate servers. However, if a preferred server is far outside of the accuracy bounds determined by consulting other servers, it will be discarded. In general, a server will not fall outside these accuracy bounds unless it or the majority of other servers are misconfigured. Using preferred servers allows setting up clients to prefer a clock that is known to be very accurate. The time exchange between the client and server can also be protected with an authentication key.
Clients can also be configured to respond to broadcast or multicast packets sent by a broadcast or multicast NTP server.
Broadcast and multicast are generally used as the primary server on a LAN or subnet. Using broadcast or multicast allows synchronizing a large number of clients without creating large amounts of NTP traffic. In addition, servers can be changed easily, since clients do not listen for a specific server when they are in broadcast mode. Because the links are mostly local, this allows accurate synchronization for the clients. The important NTP servers within an enterprise (generally low stratum numbers) and any servers separated by large distances or low latency links should use
If the clients are not configured to synchronize with a specific group of servers, a rogue system can influence the synchronization process by broadcasting invalid time information. To defend against this threat, authentication and access control should be used to help limit potential synchronization sources.
S100 User Guide – Rev. D – June 2005 | 95 |
