SUMMARY(2): xntp on private subnet

From: J.R. Lee (jrl@adc.idt.com)
Date: Thu Nov 04 1999 - 12:13:44 CST


Hello again,

Thanks to Arthur Darren Dunham <add@netcom.com> I made some changes to my
configuration. I needed to add the 'fudge' command to each server ntp.conf
file. This was for making one more preferred over the other.
On Server A:
fudge 127.127.1.0 stratum 10

On Server B:
fudge 127.127.1.0 stratum 12

I think Arthur explains it best in the following responce.

Thanks again Arthur and everyone else that helped out!!

J.R.

---- Arthur's Responce ----
It won't work like you expect.

If you set up both servers with their local clocks at the same stratum
(say 10), then you get this situation

Server A sees
      local clock at 10 preferred
      server B at 11

Server B sees
      local clock at 10 preferred
      Server A at 11

Since the local clock is a lower stratum and it's preffered, it'll never
believe the other server, and the two will not sync to each other. The
only way to do that is to declare one of them as a master, and set up
the other one with it's straum 2 levels higher.

A sees
     local at 10
     B at 13

B sees
     local at 12
     A at 11

This way B will sync to A, but will use it's own clock if A dies.

One example shown

> ---- terry gardner <terry.gardner@East.Sun.COM> ----
>
> What I do in this case is set up a local clock server with
> keys and broadcast ... I've attached some files that
> I use for config if you need them.
>
> ntp.keys:
>
> 1 A tardis
> 2 A timelord
> 3 A gallifrey
>
> /etc/inet/ntp.conf (server):
>
> server 127.127.1.0 prefer
> fudge 127.127.1.0 stratum 0

Please please please please please don't do that. *never* declare an
undisciplined local clock at stratum 0. It might escape some day when
someone finally gets some network together that was never planned for.
If you just declare it at a nice high number (like 10). Everything will
work just fine. One day in the future when you have access to a real
clock or a receiver you add the definition and everything just works
normally. If the receiver dies, then everything will revert back to the
local clock without touching anything.

--------

**** FIRST SUMMARY ****

Hello everyone,

Thank you all for the suggestions. I got a great referance site at
http://www.eecis.udel.edu/~ntp/
What I really need is a GPS, Cellular Phone, or cesium referance clock
to hang off of the machine but they are way out of our price range. So
I am going to have two servers use their localhost clocks as referance
clocks and the assign those two as peers to themselves to check against
each other. I am then going to use multicast broadcasts for my clients,
which if I am not mistaken will get readings from both.

I am still in the middle of testing but from initial testing with 'ntpq'
it looks as if it is working. If this is not a correct solution I will
update with a new summary.

Below is the original question, the server ntp.conf, the client ntp.conf,
and the responces from all of the people who were kind enough to respond.

Thanks!!

J.R.

#####original question#####

> My subnet is private due to a very strict firewall. I am trying to get
> one machine to be the xntp server without first syncing up to some stratum
> server on the internet. I would like to be able to have all machines sync
> to that machine. I have tried the broadcast and multicast scenarios but
> to no avail there is no syncing. I assume this is because the server needs
> to sync to a server first and then broadcast out because I am not getting
> any casts other than one initial one. I am using the xntp that comes with
> 2.6.

#####server ntp.conf#####

#localhost referance clock
server 127.127.1.0 prefer

#peer server to check with
peer other_server

#broadcast to clients
broadcast 224.0.1.1 ttl 8

#other stuff
enable auth monitor
driftfile /var/ntp/ntp.drift
statsdir /var/ntp/ntpstats/
filegen peerstats file peerstats type day enable
filegen loopstats file loopstats type day enable
filegen clockstats file clockstats type day enable

keys /etc/inet/ntp.keys
trustedkey 0
requestkey 0
controlkey 0

#####client ntp.conf#####

multicastclient 224.0.1.1

#####responces#####

---- terry gardner <terry.gardner@East.Sun.COM> ----

What I do in this case is set up a local clock server with
keys and broadcast ... I've attached some files that
I use for config if you need them.

ntp.keys:

1 A tardis
2 A timelord
3 A gallifrey

/etc/inet/ntp.conf (server):

server 127.127.1.0 prefer
fudge 127.127.1.0 stratum 0

broadcast 224.0.1.1 ttl 4

enable auth monitor
driftfile /var/ntp/ntp.drift
statsdir /var/ntp/ntpstats/
filegen peerstats file peerstats type day enable
filegen loopstats file loopstats type day enable
filegen clockstats file clockstats type day enable

keys /etc/inet/ntp.keys
trustedkey 1
requestkey 2
controlkey 3

/etc/inet/ntp.conf (clients):

multicastclient 224.0.1.1
keys /etc/inet/ntp.keys

Give this a shot and email if you have problems.

---- "Parthiv Shah" <pshah@nscc.com> ----

Makesure your ntp.conf file says something like this.
Than try to do some testing.. it should work..!

server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 0
driftfile /var/adm/ntp.drift

---- Michael Brock <michael@ti.com> ----

For a stand-alone server using its own clock to set other machines, the
ntp.conf should look like:
server 127.127.1.0 prefer
fudge 127.127.1.0 stratum 0

driftfile /etc/inet/ntp.drift

the client ntp.conf would look like:
server (server's ip address) prefer

driftfile /etc/inet/ntp.drift

However, once you change the date on the server, you must wait for it to get a
sample of the clock before it will allow others to sync from it... Read the
ntpdate man page to investigate further...

---- Arthur Darren Dunham <add@netcom.com> ----

An xntp server always has to sync to a clock. You can specify the local
clock if you want.

Add some lines like this...

server 127.127.1.1
fudge 127.127.1.1 stratum 10

The 1.x device is the local clock.
The second line says to hopefully not use the clock if a "real" clock
comes around.

---- Naveen_Malhotra@acml.com ----

Try the ntp s/w from "http://www.eecis.udel.edu/~ntp/". It has detailed
documents.

---- Andre Koopal <andre@nl.uu.net ----

Hmm, not really sun-manager related I guess, o well.

I asume you just want to have a common time on your network. Your ntp-server
has to have an authorative timesource to become other then stratum 16.

Look with xntpdc and than the command sysinfo what your stratum is.

Basicly you want to sync your ntp-server with your local computerclock.

I had to do the same for an y2k test. In my ntp.conf on that server I have:

# Use on local clock
peer 127.127.1.10

restrict 127.127.0.0 mask 255.255.0.0 # local config

---- Carl Brewer <carl@bl.echidna.id.au> ----

You can use the local server's clock as follows :

server 127.127.1.0
fudge 127.127.1.0 stratum 8

in ntp.conf

this is in the documentation at http://www.eecis.udel.edu/~ntp

---- "DAVID,Anthony" <Anthony.DAVID@dewrsb.gov.au> ----

Greetings

You need a reference clock. Either get a clock card/GPS
or use the fudge directive to set the local clock as
the reference clock. Downside of that is that you
propagate the server's drift to all the other clocks.
This means that all the machines will be in sync but
your users will probalby start whinging when their
watches are out of sync with your servers. This is
because computer clocks are notoriously sublect to
drift and hence xntpd was invented :)

Punching that hole in the firewall starts to look
attractive.

---- David Lee <T.D.Lee@durham.ac.uk> ----

Disclaimer 1: We are internet linked (most of the time!) so our own NTP
service can reach Internet clocks.

Disclaimer 2: I am simply a user of, not on expert on, NTP.

I wonder if there is a basic misunderstanding of ntp?

My own understanding (which, I admit, may be flawed) is as follows:

For many services (e.g. NIS, DNS, LDAP) there is a concept of a single
master server, then perhaps some slave servers, then some clients (like
many Western-style strictly hierarchical government structures from
President down to local town council down to citizen "client").

But ntp is not like these. Rather, it thrives on having lots of machines
all potentially serving each other. Indeed this is what adds to its
resilience, including its ability to detect and ignore mis-behaving clocks
(often called "false tickers").

If you have a handful of machines, one way is to have them all "peer"
with each other (a sort of single-level democracy).

If you have lots of machines, you might nominate a few to peer with each
other, and the rest to use the first set as "server" machines. This is
something like a two-level democracy). By pursuing this model, ntp allows
about 15 levels, although in practice it is rare to exceed four levels
within a site.

But the crucial point is the cross-linking within each level ("peer"
specifications), and multiple links between levels ("server").

Initially try setting up two or three machines to "peer" with each other.
Hopefully, after several minutes, they will find and begin to synchronise
with each other: use the "peers" subcommand in the UNIX "ntpq" command to
monitor this. (Forget about broadcast/multicast for the moment.)

---- Jochen Bern <bern@penthesilea.uni-trier.de> ----

Precisely. In the world of NTP terminology, a machine's clock is not
an authoritative source of time by itself, and cannot be synced
against unless it synced against an authoritative source itself.

It's been a while since I dug around in the xntpd sources, but back
then, there was a compile-time (?) flag that would allow you to have
your /etc/ntp.conf declare the machine's RTC to be a source of time
(rather than a *target* where synced time goes to) at a given
stratum (should be selected such that as long as real authoritative
sources are available, no machine will sync to the mangled one).
Very much discouraged, though, and might get removed in the ongoing
xntp 3.x -> ntp 4.0 transition ...

Note that not only computers can run NTP - we've had two Cisco 4000
routers being NTP servers for quite a while. Maybe having your
Internet gateway router sync to external servers, and allowing
machines to sync against the (local!) router through the firewall,
fits your bill.

-- 
---------------------------------------------------------------
 J.R. Lee                               email: jrl@adc.idt.com  
 System Administrator                   phone: 678-775-2947    
 Integrated Device Technology, Inc.                           
 11555 Medlock Bridge Rd. Suite #170                         
 Duluth, GA 30097                                           

"UNIX _IS_ user friendly; it's just picky about who its friends are."

perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:31 CDT