[ntp:questions] Multicast question
kardel at ntp.org
Sun Mar 2 07:48:56 UTC 2008
Danny Mayer wrote:
> Frank Kardel wrote:
>> Danny Mayer wrote:
>>> John Vossler wrote:
>>>> I have a new system running Solaris 10 set up as an NTP server. IT
>>>> is synchronizing correctly but I cannot get it to multicast on any
>>>> interface except the systems primary Ethernet interface, bge0. I
>>>> need it to multicast on interfaces bge1-bge3 and ce0 - ce7.
>>>> Client systems reside on the network segments on these other
>>>> Anyone have any suggestions on getting the server to multicast on
>>>> these other interfaces?
>>> Are you talking about outgoing packets to a multicast address? I
>>> think that there may be some bugs in that area since the addresses
>>> are limited and choosing an outgoing address becomes an issue and it
>>> will only send it out on one address. I'm not sure if it's possible
>>> to set up a server (at least not easily) to send via different
>> It is. But on a multihomed server the server must have multicast routing
>> functionality. Either this is already provided in the kernel or you
>> need to run an mcast-routing daemon like mrouted, zebra or others.
>> The ntpd setup is not different on multihomed hosts. Just the multicast
>> routing must be working.
> Even if that's true, we don't know apriori whether or not that is the
> *intent* of the sysop.
> Most times you are likely to have a server with two NICs but one is
> used as an outbound interface to the external servers and the other
> NIC is used to multicast packets to the LAN. NTPD has no way of
> knowing that.
It doesn't need to know that. Basically multicast configuration is sort
of configured backwards. The clients subscribe and the (multicast
routers) servers will supply the data where it is subscribed to (in
The whole point about multicast is to be able to provide data to a large
interested group and at the same time limit the distribution to the only
necessary distribution tree.
The only issue we might have (again) is what source address would we
like to see in these multicast and would we be willing to see all
multicasts from the server for all/some local server interfaces?
> I assume that something like mrouted can be configured in some way to
> know how to send those packets. Note that such a configuration is
> likely to introduce additional delays and jitter to the outgoing
> multicast packet.
>>> To do this correctly you need to be able to set up a different
>>> multicast address to use and associate it with a particular server
>>> address for each interface.
>> NO - see above.
> Yes, it turns out you can do this from within ntpd but you have to
> program this.
You can do many things - you can even use the same multicast address
outbound by sending over different sockets. On a multicast router this
would lead to different source addresses
seen by the multicast clients. On a non multicast router each segment
would only see the multicast packets from the interface serving them.
Usually this effort is not needed when (mcast)
routing between al segments is possible. Things get tedious when ntpd
runs on a platform that does not (by choice / misconfiguration) perform
the routing. Then requirements for
supporting split views of the ntp service come up.
The issue of local server addresses basically boils down to the ability
the configure the <local>/<remote> address pair for associations - no
matter whether they are peers/servers/broadcasts.
This will also solve all current ambiguities with the proposed query-on
directive. We could have several ways to specify the local address:
* - fully automatic - usually best and works for almost all environments
as it matches routing
(interface) - pick one of the interface addresses within the protocol
family - this one is already semantically difficult - single address
interfaces would work best here, probably that form
should generate a group of associations the match the addresses of the
IP address - a single valid local address - this is the most precise
definition but is also most likely to violate routing information when
used with a specific destination address.
The point is that associations would actually need to be configured on a
src/dst address basis to cover all these exotic network setups where
somebody put an ntp server onto a central network component. That way he
runs into all configuration issues of a (mcast-)router and it is not
even sure that this network device would be an adaequate platform for
While I have a strategy in my mind to cover all these cases (see above -
association local address specifications) I am not sure whether we want
to go through that trouble.
More information about the questions