Не синхронизируется время с ntp-сервером

Возможные причины?

Луна в созвездии Ориона.

синхронизация ntpd - процесс не быстрый, несколько минут.

ntpd умеет писать логи, может там есть что-то интересное?

В логах нет ничего интересного. Синхронизация не происходит вообще: ни через 10 минут, ни через день. Но с другими серверми синхронизируется быстро.

Тот ntp сервер публичный ?

а «ntpq -c peers» ничего странного не показывает ?

# ntpq -c peers

remote refid st t when poll reach delay offset jitter

==============================================================================

servername .LOCL. 1 u 9 64 1 24.856 -5.896 0.000

Вроде ничего преступного

Сервер в закрытой сети

это он только начал. reach должен стать 77 или выше.

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-clock.isc.org   .GPS.            1 u  275 1024  377  181.905   -6.659   1.339
+ntp0.nl.uu.net  .PPS.            1 u  801 1024  377   37.420   -0.836   0.854
*ntp1.nl.uu.net  .PPS.            1 u  611 1024  377   37.716   -0.865   1.140

Вот: # ntpq -c peers

remote refid st t when poll reach delay offset jitter

==============================================================================

servername .LOCL. 1 u 45 64 377 31.254 -3.853 5.863

Может это быть как-то связано с авторизацией? У меня нет доступа к ntp серверу, не могу посмотреть конфиг. У себя создавал ntp сервер с авторизацией, генерил ключи c помощью ntp-keygen, все равно с моим серваком всё синхронизировалось.

может быть, но тут я тебе не могу помочь.

Есть ли еще гуру, знакомые с алгоритмами работы ntpd?

посмотри tcpdump-ом ntp-шный трафик - «tcpdump -vv .. port 123» может полезную инфу показать.

Версии протоколов совпадают ?

ты от него хочешь ntpv4, а он умеет ntpv3

Но The ntpd program is an operating system daemon which sets and maintains the system time of day in synchronism with Internet standard time servers. It is a complete implementation of the Network Time Protocol (NTP) version 4, but also retains compatibility with version 3

или это надо как-то отдельно в конфиге прописывать?

«server xxx.xxx.xx.xxx version 3» IMHO

Версию протокола поменял, теперь и клиент, и сервер используют 3. Но синхронизации так и не произошло, offset то уменьшается, то увеличивается.

reach увеличиается ?

reach доходит до 377

меня смущает bad udp cksum 6590!

На исходящих пакетах - это нормально. Сетевая карта сама считает КС при отправке. Беда, если оно на входящих.

я так понимаю, в самом пакете от сервера ничего неправильного нет? проблема, видимо, в последовательности пакетов: алгоритм ntp отбрасывает их по какой-то причине.

я бы посмотрел как там включить отладку побольше и посмотрел логи. Если оно не синхронизируется, но получает ответы, то должно говорить что не нравится. Либо эти ответы не доходят до сервера, что в отладке тоже долно быть видно.

Ок, насчет отладки посмотрю, но мне кажется, я нешел косяк:

Root dispersion: 10.134460

А это есть плохо, потому что Selection Algorithm отбрасывает сервер по такому условию:

/* * A distance error occurs if the root distance exceeds the * distance threshold plus an increment equal to one poll * interval. */

if (root_dist(p) > MAXDIST + PHI * LOG2D(s.poll)) return (FALSE);

root_dist()


/*
 * root_dist() - calculate root distance
 */
double
root_dist(
        struct p *p             /* peer structure pointer */
        )
{

        /*
         * The root synchronization distance is the maximum error due to
         * all causes of the local clock relative to the primary server.
         * It is defined as half the total delay plus total dispersion
         * plus peer jitter.
         */
        return (max(MINDISP, p->rootdelay + p->delay) / 2 +
            p->rootdisp + p->disp + PHI * (c.t - p->t) + p->jitter);
}

CSCed13703 Bug Details NTP will not sync, flags server as insane, invalid An IOS system may be unable to synchronize to an NTP server despite being able to transmit to and receive packets from the server. This may be seen with a Windows system running the w32time service.

'show ntp associations detail" will show that the server is flagged as «insane, invalid». The «root dispersion» value will be seen as being in excess of 1000 ms, which will cause the IOS NTP implementation to reject the association.

Workaround: instead of running the w32time service on the Windows system, use NTP 4.x - see http://www.eecis.udel.edu/~mills/ntp/html/hints/winnt.html

http://chip0k.blogspot.com/2014/05/ntp-linux.html

Предположение подтвердилось. Проблема решена установкой параметра LocalClockDispersion службы времени w32time сервера в 0 (по умолчанию было 10).