[ntp:questions] Re: Problem with NTP multicast server configuration

David Woolley david at djwhome.demon.co.uk
Sun Jan 16 08:36:48 UTC 2005


In article <mailman.21.1105837472.588.questions at lists.ntp.isc.org>,
Larry Mills <lgmills at claritycsi.com> wrote:

> - All hosts to be time synchronized are on a closed network; absolute time
> synchronization with a true stratum 1 source is not important, but all
> servers
> on the network should be closely synchronized with each other.

This is not an intended use case for NTP.

> - Two hosts (hosts X and Y) are configured as NTP multicast servers; each
> server is a peer of the other, in symmetric-active mode.

Peering doesn't negotiate a mutual understanding of time, rather it provides
mutual backup against failure of each peer's upstream server, and also provides
mutual sanity checking when there are multiple sources of time.  If you want
consensus, isolated, timekeeping, you should a protocol like the timed that
was supplied with at least some versions of SunOS.

> if xntpd is started on host X, and host Y is not up, no multicast broadcasts
> are sent from the server, and multicast queries (e.g. from ntpdate) from

I assume that this is a safety feature, to prevent a local clock being
used (directly) as a broadcast source and therefore contaminating large
numbers of machines.  I have a feeling that this can be overridden from
the configuration file, but I'm not convinced it is a good idea to give
clues as to how to do that.

> clients are ignored.  While in this state, ntpq -p shows that the server
> is using it's local clock, and the peer information is discarded.
 
> Once the second server (Y) becomes available and exchanges timing
> information
> with the peer, the second server (only) begins to issue multicast
> broadcasts.

The second server is synchronised to an apparent real clock.  It is
one stratum further from the root so it is not a candidate as a timing
source for the first server.  As I said, there is no consensus forming
with peering.

> I'm certainly not a NTP expert, but I think the configuration I'm trying
> to implement is possible, so I'm assuming I've botched something in the

It is out of specification and seems to involve common misunderstandings
about the nature of peering.




More information about the questions mailing list