[ntp:questions] (Software) timeserver for windows being broadcast-able incl. keys

Tom Smith smith at cag.zko.hp.com
Fri Mar 16 23:04:35 UTC 2007

Per Hedeland wrote:
> In article <45FAAA30.2080401 at cag.zko.hp.com> Tom Smith
> <smith at cag.zko.hp.com> writes:
>> Erik wrote:
>>> On 15 mrt, 17:21, Tom Smith <s... at cag.zko.hp.com> wrote:
>>>>> broadcast key 1
>>>>> broadcast key 1
>>>>> broadcast key 1
>>>>> broadcast key 1
>>>> That's the right idea, but the second one above already
>>>> includes the first.
> How do you figure that? If (according to latest report) there are two
> networks a) and b), the address
> doesn't "include" in any way.
> is the broadcast address for a), is the broadcast address
> for b) - and hosts on network a) will not see as a
> broadcast address - in fact they will just see it as a random address on
> a remote network. A broadcast address is either or one
> where the network part matches exactly and the host part is all-ones. = *.0-127
    broadcast broadcasts to all of them = = *.128-255
    broadcast broadcasts to all of them - *.0-255
    broadcast broadcasts to all of them

Whether it would "work", depends on the next answer, which

>>> there is one network-card in the server that connects to the network
>>> and has access to the network segments mentioned above
>>> The IP-data of this server (PC) is (ipconfig-output):
>>> IP-adres . . . . . . . . . . . . . . .:
>>> Subnetmask . . . . . . . . . . . .:
>>> Standaardgateway . . . . . . . .:
>>> Does this answer your question?
>> Yes. That answers the question. With that configuration,
>> in order to reach any of the clients, the packets that the
>> server sends will have to be routed and cannot (usually) be
>> broadcast. The server can (usually) only broadcast to its
>> own subnet(s).
>> That said, there are, of course, exceptions. I believe
>> that if the subnets are, in fact, all on the same VLAN,
>> you may be able to send a broadcast addressed to a
>> network wider than the subnet defined by the server's
>> netmask to any other network on the VLAN. In that case,
>> you could use the single broadcast address
>> to reach all of your clients. It might work and it might not.
> No way *that* could possibly work - it's not a broadcast address on any
> of the relevant networks. *If* the subnets are actually on the same
> wire, what *might* work is to give the server an address in each network
> (using "virtual interfaces" or "aliases" depending on the OS flavor),
> and then specify all the individual broadcast addresses on their own
> "broadcast" line in ntp.conf.

Actually it would work, provided that all the "subnets"
are actually in the same VLAN. In fact, I have a server that
happens to fend off several hundred such packets a second
every few weeks when somebody accidentally connects a test
cluster intended to be on a private onto the camous network.
You may be right, though, that a broadcast address of would be needed to make sure that it does

>> The second exception is if your routers are configured
>> route broadcast messages to be beyond the subnet
>> on which they originate. In that case, you could again
>> use the single broadcast address or
>> the 3 individual broadcast addresses (2 through 4 in
>> your list). Again, it might or might not work in your
>> existing network configuration.
> No - "directed broadcast" could work if the routers are so configured
> (which they typically aren't, but that could perhaps be changed) - but
> it still requires that ntpd actually sends out packets with each of the
> per-network broadcast addresses. But here another problem arises - none
> of the client-network broadcast addresses are broadcast addresses on the
> server network. I'm not sure what ntpd will do with "broadcast" lines
> with an address that isn't actually a broadcast address on any directly-
> connected network - it would "just" need to send the packets out with
> the given address and let the kernel routing deal with it, but in case
> it searches for a local interface with the given broadcast address, it
> won't find one.

I think that's what I said without getting into details
that OP would not know what to do with.

>> What will work, without question, is not using
>> broadcast in the first place. You will have to work
>> with the company who supplied your systems to fix
>> the problem. You should continue this discussion
>> with them. This is really no longer about NTP.
>> It is about your network design.
> Agreed - sorry for pushing the subject further off-topic.:-)

It seems to be a prerequisite of posting here. :-)


More information about the questions mailing list