Trouble creating symmetric connection - NTP

This is a discussion on Trouble creating symmetric connection - NTP ; I have trouble getting two ntp servers to peer with each other. What I do is first ntpdc -c 'restrict B.B.B.B 255.255.255.255 nomodify notrap' A.A.A.A ntpdc -c 'restrict A.A.A.A 255.255.255.255 nomodify notrap' B.B.B.B after which ntpdc -creslist echoes back appropriate ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Trouble creating symmetric connection

  1. Trouble creating symmetric connection

    I have trouble getting two ntp servers to peer with each other.
    What I do is first

    ntpdc -c 'restrict B.B.B.B 255.255.255.255 nomodify notrap' A.A.A.A
    ntpdc -c 'restrict A.A.A.A 255.255.255.255 nomodify notrap' B.B.B.B

    after which ntpdc -creslist echoes back appropriate restrict lines
    with the only flags being nomodify and notrap - so I'm reasonably sure
    that the servers do allow each others as peers, and that my remote
    configuration commands are being carried out. Now:

    ntpdc -c 'addpeer B.B.B.B' A.A.A.A

    and wait a few minutes for packets to be exchanged; then

    ntpdc -c peers A.A.A.A
    ntpdc -c peers B.B.B.B

    After this A.A.A.A does list B.B.B.B as an association in
    'symmetric-active' mode, and it appears to get nontrivial time
    variables over this association, som B.B.B.B must be answering.

    However, I had expected that B.B.B.B would list A.A.A.A as an
    association in 'symmetric-passive' mode, but it doesn't. Shouldn't it?
    The peer listing of B.B.B.B does not mention A.A.A.A at all.

    Furthermore, if I unconfigure all of the servers the B.B.B.B used
    to get time from, it will eventually revert to its undisciplined
    local clock at stratum 13, rather than use the stratum-4-or-so time
    it could have gotten from A.A.A.A. So it's actually not recognizing
    A.A.A.A as a peer; it is not just the ntpdc listing that is buggy.

    Both servers run Debian 'sarge' with its default ntp-server package.

    I suspect I'm missing something really basic, but what? I have read
    the ntp documentation and googled many possible search-term
    combinations to no avail.

    --
    Henning Makholm "Det er jo svært at vide noget når man ikke ved det, ikke?"

  2. Re: Trouble creating symmetric connection

    Henning Makholm wrote:

    > I have trouble getting two ntp servers to peer with each other.


    [snip]

    > ntpdc -c 'addpeer B.B.B.B' A.A.A.A
    >
    > and wait a few minutes for packets to be exchanged; then
    >
    > ntpdc -c peers A.A.A.A
    > ntpdc -c peers B.B.B.B
    >
    > After this A.A.A.A does list B.B.B.B as an association in
    > 'symmetric-active' mode, and it appears to get nontrivial time
    > variables over this association, som B.B.B.B must be answering.
    >
    > However, I had expected that B.B.B.B would list A.A.A.A as an
    > association in 'symmetric-passive' mode, but it doesn't. Shouldn't it?


    Only if you have authentication turned off, which is inadvisable.
    Better to make both symmetric-active:

    ntpdc -c 'addpeer B.B.B.B' A.A.A.A
    ntpdc -c 'addpeer A.A.A.A' B.B.B.B

    [more snip]

    --
    Ronan Flood

  3. Re: Trouble creating symmetric connection

    Scripsit Ronan Flood
    > Henning Makholm wrote:


    >> However, I had expected that B.B.B.B would list A.A.A.A as an
    >> association in 'symmetric-passive' mode, but it doesn't. Shouldn't it?


    > Only if you have authentication turned off, which is inadvisable.
    > Better to make both symmetric-active:


    > ntpdc -c 'addpeer B.B.B.B' A.A.A.A
    > ntpdc -c 'addpeer A.A.A.A' B.B.B.B


    I though the point of "addpeer" was that a single association could
    transfer time in any direction (and I still have trouble reading
    the documentation any other way). If I need to make two associations,
    then why not just do

    ntpdc -c 'addserver B.B.B.B' A.A.A.A
    ntpcd -c 'addserver A.A.A.A' B.B.B.B

    i.e. what is the difference between a client connection and a peer
    connection if both are unidirectional?


    Hm, on further experimentation it does work in two directions with
    authentified messages. I tried this before without success, but it
    works after I switched to a 'M' (md4) key instead of an 'A' (des) key
    with the same password for the authentication. Are there known bugs
    in the DES authentication code?

    --
    Henning Makholm "Jeg køber intet af Sulla, og selv om uordenen griber
    planmæssigt om sig, så er vi endnu ikke nået dertil hvor
    ordentlige mennesker kan tillade sig at stjæle slaver fra
    hinanden. Så er det ligegyldigt, hvor stærke, politiske modstandere vi er."

  4. Re: Trouble creating symmetric connection

    >>> In article <87y7m8ap7g.fsf@kreon.lan.henning.makholm.net>, Henning Makholm writes:

    Henning> Hm, on further experimentation it does work in two directions with
    Henning> authentified messages. I tried this before without success, but it
    Henning> works after I switched to a 'M' (md4) key instead of an 'A' (des)
    Henning> key with the same password for the authentication. Are there known
    Henning> bugs in the DES authentication code?

    No, but md5 code is freely available and exportable, while DES is not.

    I'd have to dig into the code to see if DES is still supported for private
    key usage (ntp.keys file).

    H

  5. Re: Trouble creating symmetric connection

    Henning,

    'M' stands for MD5; the DES crypto code is no longer in the
    distribution. I haven't tried using a DES key with the MD5 crypto code.
    Goshdarn it might even work sorta, but not a good idea.

    Think of peer (symmetric mode) as each machine functioning
    simultaneously as a client and a server for the other machine. Time
    flows from the machine at the lower stratum to the other machine.
    Usually, both peers are clients of different lower stratum servers and
    usually operate at the same stratum, so time doesn't flow between them.
    However, if a lower stratum server fails, then the orphan peer switches
    to the other peer.

    Dave

    Henning Makholm wrote:

    > Scripsit Ronan Flood
    >
    >>Henning Makholm wrote:

    >
    >
    >>>However, I had expected that B.B.B.B would list A.A.A.A as an
    >>>association in 'symmetric-passive' mode, but it doesn't. Shouldn't it?

    >
    >
    >>Only if you have authentication turned off, which is inadvisable.
    >>Better to make both symmetric-active:

    >
    >
    >> ntpdc -c 'addpeer B.B.B.B' A.A.A.A
    >> ntpdc -c 'addpeer A.A.A.A' B.B.B.B

    >
    >
    > I though the point of "addpeer" was that a single association could
    > transfer time in any direction (and I still have trouble reading
    > the documentation any other way). If I need to make two associations,
    > then why not just do
    >
    > ntpdc -c 'addserver B.B.B.B' A.A.A.A
    > ntpcd -c 'addserver A.A.A.A' B.B.B.B
    >
    > i.e. what is the difference between a client connection and a peer
    > connection if both are unidirectional?
    >
    >
    > Hm, on further experimentation it does work in two directions with
    > authentified messages. I tried this before without success, but it
    > works after I switched to a 'M' (md4) key instead of an 'A' (des) key
    > with the same password for the authentication. Are there known bugs
    > in the DES authentication code?
    >


  6. Re: Trouble creating symmetric connection

    Henning Makholm wrote:

    > > Better to make both symmetric-active:

    >
    > > ntpdc -c 'addpeer B.B.B.B' A.A.A.A
    > > ntpdc -c 'addpeer A.A.A.A' B.B.B.B

    >
    > I though the point of "addpeer" was that a single association could
    > transfer time in any direction (and I still have trouble reading
    > the documentation any other way). If I need to make two associations,
    > then why not just do
    >
    > ntpdc -c 'addserver B.B.B.B' A.A.A.A
    > ntpcd -c 'addserver A.A.A.A' B.B.B.B
    >
    > i.e. what is the difference between a client connection and a peer
    > connection if both are unidirectional?


    I've nothing to add to Dave Mills' answer; I don't know what real
    difference there is, but at least it makes it obvious what you
    expect to happen, and both ends are clear about the relationship.

    Side comment: why are you doing all the config via ntpdc rather
    than putting it into the ntp.conf file?

    --
    Ronan Flood

  7. Re: Trouble creating symmetric connection

    Ronan Flood wrote:
    > Henning Makholm wrote:
    >
    >
    >>>Better to make both symmetric-active:

    >>
    >>> ntpdc -c 'addpeer B.B.B.B' A.A.A.A
    >>> ntpdc -c 'addpeer A.A.A.A' B.B.B.B

    >>
    >>I though the point of "addpeer" was that a single association could
    >>transfer time in any direction (and I still have trouble reading
    >>the documentation any other way). If I need to make two associations,
    >>then why not just do
    >>
    >> ntpdc -c 'addserver B.B.B.B' A.A.A.A
    >> ntpcd -c 'addserver A.A.A.A' B.B.B.B
    >>


    >
    > Side comment: why are you doing all the config via ntpdc rather
    > than putting it into the ntp.conf file?
    >


    Perhaps because he does not want to shut down ntpd and restart. Why do
    even a warm restart if you don't have to?





  8. Re: Trouble creating symmetric connection

    Scripsit mills@udel.edu

    > 'M' stands for MD5;


    Of course. Typo on my part.

    > the DES crypto code is no longer in the distribution.


    Whoops. I worked from the NTP FAQ which uses DES keys freely in
    section 6.2.2, and only mentions the absence of DES as an aside
    in 6.1.3.3 (which is not even where one would expect to find
    important caveats like that).

    > Think of peer (symmetric mode) as each machine functioning
    > simultaneously as a client and a server for the other machine. Time
    > flows from the machine at the lower stratum to the other
    > machine.


    I gathered at much from the docmentation, but it was not clear to me
    that it only works as described when the communication is
    authentified. On reflection I can see that it does make excellent
    sense to require authentification here, but it would have helped me
    if, say, the description of the 'nopeers' restriction keyword and/or
    the "peer" configuration command had included a short caveat that the
    association will only really be bidirectional if authentified (or if
    the auth flag is off).

    > Usually, both peers are clients of different lower stratum
    > servers and usually operate at the same stratum, so time doesn't flow
    > between them.


    Hmm, yes. Is there a way to specify that time should flow in the
    direction of larger synchronization distance, even at the possible
    expense of one of the servers operating on a higher stratum?
    Or is that a situation that is just expected not to happen?

    --
    Henning Makholm "... and that Greek, Thucydides"

+ Reply to Thread