Re: ntp problem in broadcastclients
On Wed, Oct 24, 2018 at 06:23:49PM -0400, Gene Heskett wrote:
> The idea is to reduce the loading of 7 machines all banging one the level
> 1 and 2 servers by designating one machine to bang of the debian pool,
> and then broadcast it on the local 192.169.xx.xx net so all the others
> stay within a millisecond of this machine.
Well yeah, of course, but you don't need "broadcast" for that.
Here at work, I chose three of my servers to act as the local NTP sources
for all of the other servers and workstations. In our local DNS, I created
records to point to those machines as ntp1, ntp2 and ntp3. (They also have
other names besides these. These are just their NTP names.)
On ntp1, one of the local "servers", the /etc/ntp.conf file has:
pool 0.debian.pool.ntp.org iburst
pool 1.debian.pool.ntp.org iburst
pool 2.debian.pool.ntp.org iburst
pool 3.debian.pool.ntp.org iburst
Ntp2 and ntp3 have the same thing, or at least they should.
On my workstation, those lines are commented out, and I added:
server ntp1.eeg.ccf.org
server ntp2.eeg.ccf.org
server ntp3.eeg.ccf.org
This is how a "normal" (in my experience) LAN handles NTP. Yes,
there's manual configuration of each machine, but I don't find that to
be a burden. It's just those crazy kids these days that think everything
has to be done with multiple layers of Rube Goldberg devices.
> 2 machines report:
> pi@picnc:/etc $ ntpq -p
> No association ID's returned
I've literally never seen such a message before. I googled it, and there
are definitely results that look relevant. After adding "broadcast" to
the search terms, I came up with this result:
http://lists.ntp.org/pipermail/questions/2014-December/039401.html
Looks like a good starting point for your "broadcast" configuration.
I hope this helps.
Reply to: