Filter
Top Products
98 S100 User Guide – Rev. D – June 2005
SyncServer S100
• Use a server’s local clock as a reference clock (not a good idea)
Synchronizing the server to a public NTP server is the most common route for most small
installations. Use the ntptrace command to obtain a general idea of the server's quality. It is
important to find a server that is peered with several other servers to provide robustness. The
NTP protocol is designed as a hierarchy to prevent large numbers of clients from accessing
the same primary time sources. A large number of clients should not be configured to hit a
busy stratum 1 time server. Networks should be designed to minimize the number of servers
that interact with public NTP servers. In addition, because public stratum 1 servers are often
overloaded, stratum 2 servers should be used except for large (over 100 clients) NTP
configurations where highly accurate time is critical. A list of public NTP servers (along with a
list of things to consider when using them) is available at: . For additional information about
NTP, see
http://www.eecis.udel.edu/~mills/ntp/servers.html.
For secure environments where synchronized time is critical, it may not be appropriate to use
a public reference clock. However, it is still important to use an external time source;
otherwise, if the primary clock in the data center wanders, it causes all of the NTP clients
connected to it to wander with it. Another option is to place the main NTP sources for the
enterprise on secure management networks and have them receive time from external
servers. However, as with any externally provided service, it is also an entry point for
attackers. Therefore it is important to keep the servers independent and well secured. A
layered security approach should be used that encompasses isolated network segments and
systems, in addition to platform and NTP security measures. For example, NTP servers could
be deployed on independent platforms running only the NTP service. In addition, the servers
should use the access control and authentication facilities in NTP to further restrict access to
the service. If possible, only authenticated NTP packets should be accepted. The server
should also only accept packets from known, approved sources. For additional security, the
NTP packets could be tunneled between the NTP sources and their external servers over
encrypted connections.
As a rule, the preferred configuration is at least three coordinated time servers providing
service throughout the administrative domain including campus networks and subnetworks.
Each of these should obtain service from at least two different outside sources of
synchronization, preferably using a different gateways and access paths. These sources
should all operate at the same stratum level, which is one less than the stratum level to be
used by the local time servers themselves. In addition, each of these time servers should
peer with all of the other time servers in the local administrative domain at the stratum level
used by the local time servers, as well as at least one (different) outside source at this level.
This configuration results in the use of six outside sources at a lower stratum level (toward the
primary source of synchronization, usually a radio clock), plus three outside sources at the
same stratum level, for a total of nine outside sources of synchronization. The actual load on
network resources is minimal, since the interval between polling messages exchanged
between peers usually ratchets back to no more than one message every 17 minutes.
The stratum level to be used by the local time servers is an engineering choice. As a matter
of policy, and in order to reduce the load on the primary servers, it is desirable to use the
highest stratum consistent with reliable, accurate time synchronization throughout the
administrative domain. In the case of enterprise networks serving hundreds or thousands of
client file servers and workstations, conventional practice is to obtain service from stratum-1
primary servers. It is important to avoid loops and possible common points of failure when