----- On Feb 26, 2017, at 2:00 AM, Brad Knowles [email protected] wrote: > > My understanding is that anycast works fine for DNS, but breaks the NTP > protocol. > > With NTP, you’re supposed to have one and only one system clock per IP > address. > Otherwise, you break critical underlying assumptions. > > For the same reason, you can’t put multiple NTP servers behind a load > balancing > switch. > > Is this not correct? Did I miss something?
Brad. I thought this at first when researching a timing project, but started digging into it a bit and found that for reasonably stable and self-contained networks, anycast doesn't really mess with the accuracy of the protocol. Imagine it this way: Each endpoint client may use the same IP for a clock, but the actual host to which they connect varies somewhat with the network topology and how the anycast participants are arranged. With a consistent routing protocol in place, the path between the endpoints (and consequently which actual ntpd server the connections from any one client actually reach) is the same each time and the underlying protocol algorithms work as intended. We have also leveraged equal-cost-multipath for load sharing of NTP requests among multiple hosts in a single datacenter. Every router vendor I've checked implements ECM in a deterministic way such that your source and dest (along with other attributes) are hashed such that as long as the participants in the multipath don't change and the topology doesn't change, the clients requests will always go to the same server. With ECM in place, we can take down an NTP node in a given location for maintenance without causing the anycast VIP that it's serving to flap and re-converge on the network since it has one or more partners in the same location still online. You're spot on that application load balancing tends to mess things up unless you turn down the smarts on the SLB so far that it's basically doing ECM...in which case, why spend the money on the SLB when a decent router does just as well. The whole anycast discussion is predisposed on the assumption that many clients can only be configured with one timing source, for better or worse. In most cases, having "pretty close time" on these devices is far more important than having the algorithm be absolutely accurate. We still use a DNS pool with real host IPs for clients that are capable. Devices that SHOULD be able to use a pool with ntpd but that can't because of how the vendor implemented the configuration (i.e. JunOS resolving DNS time sources at config-time instead of run-time) can still use the full ntpd and the anycast source with good results. Global-anycast, or some other setup where you're crossing peers or AS-es likely doesn't provide the same consistency as what's described above. It might work well for a while, but would depend greatly on dynamic routing activities that are likely out of your (organization's) control. Dan -- Dan Geist dan(@)polter.net _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
