On Mon, Nov 22, 2010 at 9:00 AM, Ben Rockwood <[email protected]> wrote: > There appears to be a long standing issue with Multicast support on > Solaris 10/OpenSolaris. Sun some old bugs relating to the issue, but I > can not find any similar bugs in the NTP bug database. The Sun bugs are: > > * http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6189538 > * http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6669167 > > The problem is this: according to the documentation > (http://www.eecis.udel.edu/~mills/ntp/html/confopt.html) multicast > should bind to all interfaces, however in practice it binds only to > one. Example: > > addto_syslog: Listen normally on 7 multicast 224.0.1.1 UDP 123 > addto_syslog: Added Multicast Listener 224.0.1.1 on interface #7 multicast > > # netstat -gv > Group Memberships: IPv4 > Interface Group RefCnt > --------- -------------------- ------ > lo0 ALL-SYSTEMS.MCAST.NET 1 > bnx0 224.0.0.251 1 > bnx0 ALL-SYSTEMS.MCAST.NET 1 > external0 NTP.MCAST.NET 1 > external0 224.0.0.251 1 > external0 ALL-SYSTEMS.MCAST.NET 1 > internal0 224.0.0.251 1 > internal0 ALL-SYSTEMS.MCAST.NET 1 > > > > Both on Sun's release (4.2.5p172) and the latest stable version > (4.2.6p2) this is still the case. > > There are two questions: > > 1) Is the a Solaris issue or an NTP issue?
A ntpd issue. See http://bugs.ntp.org/1725 > 2) Can I at least choose (force?) NTP to choose a specific interface to > bind to? In the above example I want multicast on bnx0, not external0. Quite possibly you can use interface listen bnx0 But that will only work if bnx0 is the _only_ interface you want ntpd to use, period. ntpd's multicast support has two sides. Certain functions require listening to multicast addresses, and ntpd has generally done the right thing here, listening on each interface. Other functions, such as manycastclient and multicast, require sending to a multicast address from one of the machine's unicast addresses. Here, ntpd has fallen down until very recently, as it would in fact send from a single local address, which can be seen in the dstadr= of the peer variables for a multicast or manycastclient association, which has the multicast address as srcadr=. Starting with the just-released ntp-dev snapshot 4.2.7p84, and the soon-to-be-released ntp-stable release candidate, ntp4.2.6p3-RC11, ntpd sends to multicast addresses from each local interface in turn (excepting IPv6 site-local and link-local addresses on the same interface a a global address), regardless of what dstadr= shows. This should solve a lot of problems using multicast or manycastclient on machines which have more than one local IPv4 address or more than one local IPv6 address (which is the case for anyone with a global IPv6 address). Please consider building and installing http://archive.ntp.org/ntp4/ntp-dev/ntp-dev-4.2.7p84.tar.gz on your system and file a bug if multicast is still misbehaving. I'm anxious to put these problems in the past. NTP's manycast scheme (not to be confused with BGP-based manycasting) is a wonderful way to manage a large number of machines with identical ntp.conf files which self-organize automatically. Participating clients send from a unicast address to a group multicast address an authenticated client mode request. Participating servers respond with a unicast server mode reply. To self-organize a large number of machines, each host should play both roles. The scheme has the easy configuration advantage of multicast and broadcast NTP, yet the benefits of unicast operation, such as ongoing accurate delay measurements. I encourage everyone to play with NTP manycast. I advise against any "disable auth" temptation, both because you shouldn't trust unknown others on your network, and because ntpd is not well tested or supported in the "disable auth" configuration. You will need the same key ID and cyphertext configured on each machine and used in the manycastclient lines of ntp.conf like: manycastclient 224.0.1.1 maxpoll 8 key 123 with another line like: keys /etc/ntp.keys pointing to a /etc/ntp.keys containing something like: 123 M mysecret The server side of manycast is simpler to configure and should also be listed on all your machines to allow them to self-organize: manycastserver 224.0.1.1 You might also look at the docs for automatic server discovery schemes and the following settings and perhapsdjust them as well: tos orphan 11 tos minsane 2 tos minclock 3 tos maxclock 12 If you then select a few machines to supply time (whether from local reference clocks or network NTP sources) and configure them as manycastserver with the same key, the rest of the manycast network will organize around them automatically, with each participant ntpd able to use its own perspective and measurements to select a reasonable subset of the manycast servers, and reconfigure over time as conditions change. For those lucky enough to be using ntp-dev (4.2.7) there's a revamped "pool" command that operates like manycastclient, with the exception of the way servers are solicited. manycastclient sends to the given multicast address, and gets unicast responses from participating manycastservers. pool solicits one additional server IP address acquired from DNS at a time using normal unicast client mode packets. The criteria for when to solicit additional servers is the same for pool and manycastclient, influenced by minclock and maxclock. This is a much more resilient way to use pool.ntp.org than the traditional few "server 0.*.pool.ntp.org" "server 1.*.pool.ntp.org" etc, which resolves DNS names to IP addresses at ntpd startup and then lock onto the lucky IPs until ntpd is restarted, regardless of their utility. Thanks for your interest in improving ntpd. Cheers, Dave Hart _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
