[ntp:questions] Re: Architecture / best practice for small/medium company setups

Richard B. Gilbert rgilbert88 at comcast.net
Thu Jun 29 15:30:49 UTC 2006


Joachim Schrod wrote:

> Hello,
> 
> I would like to pose a few questions on architecture / best practice
> on NTP setups for small and medium companies. I read the documentation
> and the Wiki, I also googled, but didn't find a satisfying answer. I'm
> willing to update the NTP Wiki with an HOW-TO text that results from
> this discussion.
> 
> The situation:
> 
>  -- Let's assume a company with 10 to max. 100 computer systems.
>     Forthermore, let's just talk about Unix systems, for now, and
>     let's assume that at least five of them are available.
> 
>  -- There is only one site. All computers are on the same LAN.
> 
>  -- The company has only one Internet connection, with a typical SLA of
>     97.5% availability over the year. (For example, that's the SLA of
>     T-Com for their basic CompanyConnect product here in Germany.) The
>     worst-case outage of 9 days can be ignored, but we have to cope
>     for outages of several hours length.
> 
>  -- The company has no requirements for extremely accurate
>     time-synchronization. They run the usual bunch of applications:
>     Databases, ERP systems, Office systems, and other applications
>     that access time with a granularity of one second.
> 
> I think this is a context that is common to many installations. (Well,
> I have seen many such environments. :-) My personal experience is only
> in big installations with 1000s of systems and redundant Internet
> connections; but I have been asked about such situations a few times
> in the past. (The last inquiry was a few days ago, and triggered this
> posting.)
> 
> The first few questions are about selection of time servers:
> How many, and what is their peer structure?
> 
>  -- I assume that the company should use the NTP server pool, as it's
>     not a large company with 1000s of computers.

You can use pool servers but I would not use them exclusively.

> 
>  -- How many timeservers on the LAN that are accessed by clients?
>     Looking at the available documentation, I would recommend four
>     servers. (This might mean that many of the Unix systems suddenly
>     are timeservers.) Or would three be sufficient? One server is
>     surely not sufficient, as an outage of that server would endager
>     the whole time synchronization.
> 
>     I.e., is peering between three servers sufficient to handle outage
>     of one server until the repair is done, or does one need four servers
>     to do that properly.
>     (An answer may depend on the connection of the timeservers to the
>     pool, as asked in the next question.) The Wiki recommends four
>     servers, but I have seen several places where three servers are
>     deemed sufficient. What's best practice?

Ideally, each client should configure four servers.
	a. With a single server the client must follow it, right or wrong.
	b. Two servers is the worst possible configuration.
	c. Three servers degenerates too easily to the two server case.
	d. Four servers protect you from the failure of any one server.
> 
>  -- Connection to the NTP pool:
>      -- Either all company timeservers access the pool,
>      -- or one of the timeserver accesses the pool, and the others
>         synchronizes to it,
>      -- or there is an additional timeserver that accesses the pool
>         and the company timeserver synchronize to this special server.
>         The clients don't use this special server.
>     Since there is only one Internet connection, and since there are
>     no separate network paths to the pool servers, I have to ask if
>     it's still reasonable to have several timeservers synchronizing to
>     the pool. OTOH, if there is only one pool-connected system, what
>     to do in case of an outage of that system? (Probably promote one of
>     the other servers to be the Internet-facing systems.)
> 
>     I have no idea about further advantages or disadvantages of these
>     three design possibilities. I assume that this has to be answered
>     in conjunction with my next question, on peering. (I bar firewall
>     and DMZ considerations for the moment, that might recommend the
>     third solution.)
> 
>  -- Peering: Which servers peer to each other?
>      -- If all company timeservers access the pool, I think they are
>         all peers.

Ideally, each server in a peer group should have at least one unique 
source of time!  Thus four peering servers would need a total of seven 
upstream servers.


>      -- But if only one system accesses the pool, does this system
>         also peers with the others who synchronize to it? That hasn't
>         been clear from the documentation. On the Wiki, it says that
>         one shold peer all timeservers; but also ones that are
>         different in the stratum hierarchy?
> 
>  -- Internet connection outages: Just let them happen, or use
>     undisciplined local clock on stratum 10 as backup on the
>     timeservers?
>     AFAIK, undisciplined local clocks can cause havroc when the time
>     strays too far away from the reference time source. Googling that
>     question got several potential answers, therefore: is it best
>     practice to use 127.127.1.0 as a backup for the case that no outside
>     source of synchronized time is available?
> 
> Is there a design decision for the server setup that I missed?
> 
I'm not certain that you need multiple peering servers.  For short 
outages a server can serve its local clock as "the clock of last 
resort".  It will drift but should be usable for several hours.  Can you 
tolerate an error of, say, 100 milliseconds?  Everybody would be in 
synch but could differ from UTC by up to 100 milliseconds.

It's possible to have a configuration that will survive anything but a 
direct hit with a nuclear weapon.  Very few organizations need this 
level of reliability.   I'd be inclined to start small and learn from 
experience.

>  -- Client configuration: Specific servers, or multicast?
>     Now we have a bunch of timeservers in the company. What is best
>     practice: That clients are configured to use these servers
>     specifically, or that multicast mode is used?
>     Or should one try a manycast configuration?
>     If one uses multicast or manycast, does this imply that one needs
>     to establish key-based authentication between servers and clients?
>     Such small companies usually have no PKI in place, so this might
>     mean to distribute shared secret keys during setup, or?
>     Or use Autokey, as explained in the Wiki?

I believe that authentication is not an absolute requirement.  All 
authentication does is to attempt to guarantee that the servers really 
are who they claim to be.  If traceability to some standard is a 
requirement then you probably need it.  If you see no need to guard 
against somebody pretending to be someone he's not, you can probably 
live without authentication.

Broadcast or multicast will cut down on some of the network chatter. 
AFAIK that's the only advantage.  The load on the server is not really 
significant; a server can handle a thousand clients without working too 
hard.

> 
> Sorry for the long post. I hope to get some answers, and maybe we can 
> add those answers to 
> http://ntp.isc.org/bin/view/Support/DesigningYourNTPNetwork. (Or make a 
> different page, with specific step-wise explanation for small/medium 
> company setups.) I think that page is already very good, but would be 
> further improved with such information.
> 
> Best,
>     Joachim
> 




More information about the questions mailing list