JCA wrote: > The ntp.conf configuration files of A and B are identical: > > server 127.127.1.0 > fudge 127.127.1.0 stratum 10 > server 192.168.0.1 > # server reloj.kjsl.com > > driftfile /etc/ntp/drift > multicastclient # listen on default 224.0.1.1
The multicast address is required in order for it to receive multicast packets. See html/confopt.html. If you aren't doing authentication of the server you need to turn it off: disable auth > broadcastdelay 0.008 > > 192.168.0.1 is the IP address of C in my LAN. In the ntpq traces > above B's ntp.conf file was using > > server reloj.kjsl.com Does DNS resolve this to the same address? > > rather than > > server 192.168.0.1 > > C's ntp.conf configuration file: > > server 127.127.1.0 # local clock > fudge 127.127.1.0 stratum 10 > > server reloj.kjsl.com > server ntp1.sf-bay.org > > driftfile /var/run/ntp.drift > Is C not a multicast server? If not is there another server serving as a multicast server? Otherwise, either turn off the multicastclient in A and B or add the broadcast address line to C's ntp.conf. > If in A's and B's configuration files I use the line > > server reloj.kjsl.com > > instead of > > server 192.168.0.1 > > then A and B keep the time all right. C keeps the time all right with > the configuration file above. > Is reloj.kjsl.com on that address or a different address? If it's the same address as C then you need to remove that line from C's configuration. > Interestingly, I have another Linux box D in my LAN that seems to > be keeping in sync with C with the following ntp.conf file: > > restrict default ignore > restrict 192.168.0.1 mask 255.255.255.255 nomodify notrap noquery > > restrict 127.0.0.1 > > server 192.168.0.1 > fudge 127.127.1.0 stratum 10 > > driftfile /var/lib/ntp/drift > broadcastdelay 0.008 This has no effect for a system not acting as a broadcast/multicast client. > > authenticate yes > keys /etc/ntp/keys Do you have keys set up to authenticate? If so you need "enable auth" and not "authenticate yes". > > I could of course change A's and B's ntp.conf files accordingly and > see what happens. However, were this to lead to A and B synchronizing > with C all right, it still would not explain why A and B had been > synchronizing with C with no problems until recently. You network may have changed or a firewall may have been added or DNS has changed. Danny _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
