NTP being rejected - Redhat

This is a discussion on NTP being rejected - Redhat ; Hi all, I have a strange one - but enough of my personal problems ;-) I have a small network, one machine acts as a ntp sever for my network (192.168.0.0) The windows machine sync fine - 100% The ntp ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: NTP being rejected

  1. NTP being rejected

    Hi all,

    I have a strange one - but enough of my personal problems ;-)

    I have a small network, one machine acts as a ntp sever
    for my network (192.168.0.0)

    The windows machine sync fine - 100%

    The ntp server StarGate / 192.168.0.2 syncs with the outside world and
    reports being a stratum 3 clock.

    However my linux box StarBase (192.168.0.10) is being rejected according
    to nptq -c associations

    ind assID status conf reach auth condition last_event cnt
    ================================================== =========
    1 27268 9014 yes yes none reject reachable 1

    I can stop ntpd and do a ntpdate 192.168.0.2 and all is well:

    12 Apr 13:51:58 ntpdate[21549]: ntpdate 4.2.0a@1.1190-r Thu Apr 14 07:47:27 EDT 2005 (1)
    12 Apr 13:51:23 ntpdate[21549]: step time server 192.168.0.2 offset -35.367083 sec

    I restart the daemon and no time corrections are made.

    the last few (relevant) lines from /var/log/messages are:

    Apr 12 12:39:53 StarBase ntpdate[21119]: step time server 192.168.0.2 offset -55.417695 sec
    Apr 12 12:39:53 StarBase ntpd[21121]: ntpd 4.2.0a@1.1190-r Thu Apr 14 07:47:25 EDT 2005 (1)
    Apr 12 12:39:53 StarBase ntpd[21121]: precision = 3.000 usec
    Apr 12 12:39:53 StarBase ntpd[21121]: Listening on interface wildcard, 0.0.0.0#123
    Apr 12 12:39:53 StarBase ntpd[21121]: Listening on interface wildcard, ::#123
    Apr 12 12:39:53 StarBase ntpd[21121]: Listening on interface lo, 127.0.0.1#123
    Apr 12 12:39:53 StarBase ntpd[21121]: Listening on interface eth0, 192.168.0.10#123
    Apr 12 12:39:53 StarBase ntpd[21121]: kernel time sync status 0040
    Apr 12 12:39:53 StarBase ntpd[21121]: frequency initialized -53.832 PPM from /var/lib/ntp/drift

    the ntp.conf on the problem machine is (comments removed):

    restrict default nomodify notrap noquery

    restrict 127.0.0.1

    # -- CLIENT NETWORK -------
    # restrict 192.168.0.0 mask 255.255.255.0 nomodify notrap

    # --- OUR TIMESERVERS -----
    server 192.168.0.2
    #server 0.uk.pool.ntp.org
    #server 1.uk.pool.ntp.org
    #server 2.uk.pool.ntp.org

    # --- NTP MULTICASTCLIENT ---
    #multicastclient # listen on default 224.0.1.1
    # restrict 224.0.1.1 mask 255.255.255.255 nomodify notrap
    restrict 192.168.0.0 mask 255.255.255.0 nomodify notrap

    # --- GENERAL CONFIGURATION ---
    #
    #server 127.127.1.0 # local clock
    #fudge 127.127.1.0 stratum 10


    driftfile /var/lib/ntp/drift
    broadcastdelay 0.008


    #keys /etc/ntp/keys

    uname -a gives:

    Linux StarBase 2.6.16-1.2069_FC4 #1 Tue Mar 28 12:19:10 EST 2006 i686 athlon i386 GNU/Linux

    The system _did_ work wonderfully (and no grief setting it up either) up
    till about the 8th April. Then following a yum update to both machines it
    seems broken - am I missing something simple or do I have to go back to a
    cron job to keep the time accurate.

    TIA

    The Nomad

  2. Re: NTP being rejected

    On Wed, 12 Apr 2006 08:02:02 -0500, The Nomad wrote:

    > Hi all,
    >
    > I have a strange one - but enough of my personal problems ;-)
    >
    > I have a small network, one machine acts as a ntp sever
    > for my network (192.168.0.0)
    >
    > The windows machine sync fine - 100%
    >
    > The ntp server StarGate / 192.168.0.2 syncs with the outside world and
    > reports being a stratum 3 clock.
    >
    > However my linux box StarBase (192.168.0.10) is being rejected according
    > to nptq -c associations
    >
    > ind assID status conf reach auth condition last_event cnt
    > ================================================== =========
    > 1 27268 9014 yes yes none reject reachable 1
    >
    > I can stop ntpd and do a ntpdate 192.168.0.2 and all is well:
    >
    > 12 Apr 13:51:58 ntpdate[21549]: ntpdate 4.2.0a@1.1190-r Thu Apr 14 07:47:27 EDT 2005 (1)
    > 12 Apr 13:51:23 ntpdate[21549]: step time server 192.168.0.2 offset -35.367083 sec
    >
    > I restart the daemon and no time corrections are made.
    >
    > the last few (relevant) lines from /var/log/messages are:
    >
    > Apr 12 12:39:53 StarBase ntpdate[21119]: step time server 192.168.0.2 offset -55.417695 sec
    > Apr 12 12:39:53 StarBase ntpd[21121]: ntpd 4.2.0a@1.1190-r Thu Apr 14 07:47:25 EDT 2005 (1)
    > Apr 12 12:39:53 StarBase ntpd[21121]: precision = 3.000 usec
    > Apr 12 12:39:53 StarBase ntpd[21121]: Listening on interface wildcard, 0.0.0.0#123
    > Apr 12 12:39:53 StarBase ntpd[21121]: Listening on interface wildcard, ::#123
    > Apr 12 12:39:53 StarBase ntpd[21121]: Listening on interface lo, 127.0.0.1#123
    > Apr 12 12:39:53 StarBase ntpd[21121]: Listening on interface eth0, 192.168.0.10#123
    > Apr 12 12:39:53 StarBase ntpd[21121]: kernel time sync status 0040
    > Apr 12 12:39:53 StarBase ntpd[21121]: frequency initialized -53.832 PPM from /var/lib/ntp/drift
    >
    > the ntp.conf on the problem machine is (comments removed):
    >
    > restrict default nomodify notrap noquery
    >
    > restrict 127.0.0.1
    >
    > # -- CLIENT NETWORK -------
    > # restrict 192.168.0.0 mask 255.255.255.0 nomodify notrap
    >
    > # --- OUR TIMESERVERS -----
    > server 192.168.0.2
    > #server 0.uk.pool.ntp.org
    > #server 1.uk.pool.ntp.org
    > #server 2.uk.pool.ntp.org
    >
    > # --- NTP MULTICASTCLIENT ---
    > #multicastclient # listen on default 224.0.1.1
    > # restrict 224.0.1.1 mask 255.255.255.255 nomodify notrap
    > restrict 192.168.0.0 mask 255.255.255.0 nomodify notrap
    >
    > # --- GENERAL CONFIGURATION ---
    > #
    > #server 127.127.1.0 # local clock
    > #fudge 127.127.1.0 stratum 10
    >
    >
    > driftfile /var/lib/ntp/drift
    > broadcastdelay 0.008
    >
    >
    > #keys /etc/ntp/keys
    >
    > uname -a gives:
    >
    > Linux StarBase 2.6.16-1.2069_FC4 #1 Tue Mar 28 12:19:10 EST 2006 i686 athlon i386 GNU/Linux
    >
    > The system _did_ work wonderfully (and no grief setting it up either) up
    > till about the 8th April. Then following a yum update to both machines it
    > seems broken - am I missing something simple or do I have to go back to a
    > cron job to keep the time accurate.
    >
    > TIA
    >
    > The Nomad

    Hi,

    Anyone had any thoughts on this?

    TIA

    N


+ Reply to Thread