[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 145.47.51.127 key 1
>>>>> broadcast 145.47.51.255 key 1
>>>>> broadcast 145.47.52.127 key 1
>>>>> broadcast 145.47.53.127 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) 145.47.51.0/25 and b) 145.47.51.128/25, the address
> 145.47.51.255 doesn't "include" 145.47.51.127 in any way. 145.47.51.127
> is the broadcast address for a), 145.47.51.255 is the broadcast address
> for b) - and hosts on network a) will not see 145.47.51.255 as a
> broadcast address - in fact they will just see it as a random address on
> a remote network. A broadcast address is either 255.255.255.255 or one
> where the network part matches exactly and the host part is all-ones.

145.47.51.0/25 = *.0-127
    broadcast 145.47.51.127 broadcasts to all of them
145.47.51.128/25 = = *.128-255
    broadcast 145.47.51.255 broadcasts to all of them

145.47.51.0/24 - *.0-255
    broadcast 145.47.51.255 broadcasts to all of them

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

> 
>>> 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 . . . . . . . . . . . . . . .: 145.47.54.146
>>> Subnetmask . . . . . . . . . . . .: 255.255.255.128
>>> Standaardgateway . . . . . . . .: 145.47.54.129
>>>
>>> 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 145.47.63.255
>> 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
255.255.255.255 would be needed to make sure that it does
work.

> 
>> 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 145.47.63.255 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. :-)

-Tom




More information about the questions mailing list