NTP 'reach' reset, refid errado do servidor ntp remoto e jitter alto

2

Eu tenho um servidor remoto não-tripulado que tem exibido um comportamento de relógio / NTP extremamente estranho ultimamente. Sintomas:

  • tremulação muito alta
  • ntpq -pn retorna:
    • A reconfiguração de 'when' de volta para 1, mesmo que o servidor NTP esteja literalmente 1m de distância do CAT5e e conectado diretamente à máquina em questão. Nenhum sinal de perda de pacotes ou outra falha de comunicação.
    • Freqüentemente, um refid de 'LOCAL (0)' embora eu saiba que o servidor NTP em questão não está tendo problemas seu servidor de estrato 2.
admin@machine:~$ date && ntpq -pn
Thu 24 May 19:34:02 UTC 2018
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 <local_ntpserver>  LOCAL(0)        15 u  120  128  377    0.120  -486.68 909.283

 admin@machine:~$ date && ntpq -pn
Thu 24 May 19:38:37 UTC 2018
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 <local_ntpserver>  <remote_ntpserver>    3 u    1  128  377    0.123  -1854.0 2164.83

Do servidor NTP local (ou seja, a máquina em execução no mesmo local físico):

      remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 <remote_ntpserver>   <remote_ntpserver2>  2 u   49   64  377  5076.18  1546.21 299.468

Você pode ver que esse servidor NTP local tem bom alcance e jitter relativamente baixo, apesar de estar em uma rede sem fio de alta latência.

Eu modifiquei o minpoll e o maxpoll para valores baixos (4, 5) na máquina primária para que o ntp seja executado com mais freqüência e essa solução "bandaid" parece manter a máquina principal um pouco amarrada à realidade (diferente de antes estava passando minutos a fio várias vezes por dia), mas eu gostaria de chegar à raiz desse comportamento estranho.

Eu tenho uma teoria de que o clock do tsc pode estar à deriva, mas não tenho nenhuma evidência disso. Isso explicaria a alta instabilidade, e isso, por sua vez, poderia talvez introduzir algum comportamento estranho no NTP.

Independentemente disso, eu não entendo porque o refid continua revertendo para 'LOCAL (0)' quando este claramente não é o caso. O serviço NTP não está reiniciando. Por exemplo:

● ntp.service - LSB: Start NTP daemon
   Loaded: loaded (/etc/init.d/ntp)
   Active: active (running) since Wed 2018-05-23 15:58:50 UTC; 1 day 3h ago

mas observei vários casos dessa reversão para 'LOCAL (0)' nas últimas horas, portanto, não é como começar do zero e precisar de tempo para inicializar ou coletar os dados corretos.

    
por EnemyBagJones 24.05.2018 / 21:56

0 respostas