Meus servidores ntp são marcados como falsetickers no status [closed]

Question

Eu tenho uma caixa linux, configurada com dois servidores ntp para sincronizar. Esta caixa, no caso, estava extremamente fora de sincronia (61 segundos) antes de ser forçada a sincronizar. As seguintes saídas são 1 hora após esta sincronização. Ao verificar o ntpq,

ntpq> peers                                                                           
          remote           refid      st t when poll reach   delay   offset  jitter     
==============================================================================     
x192.168.[redacted]   .MDM.            1 u  113  256  377    0.513   13.120   1.843     
x192.168.[redacted]   .MDM.            1 u  115  128  377    2.689    0.618   1.230     

Ambos estão configurados para falsetes!

ntpq> assoc                                                 

ind assID status  conf reach auth condition  last_event cnt 
=========================================================== 
  1 13191  91d4   yes   yes  none falsetick   reachable 13  
  2 13192  91d4   yes   yes  none falsetick   reachable 13  

O que levou o algoritmo de escolha de tempo a definir ambos como falsos e como posso corrigi-lo?

UPDATE!

Eu executei novamente os comandos acima e obtive um novo status:

ntpq> assoc                                                                     

ind assID status  conf reach auth condition  last_event cnt                     
===========================================================                     
  1 13191  91d4   yes   yes  none falsetick   reachable 13                      
  2 13192  96d4   yes   yes  none  sys.peer   reachable 13                      
ntpq> pe                                                                        
     remote           refid      st t when poll reach   delay   offset  jitter  
==============================================================================  
x192.168.[red]   .MDM.            1 u  241  256  377    0.513   13.120   1.396  
*192.168.[red]   .MDM.            1 u  114  256  377    2.671    0.567   0.710  

    

Answer 1

Seus dois servidores upstream afirmam ser servidores stratum-1 - ou seja, a classe mais alta de fonte de tempo capaz de falar NTP, uma para a qual uma fonte de tempo absoluta (como relógio atômico, ou um receptor GPS) está diretamente ligado - , mas seus relógios são diferentes uns dos outros (isto é, o seu deslocamento de cada servidor (a que distância seu relógio é do seu, quando você recebe o seu sinal) é muito mais do que o atraso de propagação observado (quanto tempo leva para obter um sinal de tempo de cada servidor)).

Diante de dois servidores que afirmam ser autoritários, mas estão contando tempos diferentes, ntpd está razoavelmente dizendo que não pode decidir entre eles e os considerará como charlatões.

Parece agora, deixado para si mesmo, ntpd decidiu depois de uma hora que prefere um ao outro e concordou em sincronizar com ele. Bom para isso.

O problema básico aqui é que os upstreams estão entre eles dizendo algo que não pode ser verdade . Se você quiser apenas um tempo difícil, liste apenas um deles no seu ntp.conf e você sincronizará com isso muito mais rapidamente. Se você quiser um horário exato, entre em contato com os administradores dos servidores e pergunte-lhes por que seus relógios diferem e onde cada um deles está obtendo sua fonte de horário.

Editar : se eu fosse adivinhar, eu diria que ambos deles estão errados - meu palpite é que ambos foram configurados para tratar seus relógios internos , ou alguma fonte de tempo similarmente insuficientemente precisa, como stratum-0. Eles também podem ter sido configurados para ter tempo de servidores de internet, mas desde que eles foram informados de que eles têm um relógio absolutamente preciso anexado, eles estão preferindo esse tempo e publicidade como estrato-1 em conseqüência.

    

Answer 2

Um homem com um relógio sabe que horas são. Um homem com dois relógios nunca tem certeza.

Você precisa adicionar outro servidor para que o ntpd possa quebrar o empate entre dois relógios. De todos os possíveis números de associações de servidores, dois clocks são a pior configuração. Não importa se o terceiro servidor é o estrato 2 ou estrato 3, você só precisa dar ao ntpd a chance de discernir quem é o falsete.

PS

Você não precisa redigir seus endereços RFC1918. Na verdade, fica mais difícil responder quando você as redige assim. Seria melhor se você trocasse os octetos que você redigiu: xxx.xxx.1.1 e xxx.xxx.1.2. Por isso, é fácil referir-se a um ou outro. Mas o mais importante é que não há necessidade de redigir endereços 1918.