Chinaunix首页 | 论坛 | 博客
  • 博客访问: 3194193
  • 博文数量: 443
  • 博客积分: 11301
  • 博客等级: 上将
  • 技术积分: 5679
  • 用 户 组: 普通用户
  • 注册时间: 2004-10-08 12:30
个人简介

欢迎加入IT云增值在线QQ交流群:342584734

文章分类

全部博文(443)

文章存档

2022年(1)

2021年(1)

2015年(2)

2014年(1)

2013年(1)

2012年(4)

2011年(19)

2010年(32)

2009年(2)

2008年(4)

2007年(31)

2006年(301)

2005年(42)

2004年(2)

分类:

2007-03-19 15:13:54

1. About NTP

CODE:
NTP is used to synchronize the time of a computer client or server to another server or a referenced time source such as a radio, a satellite receiver or a modem. It provides client accuracy typically within a ms on a LAN or within 10ms over a WAN relative to a primary server synchronized to Coordinated Universal Time (UTC). Bringing up a NTP primary server requires a radio or satellite receiver or modem.

Time is distributed through a hierarchy of NTP servers, with each server adopting Primary (stratum 1) servers which are at the top of the pile and have access to some external time source, usually a radio clock. A stratum-2 server is one which is currently obtaining time from a stratum-1 server, a stratum-3 server would get its time from a stratum 2 server and so on. To avoid long lived synchronization loops the number of strata is limited to 15. If your network is isolated and you cannot access other people's servers across the Internet, a radio clock may make a good investment. Otherwise you would configure your server to one of the known primary or secondary NTP servers.

Each client in the synchronization subnet (which also may be a server itself) chooses exactly one of the available servers to synchronize to, usually from among the lowest stratum servers it has access to. Since this is not always an optimal configuration, NTP operates under another premise as well; i.e., each server's time should be viewed with a certain amount of distrust. NTP really prefers to have access to several sources of lower stratum time (at least three) since it can then apply an agreement algorithm to detect insanity on the part of any one of these. Normally, when all servers are in agreement, NTP will choose the best of these in terms of lowest stratum, closest (in terms of network delay) and claimed precisions, along with several other considerations.

Finally, there is the issue of association modes. There are a number of modes to choose from depending on the association between each of the servers. Configuring an association in symmetric-active mode (usually indicated by a peer declaration in the configuration file) indicates to the remote server that one wishes to obtain time from the remote server and that one is also willing to supply time to the remote server if need be. This mode is appropriate in configurations involving a number of redundant time servers interconnected via diverse network paths, which is presently the case for most stratum - 1 and stratum - 2 servers on the internet today. Configuring an association in client mode (usually indicated by a server declaration in the configuration file) indicates that one wishes to obtain time from the remote server, but that one is not willing to provide the time to the remote server. This mode is appropriate for file server and workstation clients that do not provide synchronization to other local clients. Where the requirements in accuracy and reliability are modest, clients can be configured to use broadcast or multicast modes. Where maximum accuracy and reliability are required, clients and servers operate in either client, server, or symmetric modes.
2. Setting up an NTP server

CODE:
1. Copy over /etc/inet/ntp.server to /etc/inet/ntp.conf

# cp /etc/inet/ntp.server /etc/inet/ntp.conf


2. Edit ntp.conf file

I have added lots of comments in this file for clarification. Default file does not have many comments.

#----- start of ntp.conf file ---------------------
# @(#)ntp.server        1.4    97/05/05 SMI
#
# /etc/inet/ntp.server
#
# An example file that could be copied over to /etc/inet/ntp.conf and
# edited; it provides a configuration template for a server that
# listens to an external hardware clock, synchronizes the local clock,
# and announces itself on the NTP multicast net.
#
# SEE RFC 1305 ON FOLLOWING CLOCK DEVICES:
# This is the external clock device.  The following devices are
# recognized by xntpd 3.4y:
#
# XType Device    Name           Description
# -------------------------------------------------------
# 1    (none)    LOCAL          Undisciplined Local Clock
# 2    trak      GPS_TRAK       TRAK 8820 GPS Receiver
# 3    pst       WWV_PST        PSTI/Traconex WWV/WWVH Receiver
# 4    wwvb      WWVB_SPEC      Spectracom WWVB Receiver
# 5    goes      GPS_GOES_TRUE  TrueTime GPS/GOES Receivers
# 6    irig      IRIG_AUDIO     IRIG Audio Decoder
# 7    chu       CHU            Scratchbuilt CHU Receiver
# 8    refclock- GENERIC        Generic Reference Clock Driver
# 9    gps       GPS_MX4200     Magnavox MX4200 GPS Receiver
# 10   gps       GPS_AS2201     Austron 2201A GPS Receiver
# 11   omega     OMEGA_TRUE     TrueTime OM-DC OMEGA Receiver
# 12   tpro      IRIG_TPRO      KSI/Odetics TPRO/S IRIG Interface
# 13   leitch    ATOM_LEITCH    Leitch CSD 5300 Master Clock Controller
# 14   ees       MSF_EES        EES M201 MSF Receiver
# 15   gpstm     GPS_TRUE       TrueTime GPS/TM-TMD Receiver
# 17   datum     GPS_DATUM      Datum Precision Time System
# 18   acts      NIST_ACTS      NIST Automated Computer Time Service
# 19   heath     WWV_HEATH      Heath WWV/WWVH Receiver
# 20   nmea      GPS_NMEA       Generic NMEA GPS Receiver
# 22   pps       ATOM_PPS       PPS Clock Discipline
# 23   ptbacts   PTB_ACTS       PTB Automated Computer Time Service
#
# Some of the devices benefit from "fudge" factors.  See the xntpd
# documentation.
# Either a peer or server.  Replace "XType" with a value from the
# table above.
#If you are adding a local hardware clock device,
#its driver is   identified  here  by  a  directive  like:  server
#127.127.XX.0 where 127.127 alerts NTP that this is a local rather
#than a remote network peer, and XX is a  clocktype  described  in
#the NTP distribution.  The restrict directive in this config file
#specifies that this host will only talk to the two  IP  addresses
#specified;  it   won't trust anyone else, and it won't serve time
#to anyone else.



#following three lines are there by default, change them according to your own setup.
server 127.127.XType.0 prefer
fudge 127.127.XType.0 stratum 0
broadcast 224.0.1.1 ttl 4

#three types of time servers
# 1. peer host_address [ key # ] [ version # ] [ prefer ]
#         Specifies that local server is to operate in symmetric active mode with
#         remote server specified as host_address, i.e.
#         local server can be synchronized to the remote server
# 2. server host_address [ key # ] [ version # ] [ prefer ] [ mode] server
#         Specifies that  the local  server  is  to  operate in
#         "client" mode with the remote server named in the com-
#         mand. In this mode the local server can be synchronized
#         to  the remote server, but the remote server can never
#         be synchronized to the local server.
# 3. broadcast host_address [ key # ] [ version # ] [ttl # ]
#         Specifies that  the local  server  is  to  operate  in
#         "broadcast" mode where the local server sends periodic
#         broadcast messages  to  a  client  population  at the
#         broadcast/multicast address named in the command
#
#         key      Indicates  that  all  packets  sent  to  the
#                  address are to include authentication fields,
#                  encrypted using the specified key number. The
#                  range  of  this number is that of an unsigned
#                  32 bit integer.  By  default,  an  encryption


#                  field is not included.
#         version  Specifies the version number to be  used  for
#                  outgoing  NTP  packets.  Versions 1, 2, and 3
#                  are the choices; version 3 is the default.
#         prefer   Marks the host as  a  preferred  host.   This
#                  host  will  be  preferred for synchronization
#                  over other comparable hosts.
# for complete listing see man page on xntpd


Sample ntp.conf file for an NTP primary stratum 1 server:

server 127.127.5.0
fudge 127.127.5.0 stratum 1


Sample ntp.conf file for an NTP server in peer mode:

peer ntppeerserver


Sample ntp.conf file for an NTP server in server mode: (Note: its recommended

to have a minimum of 3 server entries, even more preferable is 5)

server sometimeserver

server sometimeserver
server sometimeserver
server sometimeserver

server sometimeserver



We can always fall back to the local clock:

server 127.127.1.0
fudge 127.127.1.0 stratum 9


Once you have created your ntp.conf file, save it and start the xntpd daemon.

# /usr/lib/inet/xntpd &

you can specify different options for the daemon to run as:

     -a             Run in "authenticate" mode

     -b             Listen for broadcast NTP and sync to this  if
                    available

     -c   ----->    Specify an alternate configuration file

     -d    ----->   Specify debugging mode. This flag  may  occur
                    multiple times, with each occurrence indicat-
                    ing greater detail of display

     -e             Specify the time (in  seconds)  it  takes  to
                    compute the NTP encryption field on this com-
                    puter

     -f driftfile   Specify the location of the drift file

     -k             Specify the location of the file  which  con-
                    tains the NTP authentication keys

     -l logfile     Specify a log file instead of logging to sys-
                    log

     -m             Listen for multicast messages and synchronize
                    to them if available (requires multicast ker-
                    nel)

     -p  ---->      Specify the name of the file  to  record  the
                    daemon's process id

     -r             Ordinarily, the daemon automatically  compen-
                    sates  for  the  network  delay  between  the
                    broadcast/multicast server and the client; if
                    the  calibration  procedure  fails,  use  the
                    specified default delay (in seconds)

     -s             Specify the directory to be used for creating
                    statistics files

     -t trustedkey  Add a key number to the trusted key list

     -v             Add a system variable

     -V             Add a system variable listed by default
3. Setting up an NTP client

CODE:
1. Copy over /etc/inet/ntp.client to /etc/inet/ntp.conf :

# cp /etc/inet/ntp.client /etc/inet/ntp.conf


The default ntp.client file uses multicast to receive NTP updates. This can be changed to broadcast as well if you wish to limit where the NTP client can get its updates. (Broadcast packets are not forwarded to other subnets whereas multicast packets are).

#
# /etc/inet/ntp.client
#
# An example file that could be copied over to /etc/inet/ntp.conf; it
# provides a configuration for a host that passively waits for a server
# to provide NTP packets on the ntp multicast net.
#

multicastclient 224.0.1.1


2. Start the xntpd daemon

# /usr/lib/inet/xntpd -m &


(We start the xntpd daemon with the -m argument to listen for multicast packets if you were using broadcast as a method of receiving NTP updates you would use -b as the argument)
4. Using the ntpdate command.

CODE:
The ntpdate utility sets the local date and time. To determine the correct time, it polls the Network Time Protocol (NTP) servers on the hosts given as arguments. This utility must be run as root on the local host. It obtains a number of samples from each of the servers and applies the standard NTP clock filter and selection algorithms to select the best of these.

It can be run on a regular basis from cron(1M) as an alternative to running a daemon. Doing so once every one to two hours will result in precise enough timekeeping to avoid stepping the clock. If you're are already running the xntpd daemon you can't use the ntpdate command. Trying to do so will generate the following error :

# ntpdate champ
23 Sep 14:55:52 ntpdate[19780]: the NTP socket is in use, exiting


You must also be root user to run the ntpdate command or you will see an error like this returned:

% ntpdate champ
23 Sep 14:44:36 ntpdate[19743]: bind() fails: Permission denied


In this example we specify the ntp server "jedi" to sync with.

# ntpdate jedi
23 Sep 17:12:21 ntpdate[20963]: adjust time server 129.148.192.147 offset 0.001422 sec
5. Using the ntpq command

CODE:
ntpq queries NTP servers which implement the recommended NTP mode 6 control message format, about current state. It can also request changes in that state. The program can be run in interactive mode; or it can be controlled using command line arguments. Requests to read and write arbitrary variables can be assembled, with raw and pretty-printed output options available. By sending multiple queries to the server, ntpq can also obtain and print a list of peers in a common format.

To query an NTP server for a list of its peers:

# ntpq -p jedi
    remote           refid      st t when poll reach   delay   offset    disp
==============================================================================
*eastpager1.East dollar.East.Sun  3 u   97   64  376     2.03    4.564    2.33
LOCAL(0)        LOCAL(0)         5 l   19   64  377     0.00    0.000   10.01
NTP.MCAST.NET   0.0.0.0         16 -    -   64    0     0.00    0.000 16000.0
255.255.255.255 0.0.0.0         16 -    -   64    0     0.00    0.000 16000.0
+sunswe.Sweden.S carbon.UK.Sun.C  3 u   48   64  377   156.80    6.367    0.41
+canadamail1.Can franc.East.Sun.  3 u   12   64  377    29.48   13.528   29.65
-cosmo.Eng.Sun.C rolex.East.Sun.  2 u   98  128  377    84.08   -1.069    0.87
-centralpager1.C venus.EBay.Sun.  3 u   41  128  377    68.73  -19.219    6.70


remote - is the remote peer

refid - is the host that the peer is synchronizing to

st - stratum number

t - type i.e. unicast, mulitcast, or local (a "-" equals don't know)

poll - polling interval in secs

reach - reachability register

* in remote indicates currently selected peer

+ means that the host is an acceptable peer for synchronization but not accepted

- not acceptable
6. Some useful debugging

CODE:
When using "server" mode (association) it is advisable to have at least 3 different servers listed in the ntp.conf file. If the servers that you are configuring are out on the Internet and you have a firewall set up, you will want to make sure that there is a rule on the firewall that allows port 123 NTP traffic in and out from your NTP server. It will normally take about 5 minutes or more for your NTP server to become synchronized with the time servers listed in the ntp.conf. Until you become synchronized you will not start sending out broadcast/multicast NTP packets to other NTP clients. Normally these packets are sent every 64 seconds. Both xntpd and ntpdate have debug options but be aware that if you use ntpdate -d it will only "go through the motions" and not actually poll the network.

In this example we are using the ntp.client for ntp.conf and have turned on xntpd -d

# /usr/lib/inet/xntpd -d &
20743
# Solaris tick = 10000
kernel vars: tickadj = 625, tick = 10000
adj_precision = 1, tvu_maxslew = 61875, tsf_maxslew = 0.0fd70a37
create_sockets(123)
bind() fd 19, family 2, port 123, addr 00000000, flags=1
bind() fd 20, family 2, port 123, addr 7f000001, flags=0
bind() fd 21, family 2, port 123, addr 8194c097, flags=1
init_io: maxactivefd 21
report_event: system event 'event_restart' (0x01) status 'sync_alarm, sync_unspec,
1 event, event_unspec' (0xc010)
input_handler: fd=19 length 48 from 8194c093 129.148.192.147
input_handler: fd=19 length 48 from 8194c093 129.148.192.147
input_handler: fd=19 length 48 from 8194c093 129.148.192.147
input_handler: fd=19 length 48 from 8194c093 129.148.192.147
input_handler: fd=19 length 48 from 8194c093 129.148.192.147
input_handler: fd=19 length 48 from 8194c093 129.148.192.147
input_handler: fd=19 length 48 from 8194c093 129.148.192.147

(129.148.192.147 is the host "jedi")


And at the same time we started snooping the ntp client on port 123 (ntp) we are expecting to see either multicast or broadcast NTP packets.

# snoop -d le0 port 123
Using device /dev/le (promiscuous mode)
slave-192-1 -> NTP.MCAST.NET NTP  broadcast (Thu Sep 23 16:42:15 1999)
       champ -> NTP.MCAST.NET NTP  broadcast (Thu Sep 23 16:42:46 1999)
        jedi -> NTP.MCAST.NET NTP  broadcast (Thu Sep 23 16:42:49 1999)
        jedi -> BROADCAST     NTP  broadcast (Thu Sep 23 16:42:50 1999)
slave-192-1 -> NTP.MCAST.NET NTP  broadcast (Thu Sep 23 16:43:19 1999)
       champ -> NTP.MCAST.NET NTP  broadcast (Thu Sep 23 16:43:50 1999)
        jedi -> NTP.MCAST.NET NTP  broadcast (Thu Sep 23 16:43:53 1999)
        jedi -> BROADCAST     NTP  broadcast (Thu Sep 23 16:43:54 1999)
slave-192-1 -> NTP.MCAST.NET NTP  broadcast (Thu Sep 23 16:44:23 1999)
7. Known Bugs

CODE:
4060650  xntpd loops continuously burning cpu and leaking memory rendering
         m/c unuseable

4097366  external clock hardware isn't supported by xntpd

4192098  xntpd does not synchronize with "c011 sync_alarm" on a few Ultra 5 systems

4130698  ntp installation / upgrade instructions for Solaris 2.6

4061948  SPARC only: 2.5.1 SUNWxntp Package Is Incompatible With Solaris 2.6
8. Additional resources for NTP

CODE:
NTP project web site:

NTP RFC:
阅读(7293) | 评论(0) | 转发(2) |
给主人留下些什么吧!~~