Sun Blueprints (816-1475) - Using NTP to Control and Synchronize System Clocks - Part I,...

8/6/2019 Sun Blueprints (816-1475) - Using NTP to Control and Synchronize System Clocks - Part I, Introduction to

http://slidepdf.com/reader/full/sun-blueprints-816-1475-using-ntp-to-control-and-synchronize-system-clocks 1/20



Please

Recycle

Copyright 2001 Sun Microsystems, Inc. 901San Antonio Road, Palo Alto, California 94303 U.S.A. All rights reserved.

This prod uct or docum ent is protected by copyrigh t and distributed und er licenses restricting its use, copying, distribution, and d ecompilation.

No part of this produ ct or documen t may be reprod uced in any form by any means without pr ior written authorization of Sun and its licensors,

if any.Third -party software, including font technology,is copyrigh ted and licensed from Sun sup pliers.

Parts of the prod uct may be derived from Berkeley BSD systems, licensed from the University of California. UNIXis a registered tradem ark in

the U.S. and other countries, exclusively licensed through X/ Open Comp any,Ltd .

Sun, Sun Microsystems, the Sun logo, Sun BluePrints, Sun Enterp rise, and Solaris are tradem arks, registered trad emarks, or service marks of

Sun Microsystems, Inc.in the U.S. and other countries.

The OPEN LOOK and Sun™ Graph ical User Interface was developed by Sun Microsystems,Inc. for its users and licensees.Sun acknow ledges

the pioneering efforts ofXerox in researching and d eveloping the concept of visual or graphical user interfaces for the compu ter industry. Sun

hold s a non -exclusive license from Xerox to the Xerox Graph ical User Interface, wh ich license also covers Sun ’s licensees who imp lemen t OPEN

LOOK GUIs and oth erwise comply with Sun’s written license agreements.

RESTRICTED RIG HTS : Use, du plication, or disclosu re by the U.S. Govern men t is subject to restrictions of FAR 52.227-14(g)(2)(6/ 87)a nd

FAR 52.227-19(6/ 87), or D FAR 252.227-7015(b)(6/ 95) and D FAR 227.7202-3(a).

DOCUMENTATION IS PROVIDED “AS IS” AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES,

INCLUD ING AN Y IMPLIED WARRANTY OF MERCHAN TABILITY, FITNESS FOR A PARTICULAR PURPO SE OR NON -

INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID.

Copyright 2001 Sun Microsystems, Inc.,901 San Antonio Road, Palo Alto, Californie 94303Etats-Unis. Tous droits réservés.

Ce produit ou docum ent est protégé par un copyrigh t et distribué avec des licences qui en restreignent l’utilisation, la copie, la distribution, et la

décomp ilation.Au cune partie de ce produit ou documen t ne peu t être reprod uite sous aucun e forme, par quelqu e moyen que ce soit, sans

l’autorisation p réalable et écrite de Sun et de ses bailleurs de licence, s’il y en a. Le logicield étenu p ar des tiers, et qui compren d la technologie

relative aux polices de caractères,est p rotégé par u n copyright et licencié par d es fournisseurs de Sun .

Des parties de ce produ it pourron t être dérivées des systèmes Berkeley BSD licenciés par l’Université de Californie.UN IXest une m arque

dép osée aux Etats-Unis et dans d’autres pays et licenciée exclusivemen t par X/ Open Comp any,Ltd .

Sun, Sun Microsystems, le logo Sun, Sun BluePrints, Sun Enterpirse, et Solaris sont des marques de fabrique ou des marques déposées, ou

marqu es de service,d e Sun Microsystems, Inc. aux Etats-Unis et dan s d’autres pays.

L’interface d’utilisation graphiqu e OPEN LOOKet Sun™ a été développée pa r Sun Microsystems, Inc.p our ses utilisateurs et licenciés. Sun

reconnaît les efforts de pionn iers de Xerox pour la recherche et le développem ent du concept des interfaces d’utilisation visuelle ou grap hique

pou r l’indu strie de l’informatiqu e. Sun détient u ne licence non exclusive d e Xerox sur l’interface d’utilisation grap hique Xerox,cette licencecouvran t également les licenciés de Sun qu i mettent en place l’interface d’utilisation grap hique OPEN LOOK et qui en outre se conforment aux

licences écrites de Sun.

CETTE PUBLICATION EST FOURN IE "EN L’ETAT" ET AUCUN E GARANTIE, EXPRESSE OU IMPLICITE, N’EST ACCO RDEE, YCOMPRIS

DES GARANTIES CONC ERNANT LA VALEUR MARCHANDE, L’APTITUDE DE LA PUBLICATION A REPON DRE A UNE UTILISATION

PARTICULIERE, OU LE FAIT QU’ELLE NE SOIT PAS CONTREFAISANTE DE P RODUIT DE TIERS. CE DENI DE GARAN TIE NE

S’APPLIQUERAIT PAS, DANS LA MESURE OU IL SERAIT TENU JURIDIQUEMENT NUL ET NON AVENU.



Introduction 1

Using NTP to Control and SynchronizeSystem Clocks - Part I:Introduction to NTP

This is Part 1 of a three-article series that discusses how to u se Netw ork Time Protocol

(NTP) to synchronize system clocks. This article sets the stage by ou tlining wh y time

synchronization is important and explaining the various components of the NTP

distribution. This article introduces the basic concepts of NTP, and also sets expectations

for the accuracy, security, and resource needs of an NTP installation. This article will be

most useful for system managers and anyone who is either unfamiliar with NTP or

un convinced of the value of time synchronization, but it does cover some aspects of NTP

that m ay be u nfamilar even to experienced system ad ministrators. The later articles in

the series will provide technical information for implemen ting, architecting, m anaging,

and troubleshooting NTP installations. Throughou t the series, emp hasis is placed on

architecting a well-plann ed, secure, efficient, and accurate NTP solution.

Part 2 of the series will cover N TP client and server ad ministration, access control,

auth entication, and architectural p rinciples for a su ccessful N TP infrastructure.

Introduction

The need for synchronized time is critical for today’s network en vironments. As

organizations grow an d th e network services they provide continue to increase, the

challenges involved w ith providing a ccurate time to their systems an d a pp lications also

increase. Every aspect of managing, securing, planning, and debu gging a netw ork

involves determining w hen even ts hap pen . Time is the critical element th at allows anevent on one network node to be mapped to a corresponding event on another. In many

cases, these challenges can be overcome by th e enterprise d eployment of the NTP

service.



2 Using NTP to Control and Synchronize System Clocks - Part I: Introduction to NTP • July 2001

Time in a Networked EnvironmentElectronic clocks in most servers and network ing d evices keep inaccurate time. One

of several reasons for this is that d esigning a compu ter to keep accurate time is

rarely a priority for compu ter man ufacturers because it add s cost and comp lexity.

How ever, even fairly accurate comp uter clocks are likely to vary du e to

man ufacturing d efects, changes in tem peratu re, electric and magn etic interference,

the age of the oscillator, or even compu ter load. Ad ditionally, even th e sma llest

errors in keeping time can significantly ad d u p over a long p eriod. Consider two

clocks that are synchron ized at th e beginning of the y ear, but one consistently takes

an extra .04 milliseconds to increment itself by a second. By the end of a year, the

two clocks will differ in time by more than 20 minutes. If a clock is off by just 10

parts p er million, it will gain or lose almost a second a day. These m easures are

actually fairly optimistic examp les of the accuracy of some of the clocks in mod ern

workstations an d PCs. The typ es of inaccuracies that exist in compu ter clocks are

difficult to classify. Some clock variations are random, caused by environmental or

electronic variations, others are systematic, caused by a miscalibrated clock.

Clearly, having any sort of mean ingful time synchronization is alm ost imp ossible if

clocks are allowed to run on their ow n. In some environm ents, this lack of

synchronization isn’t a big issue. How ever, in most mod ern netw orked comp uting

environmen ts, time syn chronization is important. To redu ce confusion in shared

filesystems, it is crucial for the modification times to be consistent, regardless of

wh at m achine the filesystems are on . Billing services and similar ap plications m ust

know the time accurately. Some financial services even require highly a ccurate time-

keeping by law. Sorting email and oth er network comm un ications can also be

difficult if time stamps are incorrect. In addition, tracking security breaches, network usage, or problems affecting a large nu mber of compon ents can be nearly imp ossible

if time stamps in logs are inaccurate. Time is often the critical factor in separating

cause from effect.

Applications such as cyptographic key management and secure document

transmission may require using accurate, encoded time stamps which match

un encoded time stamp s to help assure d ocument au thenticity. For instance, secure

RPC needs clocks to be syn ced to w ithin 15 seconds for p roper op eration. In

add ition, interactions with dy nam ic events such as stock market trad es, aviation

management, and radio and TV programming, require careful synchronization of

time.

As with an y complex problem th at is important in a wide variety of circum stances, a

nu mber of poten tial solutions to the time synchronization p roblem exist. There areseveral UNIX® comm and s for setting an d syn chronizing time, as shown in TABLE 1.

In ad dition, there are several other time synchronization p rotocols, including Digital

Time Service (alternately known as DTS or DTSS). Many other synchronization

protocols and their relative merits are discussed in detail in RFC1305, which defines



An Overview of NTP 3

the N TP version 3 specification. Other time protocols have influenced th e evolution

of NTP, including rdate and DTS. The procedu re for determ ining offsets evolved

from a model used by telephone comp anies to synchronize time. NTP builds on thelegacy an d research efforts of these other p rotocols, which makes it a very robu st

and mature technology.

NTP is a good choice for time synchronization in a variety of circum stances. Other

schemes, such as DTS, are designed primar ily for local area networks, w hile NTP is

designed specifically for Internet environments. Although a nu mber of UNIX

commands provide setting or synchronizing time, they don’t have the accuracy and

robust feature set present in NTP. Flexibility of the client/ server relationship and

security methods allow N TP to work well in almost any environm ent. NTP not only

corrects the current time, it can keep track of consistent time v ariations a nd

automatically adjust for time drift on the client. This allows for less network traffic

and keeps client clocks m ore stable, even if the netw ork is un available. In ad dition,the NTP d aemon can autom atically adjust th e time at periodic increments. NTP can

also operate through firewalls and has a nu mber of security features.

In add ition, NTP operates on a w ide variety of platforms. Simp le Network Time

Protocol (SNTP) is a lightweight va riation of NTP w hich is compatab le with N TP

and popular on wintel machines. Since many platforms and networking devices

support one or both of these protocols, NTP can be easily standardized throughout

an enterprise.

An Overview of NTPContrary to p opu lar belief, NTP is not based on the p rinciples of synchronizing

machines w ith each other. NTP is based on the pr inciples of having all machines get

as close as possible to th e correct time. The effects may be sim ilar, but th is is a subtle

TABLE 1 Common UNIX Commands Related to Time

Command Description

date Displays or sets the current system d ate and time

rdate Sets the current system time from a remote host using the date

protocol (see RFC 868)

adjtime() Adjusts th e system’s time of d ay clock gradu ally, to a sp ecified

value

settimeofday() Sets the system’s time of day clock instantly to a sp ecified v alue

ntpdate Sets the current systems clock from a remote NTP server

xntpd NTP daemon




but imp ortant d istinction. The NTP algorithms an d th e structure of an NTP

architecture clearly reflect this distinction. In addition, some of the behaviors of NTP

app lications can only be un derstood by keeping this d istinction in mind. Forinstance, if two N TP servers are synchronized to each other as peers, wha t actually

hap pen s is the clocks decide amon g them selves which is the better source of time,

and both clocks attemp t to synchronize to that. The result is that the peer th at is

actually serving th e time could change amon g the clocks as their accuracy changes.

At the top of any N TP hierarchy a re one or m ore reference clocks. These are

electronic clocks synchronized to a comm on time reference and each other u sing

some m ethods outside the scope of NTP, for instance GPS signals, radio signals, or

extremely accurate frequency control. Reference clocks are assum ed to be accurate.

The accuracy of other clocks is judged according to how “close” a clock is to a

reference clock (the stratum of the clock, as d escribed below), the n etwork latency to

the clock, and the claimed accuracy of the clock.

The pu blic NTP servers available on the Internet use Coord inated Un iversal Time(abbreviated as UTC, which d oes not stand for anything) as the u ltimate sou rce of

time. UTC evolved from Greenwich Mean Time (GMT), and still uses the Greenwich

time zone as the zero offset. GMT is based on the earth’s rotation, wh ich is not

constant enough to be used for detailed time measurements. UTC is based on a

standard second length determined by the quantu m p henomena. Time zones and

Daylight Savings Time don’t exist as far as NTP is concerned. Time is synchronized

according to time zone neutral time (as in GMT), and then th e time is projected to

the time zone u sing the time zone en vironment v ariable (TZ), which can be set in

/etc/default/init. The p ossible nam es for the time zones are the sam e as the

paths to files contained under /usr/share/lib/zoneinfo. For instance, setting

the time zone for a machine to East Newfoundland time can be accomplished by

looking under /usr/share/lib/zoneinfo for the app ropriate timezone, and then

setting th e TZ variable to that valu e in /etc/default/init as follows:

Time zones for individu al users can be chang ed by setting th e TZ variable in their

profiles.

In environments tha t need m ore accurate time than an Internet link will allow (due

to latency or other concerns), or environments th at cannot rely on Internet time

sources du e to security imp lications, a ra dio time clock or GPS system (or cesium

clock, if you h app en to have on e lying arou nd ), can be used to keep the p rimary

NTP servers aligned w ith UTC. Synchronizing a few m achines to an arbitrary time

source, such as the internal clock on a given server, may be a cceptable in a few rare

cases, but in any so rt of large insta llation it is critical to keep the clocks synchron ized

with some m aintained time stand ard. Regardless of the configuration, an NTP server

needs to b e set up in order for clients to u se it for synchronization.

TZ=Canada/East-Newfoundland




Networking and Strata

NTP uses the UDP p rotocol on p ort 123 to comm un icate between clients and servers.

Attempts are tried at d esignated intervals until the server respond s. The interval

dep end s on a num ber of factors, and ranges from about once a minute to once every

17 minu tes. Using UDP prevents retries from u sing up network b and wid th if a time

server with a large num ber of clients goes dow n.

NTP works on a hierarchical mod el in w hich a small num ber of servers give time to

a large nu mber of clients. The clients on each level, or stratu m, are in tu rn, poten tial

servers to an even larger nu mber of clients of a higher nu mbered stratum . Stratum

nu mbers increase from the prim ary (stratum 1) servers to the low nu mbered strata at

the leaves of the tree. Clients can use time information from mu ltiple servers to

autom atically d etermine the best source of time and prevent bad time sources from

corrupting their own time. FIGURE 1 illustrates the h ierarchical strata mod el of

servers used in NTP.FIGURE 1 NTP Strata

Servers that are directly connected to a reference clock are termed stratum 1 servers.

A reference clock connected to a stratum 1 server is referred to as a stratum 0 server.

Clients never comm un icate directly with a stratu m 0 server; they always go th rough

a stratum 1 server synchronized to a stratum 0 server. However, some ven dors sell

reference clocks (stratum 0 servers) which includ e an external network interface that

acts as a stratu m 1 server. Regardless of the source of time for a server, it is

importan t to remem ber that the accuracy of these time signals can vary w idely. Just

because a server is a stratum 1 server does not n ecessarily mean it has accurate time.

In fact, a stratum 1 server could ev en be configured to u se its own poorly run ning

internal clock as a reference clock. This is why it is very imp ortant to use m ultipletime sources and verify time sources before using them.

Stratum 0(ref clock)

Stratum 1

Stratum 2

Stratum 3




Clients of stratum 1 servers are referred to as stratu m 2 clients. If they serve time to

clients, they are also referred to as stratum 2 servers, and th e clients they serve are

stratum 3 clients. This continu es to higher nu mbered strata. The m aximum NTPstratum nu mber for a client is 15; how ever, in p ractice it is rare to find clients with

stratum nu mbers above 4 or 5 in most real-world configura tions. According to a

survey of NTP servers d one by David Mills, more tha n h alf of the Internet-connected

NTP clients are in stratu m 3, with almost all the remaind er in strata 2 an d 4. It is

usually best to follow this sort of a distribution in an NTP environment, as described

in the next paragraph.

Because of the difficulty of setting up a reliable reference clock, administrators

generally want to limit the nu mber of stratum 1 servers, or use p ublicly available

servers (when feasible). Organizations setup pu blic NTP servers as a p ublic service.

Setting up a large num ber of clients to use p ublic external servers is a poor u se of

their generosity (and computing resources), so it is best to have a few servers receive

accurate time read ings from the Internet or a WAN, and then u se each of these

stratum 2 or 3 servers in localized areas (a campus or LAN). All the clients at the site

can then receive upd ates from the stratum 2 or 3 servers at the site.

An alternative to using a p ublic stratum 1 server is to use a p ublic stratum 2 server.

In man y cases, pu blic stratum 2 servers are well synced to a set of accurate stratum

1 servers. Syncing to several accurate servers minimizes the chances of the server

becoming un synced. Using an accurate stratum 2 server wh ich is synced to several

time sources may allow for better accuracy than using an overloaded or inaccurate

stratum 1 server that is not configured to commu nicate with other time sources.

Selecting an NTP source requires careful consideration of accuracy and reliability.

The process of making this choice is described further in th e second ar ticle of this

series.

Resource Requiremen ts

NTP requires little resource overhead. This allows N TP to be easily deployed on

servers hosting other services, even if the servers are heavily loaded. Even a single

processor NTP server can serve hundreds or even thousands of clients using only a

few percent of its CPU capacity. If the server is a broadcast or multicast server, even

fewer resources are required.

The bandw idth requ irements for NTP are also minimal. Unencrypted NTP Ethernet

packets are 90 bytes long (76 bytes long at the IP layer). A broadcast server sends out

a p acket about every 64 seconds. A non -broadcast client/ server requires 2 packets

per tran saction. When first started, transactions occur a bout on ce per minu te,

increasing gradually to once per 17 minutes under normal conditions. Poorlysynchronized clients will tend to p oll more often th an w ell synchronized clients. In

NTP version 4 implementations, the minimum and maximum intervals can be

extended beyond these limits, if necessary.




Types of Clients and Servers

The relationship betw een N TP servers and clients can be configured to op erate in

several ways. Compu ters using N TP can op erate in different mod es with respect to

different m achines. For instance, a single ma chine could b e a client of a m achine

with a lower stratum n um ber, wh ile being a peer to a machine on the same stratum,

and a broadcast server to a number of clients at a higher stratum number.

s Serv er – An N TP server serves time to clients. Clients send a request to the server

and the server sends back a time stamped response, along with information such

as its accuracy and stratum.

s Client – An N TP client gets time responses from an NTP server or servers, and

uses the information to calibrate its clock. This consists of the client determining

how far its clock is off and adjusting its time to m atch that of the server. The

maximum error is determined based on the round-trip time for the packet to be

received.s Peer – An N TP peer is a member of a group of NTP servers that are tightly

coupled. In a group of two peers, at any given time, the most accurate p eer is

acting as a server and the other p eers are acting as clients. The result is that p eer

group s will have closely synchronized times w ithout requ iring a single server to

be specified.

s Broadcast/multicast server – An N TP server can also operate in a broad cast or

mu lticast mod e. Both w ork similarly; broadcast servers send periodic time

updates to a broadcast address, while multicast servers send periodic updates to

a multicast address. Using broadcast packets can greatly reduce the NTP traffic on

a netw ork, especially for a netw ork w ith man y NTP clients.

s Broadcast/multicast client – An NTP broadcast or multicast client listens for NTP

packets on a broad cast or mu lticast add ress. When the first packet is received, it

attemp ts to quan tify the d elay to the server in order to better qu antify the correct

time from later broad casts. This is accomp lished by a series of brief interchang es

wh ere the client an d server act as a regular (non-broadcast) NTP client and server.

Once these interchanges occur, the client has an idea of the netw ork d elay and

thereafter can estimate th e time based only on broadcast p ackets. If this

interchang e is not desirable, it can be disabled u sing N TP’s access control

features. The -r option can be used when xntpd is started to h ardw ire a delay if

the interchange fails because of access control issues or other problems.

Accuracy and Resolu tion

NTP may take several minu tes or even hou rs to adjust a system’s time to theultimate d egree of accuracy. There are several reasons for this. NTP averag es the

results of several time exchanges in order to reduce the effects of variable latency, so

it may take several minutes for NTP to even reach consensu s on wh at the average

latency is. Generally this ha pp ens in abou t 5 minu tes. In ad dition, It often takes






Because most custom ers do n ot need to force slewing to always occur in lieu of

stepping, and because slewing large time differences can lead to a n um ber of

problems, we suggest customers upgrade to the new patch as soon as it is available.

The degree of synchronization to a server is dependent primarily on network

latency. The accuracy of NTP thus d epend s on the n etwork en vironment. Because

NTP u ses UDP pa ckets, traffic congestion could tempora rily p revent

synchronization, but the client can still self-adjust, based on its historic drift.

Under good conditions on a LAN without too many routers or other sources of

network delay, synchronization to within a few milliseconds is norma l. Anything

that ad ds latency, such as hu bs, switches, routers, or n etwork traffic, will reduce this

accuracy. The synchronization accuracy on a WAN is typ ically within th e rang e of

10-100 ms. For the Internet, synchronization a ccuracy is un pred ictable, so special

attention is needed w hen configuring a client to use pu blic NTP servers.

If synchronization accuracies better than the above estimates are required, there areseveral options for obtaining even higher synchron ization accuracy:

s Connecting directly to a reference clock – If a server is attached directly to a reference

clock, the accuracy is limited on ly by th e accuracy of the reference clock an d the

hard ware an d software latencies involved in the connections to it.

s Pulse Per Second (PPS) – Clocks can use PPS radio receivers, which receive on-the-

second rad io pulses from a national stand ards organ ization. If the time is within a

fraction of a second, the PPS pu lses can b e used to precisely synchronize to the

tick of the second. This method achieves accuracies in the tens of m icrosecond

range.

s Precision time kernel – The Solaris OE has a p recision time kern el that allows th e

kernel clock to be up dated to microsecond resolution (thoug h n ot necessarily

microsecond accuracy). By d efault, the precision time kern el is used by th e

versions of NTP w hich are included with the Solaris OE. Precision time kernels

are d efined in RFC 1589.

The maximum resolution of an N TP time stam p is abou t 200 picoseconds (about the

time it takes an electrical pulse to travel throu gh 2 cm of copp er w ire), so the

ultimate accuracy of NTP is likely to be limited by hard ware an d latency concerns,

rather than by the NTP protocol.

The important th ing to remember is that N TP accuracy is always limited by th e time

source. A client synced to an inaccurate server, will be inaccurate. This d epend ency

is true all the way up the chain to the reference clock. If the reference clock is

miscalibrated, all the clients will be affected.





NTP components 11

instead of xntpd is discouraged, for reasons d iscussed below. In add ition, this

section discusses how th e ntpq, xntpdc, and ntptrace commands can be used to

monitor and control NTP clients and servers.

xntpd

The xntpd process is the NTP daem on. The same d aemon is used both for client and

server. The file /etc/inet/ntp.conf configures the NTP servers a nd clients. The

adv anced op tions enable access control, auth entication, monitoring, remote

management, and better time approximation.

In systems ru nning default installations of Solaris OE versions 2.6 and later, the

daem on is started au tomatically on startup by the /etc/init.d/xntpd file (which

is linked to from /etc/rc2.d/S74xntpd) if the ntp.conf file exists. In defau lt

installations, the ntp.conf file does not exist, so the d aemon never starts. Aconfiguration can b e created from scratch or copied from th e ntp.servers or

ntp.clients files in the same directory. Because the ntp.servers an d

ntp.clients files d o not incorporate any auth entication or access control, it is

recommend ed to follow the examp les in th is article instead.

If the configuration is changed , the daemon will need to be stopped and restarted in

order to update the configuration without rebooting. The xntpd process can be

started or restarted at an y time, and is located at /usr/lib/inet/xntpd.

Alternatively, the /etc/init.d/xntpd file can be ru n w ith the start or stop

options. Keep in mind that changes made to the startup files could be removed by

later up grades or p atches.

While most of the configura tion is taken care of by the ntp.conf file, there are a

few command flags (described in the xntpd man page). While the comman d flags

allow easy configuration from the comm and line, using them is discouraged ,

because the sam e can be accomplished u sing the configuration file. The ad vantage of

using the configuration file is th at all the configuration information is easily

determ ined if troubleshooting is n ecessary. TABLE 2 describes these files.

TABLE 2 NTP-Related Files

Default Location Description

/etc/inet/ntp.conf NTP configuration file

/etc/inet/ntp.client A preset m ulticast client file that can be copied over to

ntp.conf

/etc/inet/ntp.server A template server file that can be copied over tontp.conf and modified

/etc/inet/ntp.drift xntpd drift file

/etc/inet/ntp.keys xntpd auten tication k eys file




The xntpd process can commu nicate both time and configuration information. If

enabled, this allows th e configura tion for xntpd to be queried or chan ged rem otely.

There are two d ifferent typ es of configuration messages w hich can be sent: mode 6

messages and mode 7 messages. Mode 6 messages are sent by the ntpq program

and most m ode 6 messages are informational. The others deal with setting variables.

Mode 7 messages are sent by the xntpdc program. Mode 7 messages can be

informational or can allow remote chan ging of the N TP configuration.

ntpdate

The ntpdate program allows a client to set its date from an N TP server without

perm anently ru nning th e NTP daem on. Multiple servers can also be specified to

allow a better selection for the best time source. Essentially, this allows a one-shot

NTP transaction. Because this interaction only occurs once, the clock will eventually

stray again. Repeated usage of ntpdate can overcome this, but is far from an id eal

solution.

Some system administrators run an ntpdate comman d on an h ourly, daily, or

weekly basis as a cron job, which is capable of keeping servers in sync within a few

seconds. This light-weight solution is useful in some environmen ts because itrequires one less daem on, gives the ad ministrator more control over N TP traffic, and

is easy to configure. However, in nearly all cases, the problems are likely to

outw eigh the benefits.

The processor load of the NTP daemon is small, so little is gained by disabling it. In

add ition, many clients run cron jobs simultaneously, which causes blasts of network

traffic for ev ery cron job in the span of a few seconds. This is likely to overw helm

the netw ork, and p ossibly even the server (if the server is small and has a large

nu mber of clients).

The client-side xntpd process randomizes the delay before a time request is made,

so that this overw helming d oes not occur. Since both the ntpdate cron job and the

NTP daem on are simple to configure, there is no clear man agement ad vantage to

either.

A final advantage of xntpd over ntpdate is that it produ ces a much better time

sync. This is du e to several facts. Unlike ntpdate, xntpd can limit the wander of

the clock based on historical data—even w hen a time server is unav ailable. The

no default log file

/var/ntp/ntpstats directory for NTP statistics files (if used)

no d efault pid file

TABLE 2 NTP-Related Files (Continued)

Default Location Description



NTP components 13

xntpd process does time ad justm ent continuou sly, so the changes to the time can be

very small, so it rarely needs to u se the time jumps that are likely to occur wh en

ntpdate is run. An example of the relative accuracies of using xntpd or runningntpdate on an hourly basis is shown in FIGURE 3.

FIGURE 3 Time A ccuracy With xntpd an d ntpdate Run From cron

ntpq

The /usr/sbin/ntpq program allows querying the state of the NTP daemon on a

local or rem ote machine. Using ntpq, an ad ministrator can check the configuration

of a remote host. If such queries are allowed on a host, this can be a useful w ay of

choosing hosts to synchronize with, because information such as th eir peers and

reference clock types can be determ ined. Since ntpq uses UDP packets, hosts may

be falsely unreachable on congested n etworks.

xntpdc

The /usr/sbin/xntpdc program also allows qu erying the state of a local or remote

NTP daemon, however, xntpdc can also make run time configuration requests to a

remote m achine. This allows changing the configuration on th e fly. In ord er to m ake

run time configuration changes, an au thentication key is need ed. This requires the

creation of an NTP keys file, which is described in the xntpd man page. Like ntpq,

xntpdc uses UDP packets.

Note – The xntpdc program is not included with the NTP implementations which

come with Solaris OE versions 2.6 and 7.

T i m e O f f s e t ( m s )

Time (min)

xntpd

ntpdate (run from a cron job)





NTP Versions and Issues 15

There are a nu mber of d ifferent versions of NTP av ailable, which can be qu ite

confusing to an NTP ad ministrator. This section outlines some of the more recent

versions available. This section also h ighlights a few bu gs and issues that u sersshould be aware of. NTP is available as open sou rce from http://www.ntp.org.

The versions includ ed in the Solaris OE are derived from v ersions of the open source

NTP. The map ping of open source versions to Solaris OE versions is explained in

TABLE 3. The p rimary version n um ber indicates the specification version and the

subsequent numbers indicate the software version. Note that all current versions

includ ed with Solaris OE use the NTP version 3 sp ecifications.

The NTP versions shipp ed w ith the Solaris OE are very similar to the op en source

versions available on the Solaris OE. The v ersions includ ed with Solaris OE have

some m inor, Solaris OE specific modifications. In gen eral, these m od ifications do n ot

affect any u ser-visible features. In add ition, the versions includ ed with Solaris OE

only includ e the core NTP app lications and not the u tilities that come along w ith the

open sou rce version. Sun sup ports the included NTP versions on each OS version.

No other N TP versions are sup ported by Sun. The lack of Sun sup port d oesn’t mean

a version won ’t work, it simp ly means that Sun isn’t obligated to sup port it as part

of a standard service contract. Many custom ers use NTP versions other than the

includ ed ones (particularly NTP v4), and simply sup port them locally or through the

open source community.

The History of NTP on Solaris OE

Prior to Solaris OE 2.5.1, NTP w as not included in the d istribution an d had to be

obtained separately. The first inclusion of N TP with th e OS was in the Solaris OE

2.5.1 Hard ware release 4/ 97, but Sun only su pp orted u sing this NTP version on the

Sun Ente rp rise™ 10000 server. In this version o f NTP, dosyncdr in the /etc/

system file had to be m anu ally set to 0 (1 is the default).

Setting dosyncdr is unn ecessary (and will cause p roblems) for later versions.

Occasionally this problem pop s up wh en customers come across out-of-date

configuration gu ides. For versions o f Solaris OE 2.6 and later, setting dosyncdr to 0

will prevent N TP from working. Since dosyncdr is 1 by default, no /etc/system

TABLE 3 Solaris NTP Versions

Solaris OE version Approximate Open Source NTP version included

pre 2.5.1 None

2.5.1 N TP 3.2 (suppor ted on U lt ra En terp rise 10000 only )

2.6 NTP 3.4y, not including xntpdc

7 NTP 3.4y, not including xntpdc

8 NTP 3-5.93e




changes need to be m ade for NTP versions included in Solaris OE 2.6 and later. The

dosyncdr change is un necessary in 2.6 and later because th e hard ware clock is

autom atically set w hen the software clock is set.

In Solaris OE 2.6 and 7, Sun includ ed an NTP version wh ich w as sup ported on all

platforms. The new NTP also add ed su pp ort for multicasting. The includ ed version

was a slightly mod ified version of the p ublic dom ain d istribution of NTP 3.4y. This

version includ ed xntpd, ntpdate, ntptrace, and ntpq. Notably absent, was

xntpdc.

In the Solaris OE 2.6 version of NTP, a race condition exists between the NTP

daemon and the name service caching daemon (nscd). This problem has a low

probability of occurring, and only occurs at boot time if name resolution is needed in

th e ntp.conf file and if nscd was used . If this problem d oes occur, it could cau se

xntpd to use v ery large amou nts of CPU and affect other processes. Because this

problem h as a low probability of occurring even if all the cond itions existed, some

systems ru nning Solaris OE 2.6 could be susceptible withou t anyon e realizing it. Theworkaround is to load xntpd after nscd (move /etc/rc2.d/S74xntpd to

/etc/rc2.d/S77xntpd), or to avoid u sing host nam es in the ntp.conf file. This

problem was fixed in the Solaris OE 7 version of NTP.

In Solaris 8 OE, the includ ed version is a slightly mod ified version of the op en

source distribution of NTP 3-5.93e. This version included xntpdc.

Conclusion

NTP provid es an excellent means of keeping a large num ber of nodes in closesynchronization. An effectively d esigned N TP infrastructure can accomplish this

with a minimu m of network overhead and can also maintain a high level of accuracy

and security. In ad dition, NTP solutions are relatively easy to architect and

implement, making them ideal for everything from a small business to wide area

enterprise dep loyments. The clock synchronization afforded by NTP can be u seful

for a variety of pu rposes, including keep ing time stamps on d ifferent network n odes

in sync, wh ich enables easier network and security troubleshooting.

Later articles in this series will be focused on a technical level and will explain how

to configure, architect, and troubleshoot N TP installations.





Author’s Bio: David Deeths 18

Author’s Bio: Dav id Deeths

David Deeths has worked for Sun’s Enterprise Engineering for 4 years. His work has focused primarily

on clusters and high availability systems. He is the co-author of t he Sun ™ Blueprints book " Sun

Cluster Environment: Sun Cluster 2.2" and has published a num ber of online articles on a variety of

topics.

David holds Bachelor of Science degrees in Electrical Engineering and Cognitive Science from the

University of California, San Diego.

Author’s Bio: Glenn Brunett e

Glenn Brunette has more than 8 years experience in the areas of computer and network security. Glenn

currently works with in the Sun Professional Services organization where he is the Lead Security

Architect for the North Eastern USA region. In this role, he works with many Fortune 500 companiesto deliver tailored security solutions such as assessments, architecture design and implementation, as

well as policy and procedure review and development. His customers have included major financial

institutions, IS P, New Media, and government organizations.

In addition to billable services, Glenn works w ith t he Su n Professional S ervices Global S ecurity Practice

and Enterprise Engineering group on the development and review of new security methodologies, best

practices, and tools.

Date post:	07-Apr-2018
Category:	Documents
Upload:	arojasm2912
View:	221 times
Download:	0 times

Sun Blueprints (816-1475) - Using NTP to Control and Synchronize System Clocks - Part I,...

Documents