S100 User Guide – Rev. D – June 2005
95
2
5
3
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 non-broadcast servers can
be used by the same client. NTP clients synchronize their time to match NTP servers, while
NTP servers never synchronize their time to match NTP clients. However, NTP clients can
also be NTP servers to clients of their own.
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 non-broadcast mode in order to maintain close synchronization.
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.
Summary of Contents for SyncServer S100
Page 2: ...2 S100 User Guide Rev D June 2005 1 ...
Page 20: ...12 S100 User Guide Rev D June 2005 1 SyncServer S100 ...
Page 60: ...52 S100 User Guide Rev D June 2005 SyncServer S100 ...
Page 94: ...86 S100 User Guide Rev D June 2005 SyncServer S100 ...
Page 108: ...100 S100 User Guide Rev D June 2005 SyncServer S100 Figure 5 43 Large Net NTP Configuration ...
Page 109: ...S100 User Guide Rev D June 2005 101 2 5 3 Figure 5 44 Large Net NTP Configuration 2 ...
Page 116: ...108 S100 User Guide Rev D June 2005 SyncServer S100 ...
Page 126: ...118 S100 User Guide Rev D June 2005 SyncServer S100 ...
Page 150: ...142 S100 User Guide Rev D June 2005 1 SyncServer S100 ...
Page 166: ...158 S100 User Guide Rev D June 2005 1 SyncServer S100 ...
