[ntp:questions] handling falseticker
martin.burnicki at meinberg.de
Wed Feb 18 09:11:06 UTC 2009
catia.lavalle at bechtle.com wrote:
> I have the following configuration Stratum 0 configuration:
> 1 x Stratum 0 (DCF "Clock") --> 1 x Stratum 1 (let's give it the IP
> 1 x Stratum 0 (GPS "Clock") --> 1 x Stratum 1 (let's give it the IP
> I do not have (for security policy) the possibility to give any other
> alternative (extern) time source to the Stratum 2 Servers.
> This means that my Stratum 2 Servers have only 2 servers. Obviously this
> configuration is not "falseticker save".
> I have a monitoring active which warns me if the time offset between the 2
> Stratum 1 server gets bigger than a fixed limit.
> In such a situation anyway the NTP daemon on the Stratum 2 servers would
> mark one of the 2 Stratum 1 servers as a falseticker and "ignore" the time
> coming from it.
> Since there are only 2 Stratum 1 server to choose from the "voting"
> decision do not really apply, in such a way that the decision that the NTP
> on the Stratum 2 servers take upon "ops! there is a falseticker. Which one
> is falseticker?" is rather casual (I guess).
> Say they mark the server 10.1.1.1 as falseticker.
> remote refid
> *10.1.1.1 .GPS.
> x10.1.1.2 .DCF.
> 127.127.1.1 .LOCL.
> At this point I will get a warning from my monitoring, I will check
> manually with an external source which time really is and have a look to
> the decision that NTP on the Stratum 2 Server took. Say I realize that the
> decision taken is wrong: the 10.1.1.1 is not the false ticker, the true
> false ticker is 10.1.1.2
> What should I do? I mean is there a way to force NTP "on the fly" to
> change it's mind? I have in mind something like a command line saying
> "force to trust server 10.1.1.1" (which simultaneously automatically will
> imply "then ignore 10.1.1.2 since this means it is the true
> falseticker")? ==> to force the following "switch"
> remote refid
> x10.1.1.1 .GPS.
> *10.1.1.2 .DCF.
> 127.127.1.1 .LOCL.
> Sure I could reconfigure ntp.conf with a prefer on the 10.0.0.1 server,
> and restart the daemon (would it work? I guess so), but I do not really
> like it, I find it to "permanent".
If both of your NTP servers provided a different time even though their GPS
and DCF77 refclocks were synchronized then this would be a bug in the NTP
server's software. In this case a client which polls both servers had no
chance to find out which of the 2 upstream servers was a false ticker. The
only way to resolve this automatically is to configure at least 1 more
If one of your NTP servers has lost synchronization with the incoming radio
signal from GPS or DCF77 then the times received from both servers will
start to drift apart slowly, depending on the accuracy of the oscillators.
Depending on the configuration of the "trust time" of the refclocks in your
NTP servers the root dispersion of the freewheeling server will start to
increase, so NTP clients should be able to find out which of the servers
provides "better" time.
Alternatively you can configure the "local clock" on your NTP servers and
fudge their stratum to 15. So if the GPS or DCF77 receiver has lost
synchronization then (possibly after a "trust time") the NTP server will
select the local clock as system peer. If the local clock's stratum is 15
then the NTP server will be seen as stratum 16 on the network, which means
"not synchronized", so that NTP server will be discarded by the clients.
Hope this helps.
More information about the questions