unexpected multicast client operation - NTP

This is a discussion on unexpected multicast client operation - NTP ; Hi, I am using the NTPD (v4.1 I think) that comes out of the box with RHEL 3 and I have multicast set up. What I am seeing confuses me though. Every time the server sends the multicast packet the ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: unexpected multicast client operation

  1. unexpected multicast client operation

    Hi,

    I am using the NTPD (v4.1 I think) that comes out of the box with RHEL 3
    and I have multicast set up. What I am seeing confuses me though.
    Every time the server sends the multicast packet the client on the RHEL3
    machine does a client/server NTP transaction back to the server. Isn't the
    whole purpose of multicast so the clients just all listen and not talk to the server ?

    I dont have the server listed in the clients config so it is finding the
    server via the multicast message.

    thx

  2. Re: unexpected multicast client operation

    On 2007-02-21, none wrote:

    > I am using the NTPD (v4.1 I think) that comes out of the box with RHEL 3
    > and I have multicast set up. What I am seeing confuses me though.
    > Every time the server sends the multicast packet the client on the RHEL3
    > machine does a client/server NTP transaction back to the server.


    What you are seeing is normal. A multicast-client will use temporary
    unicast association with the multicast-server to determine the delay.

    You can supress this (w/ novolley) but then you will need to determine
    the delay manually.

    > Isn't the whole purpose of multicast so the clients just all listen
    > and not talk to the server ?


    No. Multicast association _can_ be used in architectures which only allow
    one-way communication.

    > I dont have the server listed in the clients config so it is finding the
    > server via the multicast message.


    If you _did_ have that server explicitly listed in a "client" ntp.conf
    that client would bring up a unicast assocciation with the server and
    would never bring up the multicast association.

    --
    Steve Kostecke
    NTP Public Services Project - http://ntp.isc.org/

  3. Re: unexpected multicast client operation

    On Wed, 21 Feb 2007 14:18:42 -0800, Steve Kostecke wrote:

    > On 2007-02-21, none wrote:
    >
    >> I am using the NTPD (v4.1 I think) that comes out of the box with RHEL 3
    >> and I have multicast set up. What I am seeing confuses me though.
    >> Every time the server sends the multicast packet the client on the RHEL3
    >> machine does a client/server NTP transaction back to the server.

    >
    > What you are seeing is normal. A multicast-client will use temporary
    > unicast association with the multicast-server to determine the delay.
    >
    > You can supress this (w/ novolley) but then you will need to determine
    > the delay manually.
    >
    >> Isn't the whole purpose of multicast so the clients just all listen
    >> and not talk to the server ?

    >
    > No. Multicast association _can_ be used in architectures which only allow
    > one-way communication.
    >
    >> I dont have the server listed in the clients config so it is finding the
    >> server via the multicast message.

    >
    > If you _did_ have that server explicitly listed in a "client" ntp.conf
    > that client would bring up a unicast assocciation with the server and
    > would never bring up the multicast association.


    Thankyou for the clarifications !

  4. Re: unexpected multicast client operation

    none wrote:
    > Hi,
    >
    > I am using the NTPD (v4.1 I think) that comes out of the box with RHEL 3


    You should upgrade to 4.2.4 which fixes a lot of issues with
    multicasting (released in 4.2.2, but 4.2.4 is the latest release).

    > and I have multicast set up. What I am seeing confuses me though.
    > Every time the server sends the multicast packet the client on the RHEL3
    > machine does a client/server NTP transaction back to the server. Isn't the
    > whole purpose of multicast so the clients just all listen and not talk to the server ?
    >


    You need to understand what the default behavior of multicast is. By
    default, when a multicast client receives a multicast packet, it sends a
    return packet to the server sending the packet in order to authenticate
    the multicast provider otherwise anyone can set up a multicast server
    and send packets to anyone and have them being accepted. What you see is
    the beginning of what Dave calls the key dance. During this process the
    client and server act in client/server mode until the client is either
    able to authenticate the server or able to reject it. Once authenticated
    it will just accept the multicast packets. After a certain time period
    it needs to reauthenticate the server. Note that an additional benefit
    of all this is that it is able to get a measure of the offset of the
    client from the server (via the roundtrip time for packets). The only
    way that this will not happen is if the client disables authentication
    and then you are at the mercy of whatever is sending you multicast
    packets. You also have no idea what the offset is to the server.

    > I dont have the server listed in the clients config so it is finding the
    > server via the multicast message.
    >


    Yes, it looks at the senders IP address and sends a client packet to it
    with the authentication query.

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


  5. Re: unexpected multicast client operation

    Steve Kostecke wrote:
    > You can supress this (w/ novolley) but then you will need to determine
    > the delay manually.
    >


    Not with multicastclient. It's only valid with broadcastclient.

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


  6. Re: unexpected multicast client operation

    Danny,

    The mechanism works for both multicast and broadcast; however, the
    multicast configuration syntax gets in the way. The parser could be
    easily changed to recognize novolley as not a host hame, but then I
    guarantee that somebody will bring up a host with that name.

    Originally, things like this were intended to be fixed using the new
    syntax-driven configuration code, but that project appears dead in the soup.

    Dave

    Danny Mayer wrote:

    > Steve Kostecke wrote:
    >
    >>You can supress this (w/ novolley) but then you will need to determine
    >>the delay manually.
    >>

    >
    >
    > Not with multicastclient. It's only valid with broadcastclient.
    >
    > Danny
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.isc.org
    > https://lists.ntp.isc.org/mailman/listinfo/questions
    >


+ Reply to Thread