MSK-IX NTP Server is a public time server supported by MSK-IX. The exact time server is designed to synchronize the internal clocks of computers and network equipment (servers, routers, smartphones, etc.) with the reference source using the NTP protocol.

MSK-IX NTP server belongs to the highest level of accuracy (Stratum One Time Servers) in the hierarchical system of time levels. The global signal is used as a reference time signal. satellite systems navigation GLONASS (priority) and GPS.

MSK-IX NTP Server is implemented as a grouping of servers located in Moscow, St. Petersburg, Yekaterinburg and Novosibirsk. The use of anycast network technology ensures high reliability and fast response of the system throughout the country.

MSK-IX servers are also included in the international pool of NTP servers POOL.NTP.ORG, widely used in operating system settings.

How to start using the NTP Server service?

Use the following parameters when configuring your hardware:

Server name	ntp.msk-ix.ru
IPv4 address	194.190.168.1
IPv6 address	2001:6d0:ffd4::1

How to establish peering with the MSK-IX NTP server network?

To shorten the network route to the MSK-IX NTP server, use the Route Server service or establish direct peering with the MSK-IX DNS Cloud network. Peer-to-peer interaction is established upon an additional application within the framework of the contract for connection to MSK-IX without additional payment.

NTP(Network Time Protocol) is a network protocol for synchronizing a computer's internal clock using networks with variable latency. The protocol was developed by David L. Mills, a professor at the University of Delaware, in 1985. The version for 2015 is NTPv4.

NTP, based on the Marzullo algorithm, uses the UDP protocol to operate and takes into account transmission time. The NTP system is extremely resistant to changes in transmission media latency. In version 4 it is capable of achieving an accuracy of 10 ms (1/100 s) when working over the Internet, and up to 0.2 ms (1/5000 s) and better within local networks.

The NTP protocol is most widely used for synchronizing time servers. To achieve maximum accuracy, continuous operation is preferred software NTP in system service mode. In the operating room family Microsoft systems Windows is the W32Time service, Linux is the Ntpd service.

A simpler implementation of this algorithm is known as SNTP - Simple Network Time Protocol. Used in embedded systems and devices that do not require high precision, as well as in custom time programs.

Package structure

The packet structure is described in RFC 5905. The packet consists of an integer number of 32-bit words.

The header information will differ for different operating modes. For example, a client in the fields hour layer, source id, start time And time of receipt must write zeros.

Heading

NTP header

Indentation	Octet	0								1								2								3
Octet	Bit	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	IR		Version			Mode			Hour layer								Polling interval								Accuracy
4	32	Delay
8	64	Dispersion
12	96	Source ID
16	128	Update time
20	160
24	192	Start time
28	224
32	256	Time of receipt
36	288
40	320	Dispatch time
44	352

Correction indicator

Example of time synchronization using NTP

Length - 2 bits, from Leap Indicator. An integer indicating the leap second warning.

Version number

Length - 3 bits, from Version Number. An integer representing the protocol version.

Mode

Length - 3 bits, from Mode. An integer representing the mode. The values ​​are presented in the table below.

Hour layer

Length - 8 bits, from Stratum. An integer representing the hour layer.

Polling interval

Length - 8 bits, from Poll. A signed integer representing the maximum interval between consecutive messages. The value is equal to the binary logarithm of seconds. The default suggested limits for minimum and maximum surveys are 6 and 10, respectively.

Accuracy

Length - 8 bits, from Precision. A signed integer that represents the accuracy of the system clock. The value is equal to the binary logarithm of seconds. For example, a value of -18 will correspond to an accuracy of about 1 µs.

Delay

Length - 32 bits, from Root Delay. The total time of signal propagation in both directions in short NTP format.

Dispersion

Length - 32 bits, from Root Dispersion. Total variance for a time source in short NTP format.

Source ID

Length - 32 bits, from Reference ID. Synchronization source code. Depends on the value in the Hour layer field. For layer 0- These four ASCII characters, called "kiss code", are used for debugging and monitoring. See below for layer 1 is four octets of ASCII characters, padded on the left with zeros, assigned to the time reference. The table below shows the list maintained by IANA.

ID	Source
GOES	Geostationary satellite for environmental monitoring and surveillance system
GPS	Global Positioning System
GAL	Galileo positioning system
P.P.S.	General radio signal with a pulse duration of 1 second
IRIG	Telemetry Standardization Group, USA
WWVB	Low Frequency Radio Transmitter, 60 kHz, Fort Collins, Colorado, USA
DCF	Low frequency radio transmitter, 77.5 kHz, DCF77, Mainflingen, Germany
HBG	Low frequency radio transmitter, 75 kHz, Prangins, Switzerland
MSF	Low frequency radio transmitter, 60 kHz, Anthorn, UK
JJY	Low frequency radio transmitter, 40 kHz, Fukushima, 60 kHz, Saga, Japan
LORC	Mid-frequency radio transmitter, 100 kHz, radio navigation, LORAN-C
TDF	Medium frequency radio transmitter, 162 kHz, Allouis, France
CHU	High Frequency Radio Transmitter, Ottawa, Ontario, Canada
WWV	High Frequency Radio Transmitter, Fort Collins, Colorado, USA
WWVH	High frequency radio transmitter, Kauai, Hawaii, USA
NIST
ACTS	NIST telephone modem
USNO	US National Observatory telephone modem
PTB	Telephone modem of the National Metrological Institute of Germany

For layers 2 and above is the server identifier and can be used to capture time loops. If IPv4 is used, the identifier is four octets of the IP address. If IPv6 is used, then these are the first four octets of the MD5 hash of the address. It is worth noting that when using IPv6 addresses for a server with NTPv4 and a client with NTPv3, the identifier may take a random value, which is why time loops may not be recorded.

Update time

Length - 64 bits, from Reference Timestamp. The time when the system last set or adjusted the time. NTP format.

Start time

Length - 64 bits, from Origin Timestamp. The client time when the request is sent to the server. NTP format.

Time of receipt

Length - 64 bits, from Receive Timestamp. Server time when the request comes from the client. NTP format.

Dispatch time

Length - 64 bits, from Transmit Timestamp. The server time when the request is sent to the client. NTP format.

NTP message "Kiss-o"-Death"

For layer 0, which is considered undefined or invalid, field Source ID can be used to deliver messages that serve as system state information and access control. Such messages are called "Kiss-o"-Death" (KoD), and the ASCII data they deliver are called "kiss codes". A list of currently accepted "help" codes is presented in the table below.

Recipients of KoD messages are required to check them and perform the following actions:

• When receiving code combinations DENY And RSTR the client is obliged to break virtual connections with this time server and stop sending messages to this server.
• Upon receiving the code combination RATE the client must immediately reduce its polling interval for this server and continue to reduce it each time it receives this code combination.
• When receiving a code combination starting with an ASCII character X, intended for experimental research and subsequent improvements, it should be ignored if it is not recognized.
• All other code combinations and KoD messages not defined by this protocol are destroyed after verification.

Help codes

Code	Description
ACST	Virtual connection established by unicast server
AUTH	Server authentication failed
AUTO	Autokey sequence is incorrect
BCST	Virtual connection established by broadcast server
CRYP	Cryptographic authentication or identification failed
DENY	The remote server denied access
DROP	Loss of a remote time server in symmetric mode
RSTR	Access denied due to local security policy
INIT	The virtual connection was not established the first time
MCST	Virtual synchronization connection established by dynamically discovered server
NKEY	The key was not found (either it has never been loaded before, or it is unreliable)
RATE	The speed is exceeded. The server has temporarily denied access because the client has exceeded the speed threshold
RMOT	Changing the virtual connection from a remote IP host using the NTP protocol directly
STEP	An iteration has occurred to change the system time, the virtual synchronization connection is not established

Hour layers

Yellow arrows indicate hardware connection; red arrows indicate network connection.

NTP uses a hierarchical network where each level has its own number, called a layer. Layer 1- primary servers that directly synchronize with national time services via satellite, radio or telephone modem. Layer 2- secondary servers, synchronized with primary servers, etc. Typically, NTP clients and servers with a relatively small number of clients are not synchronized with the primary servers. There are several hundred public secondary servers running on higher layers. They are the preferred choice.

Time format

Time is represented in the NTP system as a 64-bit number (8 bytes), consisting of a 32-bit second counter and a 32-bit fractional second counter, allowing time to be transmitted in the range of 2-32 seconds, with a theoretical accuracy of 2-32 seconds. Since the time scale in NTP repeats every 2 32 seconds (136 years), the recipient must at least approximately know the current time (with an accuracy of 68 years). Also note that time is measured from midnight on January 1, 1900, not 1970, so almost 70 years (including leap years) must be subtracted from NTP time to correctly match the time with Windows or Unix systems.

Regular time format

Bit	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	Seconds
4	Fractional seconds

Date format

Bit	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	Era number
4	Era indentation
8	Shares
16

For some time now, the task of finding out the exact time has not only been faced by humans. For many systems created by him, in order to function correctly, it is necessary to constantly have at his disposal very accurate clocks, and their accuracy must be significantly higher than the clocks used by people in everyday life. In addition to the actual accuracy of the clock, no less important is its synchronization with the universal time scale. After all, even on a scale UTC(Coordinated Universal Time is the basis of civil time) changes are periodically made in the form of an additional second due to discrepancies with atomic time (for example, at the time when our planet was inhabited by the first dinosaurs, the length of the day was about 22 hours).

As striking examples of systems that use very accurate and reliable methods for calculating the current time, it is not at all necessary to imagine complexes that control the movement of spacecraft or air traffic control services - although, of course, the requirements for the accuracy of the clocks of all elements of such systems are at the highest level. Stable clocks synchronized with universal time are also needed in systems that perform simpler tasks. These include, for example, scientific and industrial complexes that process data in real time various devices. Add everything related to finance - banking transactions, operator billing systems cellular communication and Internet providers who charge the traffic they serve. All of these are examples of systems whose implementation is impossible without the use of clocks synchronized and consistent with universal time. In computer networks, the client authentication protocol also uses a comparison of the server's time with the clients' clock.

The development of communications in our time has greatly simplified the task of obtaining the exact time. Now we have several dozen global positioning system satellites “over our heads” (more precisely, in orbit around the Earth), the on-board clocks of which are practically time standards. The signals they send can be used to synchronize clocks very precisely. In computer networks, synchronization is usually performed with exact time servers using the protocol NTP(Network Time Protocol) or its “light” version - SNTP(Simple Network Time Protocol) in cases where the maximum functionality of using full NTP is not necessary.

The NTP protocol uses a hierarchical system of levels, or stratums. The NTP server has the highest level ( stratum 1) if it receives data directly from a time source. Servers that synchronize their clocks with the server of the 1st stratum are located at a lower level in this model (stratum 2), etc. The NTP protocol, unlike SNTP, provides higher synchronization accuracy using complex algorithms for calculating the time of packet transmission on the network, and can perform error control and filter UDP packets.

In general terms, the SNTP protocol works quite simply and usually occurs in three stages:

• A client that needs to get the time sends a UDP packet containing an SNTP request to the generally accepted port 123 of the NTP server and goes into mode to wait for a response. In this request, it timestamps its own clock.
• When a request is received, the server responds with a UDP packet containing an SNTP message, sending it to the client from port 123. The packet records the received timestamp of the client and the timestamp of the server itself.
• When a client receives a response, it can use a timestamp it created when it sent the request to confirm the correctness of the response, trying to ensure that it was sent specifically to that client's request (if the packet was sent to a request from another source, it is likely that it contains the same creation timestamp is extremely low). It then extracts the transmission timestamp value, converting it according to the estimated latency caused by the packet traveling through the network, and uses the result to set the time of its system clock.

The packet formats for both protocols are the same, which allows the NTP server to work with both NTP and SNTP clients.

NTP Frame Structure

NTP servers, as a rule, have only one port open to the outside - UDP 123. In this configuration, the administrator does not have to worry much about the security of the server, since it is practically invulnerable to attacks from malicious programs. Nevertheless, it is very important to ensure the availability of the 1st Stratum server for clients, because otherwise the very meaning of its operation is lost. The main problem is the number of requests that the NTP server is able to serve. However, the requests themselves can be generated for very interesting reasons.

The most famous cases of NTP vandalism

In mid-May 2003, University of Madison employees discovered a rapidly increasing Internet traffic that was directed to the university's public NTP servers. The traffic consisted of NTP protocol requests, consisting of 76-byte packets transmitted to UDP port 123. However, these packets had an unusual property: despite the fact that they came from different sources, they were all sent from port number 23457.

To protect the servers, the configuration of the routers was changed, blocking only this part of incoming requests to NTP servers; regular requests continued to be serviced normally. Only all UDP traffic containing requests to the NTP server sent from port 23457 to port 123 was blocked. At that moment, the staff simply thought that they were faced with a distributed denial of service attack ( DDoS attack, from English Distributed Denial of Service, denial of service), organized from many random addresses, and stopped there, assuming that the flood would subside within a few hours, as is usually the case with attacks of a low professional level.

A month later, it turned out that the flow of incoming NTP traffic had increased significantly, reaching enormous values ​​- 250 thousand packets per second, with a volume of over 150 Mbit/s. Carefully unblocking access for some interfaces, the staff began to examine UDP packets, including their contents. They appeared to be valid SNTP version 1 requests, although their high intensity from each host was unclear. For example, during one tracking period, many clients made approximately one request per second. This would be extremely strange for a normally functioning SNTP client. Applications that use SNTP simply set their own system clock to the required precision so that the host has some reasonable idea of ​​the current time.

Querying the time every second is simply ridiculous, and quite far from normal NTP client behavior. If a random passerby asks you the time on the street, that’s normal. But what if he starts asking about the time every time immediately after you answer, and some more people join him? What if this goes on for weeks? It became clear that it was necessary to understand the reasons for what was happening.

None of the request sources were in local network complex of university buildings. This meant that the help of remote server administrators would be required to investigate the causes of the incident. From the most active IP addresses, two clients located on the networks of other universities were selected. A letter was sent to network administrators describing the problem and asking them to find out what OS and SNTP clients might be running on these hosts, and what services might be sending requests from them using UDP port 23457.

The responses received contained information that the source of traffic was production routers Netgear(One in particular has been identified as model MR814). Now events began to make some sense. The large number of hosts using the same port could be explained by the built-in SNTP client with a programmed port number. University of Madison employees began collecting information about Netgear products that claimed to support NTP. After examining the code, it turned out that the manufacturer simply programmed information about NTP servers into some of them. In addition to IP addresses from ranges reserved for local networks, they contained global routing IP addresses, including the public NTP server of the University of Madison. The problem was aggravated by the fact that of the global IP addresses specified in the code, only the university one turned out to be a real NTP server, and the built-in client of the router, having not received a response to the SNTP request, began to generate new requests every second.

Having finally identified the causes of the NTP flood, university staff turned to the router manufacturer. Netgear had to admit its mistake. It turned out that by that time over seven hundred thousand such devices had already been sold. Some simple calculations show that they were potentially capable of generating 426Mbps of traffic (700,000 UDP packets per second, each 76 bytes long) directed to the same NTP server.

To solve the problem, a group was created with the participation of representatives of the university, the manufacturer and independent experts. Corrected versions of the software were quickly released for devices containing errors in the code. Of course, this did not solve all the problems - after all, the release of a new firmware version by the manufacturer does not mean its replacement by all users, most of whom were not aware of such problems. However, the university has decided to continue servicing the defective Netgear devices by providing them with the ability to synchronize system clocks (is this decision related to the $375,000 Netgear paid to the University of Madison, said to be “to improve security?” wireless network and the development of the network of the university building complex,” is not known to the author for certain).

The same year, a similar incident occurred in Australia. This time its participants were the National Measurements Laboratory of the Commonwealth Scientific and Research Organization of Australia. CSIRO) and California-based network equipment manufacturer SMC Networks. Maximum load of CSIRO NTP servers (1st stratum, source - cesium clocks, otherwise called " atomic") was estimated at 200 kBit/s. Blocking traffic, the bulk of which came from overseas, led to the fact that SMC devices, in the absence of a response from the NTP server, began sending requests twice a minute. In the end, CSIRO decided to change the addresses of its time servers (after notifying its partners about this), and providers simply began to block requests from sources located outside Australia.

The last most famous problem of this kind occurred in 2005 and was first called “ NTP vandalism", which later became established as general term to indicate cases of abuse of NTP servers. Then the “black mark” went to the Danish server of the 1st Stratum, connected to the national network Danish Internet Exchange (DIX). The server belonged to one of the FreeBSD developers - Half-Hoening Kamp(Poul-Henning Kamp), and although it was not owned by government or scientific institutions, it existed on a non-profit basis. The rules of use directly stated that only NTP servers of the second stratum located in Denmark and applications whose operation requires extremely accurate time can use it for time synchronization.

The concern acted as a vandal D-Link. The owner of the NTP server estimated that between 75% and 90% of requests were generated by routers manufactured by D-Link. When the number of such packages exceeded three million per day, the provider demanded that Kampa pay the costs caused by the significant increase in traffic in the amount of DKK 54,000 (approximately $8,800 USD) per year.

Just as in the case of the University of Madison, Kamp contacted D-Link, hoping to solve the problem and recover the financial costs caused by it. Unlike Netgear, D-Link began to deny the existence of a problem at all, in response accusing Kamp of extortion. The confrontation lasted almost six months until Kamp made all the details of the incident widely public. Finally, in April 2006, the parties reached a peace agreement. It was stated that existing D-Link products would receive authorized access to the Kampa NTP server, and subsequent ones would stop using it (the financial side of the agreement is unknown, but according to some estimates, maintaining their own time servers capable of servicing such traffic would cost D-Link Link costs about $1000 per month).

Technical solutions

All these cases have forced network protocol developers to think about ways, other than applying different access policies, to avoid similar problems in the future. One of the solutions was the changes made to the fourth version of the NTP protocol, which appeared in early 2006 and described in RFC 4330. They include expanding the semantics of the NTP packet fields to allow the server to send a special control packet with the romantic name “ the kiss of death"(Kiss-o"-Death, KoD). In such a packet, the headers are filled in a special way - the leap second field contains the value 3, the field indicating the server stratum is set to 0, and the link identifier contains a 4-byte code indicating the reason for it parcels (in practice, so far only the RATE code is used - exceeding the frequency of requests).

Sending such a packet to a client means that the server has detected that the client has violated the rules for accessing it, and service to the client will be terminated. The client, upon receiving it, should stop sending requests and try, if necessary, to find another NTP server. If the client is unable to discover another available NTP server, it must reduce the rate of requests to the previous server according to the exponential decay algorithm.

The document also presents recommended principles, according to which the “correct” NTP client should form time intervals that determine the frequency of requests to the server, and use elements of the network infrastructure (including DNS and DHCP). If you plan to specify direct addresses of NTP servers in the device’s built-in code, urgently It is recommended to do this only after agreement with their owners.

In principle, such innovations are quite reasonable, but any tangible benefit from them will be possible only when overwhelming the number of NTP servers and clients in the global network will fully comply with the requirements of the fourth version of the NTP protocol. Alas, there is no hope for events to develop in this way in the near future (by the way, one of the “traces” thanks to which Kamp came to the conclusion that the source of the attacks were routers manufactured by D-Link was the use of the SNTP protocol version 1 by all of them).

As a technical solution that can significantly reduce the peak load on time servers, we can note the project pool.ntp.org. It is a large virtual cluster of geographically distributed NTP servers (at the time of writing, it includes 1742 servers from all continents). The project itself was launched in 2003, the fruit of a discussion about the significant costs required to maintain and operate reliable time servers capable of constantly serving a significant number of requests. The idea underlying it is very similar to the recursive mechanism of operation DNS servers. If a server like 0.pool.ntp.org is simply specified as the server providing the exact time, then the real server with which time synchronization will be carried out will be selected randomly with each client request from the list of servers included in the pool. However, pool users can independently select regional exact time servers, specifying the continental zone, or even the zone of a specific country (as a rule, the closer the server, the more accurate the synchronization is), for example - 0.ru.pool.ntp.org for Russia. It must be remembered that some countries are not represented in the pool, and some are represented by one or two servers (for example, Malaysia). Use of the pool is free of charge, except for servicing companies producing equipment and software products, whose NTP requests are planned to be served using pool.ntp.org resources.

The very idea of ​​launching a public synchronization service with an accurate clock without ensuring its stability and reliability under extreme load conditions hardly makes any sense. History knows many examples of defunct NTP servers with the declared 1st stratum, “reporting” a time that differed from the real one by tens (!) of seconds, or simply becoming unavailable for requests. A service that allows you to synchronize your watch with an accurate time source is exactly the case when the concept of reliability is as important as the accuracy of the data provided. Here is an illustration real work Mobatime Systems NTP servers:

Mobatime Systems NTP server request statistics

This is a fairly striking example of NTP vandalism - on April 1, 2009, 75 hosts were blocked that sent more than 12 million requests per day. A similar attack intensity lasted for 3 days, and its nature can hardly be explained by simple errors in the device code, or their incorrect configuration. To protect against such attacks, the Mobatime NTP server uses incoming traffic filtering algorithms. This protection mechanism makes it possible to cut off an avalanche-like flow of “garbage” that can lead the system to complete failure in a short time.

However, such protection will become practically useless if the volume of data in the transmission channel approaches its throughput. With such a load, sending data to legitimate, unblocked clients will simply become impossible due to the exhaustion of communication channel resources. The only way out of the situation, guaranteeing an almost complete elimination of cases of NTP vandalism, is perhaps the creation of a non-public exact time server with access restrictions. Having at its disposal a reliable time source (for example, a receiver of data transmitted by the GPS system), such an NTP server will be a stable provider of accurate time service.

List of materials used in preparing the publication (in English):

• RFC 4330, SNTP v4 Protocol Description
• Flawed Routers Flood University of Wisconsin Internet Time Server - a report on the incident at the University of Madison, published by its employee Dave Plonka.
• Network Devices Almost Take Down Atomic Clock - article about the incident in CSIRO
• When firmware attacks! (DDoS by D-Link) - article by Richard Clayton, who took part in clarifying the circumstances of the attack on the NTP server of Paul-Heuning Kamp
• Materials from the organization's website pool.ntp.org
• Help save the endangered time servers - Andy Lester's article on pool.ntp.org

I don't know! I just want my time to stay on track! Please tell me what to do?

Maybe it would be better to set the time zone correctly and receive updates on time (including those related to time)? Well, change the battery on mom, if it’s old... just in case...
learn to ask questions.
It never came to the question :D

Why do you need exact time?

Who needs this exact time anyway? Of course, we, the users, need it so that we are less late. Let's imagine a modern airport - for its operation, hundreds of pilots and dispatchers must use an unerringly running clock. The system for registering goods in warehouses, hospitals, railway ticket offices and many other institutions require that the time at all objects of the system be the same to one degree or another. Especially computers. They run a lot of services and programs for normal operation which require exact time, and, as a rule, more accurate than what we humans usually need. System services, security system components, and just application programs can be very critical of the watch's accuracy. The most prominent example of such services is the Kerberos authentication protocol. So, for it to work, it is necessary that on computers accessed using this protocol, the system time differs by no more than 5 minutes. In addition, accurate time on all computers greatly facilitates the analysis of security logs when investigating incidents on the local network.

NTP protocol

NTP (Network Time Protocol) is a protocol designed to synchronize time on a network. It is a set of fairly complex algorithms designed to ensure high accuracy (up to several microseconds) and fault tolerance of the time synchronization system. Thus, the protocol involves simultaneous synchronization with several servers.

There are several versions of this protocol, with some differences. The third version of this protocol was standardized as RFC 1305 in 1992. The fourth (last on this moment) version brings some improvements (automatic configuration and authentication, improved synchronization algorithms) compared to the third, but it is not yet standardized in the RFC.

In addition, in addition to the NTP protocol, there is the SNTP (Simple Network Time Protocol). At the packet level, the two protocols are fully compatible. The main difference between them is that SNTP does not have the complex filtering systems and multi-stage error correction found in NTP. Thus, SNTP is a simplified and easier to implement version of NTP. It is intended for use in networks where very high time accuracy is not required, and in Microsoft's implementation it provides accuracy within 20 seconds within an enterprise and no more than 2 seconds within a single site. The SNTP protocol is standardized as RFC 1769 (version 3) and RFC 2030 (version 4).

The NTP synchronization model assumes a hierarchical structure. At the first level of the hierarchy there are so-called “primary” time servers (First stratum). They are located in different places around the world and have the most accurate time. There are relatively few such servers, since the exact time on them is maintained using expensive specialized equipment (radio channel, satellite channel). Second-level servers (Second stratum) are synchronized with first-level servers using the NTP protocol. There are already significantly more of them, but they are already somewhat out of sync (from 1 to 20 milliseconds) relative to the “primary” servers. Next can be servers of the third, fourth and subsequent levels:

With the transition to each level, the error relative to the primary server increases slightly, but the total number of servers increases and, consequently, their load decreases. Therefore, as an external source of synchronization, instead of using primary servers that have the most accurate time, it is recommended to use secondary servers as they are less loaded.

To synchronize time in Windows 2000/XP/2003, the SNTP protocol is used. Support for this protocol is implemented as a system Windows services Time, which is part of the MS Windows 2000/XP/2003 operating system. A distinctive feature of this implementation is that the Windows Time service supports domain authentication when accessing the reference time server, which is important from a security point of view.

There are several options for operating the SNTP service included in Windows:

• Hierarchical (NT5DS). Used by default for all computers joined to a domain. Time synchronization on workstations and domain servers is carried out in a hierarchy. Thus, workstations and member servers are synchronized with the domain controller that authenticated the login, domain controllers are synchronized with the master of the “PDC emulator” operation, which in turn is synchronized with the domain controller located at a higher level of the hierarchy. It should be noted that this synchronization order is used “by default” and can be overridden manually or using group policies. How to do this will be discussed below.
• Force synchronization with the selected NTP server (NTP). IN in this case The reference time source for the Windows Time service is set either manually or using group policies.
• Disable synchronization (NoSync). This mode is required for a mixed time management scheme, in which a third-party product is used to synchronize with an external source, and Windows Time is used to maintain time within the domain.

Thus, in case working group Time synchronization will still have to be configured manually. For example, one of the computers can be configured to synchronize with an external server using the SNTP protocol, and the rest can be configured to synchronize with it. The steps required for this will be described below.

For a domain, it is recommended to use hierarchical synchronization using the SNTP protocol. In most cases, it provides acceptable system time accuracy within the domain's forest. In addition, it automatically ensures the security of time updates by supporting authentication with Active Directory. To maintain the “correct” time in the domain, it is necessary to synchronize the top-level domain controller, which owns the “PDC emulator” role, with an external NTP server. In our example, the role of such a server will be a Linux machine with the ntpd daemon running.

Setting up SNTP on Windows

To configure the Windows Time service, two utilities are used:

• Net time
• W32tm

Net time is used primarily for configuring the time service, and w32tm is used for monitoring and diagnosing operation. However, in Windows XP/2003, the w32tm utility has undergone significant changes and can be used to configure the time service. NTP configuration will be further carried out using Windows XP/2003 as an example.

So, in order to “manually” specify the synchronization source using net time, just write on the command line:

et time /setsntp:list_of_time_servers_separated by_space

To obtain information about the current time server:

net time /querysntp

You can find out the time on a domain controller like this:

net time /domain:domain_name

And synchronize time with a domain controller like this:

Net time /domain:domain_name /set

The w32tm system utility can do all the same and even more:

• w32tm /resync - Using this command, you can force a local or remote computer to synchronize its system clock with the time server it uses.
• w32tm /config – This command is used to configure the Windows Time service. With its help, you can specify the list of time servers used and the type of synchronization (hierarchical or selected by servers).

For example, to override the default values ​​and set up time synchronization with an external source, you can use the command:

w32tm /config /syncfromflags:manual /manualpeerlist:PeerList

And in order for Windows Time to apply the new settings, instead of restarting the service, you can use the command:

w32tm /config /update

In addition, w32tm provides the following options related to time monitoring on computers:

• w32tm /monitor – using this option you can find out how the system time of this computer differs from the time on the domain controller or other computers.
• w32tm /stripchart – graphically shows the time difference between the current and remote computer.
• w32tm /register – Registers the Windows Time service as a service on this computer. This option can be useful on computers that are not part of a domain, since by default the time service is stopped on them.

More detailed information about the parameters of the net time and w32tm utilities can be obtained using the /? key. or by opening the appropriate section of the Help and Support Center MS Windows XP/2003 help system.

It's easy to guess that the Windows Time service settings are stored in Windows registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\.

In the root of the section, the operating parameters of the service itself are defined, in the Config subkey – settings related to the operation of the SNTP protocol itself, the synchronization mode is defined in the Parameters subkey. The SNTP client and server settings are located in the TimeProviders\NtpClient and TimeProviders\NtpServer connections, respectively. Let's look at the main values ​​that determine the NTP client and server settings:

• Type – determines the operating mode of the NTP client (NTDS5 – hierarchical, NTP – “manual”, NoSync – do not synchronize, AllSync – all types of synchronization are available);
• Enabled – determines whether this component (client or server) is enabled;
• CrossSiteSyncFlags – determines whether it is possible to synchronize time with a source located outside the domain if hierarchical synchronization is used (0 – not possible, 1 – only with the PDC emulator, 2 – with all);
• EventLogFlags - determines whether messages from Windows Time will be logged or not (very useful feature when debugging work).

Another option for configuring the Windows Time service is to use Group Policies. Settings are defined in the object group policy at the following address: “Computer Configuration –> Administrative Templates –> System –> Windows Time Service”.

If you have Windows 2000 Server installed and you haven’t found such a setting, don’t despair, you just need to update the “Administrative Templates”. To do this, copy from the system folder system32\GroupPolicy\Adm of any machine with installed Windows XP all .adm files to the server, which is a domain controller. Next, while defining the GPO, right-click on “Administrative templates” and select “Add/Remove templates...” Remove the templates listed there and add the copied ones. After clicking the "OK" button, the templates will be updated and you can configure the time service using group policies:

It is easy to see that this mainly lists all the settings that can be changed in the registry. There is nothing surprising in this, because this is exactly how most group policies work.

In Windows XP, another way to set a time server has appeared, which can be very convenient for setting up synchronization on a home computer or a computer that is part of a workgroup:

NTP server for Linux - external synchronization for Windows domain

As mentioned above, the NTP protocol is more error-resistant, so it is better to use an NTP server as a source of reference time for external synchronization. In addition, the top-level domain controller does not always have access to the Internet via UDP port 123, which is used for NTP operation. Access may well be denied for security reasons, which is common practice for large organizations. In such cases, to solve this problem, you can install your own time server in the DMZ, configured to synchronize with an external source, and use it as a reference time source for synchronizing the top-level domain controller. Any computer, not necessarily a modern one, with a *nix-like OS, for example, Linux, installed in a minimal configuration, without an X server and other potentially vulnerable things, is quite suitable as such a computer.

There are a lot of time synchronization programs for Linux OS. The most famous are Xntpd (NTP version 3), ntpd (NTP version 4), Crony and ClockSpeed. In our example, we will use the ntpd ntp server included in Redhat 9, supplied in the ntp-4.1.2-0.rc1.2.i386.rpm package.

The package includes several programs designed to work with NTP.

Here are the main ones:

• Ntpd – ntp daemon that maintains accurate time in the background;
• Ntpq is a utility designed to poll NTP servers that support the standard polling protocol NTP mode 6. With its help, you can find out and change the current state of the server, if its settings allow it;
• Ntptdc – a utility with which you can interrogate the ntpd daemon and obtain statistics on its operation;
• Ntpdate is a program for setting the current system time using the NTP protocol.

A standard feature of the NTP protocol is the ability to perform authentication. In this case, both symmetric algorithms (DES), which appeared in the second version of the protocol, and asymmetric algorithms with a public key, which are an innovation in the fourth version, can be used.

In the case of using a symmetric authentication scheme, the client and server select an arbitrary identifier and one of 65534 keys defined by the standard. When using asymmetric algorithms, the so-called Autokey scheme is used, distinctive feature which is the absence of the need to pre-distribute public keys of servers.

To configure authentication in ntpd, there are utilities ntp-genkeys, ntpq and ntpdc.

All NTP functionality related to accurate time support is implemented in the ntpd daemon. Its configuration is done in the usual UNIX way - by editing configuration file ntp.conf, located in the /etc folder.

Let's set the following options for the NTP server.

First, let's indicate the servers with which time synchronization will be performed:

server ntp.nasa.gov # A stratum 1 server at nasa.org
server ntp1.demos.net # A stratum 2 server at demos.net

restrict ntp.research.gov mask 255.255.255.255 nomodify notrap noquery

Here the mask 255.255.255.255 is used to restrict access to our server from the ntp.nasa.gov server. Now let's define a list of hosts on our local network that we want to allow access to our NTP server to get the time:

restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap

We also require that the Linux machine has full access to its server resources:

restrict 127.0.0.1

And now the most important thing: we need to make sure that the default deny, which has a higher priority, is commented out:

#restrict default ignore

After saving the ntp.conf file, the configuration can be considered complete, but it may happen that after starting the daemon, the time will still not be synchronized. The fact is that the NTP protocol was originally developed as a protocol for maintaining time, not setting it. Therefore, if the difference between the clock readings is large enough (more than a few minutes), then synchronization will not occur. In this case, it makes sense to initially set the time manually using the ntpdate command (you can also add the ntpdate command to the machine’s startup scripts):

# ntpdate clock.vsu.ru
17 Feb 23:44:54 ntpdate: step time server 198.123.30.132 offset 25.307598 sec

17 Feb 23:45:05 ntpdate: adjust time server 198.123.30.132 offset 0.002181 sec
# ntpdate clock.vsu.ru

The ntp daemon is launched through initialization scripts. If the program was installed from an rpm package, then most likely all issues related to its automatic launch have already been resolved. To verify this, you can use the command:

# chkconfig -list ntpd
ntpd 0:on 1:off 2:off 3:on 4:off 5:on 6:off

If you don't see this line, it means automatic start ntpd is not configured. To fix this, type:

# chkconfig –level 035 ntpd on

To manage NTP (start, launch, restart, status), a standard initialization script is used:

# /etc/init.d/ntpd start

To view server synchronization statistics, you can use the following command:

# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*tick.usnogps.na .USNO. 1 u 38 64 377 220.00 0.149 7.08
-navobs1.wustl.e.PSC. 1 u 55 64 377 193.47 6.857 4.81
-ntp-nasa.arc.na .GPS. 1 u 43 64 377 254.88 7.471 9.58
-ntp0.NL.net.GPS. 1 u 144 512 377 122.54 12.515 13.75
-ntp2.ien.it .IEN. 1 u 558 1024 377 133.94 14.594 41.99
+timekeeper.isi. .GPS. 1 u 13 64 377 245.30 3.454 15.08
+news-zero.demos ntp0.usno.navy. 2 u 16 64 377 37.51 -3.239 11.14
LOCAL(0) LOCAL(0) 10 l - 64 377 0.00 0.000 10.01

NTP server/client operating modes

Client/server

This mode is by far the most commonly used on the Internet. The work scheme is classic. The client sends a request, to which the server sends a response within some time. The client is configured using the server directive in the configuration file, where the DNS name of the time server is specified.

Symmetrical active/passive mode

This mode is used if time synchronization is performed between big amount equal machines. In addition to the fact that each machine synchronizes with an external source, it also synchronizes with its neighbors (peers), acting as a client and time server for them. Therefore, even if the car “loses” external source, she will still be able to get the exact time from her neighbors. Neighbors can work in two modes – active and passive. Working in active mode, the machine itself transmits its time to all neighboring machines listed in the peers section of the ntp.conf configuration file. If neighbors are not indicated in this section, then the machine is considered to be operating in passive mode. To prevent an attacker from compromising other machines by posing as an active source, authentication must be used.

Broadcast Mode

This mode is recommended to be used in cases where a small number of servers are serving a large number of clients. When operating in this mode, the server periodically sends packets using the subnet's broadcast address. A client configured to synchronize in this manner receives the server's broadcast packet and synchronizes with the server. A feature of this mode is that time is delivered within one subnet (limiting broadcast packets). In addition, authentication must be used to protect against attackers.

Multicast mode

This mode is in many ways similar to broadcast. The difference is that multicast addresses of class D networks of the IP address space are used to deliver packets. For clients and servers, the address of the multicast group is specified, which they use for time synchronization. This makes it possible to synchronize groups of machines located on different subnets, provided that the routers connecting them support the IGMP protocol and are configured to transmit multicast traffic.

Manycast mode

This mode is an innovation in the fourth version of the NTP protocol. It involves the client searching for manycast servers among its network neighbors, receiving time samples from each of them (using cryptography) and, based on this data, selecting the three “best” manycast servers with which the client will synchronize. If one of the servers fails, the client automatically updates its list.

To transmit time samples, clients and servers operating in multicast mode use multicast group addresses (class D networks). Clients and servers using the same address form the same association. The number of associations is determined by the number of multicast addresses used.

Frequently asked questions

Why is the time not synchronized after the command net time /setsntp:server?

Make sure that the w32time service's startup type is set to Automatic.
Make sure that UDP port 123 of the NTP server you are using is available.
Make sure that the time between client and server does not vary too much.

Can an SNTP client synchronize with an NTP server?

Yes, it can, since the SNTP protocol is a subset of NTP and is fully compatible with it.

Can I use a third party NTP server on Windows 2000/XP/2003?

Yes, you can use any server, paid or free. You must first disable the appropriate components (client or server) of the Windows Time services.

Why does the NTP client not work on a computer with MS installed? SQL Server?

Most likely the problem is that SQL Server is somehow occupying UDP port 123. A solution might be to run the NTP client before MS SQL Server.

The ntpd daemon, after starting, works for 10-20 minutes, after which it stops. What could be the problem?

Make sure that the client and server times do not differ too much (no more than 5 minutes). Otherwise, force synchronization using ntpdate.

Is it possible to synchronize time in OS Windows NT4, 95, 98, Me?

It is possible using third-party programs, for example, NetTime, Automacahron, World Time5, ntpd Windows NT port.

When trying to log into a Windows domain, a message appears that the time between the domain controller and the workstation differs too much, despite the fact that synchronization is precisely configured.

Most likely the problem is that the time has gone very wrong (CMOS reset, hacker sabotage) and the service is unable to authenticate using the Kerberos protocol. To solve this problem, you need to either manually set the time or not use this type of authentication when updating the time.

Answers on questions

26.09.2018

Hard to imagine modern world no exact time. In many areas of life, it is necessary to have very accurate clocks, and the accuracy must often be much higher than the accuracy of the clocks people use in everyday life. For example, the accuracy requirements for clocks in air traffic control towers, spacecraft control systems, or military systems are at the highest level. Also, high-precision clocks are also needed in systems with simpler functions - in billing and tariff systems mobile operators and Internet providers, in banking transaction systems, in exchange systems, in industrial and scientific complexes. On local networks, the Kerberos user authentication protocol also uses a comparison of the domain controller's time with the clock of user workstations. In computer networks, synchronization is usually performed with exact time servers using the protocol NTP or its “light” version - SNTP. In this article we will look at the features, differences and examples of application of these protocols.

NTP(English) Network Time Protocol– Network Time Protocol) – a network protocol for synchronizing a computer’s internal clock using networks with variable bandwidth. Provides high accuracy of time synchronization thanks to a special algorithm that allows you to select the most accurate sources to estimate the exact time. This algorithm allows you to minimize the impact of data from obviously incorrectly configured NTP servers on the overall system. The NTP protocol provides synchronization mechanisms with nanosecond precision, and contains facilities for characterizing and estimating errors of the local clock and the time server that performs the synchronization. The NTP protocol uses a hierarchical system of levels, or stratums. An NTP server is at the highest level (stratum 1) if it receives data directly from an accurate time source. Servers that synchronize their clocks with the stratum 1 server are on the level below (stratum 2), etc.

SNTP(English) Simple Network Time Protocol– simple network time protocol) – time synchronization protocol computer network. It is a simplified implementation of the NTP protocol; it lacks the complexity of the NTP algorithm. SNTP is used for network hosts that do not require full NTP functionality. It is common practice to synchronize the clocks of several nodes on a local network with other NTP nodes over the Internet and use these nodes to time synchronize services provided to other clients over the local network. This use case does not require high precision time synchronization. The SNTP protocol provides synchronization mechanisms with an accuracy of 1 to 50 ms

An example of using the NTP protocol: Bank N provides its clients with a client-server application for exchange trading. Servers that process information about stock quotes must have a clock with high precision synchronization with the universal time scale. In this case, each exchange trading server of bank N is synchronized with the most accurate of the exact time servers (“stratum 1”), which receives data directly from the exact time source. The most accurate server is selected using an algorithm built into the NTP protocol. An approximate architecture of such a solution is shown in the diagram below:

A classic example of using SNTP is time synchronization within a domain. The domain controller receives time from the global Internet from the public servers of Stratum 1 or Stratum 2. The remaining clients of the domain synchronize their clocks with the time on the domain controller. An approximate architecture is shown in the diagram.