> 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