Re: Setting Up NTP Subnet

On 3/8/06, Danny Mayer <mayer@xxxxxxxxxxx> wrote:

Bill Myers wrote:
*Thank you for your response. I've included some additional thoughts on
my perspective below. As you can see, I've been thinking through this
some and have formulated some opinions and rationale behind my
opinions. Maybe I just need to be told I'm going off the deep end! *

On 3/7/06, *Danny Mayer* <mayer@xxxxxxxxxxx <mailto:mayer@xxxxxxxxxxx>>
wrote:

Bill Myers wrote:
> I have questions regarding best practices on architecture of NTP
subnets.
> I've thoroughly read "Notes on Setting up a NTP subnet" from the
NTP sites.
>
> Is there a need for multiple external time source
TECHNOLOGIES. That is, is
> it sufficient to use multiple (8) GPS receivers with ACTS dial
backup
> and Rubidium clocks? This is a sizeable investment for the
infrastructure,
> but is it the right way? Is it necessary or desirable to have
other sources
> such as radio and/or Internet?
>

I don't think that there is any specific reason to require this. I
don't
think you gain or lose anything by having different technology
sources
or identical technology sources. Even on identical ones from the
same
manufacturer you will get slightly different results just due to the
manufacturing process. Quality controls on the manufacturing have
tolerances for what will be allowed but that's a range and your
gizmo is
going to be anywhere in that range.


*I'm concerned that ultimately, GPS is a single source of time that
could be a single point of failure or intentional blackout due to a
perceived security condition by government or military authorities. I
didn't really mean different technologies as much as different,
independent sources. For example, the documentation I have for a well
known Stratum 1 NTP site shows two GPS, two WWVB, two Loran-C,
plus quartz and Cesium clocks. *


IIRC, each GPS satellite has it's own atomic clock which is used for
signalling position and time. Of course you could have multiple GPS
receivers receiving from the same satellite.

The documentation is likely to be from Dave Mill's lab or NIST so you
shouldn't read too much into that as they test ntp across a large number
of different pieces of hardware.


Agreed.

In case you have not picked up on it, I'm talking about an appliance
here.
I find it odd that one cannot NTP peer these appliances. This suggests
to
me that we should create a stratum 2 tier peer layer a stratum 3 tier
that
peers and serves time to the endpoints.

I don't think that's necessary. The lower the stratum the bigger the
error budget, so depending on how accurate you want your time to be you
need to limit how low you are able to go.

*The document "Notes on setting up an NTP subnet" state that one should
have at least three external time sources to each of your best stratum
servers and that the servers at this level should peer. The GPS/clock
appliances we have cannot peer or take any other external sources.

I'm not sure I understand what you mean here. A stratum 1 server can
have a stratum 0 refclock (GPS or whatever) and have other stratum 1
servers to peer with or it can become a stratum 2 server by accepting
other stratum 1 servers as servers to itself in case the refclock
becomes unavailable for some reason.


Yes, with NTP, but not with the implementation on this appliance. It only
serves, no peering.

GPS satellites can become
unavailable if they are no longer in the area in the sky that your
antenna can see. NTP is designed to fail over to other sources of NTP
packets if any server fails or gets out of synch with other servers.
That's why you need at least 3 servers so that ntpd can make intelligent
decisions about which server is providing the most reliable source.

So I
consider them as very good GPS/clock (rubidium) Stratum 0 sources that
have inadequate NTP support,

Is it because they are obsolete or is there another reason? We support
everything we can, provided we either have the equipment or have someone
who does who can help out.


Not obsolete, brank new. Eight Spectracom 9183 NetClocks with Rubidium
oscillators. Claims to be "Stratum 1 NTP/SNTP Time Server via GPS" which
basically is the qualifier for supporting NTP as a server but not
for peering.

My belief is that this appliance should be used as a reference source to an
NTP server but not as an NTP server in its own right because there is no
ability to coordinate time with the rest of the NTP subnet.

Also, eight of these in a network as primary time servers without peering or
other outside references pushes the sanity check to the Local time servers.
If the all local time servers are properly configured with three or more
Primary sources, this should not be a problem. But with misconfigured
Local NTP server, portions of the network could drift.

One option would be to adminitratively permit only known Local NTP servers
for which we have some influence to access the Primary NTP servers.

and are best used as time sources to clock
real NTP Stratum 1 servers which are properly configured with multiple
external sources and internal peering with other Stratu 1 servers in the
NTP subnet. *

> More dysfunction? The plan is for the stratum 2 tier, which is
also the
> time distribution tier, to be the cache DNS for some high-volume
data center
> environments.

Which should be fine. What is the time going to be used for in
relation
to the cache DNS?


*There's no relation to the cache DNS, just shared services on the same
platform. Large server environments querying the same server for both
DNS and NTP. With DNS being such a rich security target, could we
unnecessarily expose NTP to disruption? Also, couldn't there be resouce
contention between the services -- mostly in the direction of intense
DNS work interfering with consistent NTP responses? *
**

There is no resource contention here. I am currently running NTP on this
machine as I write. I'm banging at it as hard as I can with two
different machines to try and break it and I don't even notice that it's
running, never mind responding to packet requests.



Ok, so there's no case for clock instability due to resource contention on
NTP servers. In practice, do large enterprise NTP subnets piggyback NTP
Primary and Local servers with other services? This probably depends on
requitements ... which was mentioned in another thread where I'll delve into
that more deeply.

~Bill

Danny

_______________________________________________
questions mailing list
questions@xxxxxxxxxxxxxxxxx
https://lists.ntp.isc.org/mailman/listinfo/questions

.

Relevant Pages

  • Re: Query about NTP accuracy
    ... It's all in a GE LAN based scenario, commercial stratum 1 ... servers connected to GPS and stratum 2 and 3 servers are typically ... microseconds of UTP, as soon as the client uses NTP v3 over the LAN, ... The old has 3 geographically diverse GPS receivers ...
    (comp.protocols.time.ntp)
  • Re: Query about NTP accuracy
    ... It's all in a GE LAN based scenario, commercial stratum 1 ... servers connected to GPS and stratum 2 and 3 servers are typically ... microseconds of UTP, as soon as the client uses NTP v3 over the LAN, ... The old has 3 geographically diverse GPS receivers ...
    (comp.protocols.time.ntp)
  • Re: Setting Up NTP Subnet
    ... the documentation I have for a well known Stratum 1 NTP site shows ... I find it odd that one cannot NTP peer these appliances. ... servers and that the servers at this level should peer. ... *There's no relation to the cache DNS, just shared services on the same ...
    (comp.protocols.time.ntp)
  • Re: Query about NTP accuracy
    ... It's all in a GE LAN based scenario, commercial stratum 1 ... servers connected to GPS and stratum 2 and 3 servers are typically ... microseconds of UTP, as soon as the client uses NTP v3 over the LAN, ... The old has 3 geographically diverse GPS ...
    (comp.protocols.time.ntp)
  • Re: Query about NTP accuracy
    ... It's all in a GE LAN based scenario, commercial stratum 1 ... servers connected to GPS and stratum 2 and 3 servers are typically ... The NTP will be on a separate management LAN to the production traffic ... The old has 3 geographically diverse GPS ...
    (comp.protocols.time.ntp)