Problemas com NTPD no lado do cliente

3

nós temos um problema com o ntp-client em várias caixas de linux. Primeiro de tudo, há três servidores ntp em nossa rede. Na maioria das nossas caixas, a sincronização está bem. Desde ontem, um handfull linux boxes tem problemas com a sincronização. As caixas estão executando o Debian 8.7 com o ntp 4.2.6.p5 + dfsg-7 + deb8u2 instalado.

Parece assim:

% sudo ntpq -pn
 remote           refid          st t when poll reach   delay   offset  jitter
==============================================================================
 10.2.1.161      .INIT.          16 u    -   64    0    0.000    0.000   0.000
 10.2.1.159      .INIT.          16 u    -   64    0    0.000    0.000   0.000
 10.2.2.233      .INIT.          16 u    -   64    0    0.000    0.000   0.000

Eu entendo que os valores para delay, offset e jitter são 0 porque stratum é 16, então o cliente ntp se recusa a sincronizar com os servidores.

O que eu não entendo é, porque o stratum está em 16. Falei com os caras do firewall, nada é descartado. Então eu fiz um tcpdump, mas não consigo ver nada que explique esse comportamento.

O pacote do cliente é assim:

Network Time Protocol (NTP Version 4, client)
    Flags: 0xe3, Leap Indicator: unknown (clock unsynchronized), Version number: NTP Version 4, Mode: client
    Peer Clock Stratum: unspecified or invalid (0)
    Peer Polling Interval: 6 (64 sec)
    Peer Clock Precision: 0.000000 sec
    Root Delay: 0 seconds
    Root Dispersion: 0 seconds
    Reference ID: (Initialization)
    Reference Timestamp: Jan  1, 1970 00:00:00.000000000 UTC
    Origin Timestamp: Jan  1, 1970 00:00:00.000000000 UTC
    Receive Timestamp: Jan  1, 1970 00:00:00.000000000 UTC
    Transmit Timestamp: Jul 26, 2017 08:20:14.664923929 UTC

E o pacote do servidor é assim:

Network Time Protocol (NTP Version 4, server)
    Flags: 0x24, Leap Indicator: no warning, Version number: NTP Version 4, Mode: server
    Peer Clock Stratum: secondary reference (3)
    Peer Polling Interval: 6 (64 sec)
    Peer Clock Precision: 0.000000 sec
    Root Delay: 0.0225830078125 seconds
    Root Dispersion: 0.0608673095703125 seconds
    Reference ID: 213.239.239.166
    Reference Timestamp: Jul 26, 2017 08:05:26.414539267 UTC
    Origin Timestamp: Jul 26, 2017 08:20:14.664923929 UTC
    Receive Timestamp: Jul 26, 2017 08:20:14.664904341 UTC
    Transmit Timestamp: Jul 26, 2017 08:20:14.664934357 UTC

As entradas do syslog não mostram nenhuma mensagem de erro:

Jul 26 10:55:10 servername systemd[1]: Starting LSB: Start NTP daemon...
Jul 26 10:55:10 servername ntpd[131489]: ntpd [email protected] Fri Jul 22 17:30:51 UTC 2016 (1)
Jul 26 10:55:10 servername ntpd[131490]: proto: precision = 0.101 usec
Jul 26 10:55:10 servername ntpd[131490]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
Jul 26 10:55:10 servername ntp[131479]: Starting NTP server: ntpd.
Jul 26 10:55:10 servername systemd[1]: Started LSB: Start NTP daemon.
Jul 26 10:55:10 servername ntpd[131490]: Listen and drop on 1 v6wildcard :: UDP 123
Jul 26 10:55:10 servername ntpd[131490]: Listen normally on 2 lo 127.0.0.1 UDP 123
Jul 26 10:55:10 servername ntpd[131490]: Listen normally on 3 bond0 10.2.32.121 UDP 123
Jul 26 10:55:10 servername ntpd[131490]: Listen normally on 4 lo ::1 UDP 123
Jul 26 10:55:10 servername ntpd[131490]: Listen normally on 5 bond0 fe80::1618:77ff:fe33:2309 UDP 123
Jul 26 10:55:10 servername ntpd[131490]: peers refreshed
Jul 26 10:55:10 servername ntpd[131490]: Listening on routing socket on fd #22 for interface updates

A execução do ntpdate na linha de comando funciona bem:

% ntpdate -u 10.2.1.161
26 Jul 11:00:05 ntpdate[132651]: adjust time server 10.2.1.161 offset 0.001240 sec

Então, talvez eu não veja a madeira para as árvores. De qualquer forma, qualquer ajuda seria realmente apreciada:)

Tank you guys!

    
por audioslave 26.07.2017 / 11:03

1 resposta

1

Eu encontrei o motivo:)

A configuração usada nas caixas foi feita por um colega que não está mais trabalhando aqui. Ninguém sabe nada sobre ntp aqui. Então eu mudo para o arquivo de configuração que é distribuído com o pacote ntp e apenas mudo os servidores para o nosso. Depois de reiniciar o serviço ntp fora do curso, a sincronização de horário estava funcionando!

A maioria dos parâmetros eram analógicos, mas os seguintes estavam ausentes em nossa configuração personalizada:

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

Não tive tempo de ler sobre esses parâmetros, por isso não posso dizer nada sobre eles. O mais importante é que está funcionando agora: D

    
por 26.07.2017 / 14:51

Tags