Dentre os protocolos mais importantes (e talvez o mais subjulgado no mundo de TI), o NTP se destaca. O NTP é o protocolo que garante o sincronismo de hora entre todos os componentes em rede e na Internet. Seria impossível compartilhar recursos, realizar transações bancárias, compras e qualquer outro tipo de operação se cada estação ou servidor utilizasse seu próprio método para ajustar a hora (ou até seu próprio horário).
Computadores não são como relógios de pulso, são muito mais sensíveis a atrasos no relógio do que se pensa. Experimente alterar a data e hora do seu sistema para valores arbitrários e tente acessar o site do seu banco. Provavelmente, você verá um erro de certificado no seu navegador, causado justamente pela diferença de tempo entre o servidor que o emitiu e o cliente que o solicita.
Dito isso, vamos exibir como entender e realizar o troubleshoot básico do Infoblox (como cliente de NTP).
Vamos, em primeiro lugar, exibir a configuração do NTP em um appliance de teste, navegando até Grid > Grid Manager > NTP.
Primeiro, não se assuste se o NTP estiver desabilitado. Este indicador reflete apenas o status do NTP Server. O NTP client não precisa do serviço de NTP Server para entrar em execução.
Na toolbar do lado direito, clique na seta ao lado de “Edit” e clique em Grid NTP Properties.
A configuração atual deve ser exibida na tela.
Aqui já vemos um problema maior na configuração. Há apenas um servidor configurado quando deveriam existir pelo menos três. Por hora, vamos identificar o que está ocorrendo com o servidor configurado.
A configuração acima mostra que o Grid está habilitado para sincronizar apenas com um servidor. Quando observamos o status do membro, vemos que ele está fora de sincronia.
A melhor forma de realizar este troubleshoot é via CLI. Conectado via SSH ou console, execute o comando :
show ntp.
Aqui, vemos que existem dois IPs configurados como NTP Server. Um é o que já estava configurado e o outro é o próprio Infoblox. Explico. O Infoblox precisa sincronizar horário com alguém (nem que seja com ele mesmo, afinal, existe um relógio lógico dentro de qualquer equipamento) para manter o horário próximo da realidade. Sempre que o sincronismo falhar com os servidores externos configurados, o Infoblox realizara o sync com ele mesmo. Dentre todos, o servidor que atualmente fornece a sincronia é destacado com um asterisco ao lado esquerdo do IP.
Quanto às demais colunas:
Remote: Indica o IP (ou o endereço) do servidor remoto.
REFID: Este campo identifica o tipo da entidade que mantém o servidor no qual o cliente está conectado (ex. “ONBR” para servidores no Brasil, mantidos pelo Ntp.br.). Porém, este campo também pode ser interpretado como emissor de mensagens de debug dependendo de outros fatores (o mais importante deles, o valor definido na coluna “ST” ou stratum). Veremos exemplos mais à frente.
ST (ou Stratum): De forma resumida, este campo identifica qual é a distância entre o cliente e o servidor NTP cujo método para aferir tempo é mais preciso, como por exemplo, servidores que sincronizam seus relógios baseados em coordenadas de GPS (cujo stratum é igual à 0). Servidores que sincronizam com este servidor tem stratum 1. Servidores que sincronizam com este outro servidor tem stratum 2 e assim sucessivamente.
A tabela abaixo exibe todos os possíveis valores para este campo.
T (ou type): Identifica qual o modo de transmissão entre servidor/peer (Broadcast, Multicast ou Unicast)
When: Exibe a quantidade de tempo (segundos que se passaram) desde o último sync.
Poll: exibe a quantidade de tempo (segundos) entre uma tentativa de sync e outra. 64 é o valor default, que pode aumentar ou diminuir automaticamente dependendo de outros fatores, tais como velocidade de transmissão e diferença de valores entre cliente/servidor.
Reach: Indica a capacidade de conexão entre o cliente e o server, calculado utilizando os dados das últimas 8 tentativas de sincronização.
Delay: exibe o tempo de transmissão entre os peers (geralmente, em milisegundos).
Offset: Este campo exibe qual é a diferença de tempo entre os dois peers (que deve ser compensado pela máquina local), levando em consideração o tempo em que esta informação demora para sair do servidor e chegar ao cliente (Delay).
Jitter: Define o desvio padrão utilizado para calcular a média de tempo entre uma transmissão e outra, utilizado para compensar interferências de rede. Passando a teoria, vamos olhar novamente para o nosso Infoblox para entender o que se passa com o servidor que está configurado.
Vemos que o REFID deste servidor apresenta “.INIT.” como valor. “INIT” define que este servidor nunca sincronizou hora com o Infoblox ou que está tentando realizar o primeiro sincronismo.
A coluna stratum apresenta valor 16. “16” significa “fora de sincronia”, de acordo com a tabela exibida anteriormente.
A coluna “when” não exibe nenhuma informação, indicando que a última sincronia realizada é inexistente.
A coluna “Poll” exibe quando (em segundos) o cliente tentará novamente sincronizar com o servidor. Vemos aqui que este valor é alto (256 segundos) justamente pelo fato deste servidor não estar respondendo como deveria (evidenciado também pelo valor zerado em “Reach”). Consequentemente, “delay”, “offset” e “jitter” estarão zerados pois não há como calcular estes valores sendo que nunca houve (pelo menos uma) sincronização.
Daqui, podemos extrair varias causas para este servidor não estar funcionando.
1. Servidor Incorreto ou fora do ar
2. Restrição de Rede
3. Problema com o serviço (pouco provável, mas acontece). Vamos tentar eliminar o primeiro problema, trocando o NTP Server da configuração. Para isso, adicionamos três NTP Servers (obtidos em http://ntp.br) na configuração do Infoblox.
Nota: Não é necessário reiniciar o serviço ou o appliance. O próprio Infoblox cuidará disso quando salvarmos a configuração.
Agora, vamos executar novamente o comando show ntp via console.
Vemos aqui que muita coisa mudou. Os valores de todos os campos foram atualizados e todos os servidores parecem estar disponíveis. Para economizar tempo no troubleshoot. Vamos procurar por evidências no syslog do Infoblox procurando por “ntp”
Acima, vemos que o Infoblox foi capaz de sincronizar com um dos servidores informados na nova configuração (200.186.125.195).
De volta ao Grid Manager, vemos que o status do membro encontra-se normalizado. Podemos inferir que o servidor anteriormente configurado era inválido (o que é verdade, pois utilizamos um IP que não fornece NTP propositalmente) ou tinha problemas de conectividade.
Note que essas informações e o modo como são exibidas não são únicas para o Infoblox. Veja a saída do comando ntpd –q numa máquina Debian, por exemplo.
O NTP é um protocolo relativamente simples. O que assusta num primeiro momento é quantidade de informação que um simples comando como o show ntp ou o ntpq –p exibem. Informações mais detalhadas sobre o protocolo NTP podem ser encontradas na RFC 5905 (https://www.ietf.org/rfc/rfc5905.txt ). Um ponto sobre as RFCs é que elas sugerem a forma geral de como as coisas deveriam (e de novo, ressalto o “deveriam”) funcionar. Cada fabricante e serviço tem suas necessidades. Então sugiro sempre verificar as documentações e KBs dos fabricantes como double check. Até a próxima!