[ntp:questions] handling falseticker

catia.lavalle at bechtle.com catia.lavalle at bechtle.com
Wed Feb 18 13:05:12 UTC 2009


Hello,

what you describe is not the situation I have in mind.

You describe a "lost sync" of one of the 2 Stratum 0. This is not a 
falseticker situation. This would lead to a "lost sync" or a "sync to 
local host" which will be transferred up down on the whole  NTP tree, 
recognized by the clients and this NTP path will be ignored. Everything is 
clean everything is fine. And everything could be easily monitored (a lost 
sync is an error message!)

What I describe is a falsetiker as for example: suppose that the DCF 
signal gives you the correct time, the GPS signal has a failure (it steps 
apart a bit but not soo much that NTP refuses to stay sync)  and DOES give 
you a time BUT a wrong one. This is less easy to monitor since there no 
error!

Both Stratum 1 will keep being sync with the respective Stratum 0 because 
they DO receive a time and this time is not soooo wrong to stop syncing 
(is not a huge jump ... say is a slow drift).
The Stratum 2 will receive time from the Stratum 1. Will see that both are 
syncing with a Stratum 0 i.e. in principle they are both trustable but 
their time is too far apart to assume that both are correct. 

This means NTP has to decide which one is the wrong one. In this case NTP 
would decide which one gives the wrong time i.e. to be rejected as server 
with a voting criterion. The problem is that a voting criterion works only 
with up to 3 (well 4) servers. With 2 servers it does not work (no 
majority reach!). So NTP is forced to take anyway a decision but without 
enough elements at hand to know which is the right decision to take i.e. 
the decision it will take is not necessarily the correct one.

Here my question.

Say the decision taken is wrong. I realize it in some way (no matter how) 
and I want to correct it. I.e. I want to force NTP to switch from:

  remote        refid
=======================
*10.1.1.1               .GPS.
x10.1.1.2         .DCF.
 127.127.1.1            .LOCL.

to

  remote        refid
=======================
x10.1.1.1               .GPS.
*10.1.1.2         .DCF.
 127.127.1.1            .LOCL.

from the command line without having to change the ntp.conf file.

Is it possible?? How??

Thanks.

Catia




Externe Mail : questions-bounces+catia.lavalle=bechtle.com at lists.ntp.org   
 18.02.2009    10:11


Gesendet von: questions-bounces+catia.lavalle=bechtle.com at lists.ntp.org
An:
questions at lists.ntp.org




Kopie:








Thema:
Re: [ntp:questions] handling falseticker






Catia,

catia.lavalle at bechtle.com wrote:
> Hallo,
> 
> I have the following configuration Stratum 0 configuration:
> 
> 1 x Stratum 0 (DCF "Clock") --> 1 x Stratum 1 (let's give it the IP
> 10.1.1.1)
> 1 x Stratum 0 (GPS "Clock") --> 1 x Stratum 1 (let's give it the IP
> 10.1.1.2)
> 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".
> 
> 
> thanks

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
upstream server.

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.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

_______________________________________________
questions mailing list
questions at lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions




More information about the questions mailing list