Source address in response not the same astarget address in request - NTP

This is a discussion on Source address in response not the same astarget address in request - NTP ; I have NTP server running on two Red Hat boxes. Each box has a primary address on eth0, and share a virtual IP address that is managed by linux-ha heartbeat. NTP requests sent to the virtual IP address are responded ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Source address in response not the same astarget address in request

  1. Source address in response not the same astarget address in request

    I have NTP server running on two Red Hat boxes. Each box has a primary
    address on eth0, and share a virtual IP address that is managed by linux-ha
    heartbeat.

    NTP requests sent to the virtual IP address are responded to by the primary
    address of eth0 on the server that is handling requests at the time. Thus,
    if I execute an "ntpdate -q 10.0.0.1" where 10.0.0.1 is the virtual IP of
    eth0:0 and 10.0.0.2 is the IP of eth0, the response is sourced from
    10.0.0.2. Thus, the ntpdate query fails with the message "no server
    suitable for synchronization found".

    I found this thread
    http://lists.ntp.isc.org/pipermail/q...er/016262.html that
    touches on the subject.

    I found another thread that states:

    pick up a version 4.2.4p2 or above:
    ....
    ntpd will ALWAYS bind to all interface addresses but each interface address
    can be Enabled or Disabled. Enable means packets will be received and
    processed
    by the packet reception logic. Disable means that these packets are dropped
    right away

    I am running ntpd 4.2.0a which is the version that comes with RHEL 4 Update
    6.

    So, if I read this correctly, I should be able to upgrade to 4.2.4x and
    configure NTP to not bind to eth0, so it will receive and respond to
    requests only on the virtual interface eth0:0?

    Thanks!

    Phil

  2. Re: Source address in response not the same astarget address in request

    Phil_Newlon@wendys.com wrote:
    > I have NTP server running on two Red Hat boxes. Each box has a primary
    > address on eth0, and share a virtual IP address that is managed by linux-ha
    > heartbeat.
    >
    > NTP requests sent to the virtual IP address are responded to by the primary
    > address of eth0 on the server that is handling requests at the time. Thus,
    > if I execute an "ntpdate -q 10.0.0.1" where 10.0.0.1 is the virtual IP of
    > eth0:0 and 10.0.0.2 is the IP of eth0, the response is sourced from
    > 10.0.0.2. Thus, the ntpdate query fails with the message "no server
    > suitable for synchronization found".
    >
    > I found this thread
    > http://lists.ntp.isc.org/pipermail/q...er/016262.html that
    > touches on the subject.
    >
    > I found another thread that states:
    >
    > pick up a version 4.2.4p2 or above:
    > ...
    > ntpd will ALWAYS bind to all interface addresses but each interface address
    > can be Enabled or Disabled. Enable means packets will be received and
    > processed
    > by the packet reception logic. Disable means that these packets are dropped
    > right away
    >
    > I am running ntpd 4.2.0a which is the version that comes with RHEL 4 Update
    > 6.
    >
    > So, if I read this correctly, I should be able to upgrade to 4.2.4x and
    > configure NTP to not bind to eth0, so it will receive and respond to
    > requests only on the virtual interface eth0:0?
    >
    > Thanks!
    >
    > Phil


    Noone appears to have answered you and I've been too busy to respond.

    The general answer is no. It binds to all addresses but use of the -L
    option will mean that it ignores anything not received on :0 interfaces
    which is what I think you are saying. An enhancement that I have worked
    on will allow you to specify the addresses to listen on and to send on.
    It's not ready yet.

    Danny

  3. Re: Source address in response not the same as target address in request

    Danny Mayer wrote:
    > The general answer is no. It binds to all addresses but use of the
    > -L option will mean that it ignores anything not received on :0
    > interfaces which is what I think you are saying. An enhancement that
    > I have worked on will allow you to specify the addresses to listen
    > on and to send on. It's not ready yet.


    If it simply sends via the socket on which the query was recieved,
    having bound that socket to a given IP should result in that IP being
    used as the source IP of the response.

    Perhaps there is a reason to send via another socket, but as I'm
    typing I cannot think of it.

    rick jones
    --
    web2.0 n, the dot.com reunion tour...
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  4. Re: Source address in response not the same astarget address in request

    Rick Jones wrote:
    > Danny Mayer wrote:
    >> The general answer is no. It binds to all addresses but use of the
    >> -L option will mean that it ignores anything not received on :0
    >> interfaces which is what I think you are saying. An enhancement that
    >> I have worked on will allow you to specify the addresses to listen
    >> on and to send on. It's not ready yet.

    >
    > If it simply sends via the socket on which the query was recieved,
    > having bound that socket to a given IP should result in that IP being
    > used as the source IP of the response.
    >
    > Perhaps there is a reason to send via another socket, but as I'm
    > typing I cannot think of it.
    >
    > rick jones


    NTP always replies on the same interface with the same IP address. It
    should never reply with a different IP address as the receiving end
    would drop it as invalid.

    Danny

  5. Re: Source address in response not the same as target address in request

    Danny Mayer wrote:
    > Rick Jones wrote:
    > > If it simply sends via the socket on which the query was recieved,
    > > having bound that socket to a given IP should result in that IP being
    > > used as the source IP of the response.
    > >
    > > Perhaps there is a reason to send via another socket, but as I'm
    > > typing I cannot think of it.
    > >
    > > rick jones


    > NTP always replies on the same interface with the same IP address. It
    > should never reply with a different IP address as the receiving end
    > would drop it as invalid.


    Did you mean to say "replies on the same socket?" To a networking guy
    "socket" is distinct from interface (eg NIC) and from the first hop
    routing decision to be made by the stack.

    Soooo, if NTP is replying on the same socket, and it _isn't_ the/a
    wildcard socket, then the source IP's should already be correct and
    the mystery would seem to deepen.

    Might be a good idea for the OP to get a system call trace of NTP,
    preferably including the creation and binding of the sockets and then
    the receipt and sending of a response.

    rick jones
    --
    oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

+ Reply to Thread