.INIT. oddity - NTP

This is a discussion on .INIT. oddity - NTP ; Hi, Having an issue and its really perplexing. Its a bit of a read, so maybe you'll want to go for a dinner break first... The story starts out with a FreeBSD 4.X system (Its my personal server, I've been ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: .INIT. oddity

  1. .INIT. oddity

    Hi,

    Having an issue and its really perplexing. Its a bit of a read,
    so maybe you'll want to go for a dinner break first...

    The story starts out with a FreeBSD 4.X system (Its my personal
    server, I've been lazy to upgrade it, I know, I know, I know) running
    4.1.0-a . We'll call this BAD_SYSTEM. The /etc/ntp.conf is just :

    server GOOD_SERVER1
    server GOOD_SERVER2
    server 0.us.pool.ntp.org
    server 1.us.pool.ntp.org
    server 2.us.pool.ntp.org
    server 0.ca.pool.ntp.org
    server 0.mx.pool.ntp.org

    I have 2 local NTP servers, FreeBSD 5.5 systems (Not my fault
    again, I'm required to run that version currently). Both of them are
    running 4.2.0-a. We'll call them GOOD_SERVER1 and GOOD_SERVER2 .

    When the story started, I saw the following in an ntpq{peers} :

    remote refid st t when poll reach delay offset jitter
    ================================================== ============================
    GOOD_SERVER1 .INIT. 16 u - 64 0 0.000 0.000 0.000
    GOOD_SERVER2 .INIT. 16 u - 64 0 0.000 0.000 0.000
    +ntp2.your.org 216.218.254.202 2 u 616 1024 377 22.438 -37.986 2.191
    +clock.trit.net 192.12.19.20 2 u 562 1024 377 82.501 -29.933 0.219
    +lashiir.sapros. 74.53.198.146 3 u 572 1024 377 44.344 -45.981 0.023
    *raptor.tera-byt 64.236.96.53 2 u 565 1024 377 80.970 -32.695 3.159
    -cronos.cenam.mx .GPS. 1 u 504 1024 377 236.263 31.443 130.461

    I wasn't sure why it wasn't syncing to servers 3 feet away from it,
    on the same router (different subnet, but there is perfect connectivity between
    the two {GOOD_SERVER1+2 are also DNS servers for the machine, SMARTHOSTS, etc)
    so I pulled an "M$" and restarted ntp. No dice. I ran ntpdates to both of them
    perfectly, no issues, etc. I even used a web page that ran against them and
    came back with sane looking info. tcpdumps seemed to show the request went out,
    got to GOOD_SERVER1+2, went back, and got back to BAD_SYSTEM.

    So I then tried the typical thing of upgrading BAD_SYSTEM to
    4.2.4p4@1.1520-o . Same thing.

    I then upgraded GOOD_SERVER2 to 4.2.4p4@1.1520-o . Same thing.

    harlan on IRC had me do "peer" instead of "server".

    BEFORE GOOD_SERVER2 WAS UPGRADED:

    BAD_SYSTEM: .INIT.
    GOOD_SERVER2: .DROP.

    AFTER GOOD_SERVER2 WAS UPGRADED:

    BAD_SYSTEM: .INIT.
    GOOD_SERVER2: showed valid information


    I'm not sure where to go from here.

    Thanks, Tuc

  2. Re: .INIT. oddity

    Tuc at T-B-O-H.NET wrote:
    > Hi,
    >
    > Having an issue and its really perplexing. Its a bit of a read,
    > so maybe you'll want to go for a dinner break first...
    >
    > The story starts out with a FreeBSD 4.X system (Its my personal
    > server, I've been lazy to upgrade it, I know, I know, I know) running
    > 4.1.0-a . We'll call this BAD_SYSTEM. The /etc/ntp.conf is just :
    >
    > server GOOD_SERVER1
    > server GOOD_SERVER2
    > server 0.us.pool.ntp.org
    > server 1.us.pool.ntp.org
    > server 2.us.pool.ntp.org
    > server 0.ca.pool.ntp.org
    > server 0.mx.pool.ntp.org
    >
    > I have 2 local NTP servers, FreeBSD 5.5 systems (Not my fault
    > again, I'm required to run that version currently). Both of them are
    > running 4.2.0-a. We'll call them GOOD_SERVER1 and GOOD_SERVER2 .
    >
    > When the story started, I saw the following in an ntpq{peers} :
    >
    > remote refid st t when poll reach delay offset jitter
    > ================================================== ============================
    > GOOD_SERVER1 .INIT. 16 u - 64 0 0.000 0.000 0.000
    > GOOD_SERVER2 .INIT. 16 u - 64 0 0.000 0.000 0.000
    > +ntp2.your.org 216.218.254.202 2 u 616 1024 377 22.438 -37.986 2.191
    > +clock.trit.net 192.12.19.20 2 u 562 1024 377 82.501 -29.933 0.219
    > +lashiir.sapros. 74.53.198.146 3 u 572 1024 377 44.344 -45.981 0.023
    > *raptor.tera-byt 64.236.96.53 2 u 565 1024 377 80.970 -32.695 3.159
    > -cronos.cenam.mx .GPS. 1 u 504 1024 377 236.263 31.443 130.461
    >
    > I wasn't sure why it wasn't syncing to servers 3 feet away from it,
    > on the same router (different subnet, but there is perfect connectivity between
    > the two {GOOD_SERVER1+2 are also DNS servers for the machine, SMARTHOSTS, etc)
    > so I pulled an "M$" and restarted ntp. No dice. I ran ntpdates to both of them
    > perfectly, no issues, etc. I even used a web page that ran against them and
    > came back with sane looking info. tcpdumps seemed to show the request went out,
    > got to GOOD_SERVER1+2, went back, and got back to BAD_SYSTEM.
    >
    > So I then tried the typical thing of upgrading BAD_SYSTEM to
    > 4.2.4p4@1.1520-o . Same thing.
    >
    > I then upgraded GOOD_SERVER2 to 4.2.4p4@1.1520-o . Same thing.
    >
    > harlan on IRC had me do "peer" instead of "server".
    >
    > BEFORE GOOD_SERVER2 WAS UPGRADED:
    >
    > BAD_SYSTEM: .INIT.
    > GOOD_SERVER2: .DROP.
    >
    > AFTER GOOD_SERVER2 WAS UPGRADED:
    >
    > BAD_SYSTEM: .INIT.
    > GOOD_SERVER2: showed valid information


    I wouldn't recommend trying to use peer here. What's in the
    good_server's ntp.conf file. Do you have any restrict options? Did you
    put in the fully-qualified domain name (FQDN) of the good server in the
    ntp.conf file? Does the name you have in the ntp.conf file resolve? Use
    dig +search to check this. Are there any errors in the log?

    If all of this checks out start running tcpdump and make sure the
    packets are going out and on the other side, coming in.

    Danny

  3. Re: .INIT. oddity

    > Tuc at T-B-O-H.NET wrote:
    > > Hi,
    > >
    > > Having an issue and its really perplexing. Its a bit of a read,
    > > so maybe you'll want to go for a dinner break first...
    > >
    > > The story starts out with a FreeBSD 4.X system (Its my personal
    > > server, I've been lazy to upgrade it, I know, I know, I know) running
    > > 4.1.0-a . We'll call this BAD_SYSTEM. The /etc/ntp.conf is just :
    > >
    > > server GOOD_SERVER1
    > > server GOOD_SERVER2
    > > server 0.us.pool.ntp.org
    > > server 1.us.pool.ntp.org
    > > server 2.us.pool.ntp.org
    > > server 0.ca.pool.ntp.org
    > > server 0.mx.pool.ntp.org
    > >
    > > I have 2 local NTP servers, FreeBSD 5.5 systems (Not my fault
    > > again, I'm required to run that version currently). Both of them are
    > > running 4.2.0-a. We'll call them GOOD_SERVER1 and GOOD_SERVER2 .
    > >
    > > When the story started, I saw the following in an ntpq{peers} :
    > >
    > > remote refid st t when poll reach delay offset jitter
    > > ================================================== ============================
    > > GOOD_SERVER1 .INIT. 16 u - 64 0 0.000 0.000 0.000
    > > GOOD_SERVER2 .INIT. 16 u - 64 0 0.000 0.000 0.000
    > > +ntp2.your.org 216.218.254.202 2 u 616 1024 377 22.438 -37.986 2.191
    > > +clock.trit.net 192.12.19.20 2 u 562 1024 377 82.501 -29.933 0.219
    > > +lashiir.sapros. 74.53.198.146 3 u 572 1024 377 44.344 -45.981 0.023
    > > *raptor.tera-byt 64.236.96.53 2 u 565 1024 377 80.970 -32.695 3.159
    > > -cronos.cenam.mx .GPS. 1 u 504 1024 377 236.263 31.443 130.461
    > >
    > > I wasn't sure why it wasn't syncing to servers 3 feet away from it,
    > > on the same router (different subnet, but there is perfect connectivity between
    > > the two {GOOD_SERVER1+2 are also DNS servers for the machine, SMARTHOSTS, etc)
    > > so I pulled an "M$" and restarted ntp. No dice. I ran ntpdates to both of them
    > > perfectly, no issues, etc. I even used a web page that ran against them and
    > > came back with sane looking info. tcpdumps seemed to show the request went out,
    > > got to GOOD_SERVER1+2, went back, and got back to BAD_SYSTEM.
    > >
    > > So I then tried the typical thing of upgrading BAD_SYSTEM to
    > > 4.2.4p4@1.1520-o . Same thing.
    > >
    > > I then upgraded GOOD_SERVER2 to 4.2.4p4@1.1520-o . Same thing.
    > >
    > > harlan on IRC had me do "peer" instead of "server".
    > >
    > > BEFORE GOOD_SERVER2 WAS UPGRADED:
    > >
    > > BAD_SYSTEM: .INIT.
    > > GOOD_SERVER2: .DROP.
    > >
    > > AFTER GOOD_SERVER2 WAS UPGRADED:
    > >
    > > BAD_SYSTEM: .INIT.
    > > GOOD_SERVER2: showed valid information

    >
    > I wouldn't recommend trying to use peer here. What's in the
    > good_server's ntp.conf file. Do you have any restrict options? Did you
    > put in the fully-qualified domain name (FQDN) of the good server in the
    > ntp.conf file? Does the name you have in the ntp.conf file resolve? Use
    > dig +search to check this. Are there any errors in the log?
    >
    > If all of this checks out start running tcpdump and make sure the
    > packets are going out and on the other side, coming in.
    >


    Sorry I realized I forgot GOOD_SERVER1+2's ntp.conf. They both are:

    server 0.us.pool.ntp.org
    server 1.us.pool.ntp.org
    server 2.us.pool.ntp.org
    server 0.ca.pool.ntp.org
    server 0.mx.pool.ntp.org

    No, no restrict. Yes, FQDN. Yes, name resolves to an A record, but
    the forward/backward don't match. (I'm referencing GOOD_SERVER1 as ntp1.example.com,
    but its in-addr.arpa is v.example.com . GOOD_SERVER2 as ntp2.example.com, but
    its in-addr.arpa is a.example.com . ) I've got the same ntp.conf on BAD_SERVER
    as every OTHER server in the datacenter, and none of the others have the slightest
    problem. dig +search shows an "IN A" of the proper IP. No errors in the logs.

    Yup, they do. I can track the packets back and forth on both systems.

    Tuc/TBOH

  4. Re: .INIT. oddity

    Tuc at T-B-O-H.NET wrote:
    >> Tuc at T-B-O-H.NET wrote:
    >>> Hi,
    >>>
    >>> Having an issue and its really perplexing. Its a bit of a read,
    >>> so maybe you'll want to go for a dinner break first...
    >>>
    >>> The story starts out with a FreeBSD 4.X system (Its my personal
    >>> server, I've been lazy to upgrade it, I know, I know, I know) running
    >>> 4.1.0-a . We'll call this BAD_SYSTEM. The /etc/ntp.conf is just :
    >>>
    >>> server GOOD_SERVER1
    >>> server GOOD_SERVER2
    >>> server 0.us.pool.ntp.org
    >>> server 1.us.pool.ntp.org
    >>> server 2.us.pool.ntp.org
    >>> server 0.ca.pool.ntp.org
    >>> server 0.mx.pool.ntp.org
    >>>
    >>> I have 2 local NTP servers, FreeBSD 5.5 systems (Not my fault
    >>> again, I'm required to run that version currently). Both of them are
    >>> running 4.2.0-a. We'll call them GOOD_SERVER1 and GOOD_SERVER2 .
    >>>
    >>> When the story started, I saw the following in an ntpq{peers} :
    >>>
    >>> remote refid st t when poll reach delay offset jitter
    >>> ================================================== ============================
    >>> GOOD_SERVER1 .INIT. 16 u - 64 0 0.000 0.000 0.000
    >>> GOOD_SERVER2 .INIT. 16 u - 64 0 0.000 0.000 0.000
    >>> +ntp2.your.org 216.218.254.202 2 u 616 1024 377 22.438 -37.986 2.191
    >>> +clock.trit.net 192.12.19.20 2 u 562 1024 377 82.501 -29.933 0.219
    >>> +lashiir.sapros. 74.53.198.146 3 u 572 1024 377 44.344 -45.981 0.023
    >>> *raptor.tera-byt 64.236.96.53 2 u 565 1024 377 80.970 -32.695 3.159
    >>> -cronos.cenam.mx .GPS. 1 u 504 1024 377 236.263 31.443 130.461
    >>>
    >>> I wasn't sure why it wasn't syncing to servers 3 feet away from it,
    >>> on the same router (different subnet, but there is perfect connectivity between
    >>> the two {GOOD_SERVER1+2 are also DNS servers for the machine, SMARTHOSTS, etc)
    >>> so I pulled an "M$" and restarted ntp. No dice. I ran ntpdates to both of them
    >>> perfectly, no issues, etc. I even used a web page that ran against them and
    >>> came back with sane looking info. tcpdumps seemed to show the request went out,
    >>> got to GOOD_SERVER1+2, went back, and got back to BAD_SYSTEM.
    >>>
    >>> So I then tried the typical thing of upgrading BAD_SYSTEM to
    >>> 4.2.4p4@1.1520-o . Same thing.
    >>>
    >>> I then upgraded GOOD_SERVER2 to 4.2.4p4@1.1520-o . Same thing.
    >>>
    >>> harlan on IRC had me do "peer" instead of "server".
    >>>
    >>> BEFORE GOOD_SERVER2 WAS UPGRADED:
    >>>
    >>> BAD_SYSTEM: .INIT.
    >>> GOOD_SERVER2: .DROP.
    >>>
    >>> AFTER GOOD_SERVER2 WAS UPGRADED:
    >>>
    >>> BAD_SYSTEM: .INIT.
    >>> GOOD_SERVER2: showed valid information

    >> I wouldn't recommend trying to use peer here. What's in the
    >> good_server's ntp.conf file. Do you have any restrict options? Did you
    >> put in the fully-qualified domain name (FQDN) of the good server in the
    >> ntp.conf file? Does the name you have in the ntp.conf file resolve? Use
    >> dig +search to check this. Are there any errors in the log?
    >>
    >> If all of this checks out start running tcpdump and make sure the
    >> packets are going out and on the other side, coming in.
    >>

    >
    > Sorry I realized I forgot GOOD_SERVER1+2's ntp.conf. They both are:
    >
    > server 0.us.pool.ntp.org
    > server 1.us.pool.ntp.org
    > server 2.us.pool.ntp.org
    > server 0.ca.pool.ntp.org
    > server 0.mx.pool.ntp.org
    >
    > No, no restrict. Yes, FQDN. Yes, name resolves to an A record, but
    > the forward/backward don't match. (I'm referencing GOOD_SERVER1 as ntp1.example.com,
    > but its in-addr.arpa is v.example.com . GOOD_SERVER2 as ntp2.example.com, but
    > its in-addr.arpa is a.example.com . ) I've got the same ntp.conf on BAD_SERVER
    > as every OTHER server in the datacenter, and none of the others have the slightest
    > problem. dig +search shows an "IN A" of the proper IP. No errors in the logs.
    >
    > Yup, they do. I can track the packets back and forth on both systems.
    >
    > Tuc/TBOH
    >


    Then the next question is what does ntpq show when querying that server?
    Your server is certainly saying that there is something wrong with that
    server. Are these servers on the Internet or are they behind a firewall?

    Danny

  5. Re: .INIT. oddity

    > Tuc at T-B-O-H.NET wrote:
    > >> Tuc at T-B-O-H.NET wrote:
    > >>> Hi,
    > >>>
    > >>> Having an issue and its really perplexing. Its a bit of a read,
    > >>> so maybe you'll want to go for a dinner break first...
    > >>>
    > >>> The story starts out with a FreeBSD 4.X system (Its my personal
    > >>> server, I've been lazy to upgrade it, I know, I know, I know) running
    > >>> 4.1.0-a . We'll call this BAD_SYSTEM. The /etc/ntp.conf is just :
    > >>>
    > >>> server GOOD_SERVER1
    > >>> server GOOD_SERVER2
    > >>> server 0.us.pool.ntp.org
    > >>> server 1.us.pool.ntp.org
    > >>> server 2.us.pool.ntp.org
    > >>> server 0.ca.pool.ntp.org
    > >>> server 0.mx.pool.ntp.org
    > >>>
    > >>> I have 2 local NTP servers, FreeBSD 5.5 systems (Not my fault
    > >>> again, I'm required to run that version currently). Both of them are
    > >>> running 4.2.0-a. We'll call them GOOD_SERVER1 and GOOD_SERVER2 .
    > >>>
    > >>> When the story started, I saw the following in an ntpq{peers} :
    > >>>
    > >>> remote refid st t when poll reach delay offset jitter
    > >>> ================================================== ============================
    > >>> GOOD_SERVER1 .INIT. 16 u - 64 0 0.000 0.000 0.000
    > >>> GOOD_SERVER2 .INIT. 16 u - 64 0 0.000 0.000 0.000
    > >>> +ntp2.your.org 216.218.254.202 2 u 616 1024 377 22.438 -37.986 2.191
    > >>> +clock.trit.net 192.12.19.20 2 u 562 1024 377 82.501 -29.933 0.219
    > >>> +lashiir.sapros. 74.53.198.146 3 u 572 1024 377 44.344 -45.981 0.023
    > >>> *raptor.tera-byt 64.236.96.53 2 u 565 1024 377 80.970 -32.695 3.159
    > >>> -cronos.cenam.mx .GPS. 1 u 504 1024 377 236.263 31.443 130.461
    > >>>
    > >>> I wasn't sure why it wasn't syncing to servers 3 feet away from it,
    > >>> on the same router (different subnet, but there is perfect connectivity between
    > >>> the two {GOOD_SERVER1+2 are also DNS servers for the machine, SMARTHOSTS, etc)
    > >>> so I pulled an "M$" and restarted ntp. No dice. I ran ntpdates to both of them
    > >>> perfectly, no issues, etc. I even used a web page that ran against them and
    > >>> came back with sane looking info. tcpdumps seemed to show the request went out,
    > >>> got to GOOD_SERVER1+2, went back, and got back to BAD_SYSTEM.
    > >>>
    > >>> So I then tried the typical thing of upgrading BAD_SYSTEM to
    > >>> 4.2.4p4@1.1520-o . Same thing.
    > >>>
    > >>> I then upgraded GOOD_SERVER2 to 4.2.4p4@1.1520-o . Same thing.
    > >>>
    > >>> harlan on IRC had me do "peer" instead of "server".
    > >>>
    > >>> BEFORE GOOD_SERVER2 WAS UPGRADED:
    > >>>
    > >>> BAD_SYSTEM: .INIT.
    > >>> GOOD_SERVER2: .DROP.
    > >>>
    > >>> AFTER GOOD_SERVER2 WAS UPGRADED:
    > >>>
    > >>> BAD_SYSTEM: .INIT.
    > >>> GOOD_SERVER2: showed valid information
    > >> I wouldn't recommend trying to use peer here. What's in the
    > >> good_server's ntp.conf file. Do you have any restrict options? Did you
    > >> put in the fully-qualified domain name (FQDN) of the good server in the
    > >> ntp.conf file? Does the name you have in the ntp.conf file resolve? Use
    > >> dig +search to check this. Are there any errors in the log?
    > >>
    > >> If all of this checks out start running tcpdump and make sure the
    > >> packets are going out and on the other side, coming in.
    > >>

    > >
    > > Sorry I realized I forgot GOOD_SERVER1+2's ntp.conf. They both are:
    > >
    > > server 0.us.pool.ntp.org
    > > server 1.us.pool.ntp.org
    > > server 2.us.pool.ntp.org
    > > server 0.ca.pool.ntp.org
    > > server 0.mx.pool.ntp.org
    > >
    > > No, no restrict. Yes, FQDN. Yes, name resolves to an A record, but
    > > the forward/backward don't match. (I'm referencing GOOD_SERVER1 as ntp1.example.com,
    > > but its in-addr.arpa is v.example.com . GOOD_SERVER2 as ntp2.example.com, but
    > > its in-addr.arpa is a.example.com . ) I've got the same ntp.conf on BAD_SERVER
    > > as every OTHER server in the datacenter, and none of the others have the slightest
    > > problem. dig +search shows an "IN A" of the proper IP. No errors in the logs.
    > >
    > > Yup, they do. I can track the packets back and forth on both systems.
    > >
    > > Tuc/TBOH
    > >

    >
    > Then the next question is what does ntpq show when querying that server?
    > Your server is certainly saying that there is something wrong with that
    > server. Are these servers on the Internet or are they behind a firewall?
    >
    > Danny
    >

    Not sure which server is "that server". If I ntpq/peers on BAD_SYSTEM,
    I see ".INIT." for GOOD_SERVER1 and GOOD_SERVER2. If I ntpq/peers on ANOTHER_SYSTEM1
    I see :

    remote refid st t when poll reach delay offset jitter
    ================================================== ============================
    +ntp2.arttoday.c 10.0.0.55 3 u 416 1024 377 90.511 -5.703 0.519
    time.awin.com .STEP. 16 u 380d 1024 0 0.000 0.000 4000.00
    +198.247.173.220 128.206.12.130 3 u 439 1024 377 35.045 5.241 0.771
    *GOOD_SERVER1 200.23.51.205 2 u 401 1024 377 0.470 3.214 0.636
    +GOOD_SERVER2 148.234.7.30 3 u 365 1024 377 0.700 12.488 0.515

    and on ANOTHER_SYSTEM2 I see :

    remote refid st t when poll reach delay offset jitter
    ================================================== ============================
    +clock.trit.net 192.12.19.20 2 u 242 1024 377 82.996 -8.153 0.216
    +elle.fallingsno 138.23.180.126 3 u 335 1024 377 82.257 -2.162 0.965
    +patbox3.patrick 64.90.182.55 2 u 311 1024 377 8.085 -2.549 0.257
    *GOOD_SERVER1 200.23.51.205 2 u 230 1024 377 0.465 -4.408 0.908
    -GOOD_SERVER2 148.234.7.30 3 u 329 1024 377 0.597 4.544 0.192

    I can even "ntpq GOOD_SERVER1" and "ntpq GOOD_SERVER2" from BAD_SYSTEM
    and have it show me the peers there.

    It seems ONLY my personal server is claiming to have issues. The
    systems are physically plugged into the same router, and not behind any sort
    of NAT, or anything that would impeede it. The packet travels about 6 feet
    of cable TOTAL between the 2 systems.

    Tuc

+ Reply to Thread