☰

Configuração multicast NTPd

tag-icon • tag-icon ntp ntpd
Configuração multicast NTPd

Preciso configurar um cliente multicast NTP. Para poder verificar se minha configuração está boa, procuro configurar um servidor multicast NTP.

Minha configuração:

  • 2 VM do Centos 7, atualizado
  • Estou usando 2 máquinas virtuais no virtualbox, configurei ambas com modo promicius: permitir todos

Meus problemas são:

  • No servidor, a entrada multicast é relatada como estrato 16; o estrato é relevante para multicast? O cliente rejeitará isso porque o estrato é baixo? Como posso forçar um estrato inferior para um servidor multicast?
  • Meu cliente não parecevermeu servidor, mesmo que meus arquivos de chaves sejam idênticos e eu tenha confiado na chave 1 em ambos os lados.

Usando instruções para órfão, parece não diminuir o estrato relatado para o endereço multicast:

ntpq -n -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.165.10.2    192.165.10.109   4 u   14   64  377    0.454    2.267   1.479
 224.0.1.1       .MCST.          16 u    -   64    0    0.000    0.000   0.000

E meu cliente ainda parece não conseguir encontrar um servidor no endereço 224.0.1.1.

Eu verifiquei no servidor vm, na minha máquina host e no cliente vm, todos eles veem as mensagens multicast do servidor (para vm: usando tcpdump, para host: usando wireshark).

No cliente, usar ntpq -n -pretornará isto:

No association ID's returned

No cliente, meu arquivo de configuração tem todas as instruções restritas comentadas, e eu só tenho estas (e mais algumas como driftfile e outras):

multicastclient 224.0.1.1
keys /etc/ntp/keys
trustedkey 1

log do cliente ntpd me dá isso:

systemd[1]: Starting Network Time Service...
ntpd[11076]: ntpd [email protected] Tue Jun 23 15:38:18 UTC 2020 (1)
systemd[1]: Started Network Time Service.
ntpd[11077]: proto: precision = 0.052 usec
ntpd[11077]: 0.0.0.0 c01d 0d kern kernel time sync enabled
ntpd[11077]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
ntpd[11077]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
ntpd[11077]: Listen and drop on 1 v6wildcard :: UDP 123
ntpd[11077]: Listen normally on 2 lo 127.0.0.1 UDP 123
ntpd[11077]: Listen normally on 3 enp0s3 192.165.10.107 UDP 123
ntpd[11077]: Listen normally on 4 lo ::1 UDP 123
ntpd[11077]: Listen normally on 5 enp0s3 fe80::a00:27ff:fec1:cc1 UDP 123
ntpd[11077]: Listening on routing socket on fd #22 for interface updates
ntpd[11077]: Listen normally on 6 multicast 224.0.1.1 UDP 123
ntpd[11077]: Joined 224.0.1.1 socket to multicast group 224.0.1.1
ntpd[11077]: 0.0.0.0 c016 06 restart
ntpd[11077]: 0.0.0.0 c012 02 freq_set kernel 0.000 PPM
ntpd[11077]: 0.0.0.0 c011 01 freq_not_set
ntpd[11077]: io_setbclient: Opened broadcast client on interface #3 enp0s3

Responder1

O estrato 16 indica que o servidor NTP não acredita ter um horário válido porque não tem conexão com nenhuma fonte de horário configurada. Para fazer com que ntpdo sistema servidor confie no relógio local do sistema como fonte de horário, existem duas opções:

  • O método moderno é especificar as palavras-chave tos orphane tos orphanwaitno ntp.confarquivo no servidor multicast.
# If orphaned, serve others with this stratum.
tos orphan 8
# Wait for this many seconds before starting to serve others (default is 300 s)
tos orphanwait 1
  • A maneira mais antiga é ntpdusar o relógio local como uma fonte de horário falsa no servidor multicast. Esta configuraçãonão deve ser usado junto com fontes de tempo NTP reais, pois pode fazer com que ntpdacredite no relógio local em vez das fontes NTP reais, a menos que um número suficiente de fontes externas tenha sido configurado e esteja em sincronia suficiente entre si para superar a pseudo-fonte 127.127.1.0 (que é sempre perfeitamente de acordo com o relógio local, por isso tende a ser excessivamente favorecido pelo ntpdalgoritmo de seleção).
server 127.127.1.0 iburst
fudge 127.127.1.0 stratum 8

Os endereços IP que começam com 127.127.*são especiais para ntpd: eles se referem a vários drivers de relógio de referência integrados ntpd.

Ambos os métodos farão com que o sistema atenda o horário UTC com base no relógio do sistema local não sincronizado sobre NTP usando o estrato 8, portanto, qualquer sistema com uma conexão razoavelmente direta a uma fonte de tempo NTP real (= estrato 7 ou menos) deve preferi-lo. Este.

Usar a forma mais recente é recomendado sempre que sua versão ntpdsuportar, pois com ela você não precisa se lembrar de remover a pseudo-fonte se/quando você adicionar fontes de tempo NTP reais ao sistema.

informação relacionada