NTP protocol description. How does NTP time synchronization protocol differ from SNTP? How to start using the NTP Server service



Time synchronization is an important task, although not many people have thought about it. Well, what's wrong with time running away on a server? Did you know that many clock problems affect protocols related to cryptography? For this reason, in Active Directory, clock differences greater than 5 minutes will cause Kerberos authentication problems.

Hourly levels. Strata.

To understand the NTP device you need to know about the concept strata or stratum. Authoritative time sources such as GPS satellites, cesium atomic clocks, WWVB radio waves - all this stratum 0. They are authoritative on the basis that they have some way of maintaining highly accurate timekeeping. You can, of course, use an ordinary quartz watch, but knowing that it is easy to lose 15 seconds with them in a month, it is better not to use them as a measure of time. Stratum 0 This is when a second is not lost in 300,000 years!

Computers that directly (not over the network!) take time from stratum 0- This stratum 1. Since there are always delays due to signal transmission and costs for setting the time, computers stratum 1 not as accurate as stratum 0, but in real life the difference reaches a couple of microseconds (1 μs = 10 -6 s), which is a completely acceptable deviation.

The next level of computers taking time over the network from stratum 1- this is... drum roll... intrigue... stratum 2! Again due to various delays (network delays for sure), stratum 2 a little behind stratum 1 and certainly from stratum 0. In practice, this is a difference from several microseconds (1 μs = 10 -6 s) to several milliseconds (1 ms = 10 -3 s). Many people want to sync with the layer no further stratum 2.

As is clear from the diagram, stratum 4 takes time from a superior stratum 3. stratum 5 at stratum 4 and so on. stratum 16 is considered the lowest layer and time is counted there unsynchronized.

To synchronize time using NTP, you must first manually set your time. There must not be a difference of more than 1000 seconds between your exact time and your watch. If the time server you are using is lying for more than 1000 milliseconds (1 second), it will be excluded from the list and others will be used instead. This mechanism allows you to filter out bad time sources.

Time client.

In the /etc/ntp.conf file, the Server lines are important for the client. There can be several of them - up to 10 pieces!

How much to add? Please keep in mind:

  • If you have only one server (one line server), then if this server starts to lie, then you will blindly follow it. If his time runs out by 5 seconds and you run after him.
  • If 2 servers are added (2 server lines), then NTP will mark them both as false tickers. If one of them lies, then NTP cannot understand who is lying, since there is no quorum.
  • If 3 or more time servers are added, then one liar can be identified false tickers. If there are 5 or 6 time servers, then you can find 2 liars false tickers. If there are 7 or 8 servers, then 3 false tickers. If there are 9 and 10 servers, then 4 false tickers.

NTP Pool Project.

There is a project called NTP Pool at which address pool.ntp.org/zone/ru/ you can find time servers recommended for Russian users.

server 0.ru.pool.ntp.org
server 1.ru.pool.ntp.org
server 2.ru.pool.ntp.org
server 3.ru.pool.ntp.org

Operating systems such as Debian and Ubuntu offer users their own time servers.

server 0.debian.pool.ntp.org
server 1.debian.pool.ntp.org
server 2.debian.pool.ntp.org
server3.debian.pool.ntp.org

server 0.ubuntu.pool.ntp.org
server 1.ubuntu.pool.ntp.org
server 2.ubuntu.pool.ntp.org
server 3.ubuntu.pool.ntp.org

If you run the command ntpq -pn on your Linux computer that uses NTP

Remote refid st when poll reach delay offset jitter =============================== ===================================================== +93.180.6.3 77.37.134.150 2 u 62 1024 377 53.658 -0.877 1.174 +85.21.78.23 193.190.230.65 2 u 1027 1024 377 54.651 0.167 1.531 *62.173.138.130 89.109.251.24 2 u 940 1024 377 52.796 -0.143 1.001 +91.206.16.3 194.190.168.1 2 u 258 1024 377 93.882 -0.680 2.196 -91.189.94.4 193.79.237.14 2 u 596 1024 377 100.219 1.562 1.482

What the column names say:

  • remote- remote servers with which you synchronize time.
  • refid- superior stratum for this server.
  • st- stratum level. From 0 (not available to us) to 16 (not desirable to us). Ideal - 2.
  • t- connection type. " u" - unicast or manycast, " b" - broadcast or multicast, " l" local reference clock, " s" - symmetrical knot, " A" - manycast server, " B" - broadcast server, " M" - multicast server.
  • when- time when the server last responded to us. The parameter displays the number in seconds, but may display in minutes if the number is with m or in hours if h.
  • poll- polling frequency. Minimum 16 seconds, maximum 32 hours. The number must be 2n. Typically, this parameter displays either 64 seconds or 1024.
  • reach- 8 bits of an octet indicating the status of communication with a remote time server: successful or failed. If the bits are set, then it is successful, otherwise it is a failure. The value 377 is binary 0000 0000 1111 1111.
  • delay- the value in milliseconds shows the time between sending and receiving a response (round trip time - RTT).
  • offset- the offset in milliseconds between you and the time servers. Can be a positive or negative number.
  • jitter- the absolute value in milliseconds indicating the standard deviation of your offset.

There is a symbol before the IP address of the NTP server - this is tally code. Kinds tally code:

  • " " - discarded as invalid. For example, there is no connection with him or he is offline, he is too high rank and does not serve people like you.
  • "x"- rejected by the intersection algorithm. The intersection algorithm prepares a list of candidate partners that can become synchronization sources and calculates a confidence interval for each of them.
  • "." - discarded due to table overflow.
  • "-" - discarded by the cluster algorithm. The clustering algorithm sorts the list of candidates by layer and synchronization distance codes.
  • "+" - the server is turned on by the “combine algorithm”. This server is an excellent candidate if your current time server starts to fail you.
  • "#" - the server is an excellent alternative time server. The server with # can only be seen if you have more than 10 server entries in /etc/ntp.conf
  • "*" - current time server. Its readings are used to synchronize your watch.
  • "o"- Pulse per second (PPS) server. This usually means that the time server in question uses time sources such as GPS satellites and other precise time signals. If drawn O, then other types of tally code will no longer be displayed.

In field refid can have the following values:

  • IP address - address of the remote time server.
  • .ACST.- NTP manycast server.
  • .ACTS.- Automated Computer Time Service from the American National Institute of Standards and Technology.
  • .AUTH. - authentication error.
  • .AUTO. - error in Autokey sequences.
  • .BCST.- NTP broadcast server.
  • .CHU.- Shortwave radio receiver from station CHU in Ottawa, Ontario, Canada.
  • .CRYPT. - Autokey protocol error.
  • .DCFx.- LF radio receiver from station DCF77 in Mainflingen, Germany.
  • .DENY.- Access denied.
  • .GAL.- European Galileo satellite receiver.
  • .GOES.- American Geostationary Operational Environmental Satellite receiver.
  • .GPS.- American Global Positioning System receiver.
  • .HBG.- LF radio receiver from HBG station in Prangins, Switzerland.
  • .INIT.- Peer association initialized.
  • .IRIG.- Inter Range Instrumentation Group time code.
  • .JJY.- LF radio receiver from JJY station in Mount Otakadoya, near Fukushima or Mount Hagane on Kyushu Island, Japan.
  • .LFx.- Regular LF radio receiver.
  • .LOCL. - local host clock.
  • .LORC.- LF radio receiver from Long Range Navigation (LORAN-C).
  • .MCST.- NTP multicast server.
  • .MSF.- Anthorn Radio Station near Anthorn, Cumbria.
  • .NIST.- American National Institute of Standards and Technology.
  • .PPS.- Pulse per second clock.
  • .PTB.- Physikalisch-Technische Bundesanstalt from Brunswick and Berlin, Germany.
  • .RATE. - NTP polling threshold exceeded.
  • .STEP. - change the NTP step. Bias offset less than 1000 milliseconds but more than 125 milliseconds.
  • .TDF.- LF radio receiver from TéléDiffusion de France station in Allouis, France.
  • .TIME.- NTP association timeout.
  • .USNO.- United States Naval Observatory.
  • .WWV.- HF radio receiver from WWV station in Fort Collins, Colorado, United States.
  • .WWVB.- LF radio receiver from WWVB station in Fort Collins, Colorado, United States.
  • .WWVH.- HF radio receiver from the WWVH station in Kekaha, on the island of Kauai on Hawaii, United States.

First, get rid of the idea of ​​how to get time from stratum 1, they say they are closest to the exact time. They are closer to the most accurate time on the planet, but they themselves are overloaded and have high RTT delays for regular servers. Better find a normal one stratum 2 and don't worry about it. Don't forget that we are talking about microseconds and milliseconds, which is quite enough in ordinary life.

Secondly, remember that connecting to the nearest time server is not always ideal. What is more important is not the territorial proximity, but the level of stratum. The NTP Pool project publishes a list of tier-only servers stratum 1 And stratum 2 and it’s better to take up to 10 time servers from this list, which will be just great.

Thirdly, if you are a simple home user-client, then the servers recommended for you in your operating system will be an ideal option that does not require unnecessary movements.

For large offices, the best option would be to set up their own time server for work computers. This server will receive accurate time from time servers on the Internet and provide it to local computers. On Debian and Ubuntu servers, just uncomment the line

Restrict 192.168.0.0 mask 255.255.0.0 nomodify notrap

in the ntpd daemon configuration file - /etc/ntp.conf

Users from the 192.168/16 network will be able to take accurate clock readings from your server. For internal Linux-based servers that are not time servers and are engaged in their own tasks, instead of running the ntpd daemon in client mode, it is quite enough to specify it in the /etc/cron.daily/syncntpd file. It is recommended that you read the differences between ntpdate and ntp and decide for yourself.
#!/bin/sh
/usr/sbin/ntpdate IP.address.of.your.server > /dev/null 2>&1
exit 0

and once a day, thanks to the ntpdate command, time synchronization will be performed. To avoid misunderstandings, do not be lazy before implementing a time server and synchronizing everything via the NTP protocol - manually set the correct time on all servers and workstations available to you. If your unsynchronized time is too different from the correct one, then you can create a lot of unnecessary problems in the beginning.

Fourthly, NTP has nothing to do with which country and which time zones are used and how the transition to summer and winter time occurs and whether such a transition is made in a given country. This responsibility lies with the operating system, which you need to update if there are changes in watchmaking in the country. On Debian and Ubuntu systems, the tzdata package is responsible for this and must be up to date.

Fifthly, it is better not to run your NTP server on a highly loaded system.

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, the normal operation of which requires precise time, and, as a rule, more precise time than we humans usually need. System services, security system components, and simply application programs can be very critical to the accuracy of the clock. 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 (currently latest) 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 in the form of the Windows Time system service, 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 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 the case of a workgroup, 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 time update security by supporting Active Directory authentication. 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 is not difficult to guess that the Windows Time service settings are stored in the Windows registry in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\ section.

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 (a very useful feature when debugging).

Another option for configuring the Windows Time service is to use Group Policies. The settings are defined in the Group Policy Object 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 all .adm files from the system32\GroupPolicy\Adm system folder of any machine with Windows XP installed to the server that 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, the distinctive feature of which is that there is no need to pre-distribute server public keys.

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. It is configured in the usual UNIX way - by editing the ntp.conf configuration file 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 do not see this line, it means that ntpd is not configured to start automatically. 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 a large number of peer 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. So even if a machine "loses" an external source, it will still be able to obtain accurate time from its 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 for use in cases where a small number of servers serve 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 SQL Server installed?

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.

NTP uses the UDP protocol to operate. The NTP system is extremely resilient to changes in media latency.

NTP uses the Marzullo algorithm (proposed by Keith Marzullo of the University of California, San Diego), including the transmission timing feature. 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.

NTP is one of the oldest protocols in use. NTP was developed by David L. Mills from the University of Delaware in 1985 and is currently being improved. The current version is NTP 4.

NTP uses a hierarchical system of "clock levels" (stratum). Level 1 is synchronized with a high-precision clock, for example, with a GPS system, GLONASS (Unified State Time Scale of the Russian Federation) or an atomic time standard. Level 2 synchronizes with one of Level 1's machines, and so on.

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 50 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.

The NTP protocol is most widely used for implementing precise time servers. To achieve maximum accuracy, it is preferable to always run the NTP software in system service mode. In the Microsoft Windows family of operating systems, this is the W32Time service (w32time.dll module running in svchost.exe), Linux - the Ntpd service.

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

The detailed implementation of the protocol and the system as a whole is described in:

NTP should not be confused with daytime protocol RFC 867 or time protocol RFC 868 (win program FG Time Sync).

Hour layers

NTP uses a hierarchical, multi-level system of time sources. Each level of this hierarchy is called a layer, each layer is assigned a number, starting with 0 (zero) at the top. The layer level defines the distance from the reference clock and exists to prevent cyclic dependencies in the hierarchy. It is important to note that the layer is not an indicator of quality and reliability, it means that the source layer 3 may provide a higher quality signal than some sources layers 2. Basically, the layers serve to distribute the load and provide a larger area of ​​coverage. This definition of a layer also differs from the concept of clock layers used in telecommunications systems.

Layer 0

Layer 0 is a high-precision device that serves as a time standard, such as atomic (molecular, quantum) clocks, radio clocks or their analogues. Typically these devices are not connected to a network; instead, they are connected to the local computer (for example, via an RS-232 interface) and transmit PPS signals for synchronization.

Layer 1

This is a computer to which the reference clock is directly connected. It acts as a network time server and responds to NTP requests sent by layer 2 computers.

Layer 2

These are computers that receive time from the first layer servers using the NTP protocol. Typically, computers in the second layer contact several servers in the first layer, and using the NTP algorithm, get the best sample of data, eliminating servers with obviously incorrect times. Computers can compare their data with other computers in their layer to obtain stable and consistent data across all computers in the layer. Computers in the second layer, in turn, act as servers for computers in the third layer and respond to NTP requests.

Layer 3

Computers of the third layer work in exactly the same way as computers of the second layer, with the only difference being that the servers for them are computers of the overlying second layer. They can also act as servers for the underlying layer. NTP (depending on version) supports up to 256 layers.

see also

Links

  • - list of NTP servers of the State Time and Frequency Standard (STSE) of the Russian Federation
  • Network Time Protocol project - a public project to develop the NTP protocol and services
  • NTP Public Services Project - NTP public servers project and the IETF NTP Working Group
  • pool.ntp.org is a resource that represents a large virtual cluster of NTP servers for millions of users. As of December 29, 2010, 2078 servers are registered in pool.ntp.org. It is possible to select regional servers.
  • ntp.mobatime.ru - since 2005, a public free NTP server Mobatime of the first stratum (Russia, St. Petersburg).
  • time.bakulev.ru - public free NTP server of the first stratum (Russia, Moscow).

Wikimedia Foundation. 2010.

See what "NTP" is in other dictionaries:

    NTP- is a three letter initialism which may stand for: Contents 1 Computing 2 Politics 3 Science 3.1 Chemistry 3.2 Medicine … Wikipedia

    NTP-abbrev. normal temperature and air pressure: former term for STP * * * NTP abbr. normal temperature and pressure. * * * …Universalium

    NTP- NTP, Abk. für Network Time Protocol…Universal-Lexikon

    NTP- (Network Time Protocol) (Internet) protocol that schedules the computer s internal clock with the atomic clocks or radio clocks on the Internet ... English contemporary dictionary

    NTP-abbrev. normal temperature and air pressure: former term for STP … English World dictionary

    NTP- Cette page d'homonymie répertorie les différents sujets et articles partageant un même nom. Sigles d’une seule lettre Sigles de deux lettres > Sigles de trois lettres Sigles de quatre lettres … Wikipédia en Français

    NTP

    Ntp- Die Abkürzung NTP steht für: Network Time Protocol, ein Protokoll zur Zeitsynchronization zwischen Computern Normal Temperature and Pressure, die englische Bezeichnung für die physikalischen Normalbedingungen Nukleosidtriphosphat in der… … Deutsch Wikipedia

    NTP- Abbreviation for nucleoside 5′ triphosphate. * * * narcotic treatment program; National Toxicology Program; nitroprusside; nonthrombopenic purpura; normal temperature and pressure; 5´ nucleotidase; sodium nitroprusside * * * NTP abbr normal… … Medical dictionary

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, it is preferable to always run the NTP software in system service mode. In the Microsoft Windows family of operating systems this is the W32Time service, Linux - 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

Network Time Protocol is a network protocol for synchronizing a computer's internal clock using variable latency networks based on packet switching.

Although NTP traditionally uses UDP to operate, it is also capable of running over TCP. The NTP system is extremely resistant to changes in transmission media latency.

Time is represented in the NTP system as a 64-bit number, 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.

How it works

NTP servers operate in a hierarchical network, each level of the hierarchy is called a stratum. Tier 0 is represented by the reference clock. The standard is taken from the GPS (Global Positioning System) signal or the ACTS (Automated Computer Time Service) service. On the zero tier, NTP servers do not work.

Tier 1 NTP servers obtain time information from a reference clock. Tier 2 NTP servers are synchronized with Tier 1 servers. There can be up to 15 tiers in total.

NTP servers and NTP clients obtain time data from Tier 1 servers, although in practice NTP clients should not do this because thousands of individual client requests would be too much of a burden for Tier 1 servers. It is better to configure a local NTP server that your clients will use to obtain time information.

The hierarchical structure of the NTP protocol is fault-tolerant and redundant. Let's look at an example of his work. Two Tier 2 NTP servers synchronize with six different Tier 1 servers, each on an independent channel. Internal nodes are synchronized with internal NTP servers. Two Tier 2 NTP servers coordinate time with each other. If the link to a Tier 1 server or one of the Tier 2 servers fails, the redundant Tier 2 server takes over the synchronization process.

Likewise, Tier 3 nodes and devices can use any of the Tier 2 servers. What's more important is that having a redundant network of NTP servers ensures that time servers are always available. By synchronizing with multiple time servers, NTP uses data from all sources to calculate the most accurate time.

It is worth noting that the NTP protocol does not set time in its pure form. It adjusts the local clock using a time offset, the difference between the time on the NTP server and the local clock. NTP servers and clients adjust their clocks, synchronizing with the current time gradually or all at once.


2024 gtavrl.ru.