Public ntp servers. An example of configuring a local NTP server to work with NetPing devices

The exact time server is designed to synchronize time-frequency indicators. The device generates frequency and time signals with high accuracy and synchronizes these parameters at remote sites.

The time synchronization server can operate using various signals and protocols, including the common NTP protocol and the more popular PTP protocol. Receiving signals from satellites of global positioning systems GPS and GLONASS, the server transmits them to client devices and synchronizes time parameters.

Description of SSV-1G

Frequency and time server "SSV-1G" is a stand-alone device 1.5 U high, installed in a 19" telecommunication rack, designed to generate frequency and time signals.

Unlike many other products on the market, the SSV-1G time server is not based on industrial servers, but uses its own hardware platform, which has significantly reduced its cost, increased reliability, and eliminated dependence on the manufacturer operating system and server platform.

Synchronization of the exact time server is carried out from the signals of satellite radio navigation systems (SRNS) of both the Russian GLONASS and GPS, which increases the accuracy of time determination and reduces the risks of the operator's dependence on foreign navigation systems.

The 1PPS signal input, the E1/2.048 MHz input, or the 5 (10) MHz input can be used as backup clock sources for the master oscillator.

The RS232 input of the COMB module can be used as a backup source of time scale synchronization using the TOD, Sirf protocols.

The SSV-1G is powered by two inputs (Main / Backup) from independent sources AC 220 V 50Hz / DC 48 V. A delivery option is available with two DC 48 V power inputs and an additional external converter AC 220 V 50Hz - DC 48 V, which allows to supply power to the SSV-1G through one input AC 220 V 50 Hz, and through the other input DC 48 V. Power consumption depends on the configuration and does not exceed 40 W.

Maintenance of the device is simplified as much as possible. The operating personnel can receive information and control the device using the Maintenance System software, or using the control tools built into the device - a graphic indicator and a keyboard.

Specifications SSV-1G

Advantages of the SSV-1G time source

• Optimal price-quality ratio

The SSV-1G source has one of the best price-quality ratios in its equipment class. This is achieved by two technological solutions.

Firstly, the SSV-1G is built on the basis of a hardware platform of its own production. In addition, there is no third-party licensed software in the SSV-1G device.

Secondly, instead of expensive high-precision rubidium oscillators with a short service life, quartz oscillators are used with double temperature control, which ensures a constant temperature level necessary to ensure a stable operating mode. This solution is similar in accuracy to rubidium generators, but it costs significantly less and is more reliable.

• Information Security

All SSV-1G expansion modules, including the NTP-server module, have a hardware implementation built on the basis of a rigid machine.

This solution provides the highest performance and as a result:

1. High accuracy of time stamp transmission due to the absence of internal delays that affect the asymmetry of the NTP packets transmission and reception channel.
2. The impossibility of disrupting the functioning of the NTP server due to DDOS attacks. Performance local NTP-server is higher than the speed of the Ethernet channel.
3. The impossibility of disrupting the functioning of the NTP server due to unauthorized access to resources through the Ethernet port. The NTP time server only provides functionality and does not respond to any other IP packets.

Modular design

The base chassis of the SSV-1G source is a 19-inch case with installed modules control, a receiver of SRNS signals, a thermally stabilized quartz oscillator with a phase-locked loop, as well as a backplane for installing functional expansion modules.

The modular design allows you to create up to 16 NTP servers on the basis of one device in physically separated networks.

Expansion modules are installed in accordance with the required configuration of input / output signals based on the specification determined at the time of order.

When changing the configuration, there is no need to buy a new device, it is enough to install an additional required number of expansion modules.

In total, up to 8 expansion modules can be installed.

Frequency and time source modules SSV-1G

MLAN module

• Simple Network Time Protocol (RFC 1769, RFC 2030);
• Time Protocol (RFC 868);
• Daytime Protocol (RFC 867).

MLANP module

The module is designed to receive requests from clients and generate a packet with the exact current time according to the following protocols:

• Network Time Protocol (RFC 1119, RFC 1305, RFC 5905);

The Precision Time Protocol (PTP) is designed for a single client connection. The operating mode is determined by any combination of the following parameters:

When using the Network Time Protocol (NTP), it is possible to send packets to the specified IP address (including broadcast Broadcast), with the specified frequency.

The module has two independent channels with identical functionality and the same set of configuration parameters. Channels are configured individually. The load capacity of each channel is about 123,000 packets per second.

MGLAN module (NTP/PTP)

The module is designed to receive requests from clients and generate a packet with the exact current time according to the following protocols:

• Precision Time Protocol V2 (IEEE Std 1588-2008);
• Network Time Protocol (RFC 1119, RFC 1305, RFC 5905);
• Simple Network Time Protocol (RFC 1769, RFC 2030).

MPPS module

The module is designed to receive a PPS signal (1Hz) and generate a signal, the shape of which is set in the configuration, has two identical channels, each of which can operate in the receive or transmit mode.

Module "MSYNC 120", "MSYNC 75"

The module is designed to receive and generate 2.048 MHz (G.703/10) or 2.048 Mbps (G.703/6) signals and has two identical channels, each of which can operate in the signal reception or transmission mode.

MCOMB module

The MCOMB module is designed to receive / transmit the exact current time in the specified format via the RS-232 interface, as well as receive and generate a 1 PPS time stamp pulse.

Supported RS-232 interface protocols: TOD; Sirf, TimeString, NMEA.

Module "M10M"

The module is designed to receive and generate 5 MHz or 10 MHz signals and has two identical channels, each of which can operate in the mode of receiving or transmitting a signal.

Module "MTP" (Current Loop)

The module is designed to generate a time stamp pulse via the "Current loop" or "Dry contact" interface and has two independent, galvanically isolated channels.

MIRIG module

The MIRIG module is designed to generate a signal according to the IRIG STANDARD 200-04 protocol specification.

Module "M422"

Module "M422" is intended for receiving/transmitting the exact current time in the specified format via the RS-422/485 interface, as well as receiving and generating a time stamp pulse via the RS-422/485 interface.

Supported RS-422/485 interface protocols: TOD, Sirf, TimeString, NMEA.

Centralized Management

Control and management of the operation of synchronization devices installed on the operator's network can be provided by a specialized network software"Maintenance", developed by CJSC "COMSET-service".

Troubleshooting Management

• collection of messages about accidents, malfunctions and events requiring attention from connected devices;
• getting a list of accidents;
• filtration of accidents with assignment of severity degree to them;
• display of accidents and malfunctions, as well as their characteristics;
• control of the accessibility of the control device (the presence of a communication channel between the device and the control system);
• generation of reports on accidents and events.

Security management

• protection of access to the system using a username and password;
• user authorization in the control system;
• four levels of user rights from administrator (with full rights) to a user with read-only rights;
• control of actions of operators on processing of malfunctions.

Configuration management

• adding a new device;
• for each supported device remote display of information about the device: information on the inputs/outputs used, device configuration, device operation modes, parameters that determine the operation of the device;
• automatic recognition serial numbers devices (inventory function).

Performance management

• displaying the current characteristics of devices in real time.

Output and User Interface

• data on the state of network elements are displayed in a tabular form with the possibility of printing them;
• the system has a convenient user interface, making it easy to view:
  • a list of devices, their current state and state information elements;
  • list of users, access rights granted to users;
  • current state of all device modules;
  • the state of the satellite signal receiver, the state of the satellite constellation visible at the installation point;
  • and much more.
• “Maintenance” software has advanced tools for visualization and analysis of fault signals with the possibility of sound notification of various tones, easily customizable by the user of the system.

The time server "SSV-1G" is a proprietary development of the KOMSET-service company. It has an independent hardware platform, high precision transmission of time indicators, user-friendly interface and two power supplies: main and backup. You can buy a time synchronization server in Moscow from us in a standard or extended version. It is also possible to supply the device throughout Russia. You can get prices for equipment by submitting a request to commercial proposal companies.

Where is the NTP time server used?

The scope of the equipment is quite wide. NTP servers are used at all facilities where it is extremely important to regulate time parameters:

• Companies mobile operators and telecommunications.
• Internet providers.
• Airports, railway and bus stations.
• In commercial automated accounting systems.

There are many services in operating systems whose normal functioning depends on the accuracy of the system clock. If the exact time is not set on the server, this can cause various problems.

For example, in local network it is required that the clocks of machines sharing files be synchronized - otherwise it will not be possible to correctly set the modification time of files. This, in turn, can cause version conflicts or important data to be overwritten.

If the server does not have an exact time set, there will be problems with Cron jobs - it is not clear when they will run. It will be very difficult to analyze the system event logs to diagnose the causes of failures and malfunctions ...

You can go on for a long time...

To avoid all the described problems, you need to set up synchronization of the system clock. Linux uses NTP (Network Time Protocol) for this. In this article, we will talk in detail about how to install and configure NTP on the server. Let's start with a little theoretical introduction.

How does the NTP protocol work?

The NTP protocol is based on a hierarchical structure of exact time servers, in which different levels (English strata) are distinguished. Level 0 refers to the reference clock (atomic clock or GPS clock). At level zero, NTP servers don't work.

Tier 1 NTP servers, which are sources for Tier 2 servers, synchronize with the reference clock. Tier 2 servers synchronize with Tier 1 servers, but can also synchronize with each other. Tier 3 and below servers work the same way. In total, up to 256 levels are supported.

The hierarchical structure of the NTP protocol is characterized by fault tolerance and redundancy. In the event of connection failures with the upstream servers, the backup servers take over the synchronization process. Redundancy ensures that NTP servers are always available. By synchronizing with multiple servers, NTP uses data from all sources to calculate the most accurate time.

Installing and configuring an NTP server

The most famous and widespread software tool for time synchronization is the ntpd daemon. Depending on the settings specified in configuration file(this will be discussed below), it can act both as a server and as a client (that is, it can both receive time from remote hosts and distribute it to other hosts). Below we will describe in detail how to install and configure this daemon in OC Ubuntu.

Installation

The NTP program is included in the distribution kits of most modern Linux systems and is installed using standard manager packages:

$ sudo apt-get install ntp

Setting

After the installation is completed, open in text editor/etc/ntp.conf file. It stores all program settings. Let's consider them in more detail.

Logging options

The first line of the config file looks like this:

Driftfile /var/lib/ntp/ntp.drift

It specifies a file for storing information about the frequency of the time offset. This file stores the value resulting from previous time adjustments. If external NTP servers become unavailable for one reason or another, the value will be taken from it.

Logfile /var/log/ntp.log

List of servers for synchronization

The configuration file specifies the list of NTP servers with which synchronization will be performed. By default it looks like this:

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

Each line means a group of servers that will report the correct time to our server. You can improve synchronization accuracy using the iburst option (it indicates that not one, but several packets should be sent to the server for synchronization):

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

You can also specify your preferred server with the prefer option:

Server 0.ubuntu.pool.ntp.org iburst prefer

NTP servers are scattered around the world (here, for example, is a list of available public NTP servers). To ensure a more accurate setting of the system clock, it is recommended to synchronize only with ntp servers of the region in which our server is geographically located. To do this, in the /etc/ntp.conf configuration file, specify the regional subdomain for pool.ntp.org in the server addresses:

• Asia - asia.pool.ntp.org;
• Europe - europe.pool.ntp org;
• Africa — africa.pool.ntp.org;
• North America - north-america.pool.ntp.org;
• South America - south-america.pool.ntp.org;
• Oceania - oceania.pool.ntp.org.

You can also specify subdomains for individual countries (for more details, see ). There is also a subdomain for Russia - ru.pool.ntp.org

Backup time server

An NTP server that is disconnected from the Internet for any reason may transmit its system clock data for synchronization. To do this, add the following line to the configuration file:

Server 127.127.1.0

Restrictions

Recently, cases of using NTP servers to amplify traffic in DDoS attacks have become more frequent (for more details, see, for example,). To prevent our server from becoming a victim of abuse, it would be useful to set access restrictions for external clients. By default, the following restrictions are set in the /etc/ntp.conf file:

Restrict −4 default kod notrap nomodify nopeer noquery restrict −6 default kod notrap nomodify nopeer noquery

The nomodify, notrap, nopeer, and noquery options prevent third-party clients from modifying anything on the server. The kod parameter (this is an abbreviation for kiss of death) provides additional protection: a client that sends too many requests will first receive a so-called kod packet (denial of service warning) and then be disconnected from the server.

In order for machines from the local network to synchronize with the NTP server, add the following line to the configuration file:

Restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

For the local host, you can set access to the NTP server without restrictions:

Restrict 127.127.1.0

Synchronization check

After all the necessary changes have been made to the configuration file and saved, restart the NTP server:

$ service restart ntp

Then run the following command:

$ ntpq -pn

Its output will be presented in the form of a table:

Remote refid st t when poll reach delay offset jitter ======================================= ===================================== *62.76.96.4 130.173.91.58 2 u 207 256 37 10.985 -215.79 256.992 +85.21.78.91 89.175.22.41 2 U 193 256 37 32.623 -207.70 259.121 +31.131.249.27 89.175.22.41 2 U 198 256 37 0.621 -216.90 257.037 +85.21.78.8 193.11.166.20 2 U 193 256 37 32.028 - 207.41 259.863 +91.189.94.4 193.79.237.14 2 u 192 256 37 50.573 -206.62 259.542

The table indicates the following parameters:

• remote — exact time server address (this column displays servers from the list in the configuration file);
• refid - upstream server (the one from which the server from the previous columns receives synchronization);
• st — level (stratum) of the server;
• t — peer type (u- unicast, m- multicast);
• when is the time of the last synchronization;
• poll is the time in seconds it takes for the NTP daemon to synchronize with the peer.
• reach — server availability status; after eight successful synchronization attempts, the value of this parameter becomes equal to 377;
• delay — response delay time from the server;
• offset is the time difference between our server and the synchronization server; a positive value of this parameter means that our clock is fast, a negative value means that it is behind;
• jitter is the time offset on the remote server.

The following characters can be specified to the left of the server address:

• * server selected for synchronization;
• + a server suitable for updating (with which you can synchronize);
• — it is not recommended to synchronize with the server;
• x server is unavailable.

You can check if a server from the list is suitable for synchronization using the command:

Ntpdate -q server хх.ххх.ххх.ххх, stratum 2, offset −0.127936, delay 0.02600 7 Jul 14:30:23 ntpdate: adjust time server хх.ххх.ххх.ххх offset −0.127936 sec

From the above output, it can be seen that the server is suitable for synchronization, its level is 2, the offset is 0.127936 ms, and the delay is 0.026 ms.

You can also find out how the synchronization went (successfully or with errors) from the logs:

7 Jul 15:17:17 ntpd: synchronized to 91.198.10.4, stratum=2 7 Jul 15:17:17 ntpd: kernel time sync disabled 0041 7 Jul 15:17:21 ntpd: kernel time sync enabled 0001

Setting the local date and time

The ntpdate command can be used to set the local date and time on the server by sending a request to the NTP server.

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

hourly levels. Strata.

To understand an NTP device, you should 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 grounds that they have some way of maintaining highly accurate timekeeping. You can, of course, use ordinary quartz watches, 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- it stratum 1. Since there are always delays due to signal transmission and costs for setting 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 quite an acceptable deviation.

The next level of computers taking time over the network from stratum 1- it's... drumroll... intrigue... stratum 2! Again, due to various delays (network for sure), stratum 2 a bit behind stratum 1 and certainly from stratum 0. In practice, this difference ranges from a few microseconds (1 µs = 10 -6 s) to a few milliseconds (1 ms = 10 -3 s). Many want to sync with the layer no further stratum 2.

As is clear from the diagram, stratum 4 takes time from superiors stratum 3. stratum 5 at stratum 4 etc. stratum 16 is considered the lowest layer and time is considered there out of sync.

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

Time client.

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

How much to add? Keep in mind:

• If you have only one server (one server line), then if given server starts to lie, then you will blindly follow him. 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 both of them 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 calculated 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 such a project NTP Pool at the address of which pool.ntp.org/zone/ru/ you can find time servers recommended for Russian users.

server0.ru.pool.ntp.org
server1.ru.pool.ntp.org
server2.ru.pool.ntp.org
server3.ru.pool.ntp.org

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

server0.debian.pool.ntp.org
server1.debian.pool.ntp.org
server2.debian.pool.ntp.org
server3.debian.pool.ntp.org

server0.ubuntu.pool.ntp.org
server1.ubuntu.pool.ntp.org
server2.ubuntu.pool.ntp.org
server3.ubuntu.pool.ntp.org

If you call ntpq -pn on your Linux machine that uses NTP

Remote refid st t 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 do 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 for us). Ideal - 2.
• t- connection type. " u"- unicast or manycast, " b"-broadcast or multicast, " l" local reference clock, " s" - symmetrical node, " A" - manycast server, " B"-broadcast server, " M"- multicast server.
• when- the time when the server last answered us. The parameter displays the number in seconds, but may be in minutes if the number is m or hours if h.
• poll- polling frequency. Minimum 16 seconds, maximum 32 hours. The number must be 2 n . Usually in this parameter there is either 64 seconds or 1024.
• reach- An 8 bit octet indicating the status of communication with the remote time server: success or failure. If the bits are set, then success, otherwise, 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- offset in milliseconds between you and the time servers. Can be positive or negative number.
• jitter- an absolute value in milliseconds indicating the standard deviation of your offset.

Before the IP address of the NTP server there is a symbol - 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 in rank and does not serve people like you.
• "x"- discarded 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.
• "." - dropped due to table overflow.
• "-" - discarded by the cluster algorithm. The clustering algorithm sorts the list of candidates by layer codes and synchronization distances.
• "+" - the server is enabled by the "combine algorithm". This server is a great candidate if your current time server starts to fail you.
• "#" - the server is a great 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 clocks.
• "o"- Pulse per second (PPS) server. This usually means that this time server uses time sources like GPS satellites and other time signals. If drawn O, then other types of tally code will no longer be displayed.

In field refid can be 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 CHU station 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 at Mount Otakadoya, near Fukushima or Mount Hagane on Kyushu Island, Japan.
• .LFx.- Regular LF radio receiver.
• .LOCL. - local clock of the host.
• .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.- clock Pulse per second.
• .PTB.- Physikalisch-Technische Bundesanstalt from Brunswick and Berlin, Germany.
• .RATE.- NTP poll 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 the WWV station at Fort Collins, Colorado, United States.
• .WWVB.- LF radio receiver from the WWVB station at Fort Collins, Colorado, United States.
• .WWVH.- HF radio receiver from the WWVH station at Kekaha, on the island of Kauai in Hawaii, United States.

First, get rid of the thought 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, only 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. Do not forget that we are talking about microseconds and milliseconds, which in ordinary life is quite enough.

Second, remember that connecting to the nearest time server is not always ideal. More important is not territorial proximity, but the level of stratum. The NTP Pool project publishes a list of servers only at the level stratum 1 and stratum 2 and it's better to take up to 10 time servers from this list, which will be just wonderful.

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

For large offices the best option there will be a raising of the time server for working computers. This server will receive the exact time from Internet time servers and provide it 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 get the most accurate clock from your server. For internal Linux-based servers that are not time servers and do their own thing, instead of running the ntpd daemon in client mode, it is enough to specify 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 your server's IP address > /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 and 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 start a lot of unnecessary problems in the beginning.

Fourthly, NTP is not related in any way in which country and what time zones are used and how the transition to summer and winter time occurs and whether such a transition is made in this country. This responsibility lies with the operating system, which you need to update if there are changes in watchmaking in the country. V Debian systems and Ubuntu is responsible for the tzdata package, which should be up to date.

Fifth, it is better not to raise your NTP server on a highly loaded system.

Setting up an NTP server in Windows

Starting with Windows 2000, all operating Windows systems include time service W32Time. This service is designed to synchronize time within an organization. W32Time is responsible for the operation of both the client and server parts of the time service, and the same computer can be both an NTP (Network Time Protocol) client and server at the same time.

By default, the Windows time service is configured as follows:

When the operating system is installed, Windows starts an NTP client and synchronizes with an external time source;
When you add a computer to a domain, the synchronization type changes. Everything client computers and member servers in the domain use a domain controller to synchronize time, authenticating them;
When a member server is promoted to a domain controller, an NTP server is launched on it, which uses a controller with the PDC emulator role as a time source;
The PDC emulator, located in the forest root domain, is the primary time server for the entire organization. At the same time, it is also synchronized with an external time source.

This scheme works in most cases and does not require intervention. However, the Windows time service structure may not follow a domain hierarchy, and any computer can be designated as a reliable time source. As an example, I will describe setting up an NTP server in Windows Server 2008 R2, although the procedure has not changed much since Windows 2000.

Starting an NTP server

I note right away that the time service in Windows Server (from 2000 to 2012) does not have GUI and configured either from command line, or by direct editing system registry. Personally, the second method is closer to me, so we go to the registry.

So, the first thing we need to do is start the NTP server. Open the registry branch
HKLM\System\CurrentControlSet\services\W32Time\TimeProviders\NtpServer.
Here to enable the NTP server parameter Enabled you need to set the value 1 .

Then we restart the time service with the command net stop w32time && net start w32time

After restarting the NTP service, the server is already active and can serve clients. You can verify this using the w32tm /query /configuration command. This command outputs full list service settings. If section NtpServer contains the string Enabled:1, then everything is in order, the time server is working.

In order for the NTP server to serve clients, do not forget to open UDP port 123 on the firewall for incoming and outgoing traffic.

Basic NTP server settings

The NTP server has been enabled, now you need to configure it. Open the registry branch HKLM\System\CurrentControlSet\services\W32Time\Parameters. Here we are primarily interested in the parameter type A that specifies the type of sync. It can take the following values:

NoSync- The NTP server is not synchronized with any external time source. The clock built into the CMOS chip of the server itself is used;
NTP- The NTP server is synchronized with external time servers, which are specified in the registry setting NtpServer;
NT5DS- The NTP server synchronizes according to the domain hierarchy;
AllSync- The NTP server uses all available sources for synchronization.

The default value for a computer that is a member of a domain is NT5DS, for separately standing computer — NTP.

And parameter NtpServer, which specifies the NTP servers with which this server will synchronize time. By default, this parameter contains the Microsoft NTP server (time.windows.com, 0x1), if necessary, you can add several more NTP servers by entering their DNS names or IP addresses separated by a space. The list of available time servers can be viewed for example.

You can add a flag at the end of each name (ex. ,0x1) which specifies the mode to synchronize with the time server. The following values ​​are allowed:

0x1– SpecialInterval, use of a special polling interval;
0x2– UseAsFallbackOnly mode;
0x4– SymmetricActive, symmetrical active mode;
0x8– Client, sending a request in client mode.

When using the SpecialInterval flag, the interval value set in the key is required SpecialPollInterval. If the UseAsFallbackOnly flag is set, the time service is told that this server will be used as a fallback server and that other servers in the list will be contacted before synchronizing with it. Symmetric active mode is used by default by NTP servers, and client mode can be used in case of synchronization problems. You can see more about synchronization modes, or don’t fool around and just put it everywhere ,0x1(as advised by Microsoft).

Another important parameter Announce Flags located in the registry key HKLM\System\CurrentControlSet\services\W32Time\Config. It is responsible for how the NTP server declares itself and can take the following values:

0x0( Not a time server) - the server does not advertise itself through NetLogon as a time source. It can respond to NTP requests, but neighbors will not be able to recognize it as a time source;
0x1(Always time server) - the server will always announce itself regardless of the status;
0x2(Automatic time server) - the server will only announce itself if it receives reliable time from another neighbor (NTP or NT5DS);
0x4(Always reliable time server) - the server will always declare itself as a reliable time source;
0x8(Automatic reliable time server) - a domain controller is automatically declared reliable if it is a forest root domain PDC emulator. This flag allows the forest master PDC to assert itself as the authorized time source for the entire forest, even if it is not connected to the upstream NTP servers. No other controller or member server (which has the default flag 0x2) cannot claim to be a reliable source of time if it cannot find a source of time for itself.

Meaning Announce Flags is the sum of its constituent flags, for example:

10=2+8 - NTP server declares itself as a reliable time source, provided that it receives time from a reliable source or is a PDC of the root domain. Flag 10 is set by default for both domain members and standalone servers.

5=1+4 - The NTP server always claims to be a reliable time source. For example, to declare a member server (not a domain controller) as a reliable time source, flag 5 is needed.

Well, let's set the interval between updates. The key already mentioned above is responsible for it. SpecialPollInterval, located in the registry key HKLM\System\CurrentControlSet\services\W32Time\TimeProviders\NtpClient. It is in seconds and defaults to 604800, which is 1 week. This is a lot, so it's worth reducing the value of SpecialPollInterval to a reasonable value, say 1 hour (3600).

After configuration, you need to update the service configuration. You can do this with the w32tm /config /update command. And a few more commands for configuring, monitoring and diagnosing the time service:

w32tm /monitor - with this option you can find out how much system time this computer different from the time on the domain controller or other computers. For instance: w32tm /monitor /computers:time.nist.gov
w32tm /resync - With this command, you can force the computer to synchronize with the time server it uses.
w32tm /stripchart - shows the time difference between the current and remote computer, and can display the result in graphical form. For example, the command w32tm /stripchart /computer:time.nist.gov /samples:5 /dataonly will make 5 comparisons with the specified source and display the result in text form.

w32tm /config is the main command used to configure the NTP service. With its help, you can set the list of time servers used, the type of synchronization, and much more. For example, you can override the default values ​​and set up time synchronization with an external source using the command w32tm /config /syncfromflags:manual /manualpeerlist:time.nist.gov /update
w32tm /query - Shows the current service settings. For example, w32tm /query /source will show the current time source, and w32tm /query /configuration will show all service parameters.

Well, as a last resort 🙁
w32tm /unregister - Removes the time service from the computer.
w32tm /register - Registers the time service on the computer. In this case, the entire parameter branch in the registry is recreated.

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

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

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

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

How to start using the NTP Server service?

Use the following options when configuring hardware:

How to establish peering with 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 under the contract for connection to MSK-IX at no additional charge.