Os roteadores não sincronizam o relógio usando o NTP

Question

Eu tenho três roteadores Cisco conectados, conforme mostrado no diagrama.

O problema é que, enquanto R1 está sincronizando o relógio usando NTP, R2 e R3 não são.

Todos os três roteadores foram configurados para NTP usando o mesmo conjunto de comandos,

ntp server 192.168.10.2
ntp authenticate
ntp authentication-key 1 md5 <key>
ntp trusted-key 1
ntp update-calendar

R1 sincronizado perfeitamente. Mas R2 e R3 não.

Para R2 e R3, os comandos de depuração mostram uma saída como essa,

R2#show ntp status
Clock is insane, stratum 16, reference is 192.168.10.2 nominal freq is 000.0000 Hz, actual freq is 000.0000 Hz, precision is 0**00 reference time is 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1990) clock offset is 0.00 msec, root delay is 0.00 msec root dispersion is 0.00 msec, peer dispersion is 0.00 msec.

Ativar debug ntp mostra isso,

Mar 01 00:25:10.243: NTP: xmit packet to 192.168.10.2
Mar 01 00:25:10.254: NTP: rcv packet from 192.168.10.2
Mar 01 00:30:10.244: NTP: xmit packet to 192.168.10.2
Mar 01 00:30:10.271: NTP: rcv packet from 192.168.10.2

Então, o pacote NTP está sendo transmitido bem.

Qualquer sugestão será apreciada.

    

Answer 1

O erro neste caso foi não especificar corretamente o key . A execução de show running-config nos roteadores mostrou uma saída como essa,

--truncated--
ntp server 192.168.10.2 key 0
--truncated--

em que a chave real em questão era 1. Mais investigação do ntp server command nos mostra que este comando possui vários parâmetros opcionais, incluindo [key key-id] . Quando o usuário se esquece de especificar um valor de chave, o roteador atribui um valor padrão de zero. Assim, isso faz com que todos os pacotes NTP fiquem desconfiados e sejam rejeitados. Eventualmente, o tempo permanece não sincronizado e o cliente NTP mostra uma condição insana.

Basta especificar o valor da chave da seguinte maneira para resolver o problema.

ntp server 192.168.10.2 key 1

Talvez a razão inicialmente R1 tenha sincronizado a hora em que seus comandos NTP foram emitidos primeiro, após o qual o valor da chave no servidor NTP foi configurado. O servidor NTP já estava executando um serviço NTP com um valor de chave padrão de 0, onde, mais tarde, este segredo compartilhado simétrico foi ajustado para o valor diferente desejado de 1.