[ntp:questions] Multicast question

Frank Kardel kardel at ntp.org
Sun Mar 2 07:48:56 UTC 2008


Danny Mayer wrote:
> Frank Kardel wrote:
>> Danny Mayer wrote:
>>> John Vossler wrote:
>>>> Greetings,
>>>>
>>>> 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 
>>>> interfaces.
>>>>
>>>> Anyone have any suggestions on getting the server to multicast on 
>>>> these other interfaces?
>>>>
>>>> John
>>>
>>> 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 
>>> interfaces.
>> 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 
normal configuration),
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.

Generalisation:
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 
given interface.
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 
ntpd performancewise.

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.

Frank



More information about the questions mailing list