O servidor NTP preferido foi rejeitado apesar de ter melhor compensação e jitter

Question

Temos um cliente NTP configurado em um dos nossos sistemas. O cliente tem um conjunto de servidores disponíveis com quem pode sincronizar.

No entanto, o servidor preferido que escolhemos é o nosso servidor mestre interno com o IP 169.254.1.51.

O conteúdo do ntp.conf para o mesmo está abaixo: -

 

    # --- CLIENT NETWORK -------
    # --- USER SETTINGS BEGIN ---

    server 10.241.34.2 iburst

    server 10.241.34.3 iburst

    server 10.241.34.4 iburst
    restrict 10.241.34.2  mask 255.255.255.255 nomodify notrap noquery
    restrict 10.241.34.3  mask 255.255.255.255 nomodify notrap noquery
    restrict 10.241.34.4  mask 255.255.255.255 nomodify notrap noquery
    # --- USER SETTINGS END ---

    # --- NTP MULTICASTCLIENT ---
    restrict 169.254.0.0 mask 255.255.0.0 nomodify notrap  # internal network
    # --- INTERNAL TIMESERVERS BEGIN-----
    server 169.254.1.51 burst iburst minpoll 4 maxpoll 6 prefer #Internal master Server

    # --- GENERAL CONFIGURATION ---
    server  127.127.1.0 iburst minpoll 4    # local clock
    fudge   127.127.1.0 stratum 10
    tinker step 0

O acima é para a parte de configuração. No entanto, quando verificamos o syslog após a configuração e reiniciamos o sistema, descobrimos que o cliente está sincronizando com o servidor externo em vez de preferir o servidor como capturado na saída ntpq no syslog

    Mar 22 05:52:48 Node ntpcheck:      remote           refid      st t when poll reach   delay   offset  jitter
    Mar 22 05:52:48 Node ntpcheck: ==============================================================================
    Mar 22 05:52:48 Node ntpcheck: *10.241.34.2     10.240.33.1      4 u    2   64    1    0.192  -519.50   5.769
    Mar 22 05:52:48 Node ntpcheck:  10.241.34.3     10.241.34.2      5 u    1   64    1    0.172  -523.79   8.912
    Mar 22 05:52:48 Node ntpcheck:  10.241.34.4     10.241.34.2      5 u    2   64    1    0.207  -520.73   8.082
    Mar 22 05:52:48 Node ntpcheck:  169.254.1.51    LOCAL(0)        11 u    1   16    1    0.113   -0.043   2.099
    Mar 22 05:52:48 Node ntpcheck:  127.127.1.0     .LOCL.          10 l   14   16    1    0.000    0.000   0.001}

Além disso, a mensagem abaixo foi continuamente inundada no syslog

    Mar 22 06:51:11 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:51:27 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:51:45 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:52:03 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:52:20 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:52:35 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:52:51 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:53:06 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:53:20 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:53:23 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:53:38 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:53:53 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:54:11 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:54:29 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:54:47 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:55:02 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:55:20 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:55:21 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:55:35 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:55:53 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:56:10 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:56:28 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:56:46 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:57:03 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:57:21 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:57:38 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:57:54 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:58:09 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:58:24 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:58:42 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:58:59 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:59:15 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
    Mar 22 06:59:30 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
    Mar 22 06:59:46 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
    Mar 22 07:00:02 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
    Mar 22 07:00:17 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4

Nós tentamos verificar nos fóruns do NTP e identificamos que ele usa o parâmetro abaixo na definição do servidor a ser preferencialmente sincronizado com (Referência: - link ): -

• O primeiro nível de rejeição acontece com base no deslocamento e no atraso.
• Em seguida, depois de rejeitar o conjunto, os sobreviventes são passados para o algoritmo de clustering do relógio.
• O algoritmo de clusterização depende do jitter para decidir.
• Os restantes servidores são sobreviventes selecionáveis, qualquer um deles pode ser escolhido.
• Agora, o papel da palavra-chave preferida entra em cena, e todos os selecionáveis são verificados e prefere que um seja escolhido.
• Se o sobrevivente não estiver presente, a regra de migração decidirá o par.

No entanto, na saída ntpq, o servidor preferencial tem melhor offset e jitter, mesmo assim ele não é escolhido.

É possível identificar em que base está rejeitando o servidor preferencial neste caso.

EDIT -1

Encontramos ainda o syslog por mencionar a escolha de 169.254.1.51 apesar do estrato mais alto como abaixo: -

 

Mar 24 05:01:01 Node ntpq: ==============================================================================
Mar 24 05:01:01 Node ntpq: +10.241.34.2     10.240.33.1      4 u  693 1024  377    0.242  -251.08  10.473
Mar 24 05:01:01 Node ntpq: +10.241.34.3     10.241.34.2      5 u   46   64  377    6.675  -255.20   0.326
Mar 24 05:01:01 Node ntpq: +10.241.34.4     10.241.34.2      5 u  245 1024  377    0.312  -264.63   7.708
Mar 24 05:01:01 Node ntpq: *169.254.1.51          LOCAL(0)        11 u   12   64  377    0.143   80.034   2.248
Mar 24 05:01:01 Node ntpq:  LOCAL(0)        .LOCL.          10 l   10   16  377    0.000    0.000   0.001

    

Answer 1

Veja desta forma: você tem quatro servidores:

1. 10.241.34.2
2. 10.241.34.3
3. 10.241.34.4
4. 169.254.1.51

Os números dois e três têm o tempo de # 1. Mas eles são low-ish low estratum, com 4 e 5. Isto é o que eu esperaria em um servidor NTP interno. Eles relatam tempos relativamente próximos, com compensações semelhantes ao seu relógio local, e suas diferenças estão dentro do jitter.

Além disso, você tem o 169.254.1.51, que é o stratum 11. O stratum diz algo sobre o quão longe foi removido da fonte de tempo (stratum 0) que você é. O estrato 1 está ligado à fonte de tempo, por ex. GPS ou relógio atômico. O estrato 2 está ligado ao estrato 1 e assim por diante. Você tem três (na realidade um, porque # 2 & # 3 estão referenciando # 1) servidores que dizem ei, confie em mim, eu sou quatro etapas da fonte de tempo. Eles concordam com o tempo.

Então você tem um, que é meio segundo desses três, e diz que são onze etapas removidas de um relógio confiável. É claro que o NTP deve confiar mais nos servidores NTP do estrato inferior.

Além disso, você falsifica o relógio local para o stratum 10. Na verdade, você está dizendo que confia no relógio local mais do que o seu servidor NTP preferido. Isso não funcionará. A configuração aqui é totalmente insana. Em resumo. O NTP é hierárquico e precisa ser tratado como tal.

1. Sincronize seu 169.254.1.51 com um pool externo. As piscinas são geralmente do estrato 2-3, por isso acabará como estrato 3-4. Isso é muito bom para a maioria dos propósitos.
2. Configure três ou mais servidores NTP, todos recebendo tempo de um dos pools. Você pode espiá-los uns com os outros, mas para não fazer # 2 e 3 obter o tempo de # 1.
3. Faça seus clientes usarem os três servidores NTP que você configurou.
4. Se você não pode ter três servidores NTP, configure um ou use os pools diretamente. Os pools manipularão a carga, a menos que você tenha muitos (pense em milhares) de clientes.
5. Não fudge o relógio local para o stratum 10 - se não estiver sincronizado, não será confiável. Se você quiser sincronização de tempo quando nenhuma fonte upstream estiver disponível por algum tempo, configure um do clock local do servidor para o stratum dez. Isso fará com que o mestre se não haja upstreams disponíveis.
6. Duas fontes de tempo são piores que uma. Se você tem um, você o segue. Se você tem dois, e eles discordam, você não sabe qual deles seguir. Se você tem três e dois concordam, você sabe qual deles seguir. Uma outra alternativa é defini-lo como truechimer anexando a linha do servidor com true.

Documentação NTP contém alguns conselhos sobre a configuração do NTP. Você provavelmente deveria ler.

Além disso, o uso de 169.254.xx em uma rede é um prática estranha . Eu recomendaria re-IPing dessa rede para usar um espaço RFC1918 sã . 169.254.0.0/16 destina-se a ser uma rede link-local automática e provavelmente não deve ser usada dessa maneira.