r1 - 2016-04-18 - 10:12:38 - HarlanStennYou are here: NTP >  Dev Web > PreferKeyword
NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.

ntp-4.2.8p10 was released on 21 March 2017. It addresses 6 medium- and 5 low-severity security issues, 4 informational security topics, 15 bugfixes, and contains other improvements over 4.2.8p9.

Please see the NTP Security Notice for vulnerability and mitigation details.

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.

Prefer Keyword

Related Topics: bug_small.png Bug #1406, bug_small.png Bug #3029, html/prefer.html

The prefer keyword was designed to be used by refclocks. It may also be used for other associations.

The documentation says:

The cluster algorithm works on the set of truechimers produced by the select algorithm. At each round the algorithm casts off the survivor least likely to influence the choice of system peer. If selectable, the prefer peer is never discarded; on the contrary, its potential removal becomes a termination condition. However, the prefer peer can still be discarded by the select algorithm as a falseticker; otherwise, the prefer peer becomes the system peer.

The Book says:

...

In the prefer scheme, the cluster algorithm is modified so that the prefer peer is never discarded, on the contrary, its potential removal becomes a termination condition. If the original algorithm were about to toss out a prefer peer, the algorithm would terminate immediately. A prefer peer can still be discarded by the sanity checks and select algorithm, but if it survives them, it will always survive the cluster algorithm. If it does not survive or for some reason it fails to provide updates, it will eventually become unselectable, and the clock selection will remitigate to select the next-best source.

The combine algorithm is not used when a prefer peer is selected; instead, the prefer peer offset is used exclusively to discipline the system clock. In the usual case involving a reference clock and a flock of remote primary servers, and with the reference clock designated the prefer peer, the result is that the hich-quality reference time disciplines the system clock as long as the reference clock itself remains a truechimer.

Based on the bug reports referenced above, there are some corner cases that need to be examined.

 
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r1 | More topic actions
 
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback