Wednesday, 28 December 2011

NTP server Overview

Overview
NTP (Network Time Protocol) provides accurate and syncronised time across the Internet. This introductory article will try to show you how to use NTP to control and synchronize your system clock.
First approach
NTP is organised in a hierarchical client-server model. In the top of this hierarchy there are a small number of machines known as reference clocks. A reference clock is known as stratum 0 and is typically a cesium clock or a Global Positioning System (GPS) that receives time from satellites. Attached to these machines there are the so-called stratum 1 servers (that is, stratum 0 clients), which are the top level time servers available to the Internet, that is, they are the best NTP servers available.
Note: in the NTP lingo measure for synchronization distance is termed as stratum: the number of steps that a system lies from a primary time source.
Following this hierarchy, the next level in the structure are the stratum 2 servers which in turn are the clients for stratum 1 servers. The lowest level of the hierarchy is made up by stratum 16 servers. Generally speaking, every server syncronized with a stratum n server is termed as being at stratum n+1 level. So, there are a few stratum 1 servers which are referenced by stratum 2 servers, wich in turn are refenced by stratum 3 servers, which are referenced by stratum 4 and so on.
NTP servers operating in the same stratum may be associated with others in a peer to peer basis, so they may decide who has the higher quality of time and then can synchronise to the most accurate.
In addition to the client-server model and the peer to peer model, a server may broadcast time to a broadcast or multicast IP addresses and clients may be configured to synchronise to these broadcast time signals.
So, at this point we know that NTP clients can operate with NTP servers in three ways:
  • in a client-server basis
  • in a peer to peer mode
  • sending the time using broadcast/multicast
How does it work
Whenever ntpd starts it checks its configuration file (/etc/ntp.conf) to determine syncronization sources, authentication options, monitoring options, access control and other operating options. It also checks the frequency file (/etc/ntp/drift) that contains the latest estimate of clock frequency error. If specified, it will also look for a file containing the authentication keys (/etc/ntp/keys).
Note that the path and/or name of these configuration files may vary in your system. Check the -c command line option.
Once the NTP daemon is up and running, it will operate by exchanging packets (time and sanity check exchanges) with its configured servers at poll intervals and its behaviour will depend on the delay between the local time and its reference servers. Basically, the process starts when the NTP client sends a packet containing its timestamp to a server. When the server receives such a packet, it will in turn store its own timestamp and a transmit timestamp into the packet and send it back to the client. When the client receives the packet it will log its receipt time in order to estimate the travelling time of the packet.
The packet exchange takes place until a NTP server is accepted as a synchronization source, which take about five minutes. The NTP daemon tries to adjust the clock in small steps and will continue until the client gets the accurate time. If the delay between both the server and client is big enough the daemon will terminate and you will need to adjust the time manually and start the daemon again.
Sample ntp.conf configuration file
     server 134.214.100.6
     server swisstime.ee.ethz.ch

     peer 192.168.100.125
     peer 192.168.100.126
     peer 192.168.100.127

     driftfile /etc/ntp/drift
     #multicastclient  # listen on default 224.0.1.1
     #broadcastdelay  0.008

     authenticate no

     #keys           /etc/ntp/keys
     #trustedkey     65535
     #requestkey     65535
     #controlkey     65535

     # by default ignore all ntp packets
     restrict 0.0.0.0 mask 0.0.0.0 ignore

     # allow localhost
     restrict 127.0.0.1 mask 255.255.255.255

     # accept packets from...
     restrict 192.168.100.125 mask 255.255.255.255
     restrict 192.168.100.126 mask 255.255.255.255
     restrict 192.168.100.127 mask 255.255.255.255



Configuration on Unix
Unix Workstation as NTP Client
The NTP client program ntpdate sets the system clock once. As real clocks drift, you need periodic corrections. Basically you can run ntpdate in a cron job hourly or daily, but your machine won't be an NTP server then.
Crontab entry to update the system clock once a day
0 2 * * * /usr/sbin/ntpdate -s -b -p 8 -u 129.132.2.21
  • -b 
Force the time to be stepped using the settimeofday() system call, rather than slewed (default) using the adjtime() system call. This option should be used when called from a startup file at boot time.
  • -p samples
Specify the number of samples to be acquired from each server as the integer samples, with values from 1 to 8 inclusive. The default is 4.
  • -s
Divert logging output from the standard output (default) to the system syslog facility. This is designed primarily for convenience of cron scripts.
  • -u
Direct ntpdate to use an unprivileged port or outgoing packets. This is most useful when behind a firewall that blocks incoming traffic to privileged ports, and you want to synchronise with hosts beyond the firewall. Note that the -d option always uses unprivileged ports.
Public NTP Server in Switzerland
swisstime.ethz.ch (129.132.2.21)
Location: Integrated Systems Laboratory, Swiss Fed. Inst. of Technology,
CH 8092 Zurich, Switzerland
Geographic Coordinates: 47:23N, 8:32E
Synchronization: NTP primary (DCF77 clock), Sun-4/SunOS 4.1.4
Service Area: Switzerland/Europe
Access Policy: open access
Contact: Christoph Wicki (time@iis.ee.ethz.ch)


Troubleshooting
One of the quickest commands to verify that ntpd is still up and running as desired is ntpq -p. That command will show all peers used and configured together with their corner performance data.
# ntpq -p
     remote      refid    st t when poll reach   delay  offset jitter
=====================================================================
 LOCAL(0)        LOCAL(0) 3 l    9   64  377    0.000   0.000   0.000
*swisstime.ethz. .DCFa.   1 u   17   64  377   25.088 -10.040   1.071
To obtain a current list peers of the server, along with a summary of each peer's state. Summary information includes the address of the remote peer, the reference ID (0.0.0.0 if this is unknown), the stratum of the remote peer, the type of the peer (local, unicast, multicast or broadcast), when the last packet was received, the polling interval, in seconds, the reachability register, in octal, and the current estimated delay, offset and dispersion of the peer, all in milliseconds.
# ntpq -c pee swisstime.ethz.ch
     remote      refid   st t when poll reach   delay  offset jitter
====================================================================
*GENERIC(0)      .DCFa.   0 l   14   16  377    0.000   0.126  0.170
 LOCAL(0)        LOCAL(0) 6 l   13   64  377    0.000   0.000 10.010
 sns2-tss2.unige lantime  2 u  323 1024  377   11.000   0.014  1.770
+nz11.rz.uni-kar .DCF.    1 u   40   64  376  353.290  18.088 17.120
xjane.planNET.de .DCFa.   1 u   80  256  377  125.050 -38.018  0.210
+sombrero.cs.tu- .GPS.    1 u   49   64  377   36.070   1.159  0.790
# ntpdc
ntpdc> peers
Be sure that there is an entry for the the swisstime.ethz.ch server, and that there is an entry for your local net. The "st" (stratum) column for the ITD time servers should be "1" or "2", indicating that the time server are stratum-1/2 servers, e.g. they obtain their time from stratum-1 servers, which are directly connected to external time reference sources. If the stratum for any server is "16" then this server is not synchronizing successfully.
     remote           local     st poll reach delay   offset    disp
====================================================================
=LOCAL(0)        127.0.0.1       3  64 377 0.00000  0.000000 0.00095
=cosmos.hsz.akad 5.0.0.0        16  64   0 0.00000  0.000000 0.00000
*swisstime.ethz. 192.168.138.29  1 128 377 0.02658 -0.001197 0.00215


Troubleshooting
One of the quickest commands to verify that ntpd is still up and running as desired is ntpq -p. That command will show all peers used and configured together with their corner performance data.
# ntpq -p
     remote      refid    st t when poll reach   delay  offset jitter
=====================================================================
 LOCAL(0)        LOCAL(0) 3 l    9   64  377    0.000   0.000   0.000
*swisstime.ethz. .DCFa.   1 u   17   64  377   25.088 -10.040   1.071
To obtain a current list peers of the server, along with a summary of each peer's state. Summary information includes the address of the remote peer, the reference ID (0.0.0.0 if this is unknown), the stratum of the remote peer, the type of the peer (local, unicast, multicast or broadcast), when the last packet was received, the polling interval, in seconds, the reachability register, in octal, and the current estimated delay, offset and dispersion of the peer, all in milliseconds.
# ntpq -c pee swisstime.ethz.ch
     remote      refid   st t when poll reach   delay  offset jitter
====================================================================
*GENERIC(0)      .DCFa.   0 l   14   16  377    0.000   0.126  0.170
 LOCAL(0)        LOCAL(0) 6 l   13   64  377    0.000   0.000 10.010
 sns2-tss2.unige lantime  2 u  323 1024  377   11.000   0.014  1.770
+nz11.rz.uni-kar .DCF.    1 u   40   64  376  353.290  18.088 17.120
xjane.planNET.de .DCFa.   1 u   80  256  377  125.050 -38.018  0.210
+sombrero.cs.tu- .GPS.    1 u   49   64  377   36.070   1.159  0.790
# ntpdc
ntpdc> peers
Be sure that there is an entry for the the swisstime.ethz.ch server, and that there is an entry for your local net. The "st" (stratum) column for the ITD time servers should be "1" or "2", indicating that the time server are stratum-1/2 servers, e.g. they obtain their time from stratum-1 servers, which are directly connected to external time reference sources. If the stratum for any server is "16" then this server is not synchronizing successfully.
     remote           local     st poll reach delay   offset    disp
====================================================================
=LOCAL(0)        127.0.0.1       3  64 377 0.00000  0.000000 0.00095
=cosmos.hsz.akad 5.0.0.0        16  64   0 0.00000  0.000000 0.00000
*swisstime.ethz. 192.168.138.29  1 128 377 0.02658 -0.001197 0.00215



 

No comments:

Post a Comment