1. Watch YouTube to learn more on ELPROMA concept of LCTS (Local Corporation Time Scale) - White Papers
2. Watch YouTube for new ELPROMA NTP driver development for 5071A caesium atomic clock
3 Introducing TFTS (Time Failed Tolerance Systems) - Part 1 (Watch YouTube to learn more on ELPROMA multi reference NTP Servers)
3 Introducing TFTS (Time Failed Tolerance Systems) - Part 2 (Watch YouTube to learn more how to improve redundancy)
3 Introducing TFTS (Time Failed Tolerance Systems) - Part 3 (Watch YouTube to learn on replacing GPS by LCTS)
3.4 Introducing TFTS (Time Failed Tolerance Systems) - Part 4 by Limiting SPOFs and Maximizing Independence on Stratum Hierarchy
Single points of failure can be reduced by assuring that client and servers are as independent as possible. Using a number of independent, dedicated NTP servers reduces the effectiveness of an incorrectly configured server spoofing the time, and thus increases security. Verifying NTP servers STRATUM 2-14 independence can be difficult if the server configuration is incoherent and servers are possibly not NTP dedicated. To effectively map the dependencies on an NTP subnet, each of the peers and servers must be mapped. This quickly becomes unwieldy in a large configuration. A more workable solution is to use ntptrace to determine the hierarchy of time sources used by a client. It can then be easily identified if two machines share common time servers. This is less ideal, because it only shows the currently used time source, as opposed to all configured peers. Regardless, a client should always receive time from at least 2-4 dedicated NTP servers. This will reduce the chances of it losing synchronization when a server fails. If fewer than four servers are used, the agreement algorithm cannot reliably detect a clique including a majority of trusted sources. An easy solution is to use three servers from a lower stratum number and one unrelated peer from the same stratum. 3.5 Introducing TFTS (Time Failed Tolerance Systems) - Part 5 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.
|