Time Server NTP Division

Synchronizing the LAN to NTP server is the most common route for most small installations. The NTP protocol is designed as a hierarchy to prevent large numbers (more than 10,000) of clients from accessing the same primary time sources. This  hierarchy should be adhered to, and a large number of NTP clients should not be configured to hit a busy single NTP time server. Networks should be designed to minimize the number of computers that interact single busy NTP server. There are 2 different ways to set up an NTP server for a large number of clients:

1)  Set up a dedicated NTP time sever on a secured network

For secure environments where synchronized time is critical, it may not be appropriate to use a public NTP Server directly. Because of these restrictions, it may be difficult to have reference time available behind the firewall unless a site is willing to invest a great deal in infrastructure and design. An good option for obtaining secure externally synchronized time is using NTS-dialup functionality or a combination set of NTS-dialup + NTS-3000-4000-5000, to set a primary clock to a standard. For standard secured LAN, in most cases  GPS Network Time Servers like NTS-3000, NTS-4000. NTS-5000 are fine.

by Limiting SPOFs and Maximizing Independence

Building Time Fail Tolerance Networks

by Controlling Network Impact

It is important for NTP architects to understand how NTP and the network relate. The goals of an NTP architect are two-fold: to limit NTP’s network activity and increase the accuracy of the clocks. To achieve high clock accuracy, the network latency needs to be low. NTP can achieve a high level of accuracy and remain a good network citizen if local NTP servers are used and NTP servers use the appropriate modes. The easiest way to increase accuracy in an NTP configuration is to reduce the latency between the connections by putting NTP servers on the same LAN as their clients. If a LAN is very large, it is a good idea to have multiple servers in different geographic or network segments. Reducing the latency of a single NTP connection does not necessarily reduce the overall network latency. This is because the latency from the root time source could be increased by putting an additional server in the way, even though the latency to that server is reduced. However, if several independent servers are used, the NTP clock selection algorithms will probably help mitigate the effects of any increased latency. Another advantage to using local servers is that they tend to reduce the load on the WAN, though NTP is unlikely to be a big source of network load.

Another way of reducing NTP traffic, while keeping clock accuracy, is to use appropriate server modes. Central servers (generally stratum 1) should use non-broadcast server/client mode or peer mode, which allows more accurate time distribution. These servers are generally geographically distributed; therefore, the accuracy of the time distribution is critical. Broadcasting over high latency links can lead to very inaccurate time, both because of the latency and because it is likely the latency will be variable and unpredictable. Using broadcasting or multicasting over relatively local connections is acceptable. In fact, for a local server with a large number of clients and a fairly constant network latency broadcasting or multicasting is likely to be nearly as accurate as using a nonbroadcast server. Multicasting is preferable to broadcasting because it makes identifying NTP traffic easier and does not affect non-NTP clients on the network. Broadcasting or multicasting is a good fit in some environments, however, it is not appropriate for all environments. In particular, architectural or security concerns may preclude the use of broadcasting or multicasting.

Broadcasting and multicasting are less acceptable than non-broadcast NTP transactions in many organizations due to the impact of these choices on their security architecture. Many companies are not willing to permit broadcast traffic through their firewalls. The use of broadcast or multicast NTP transactions also opens the network to possible denial of service attacks. Architectural or managerial constraints could also prevent the use of broadcasting and multicasting.

Enabling Access Control

For security conscious environments, monitoring should be turned off because it could allow an attacker to obtain sensitive information about hosts or networks. In most other environments, disabling monitoring is an unnecessary restriction and only makes it more difficult to solve NTP problems. Requiring authorization keys for queries is another option. Limiting access to NTP queries prevents intruders from probing for information using the ntpq command. While the information obtained from ntpq may seem trivial, an intruder could discover sensitive information, including network delays (which could lead to determining network architecture), hostnames, IP addresses, and OS versions. In addition to authenticated transactions, NTP also provides the capability to restrict access to its services. This function is provided using the restrict keyword. This keyword is defined in the ntp.conf file.