(Software) timeserver for windows being broadcast-able incl. keys - NTP

This is a discussion on (Software) timeserver for windows being broadcast-able incl. keys - NTP ; Tom Smith wrote: >> Do you have any idea why (in the ntp.keys-file on all clients) more >> than one key is specified? > > You'll have to ask whomever put them there. Presumably because > at one time different ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 42

Thread: (Software) timeserver for windows being broadcast-able incl. keys

  1. Re: (Software) timeserver for windows beingbroadcast-able incl. keys

    Tom Smith wrote:
    >> Do you have any idea why (in the ntp.keys-file on all clients) more
    >> than one key is specified?

    >
    > You'll have to ask whomever put them there. Presumably because
    > at one time different keys were used for different purposes
    > somebody thought they would be.
    >


    Well each server, broadcast line, etc. can use a different key. There's
    no requirement to use the same key for all packets sent from the server.

    Danny
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  2. Re: (Software) timeserver for windows being broadcast-able incl. keys

    Hello Tom

    you're right, were actually several network segments listed falsely
    together
    The .194 indeed should be .192. This is the complete listing:

    145.47.51.[016-067]
    with netmask 255.255.255.128
    => broadcast-address 145.47.51.127

    145.47.51.[144-183]
    with netmask 255.255.255.128
    => broadcast-address 145.47.51.255

    145.47.52.[032-047]
    with netmask 255.255.255.128
    => broadcast-address 145.47.52.127

    145.47.53.[076-091]
    with netmask 255.255.255.192
    => broadcast-address 145.47.53.127


    >> - Does the above require me to use more than one broadcast-address?


    > Yes.


    >From the PC which I want to act as broadcaster I can reach all above

    network segments
    Assuming the switches/routers between these segements are configured
    to pass these broadcasts,
    can I therefore set up the following 4 lines of the "broadcast"-code
    in the ntp.conf-file ?

    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

    Or did I understand you incorrectly ?


    > OK. Then if there is no legacy system to support, why don't
    > you just reconfigure the clients into something rational?
    > For example, get rid of the keys and the broadcast, and just
    > point each client to the server with a simple "server [address]"
    > declaration.


    I agree, yet, the specific systems involved are maintained / serviced
    by the
    company who built them. The changes required to change the way of
    time synchronisation are set under master user, yet password is not
    given to customer. This means, systems are (on Linux-level) as-is


    Thanks once again
    Erik


  3. Re: (Software) timeserver for windows being broadcast-able incl. keys

    On 15 mrt, 02:35, m...@ntp.isc.org (Danny Mayer) wrote:

    > Tom Smith wrote:
    > >> Do you have any idea why (in the ntp.keys-file on all clients) more
    > >> than one key is specified?

    >
    > Well each server, broadcast line, etc. can use a different key. There's
    > no requirement to use the same key for all packets sent from the server.
    >
    > Danny
    > _______________________________________________


    Ok, could well be the reason.
    Thanks
    Erik


  4. Re: (Software) timeserver for windows being broadcast-able incl.keys

    Erik wrote:
    >>From the PC which I want to act as broadcaster I can reach all above

    > network segments
    > Assuming the switches/routers between these segements are configured
    > to pass these broadcasts,
    > can I therefore set up the following 4 lines of the "broadcast"-code
    > in the ntp.conf-file ?
    >
    > 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
    >
    > Or did I understand you incorrectly ?


    That's the right idea, but the second one above already
    includes the first.

    Your network configuration seems a little strange.
    What is the address and netmask of your server (or
    the addresses and netmasks if it has multiple interfaces)?
    You should probably just broadcast to whatever subnet(s)
    it is on. You need one broadcast statement for each
    interface on the server.

    -Tom

  5. Re: (Software) timeserver for windows being broadcast-able incl.keys

    Danny Mayer wrote:
    > Tom Smith wrote:
    >
    >>>Do you have any idea why (in the ntp.keys-file on all clients) more
    >>>than one key is specified?

    >>
    >>You'll have to ask whomever put them there. Presumably because
    >>at one time different keys were used for different purposes
    >>somebody thought they would be.
    >>

    >
    >
    > Well each server, broadcast line, etc. can use a different key. There's
    > no requirement to use the same key for all packets sent from the server.
    >
    > Danny


    There may be three keys in the ntp.keys file because one was used to
    authenticate the server to the client, one was used to access the
    privileged functions of ntpq and another to access the privileged
    functions of ntpdc. These keys may be designated as the "trusted key",
    the, "request key" (ntpdc) and the "control key" (ntpq).

    Another possibility is that three keys were intended for use by three
    different servers.

    Note that the ntp.conf file allows comments. Comments should be used
    liberally to document what you did, why you did it, and perhaps even
    when you did it. Unless you have a perfect memory you will need to
    refer to those comments sooner or later. Even if you do have a perfect
    memory, someone else may need to understand what you did and why.



  6. Re: (Software) timeserver for windows being broadcast-able incl. keys

    On 15 mrt, 17:21, Tom Smith 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.
    >
    > Your network configuration seems a little strange.
    > What is the address and netmask of your server (or
    > the addresses and netmasks if it has multiple interfaces)?
    > You should probably just broadcast to whatever subnet(s)
    > it is on. You need one broadcast statement for each
    > interface on the server.
    >


    Hi Tom

    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?

    Kind regards
    Erik


  7. Re: (Software) timeserver for windows being broadcast-able incl. keys

    On 15 mrt, 19:23, "Richard B. gilbert" wrote:
    > Danny Mayer wrote:
    >
    > >>>Do you have any idea why (in the ntp.keys-file on all clients) more
    > >>>than one key is specified?


    > There may be three keys in the ntp.keys file because one was used to
    > authenticate the server to the client, one was used to access the
    > privileged functions of ntpq and another to access the privileged
    > functions of ntpdc. These keys may be designated as the "trusted key",
    > the, "request key" (ntpdc) and the "control key" (ntpq).


    Danny,

    thanks for the input but for me as a novice:
    how does this fit into the principle of using 'broadcast
    xxx.xxx.xxx.xxx key xx' as the way of time-correction?
    That is, when your assumption above is correct, I can still use only
    one key, namely the assumed key to identify the server
    (because I see no way of sending along the other two; see also
    discussion in this thread's history with others confirming the
    impossibility)
    >
    > Another possibility is that three keys were intended for use by three
    > different servers.


    ok, possibly

    > Note that the ntp.conf file allows comments. Comments should be used
    > liberally to document what you did, why you did it, and perhaps even
    > when you did it. Unless you have a perfect memory you will need to
    > refer to those comments sooner or later. Even if you do have a perfect
    > memory, someone else may need to understand what you did and why


    Agree, yet file was not created by me, but I guess I have to suffer

    Thanks
    Erik


  8. Re: (Software) timeserver for windows being broadcast-able incl.keys

    Erik wrote:
    > On 15 mrt, 17:21, Tom Smith 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.
    >>
    >> Your network configuration seems a little strange.
    >> What is the address and netmask of your server (or
    >> the addresses and netmasks if it has multiple interfaces)?
    >> You should probably just broadcast to whatever subnet(s)
    >> it is on. You need one broadcast statement for each
    >> interface on the server.
    >>

    >
    > Hi Tom
    >
    > 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.

    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.

    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.

    -Tom

  9. Re: (Software) timeserver for windows being broadcast-able incl.keys

    Erik wrote:
    > On 15 mrt, 19:23, "Richard B. gilbert" wrote:
    >
    >>Danny Mayer wrote:
    >>
    >>
    >>>>>Do you have any idea why (in the ntp.keys-file on all clients) more
    >>>>>than one key is specified?
    >>>>


    >
    >>Note that the ntp.conf file allows comments. Comments should be used
    >>liberally to document what you did, why you did it, and perhaps even
    >>when you did it. Unless you have a perfect memory you will need to
    >>refer to those comments sooner or later. Even if you do have a perfect
    >>memory, someone else may need to understand what you did and why

    >
    >
    > Agree, yet file was not created by me, but I guess I have to suffer
    >
    > Thanks
    > Erik
    >


    I was really writing about eliminating future suffering. There is a
    good chance that someday, someone else will need to understand how your
    NTP subnet is configured.

    Do something like this.

    #
    # Authentication parameters
    #
    keys /etc/inet/ntp.keys
    trustedkey 4 5 6 # Used by Servers A, B & C respectively
    controlkey 3 # To access the ntpq utility
    requestkey 2 # To access the ntpdc utility


  10. Re: (Software) timeserver for windows being broadcast-able incl.keys

    In article <45FAAA30.2080401@cag.zko.hp.com> Tom Smith
    writes:
    >Erik wrote:
    >> On 15 mrt, 17:21, Tom Smith 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.

    >> 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.

    >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.

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

    --Per Hedeland
    per@hedeland.org

  11. Re: (Software) timeserver for windows being broadcast-able incl.keys

    Per Hedeland wrote:
    > In article <45FAAA30.2080401@cag.zko.hp.com> Tom Smith
    > writes:
    >> Erik wrote:
    >>> On 15 mrt, 17:21, Tom Smith 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

  12. Re: (Software) timeserver for windows beingbroadcast-able incl. keys

    Tom Smith wrote:
    > Erik wrote:
    >> On 15 mrt, 17:21, Tom Smith 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.
    >>>
    >>> Your network configuration seems a little strange.
    >>> What is the address and netmask of your server (or
    >>> the addresses and netmasks if it has multiple interfaces)?
    >>> You should probably just broadcast to whatever subnet(s)
    >>> it is on. You need one broadcast statement for each
    >>> interface on the server.
    >>>

    >> Hi Tom
    >>
    >> 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.
    >
    > 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.
    >
    > 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.
    >
    > -Tom


    This is beginning to sound like he should be using Multicast rather than
    Broadcast. It's a lot more controllable and directable to do what he needs,

    Danny
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  13. Re: (Software) timeserver for windows being broadcast-able incl. keys

    controlkey 3 # To access the ntpq utility

    See http://bugs.ntp.isc.org/418 . controlkey has apparently never worked.

    H


  14. Re: (Software) timeserver for windows being broadcast-able incl.keys

    In article <45FB2283.8000201@cag.zko.hp.com> Tom Smith
    writes:
    >Per Hedeland wrote:
    >> In article <45FAAA30.2080401@cag.zko.hp.com> Tom Smith
    >> writes:
    >>> Erik wrote:
    >>>> On 15 mrt, 17:21, Tom Smith 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


    Yes of course - but the 2 x /25 and the 1 x /24 are two different cases,
    and according to the OP /25 was used here.

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


    No, regardless of whether the subnets are on the same wire, or whether
    routers forward directed broadcasts, the hosts on 145.47.51.0/25 will
    never see 145.47.51.255 as a broadcast address. For route advertisement
    to remote networks, adjacent subnets can and should be aggregated -
    i.e. the router that has both 145.47.51.0/25 and 145.47.51.128/25 can
    advertise 145.47.51.0/24 - but that doesn't change the local broadcast
    address on those networks, of course.

    The remaining points seem to result from a similar misconception, so I
    won't comment further on them.

    --Per Hedeland
    per@hedeland.org

  15. Re: (Software) timeserver for windows being broadcast-able incl.keys

    Harlan Stenn wrote:
    > controlkey 3 # To access the ntpq utility
    >
    > See http://bugs.ntp.isc.org/418 . controlkey has apparently never worked.
    >
    > H
    >


    I don't think I've ever tried it! I never needed to. I do use the
    request key with ntpdc occasionally.


  16. Re: (Software) timeserver for windows beingbroadcast-able incl. keys

    Per Hedeland wrote:
    > In article <45FAAA30.2080401@cag.zko.hp.com> Tom Smith
    > writes:
    >> Erik wrote:
    >>> On 15 mrt, 17:21, Tom Smith 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.
    >


    There's currently a problem with the broadcast address 255.255.255.255
    (see bug #779 https://ntp.isc.org/bugs/show_bug.cgi?id=779) so don't use it.

    Danny

    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  17. Re: (Software) timeserver for windows being broadcast-able incl.keys

    Danny Mayer wrote:
    > Tom Smith wrote:
    >> Erik wrote:
    >>> On 15 mrt, 17:21, Tom Smith 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.
    >>>>
    >>>> Your network configuration seems a little strange.
    >>>> What is the address and netmask of your server (or
    >>>> the addresses and netmasks if it has multiple interfaces)?
    >>>> You should probably just broadcast to whatever subnet(s)
    >>>> it is on. You need one broadcast statement for each
    >>>> interface on the server.
    >>>>
    >>> Hi Tom
    >>>
    >>> 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.
    >>
    >> 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.
    >>
    >> 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.
    >>
    >> -Tom

    >
    > This is beginning to sound like he should be using Multicast rather than
    > Broadcast. It's a lot more controllable and directable to do what he needs,
    >
    > Danny


    Unfortunately, Erik seems to be between a rock and a hard place.
    He can't change the clients, which have all been configured as
    broadcast clients, but the current network design and server
    configuration won't support broadcast unless another unusual
    condition is also present - single VLAN or routed broadcast packets.

    He can change the server - address(es)/netmask(s), maybe add NICs -
    and maybe he can change the router configuration. What he can't
    change at the moment is the clients, so he's stuck with trying
    to find a broadcast solution that hits 4 different subnets of
    different sizes.

    I'm sure Erik would rather be doing something else by now. :-)

    -Tom

  18. Re: (Software) timeserver for windows being broadcast-able incl. keys

    On Mar 18, 12:09 am, Tom Smith wrote:

    > He can change the server - address(es)/netmask(s), maybe add NICs -
    > and maybe he can change the router configuration. What he can't
    > change at the moment is the clients, so he's stuck with trying
    > to find a broadcast solution that hits 4 different subnets of
    > different sizes.
    >
    > I'm sure Erik would rather be doing something else by now. :-)


    Agreed. I'd work with the manufacturer to change the clients; surely
    other customers of theirs have the similar issues. Erik really needs a
    unicast or multicast setup for NTP because the network topology.

    If the clients absolutely cannot change for any reason, the final
    option would be a "brute force" approach: actually put a physical NTP
    server (old junk PC running Linux or *BSD) in each of the four
    subnets. Have each of these broadcast to its local subnet, while
    getting the time from your main time server (and some other time
    sources from off-network).

    If money isn't an issue, you could even get some nice little Soekris
    or Gumstix boxes to be time servers for each subnet. This could be
    cheaper and easier than re-architecting the network topology to be
    "flatter".

    Regards,
    Ryan


  19. Re: (Software) timeserver for windows being broadcast-able incl. keys

    On 18 mrt, 06:09, Tom Smith wrote:
    > Unfortunately, Erik seems to be between a rock and a hard place.
    > He can't change the clients, which have all been configured as
    > broadcast clients, but the current network design and server
    > configuration won't support broadcast unless another unusual
    > condition is also present - single VLAN or routed broadcast packets.
    >
    > He can change the server - address(es)/netmask(s), maybe add NICs -
    > and maybe he can change the router configuration. What he can't
    > change at the moment is the clients, so he's stuck with trying
    > to find a broadcast solution that hits 4 different subnets of
    > different sizes.


    Right!

    > I'm sure Erik would rather be doing something else by now. :-)


    No, not at all; find it interesting to see everyone putting effort in
    helping me get on track


  20. Re: (Software) timeserver for windows being broadcast-able incl. keys

    On 18 mrt, 13:43, "Ryan Malayter" wrote:
    > On Mar 18, 12:09 am, Tom Smith wrote:
    >
    > > He can change the server - address(es)/netmask(s), maybe add NICs -
    > > and maybe he can change the router configuration. What he can't
    > > change at the moment is the clients, so he's stuck with trying
    > > to find a broadcast solution that hits 4 different subnets of
    > > different sizes.

    >
    > > I'm sure Erik would rather be doing something else by now. :-)

    >
    > Agreed. I'd work with the manufacturer to change the clients; surely
    > other customers of theirs have the similar issues. Erik really needs a
    > unicast or multicast setup for NTP because the network topology.
    >
    > If the clients absolutely cannot change for any reason, the final
    > option would be a "brute force" approach: actually put a physical NTP
    > server (old junk PC running Linux or *BSD) in each of the four
    > subnets. Have each of these broadcast to its local subnet, while
    > getting the time from your main time server (and some other time
    > sources from off-network).
    >
    > If money isn't an issue, you could even get some nice little Soekris
    > or Gumstix boxes to be time servers for each subnet. This could be
    > cheaper and easier than re-architecting the network topology to be
    > "flatter".
    >
    > Regards,
    > Ryan


    Hello Ryan, (Tom, Danny, . name list is quite long already ;-)

    I have tried to understand the discussion up till now but because of
    lack of knowledge on this matter
    (as well as English not being my native language) I must admit I do
    not fully understand it

    What I do understand is that the difficulty is in the combination of
    broadcast-time-correcting inchangeable
    (broadcast-)clients on different network segments by one server

    What I still would like to know:

    Is the following (earlier posted) idea...

    >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


    ...from server...

    >IP-adres . . . . . . . . . . . . . . .: 145.47.54.146
    >Subnetmask . . . . . . . . . . . .: 255.255.255.128
    >Standaardgateway . . . . . . . .: 145.47.54.129


    .... definetely useless or still worth a try?

    BTW: the manufacturer advises to install its systems in the same
    network segment behind a router to be coupled with the company-VLAN
    The time server, being on the same router, will be able to reach all
    clients by broadcast
    Yet, here we do not have networks-per-manufacturer but mixed networks,
    resulting in a network with systems of this manufacturer
    spread across the whole network (which is divided into several
    subnets)

    Kind regards and thank you for the good discussion so far

    Erik
    Holland


+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast