[ntp:questions] .INIT. oddity

Danny Mayer mayer at ntp.isc.org
Fri Jul 11 11:44:37 UTC 2008


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 at 1.1520-o . Same thing. 
> 
> 	I then upgraded GOOD_SERVER2 to 4.2.4p4 at 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



More information about the questions mailing list