A sincronização NTP permanece sem alcance

Question

Normalmente, quando uma máquina perde a conexão completamente, o ntpd perde algumas pesquisas e marca todas as fontes como falha de sanidade. O que parece bastante lógico. Mas encontrei uma situação em que um servidor permanece marcado como a fonte de tempo atual enquanto seu alcance está em 0.

O servidor Sever é implantado em uma mesma sub-rede que uma máquina de destino, proporcionando atraso, deslocamento e instabilidade muito baixos. A situação foi modelada ao encerrar a conexão fisicamente: apenas desconectando um cabo de uma máquina cliente. Eu tentei recriar isso, mas desde então, a mesma máquina sempre perde o status de sincronização muito bem após 5-6 pesquisas sem sucesso.

A verdadeira questão é: o que exatamente determina o status da sincronização quando a conexão é perdida?

    

Answer 1

Há uma explicação deffinite sobre o registro de alcance no RFC-1305:

The reachability register is shifted one position to the left, with zero replacing the vacated bit. If all bits of this register are zero, the clear procedure is called to purge the clock filter and reselect the synchronization source, if necessary. If the association was not configured by the initialization procedure, the association is demobilized.

O RFC-1305 é obsoleto pelo RFC-5905, que não é tão destrutivo:

Next, the 8-bit p.reach shift register in the poll process described in Section 13 is used to determine whether the server is reachable and the data are fresh. The register is shifted left by one bit when a packet is sent and the rightmost bit is set to zero. As valid packets arrive, the rightmost bit is set to one. If the register contains any nonzero bits, the server is considered reachable; otherwise, it is unreachable.

Nenhum procedimento claro é mencionado na Seção 13. Mas ainda parece que um ponto não-reativo deve perder seu status de sincronização em algum momento.

Consegui recriar o status sincronizado com a situação de alcance 0 para garantir que seja raro e nada permanente. Demorou desabilitar "burst" na configuração dos servidores e interromper a conexão logo após a sincronização.

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 91.198.10.4     194.190.168.1    2 u   20   64  177   51.137   -2.192  11.049
 192.168.1.1     193.67.79.202    2 u   65   64   77    0.459   -1.818   0.922
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*91.198.10.4     194.190.168.1    2 u   21   64  177   51.137   -2.192  11.049
+192.168.1.1     193.67.79.202    2 u    -   64  177    0.449   -3.192   1.828

O alcance era 177, que é 01111111 em binário. Então, foram necessárias 7 pesquisas para estabelecer a sincronização.

A sincronização foi perdida nessa posição:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+91.198.10.4     194.190.168.1    2 u  574   64    0   63.846   -9.652   0.756
*192.168.1.1     193.67.79.202    2 u  553   64    0    0.449   -3.192   0.505
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 91.198.10.4     194.190.168.1    2 u  575   64    0   69.871  -10.409   0.002
 192.168.1.1     193.67.79.202    2 u  554   64    0    0.449   -3.192   0.505

Quando os números são um pouco estranhos como 64 * 9 = 576 não 575, mas eu acho que a representação pode ser 1 segundo imprecisa. Considerando isso, foram necessárias 9 pesquisas malsucedidas para quebrar o status de sincronização.

Assim, considerando a teoria e a prática, parece que o estado em que a fonte com 0 alcance pode ser considerada a fonte de tempo atual é possível, mas também é raro e temporário.