From: Dave Hart The skunk watches for intruders and sprays. Last update:
-30-Sep-2009 17:16
+11-Apr-2010 22:57
UTC The chicken is getting configuration advice. Last update:
- 25-Nov-2009 4:46
+ 11-Apr-2010 23:07
Make sure who your friends are. Last update:
- 25-Nov-2009
+ 11-Apr-2010 23:09
UTC Manycast is a automatic server discovery and configuration paradigm new to NTPv4. It is intended as a means for a client to troll the nearby network neighborhood to find cooperating servers, validate them using cryptographic means and evaluate their time values with respect to other servers that might be lurking in the vicinity. It uses the grab-n'-drop paradigm with the additional feature that active means are used to grab additional servers should the number of survivors fall below the minclock option of the tos command. The manycast paradigm is not the anycast paradigm described in RFC-1546, which is designed to find a single server from a clique of servers providing the same service. The manycast paradigm is designed to find a plurality of redundant servers satisfying defined optimality criteria. A manycast clients is configured using the manycastclient configuration command, which is similar to the server configuration command. It sends ordinary client mode messages, but with a broadcast address rather than a unicast address and sends only if less than minclock associateons remain and then only at the minimum feasible rate and minimum feasible time-to-live (TTL) hops. The polling strategy is designed to reduce as much as possible the volume of broadcast messages and the effects of implosion due to near-simultaneous arrival of manycast server messages. There can be as many manycast client associations as different addresses, each one serving as a template for a future unicast client/server association. A manycast clients is configured using the manycastclient configuration command, which is similar to the server configuration command. It sends ordinary client mode messages, but with a broadcast address rather than a unicast address and sends only if less than minclock associations remain and then only at the minimum feasible rate and minimum feasible time-to-live (TTL) hops. The polling strategy is designed to reduce as much as possible the volume of broadcast messages and the effects of implosion due to near-simultaneous arrival of manycast server messages. There can be as many manycast client associations as different addresses, each one serving as a template for future unicast client/server associations. A manycast server is configured using the manycastserver command, which listens on the specified broadcast address for manycast client messages. If a manycast server is in scope of the current TTL and is itself synchronized to a valid source and operating at a stratum level equal to or lower than the manycast client, it replies with an ordinary unicast server message. The manycast client receiving this message mobilizes a preemptable client association according to the matching manycast client template, but only if cryptographically authenticated and the server stratum is less than or equal to the client stratum. It is possible and frequently useful to configure a host as both manycast client and manycast server. A number of hosts configured this way and sharing a common multicast group address will automatically organize themselves in an optimum configuration based on stratum and synchronization distance. The use of cryptograpic authentication is always a good idea in any server descovery scheme. Both symmetric key and public key cryptography can be used in the same scenarios as described above for the broadast/multicast scheme. The idea of targeting servers on a random basis to distribute and balance the load is not a new one; however, the NTP pool scheme puts this on steroids. At present, several hundred operators around the globe have volunteered their servers for public access. In general, NTP is a lightweight service and servers used for other purposes don't mind an additional small load. The trick is to randomize over the population and minimize the load on any one server while retaining the advantages of multiple servers using the NTP mitigation algorithms. The idea of targeting servers on a random basis to distribute and balance the load is not a new one; however, the NTP pool scheme puts this on steroids. At present, several thousand operators around the globe have volunteered their servers for public access. In general, NTP is a lightweight service and servers used for other purposes don't mind an additional small load. The trick is to randomize over the population and minimize the load on any one server while retaining the advantages of multiple servers using the NTP mitigation algorithms. To support this service the DNS for some volunteer servers as been
modified to collect a number of other volunteer servers and return a
randomized list in response to a DNS query. The client receiving this list
- mobilizes some or all of them just as in the other discovery schemes and casts
- off the excess. The pool scheme is configured using one or pool commands with the DNS name region.pool.ntp.org, where region is a region of the world, country of the region or state of the country or even the whole world if absent. The pool command can be used more than once; duplicate servers are detected and discarded. In principle, it is possible to use a configuration file containing a single line pool pool.ntp.org.
@@ -72,7 +72,7 @@ restrict time.nist.gov # allow access
@@ -86,21 +86,27 @@ time) in log2 s with default 3.
+ restrict source [flag][...]
+ restrict address [mask mask] [flag][...]
Related Links
@@ -78,11 +78,12 @@ Walt Kelly
the address must match the address specified on the manycastserver command
of one or more designated manycast servers.
from Alice's Adventures in Wonderland, Lewis Carroll
Related Links
@@ -46,21 +46,34 @@
Manycast Scheme
Server Pool Scheme
-
The pool scheme is configured using one or pool commands with DNS names + indicating the pool from which to draw. The pool command can be used more + than once; duplicate servers are detected and discarded. In principle, it is + possible to use a configuration file containing a single line pool + pool.ntp.org. The NTP Pool + Project offers instructions on using the pool with the server + command, which is suboptimal but works with older versions of ntpd + predating the pool command. With recent ntpd, consider replacing the + multiple server commands in their example with a single pool + command.