Guia de solução de problemas e depuração de problemas do Network Time Protocol (NTP)
Contents
Introduction
Este documento descreve o uso de depurações para solucionar problemas do Network Time Protocol (NTP), bem como a saída dos principais comandos show ntp.
Comandos show do NTP
Antes de examinar a causa dos problemas de NTP, você deve entender o uso e a saída destes comandos:
- show ntp association
- show ntp association detail
- show ntp status
show ntp association
Uma associação NTP pode ser uma associação de peer (um sistema está disposto a sincronizar com o outro sistema ou a permitir que o outro sistema sincronize com ele) ou uma associação de servidor (apenas um sistema sincroniza com o outro sistema e não o contrário).
Este é um exemplo de saída do comando show ntp association:
CLA_PASA#sh ntp association
address ref clock st when poll reach delay offset disp
~127.127.7.1 127.127.7.1 9 50 64 377 0.0 0.00 0.0
~10.50.44.69 10.50.36.106 5 21231 1024 0 3.8 -4.26 16000.
+~10.50.44.101 10.50.38.114 5 57 64 1 3.6 -4.30 15875.
+~10.50.44.37 10.50.36.50 5 1 256 377 0.8 1.24 0.2
~10.50.44.133 10.50.38.170 5 12142 1024 0 3.2 1.24 16000.
+~10.50.44.165 10.50.38.178 5 35 256 357 2.5 -4.09 0.2
+~10.50.38.42 86.79.127.250 4 7 256 377 0.8 -0.29 0.2
*~10.50.36.42 86.79.127.250 4 188 256 377 0.7 -0.17 0.3
+~10.50.38.50 86.79.127.250 4 42 256 377 0.9 1.02 0.4
+~10.50.36.50 86.79.127.250 4 20 256 377 0.7 0.87 0.5
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
| Termo | Explicação |
|---|---|
Os caracteres antes do endereço têm estas definições:
|
|
endereço |
Esse é o endereço IP do peer. No exemplo, a primeira entrada mostra 127.127.7.1. Isso indica que a máquina local foi sincronizada consigo mesma. Geralmente, apenas um mestre NTP sincroniza com ele mesmo. |
ref clock |
Esse é o endereço do relógio de referência do peer. No exemplo, os primeiros seis peers/servidores têm um IP privado como relógio de referência, portanto seus mestres são provavelmente roteadores, switches ou servidores na rede local. Para as últimas quatro entradas, o relógio de referência é um IP público, então seus mestres provavelmente são uma fonte de tempo pública. |
st |
O NTP usa o conceito de um estrato para descrever a distância (em saltos NTP) que uma máquina está de uma fonte de tempo autoritativa. Por exemplo, um servidor de horário da camada 1 tem um relógio de rádio ou atômico diretamente conectado a ele. Ele envia seu tempo para um servidor de horário do estrato 2 através do NTP, e assim por diante até o estrato 16. Uma máquina que executa o NTP escolhe automaticamente a máquina com o menor número de stratum com o qual pode se comunicar e usa o NTP como sua fonte de tempo. |
quando |
O tempo desde que o último pacote NTP foi recebido de um peer é relatado em segundos. Esse valor deve ser inferior ao intervalo de pesquisa. |
sondagem |
O intervalo de sondagem é relatado em segundos. O intervalo normalmente começa com um mínimo de intervalos de pesquisa de 64 segundos. O RFC especifica que não é necessária mais de uma transação NTP por minuto para sincronizar duas máquinas. À medida que o NTP se torna estável entre um cliente e um servidor, o intervalo de sondagem pode aumentar em pequenos passos de 64 segundos até 1024 segundos e geralmente se estabiliza em algum ponto entre eles. Mas esse valor muda dinamicamente, com base nas condições de rede entre o cliente e o servidor e na perda de pacotes NTP. Se um servidor estiver inacessível por algum tempo, o intervalo de pesquisa será aumentado em etapas para 1024 segundos para reduzir a sobrecarga da rede. Não é possível ajustar o intervalo de sondagem NTP em um roteador, porque o interno é determinado por algoritmos heurísticos. |
alcance |
A alcançabilidade do ponto é uma cadeia de bits relatada como um valor octal. Este campo mostra se os últimos oito pacotes foram recebidos pelo processo NTP no software Cisco IOS®. Os pacotes devem ser recebidos, processados e aceitos como válidos pelo processo NTP e não apenas pelo roteador ou switch que recebe os pacotes IP do NTP. Reach usa o intervalo de pesquisa por um tempo de espera para decidir se um pacote foi recebido ou não. O intervalo de pesquisa é o tempo que o NTP espera antes de concluir que um pacote foi perdido. O tempo de pesquisa pode ser diferente para diferentes peers, de modo que o tempo antes do alcance decida que um pacote foi perdido também pode ser diferente para diferentes peers. No exemplo, há quatro valores de alcance diferentes:
O alcance é um bom indicador de que os pacotes NTP estão sendo descartados devido a um link ruim, problemas de CPU e outros problemas intermitentes. Converter octal < - > binário é um conversor de unidade on-line para essa e muitas outras conversões. |
atraso |
O retardo de ida e volta para peer é relatado em milissegundos. Para ajustar o relógio com mais precisão, esse atraso é considerado quando o tempo do relógio é definido. |
deslocamento |
Deslocamento é a diferença de tempo do relógio entre os peers ou entre o mestre e o cliente. Esse valor é a correção aplicada a um relógio cliente para sincronizá-lo. Um valor positivo indica que o relógio do servidor é maior. Um valor negativo indica que o relógio do cliente é maior. |
disp |
Dispersão, relatada em segundos, é a diferença máxima de tempo do relógio que já foi observada entre o relógio local e o relógio do servidor. No exemplo, a dispersão é 0,3 para o servidor 10.50.36.42, portanto a diferença máxima de tempo observada localmente entre o relógio local e o relógio do servidor é 0,3 segundos. Você pode esperar ver um alto valor quando os relógios estiverem sincronizando inicialmente. Mas, se a dispersão for muito alta em outras ocasiões, o processo NTP no cliente não aceita mensagens NTP do servidor. A dispersão máxima é de 16000; no exemplo, essa é a dispersão para servidores 10.50.44.69 e 10.50.44.133, portanto, o cliente local não aceita o tempo desses servidores. Se o alcance for zero e a dispersão for muito alta, o cliente provavelmente não está aceitando mensagens desse servidor. Consulte a segunda linha do exemplo: address ref clock st when poll reach delay offset disp Mesmo que o desvio seja apenas -4,26, a dispersão é muito alta (talvez devido a um evento passado), e o alcance é zero, portanto esse cliente não aceita o tempo desse servidor. |
show ntp association detail
Este é um exemplo de saída do comando show ntp association detail:
Router#sho ntp assoc detail
10.4.2.254 configured, our_master, sane, valid, stratum 1
ref ID .GPS., time D36968AA.CC528FE7 (02:10:50.798 UTC Fri May 25 2012)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.44, reach 377, sync dist 207.565
delay 2.99 msec, offset 268.3044 msec, dispersion 205.54
precision 2**19, version 3
org time D36968B7.E74172BF (02:11:03.903 UTC Fri May 25 2012)
rcv time D36968B7.A2F44E2C (02:11:03.636 UTC Fri May 25 2012)
xmt time D36968B7.A21D3780 (02:11:03.633 UTC Fri May 25 2012)
filtdelay = 2.99 2.88 976.61 574.65 984.71 220.26 168.12 2.72
filtoffset = 268.30 172.15 -452.49 -253.59 -462.03 -81.98 -58.04 22.38
filterror = 0.02 0.99 1.95 1.97 2.00 2.01 2.03 2.04
10.3.2.254 configured, selected, sane, valid, stratum 1
ref ID .GPS., time D36968BB.B16C4A21 (02:11:07.693 UTC Fri May 25 2012)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 3.34, reach 377, sync dist 192.169
delay 0.84 msec, offset 280.3251 msec, dispersion 188.42
precision 2**19, version 3
org time D36968BD.E69085E4 (02:11:09.900 UTC Fri May 25 2012)
rcv time D36968BD.9EE9048B (02:11:09.620 UTC Fri May 25 2012)
xmt time D36968BD.9EA943EF (02:11:09.619 UTC Fri May 25 2012)
filtdelay = 0.84 0.75 663.68 0.67 0.72 968.05 714.07 1.14
filtoffset = 280.33 178.13 -286.52 42.88 41.41 -444.37 -320.25 35.15
filterror = 0.02 0.99 1.97 1.98 1.98 2.00 2.03 2.03
10.1.2.254 configured, insane, invalid, stratum 1
ref ID .GPS., time D3696D3D.BBB4FF24 (02:30:21.733 UTC Fri May 25 2012)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 4.15, reach 1, sync dist 15879.654
delay 0.98 msec, offset 11.9876 msec, dispersion 15875.02
precision 2**19, version 3
org time D3696D3D.E4C253FE (02:30:21.893 UTC Fri May 25 2012)
rcv time D3696D3D.E1D0C1B9 (02:30:21.882 UTC Fri May 25 2012)
xmt time D3696D3D.E18A748D (02:30:21.881 UTC Fri May 25 2012)
filtdelay = 0.98 0.00 0.00 0.00 0.00 0.00 0.00 0.00
filtoffset = 11.99 0.00 0.00 0.00 0.00 0.00 0.00 0.00
filterror = 0.02 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0
Os termos já definidos na seção show ntp association não são repetidos.
Termo |
Explicação | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
configurado |
Esta origem de relógio NTP foi configurada para ser um servidor. Esse valor também pode ser dinâmico, onde o peer/servidor foi descoberto dinamicamente. |
|||||||||||||||||||||||||||
nosso_mestre |
O cliente local é sincronizado com este peer. |
|||||||||||||||||||||||||||
selecionado |
O peer/servidor é selecionado para uma possível sincronização, quando 'our_master' falha ou o cliente perde a sincronização. |
|||||||||||||||||||||||||||
sã |
Os testes de sanidade são usados para testar o pacote NTP recebido de um servidor. Esses testes são especificados na RFC 1305, Network Time Protocol (Versão 3) Specification, Implementation and Analysis . Os testes são:
Os dados do pacote são válidos se os testes 1 a 4 forem aprovados. Os dados são então usados para calcular deslocamento, atraso e dispersão. O cabeçalho do pacote é válido se os testes 5 a 8 forem aprovados. Somente pacotes com um cabeçalho válido podem ser usados para determinar se um peer pode ser selecionado para sincronização. |
|||||||||||||||||||||||||||
insano |
As verificações de integridade falharam, portanto, o tempo do servidor não é aceito. O servidor não está sincronizado. |
|||||||||||||||||||||||||||
válido |
A hora do peer/servidor é válida. O cliente local aceita desta vez se esse peer se tornar o mestre. |
|||||||||||||||||||||||||||
inválido |
A hora do peer/servidor é inválida e a hora não será aceita. |
|||||||||||||||||||||||||||
ID de referência |
A cada peer/servidor é atribuída uma ID de referência (rótulo). |
|||||||||||||||||||||||||||
tempo |
Hora é o último carimbo de hora recebido desse peer/servidor. |
|||||||||||||||||||||||||||
nosso modo/modo peer |
Este é o estado do cliente/peer local. |
|||||||||||||||||||||||||||
intvl/ poll intvl da nossa pesquisa |
Este é o intervalo de pesquisa de nossa pesquisa para este peer ou do peer para a máquina local. |
|||||||||||||||||||||||||||
retardo raiz |
O atraso da raiz é o atraso em milissegundos na raiz da configuração do NTP. Os relógios do stratum 1 são considerados como sendo a raiz de uma configuração/projeto de NTP. No exemplo, os três servidores podem ser a raiz porque estão no estrato 1. |
|||||||||||||||||||||||||||
dispersão da raiz |
A dispersão da raiz é a diferença máxima de tempo do relógio que já foi observada entre o relógio local e o relógio da raiz. Consulte a explicação de 'disp' na seção show ntp association para obter mais detalhes. |
|||||||||||||||||||||||||||
sync dist (disco de sincronização). |
Esta é uma estimativa da diferença máxima entre o tempo na fonte do stratum 0 e o tempo medido pelo cliente; consiste em componentes para o tempo de ida e volta, precisão do sistema e derivação de relógio desde a última leitura real da fonte de stratum. Em uma configuração de NTP grande (servidores NTP no stratum 1 na Internet, com servidores que originam tempo em diferentes estratos) com servidores/clientes em vários estratos, a topologia de sincronização de NTP deve ser organizada para produzir a mais alta precisão, mas nunca deve ser permitida a formação de um loop de sincronização de tempo. Um fator adicional é que cada incremento no estrato envolve um servidor de tempo potencialmente não confiável, o que introduz erros adicionais de medição. O algoritmo de seleção usado no NTP usa uma variante do algoritmo de roteamento distribuído Bellman-Ford para calcular as árvores de abrangência com peso mínimo baseadas nos servidores primários. A métrica da distância usada pelo algoritmo consiste no stratum mais a distância de sincronização, que consiste na dispersão mais metade do atraso absoluto. Assim, o caminho de sincronização sempre leva o número mínimo de servidores à raiz; os laços são resolvidos com base no erro máximo. |
|||||||||||||||||||||||||||
atraso |
Este é o atraso de ida e volta para o peer. |
|||||||||||||||||||||||||||
precisão |
Esta é a precisão do relógio peer em Hz. |
|||||||||||||||||||||||||||
versão |
Este é o número da versão NTP usada pelo peer. |
|||||||||||||||||||||||||||
hora da organização |
Esse é o datador de hora do originador do pacote NTP; em outras palavras, é o datador de hora desse peer quando ele criou o pacote NTP, mas antes de enviar o pacote ao cliente local. |
|||||||||||||||||||||||||||
tempo de rcv |
Este é o datador de hora em que o cliente local recebeu a mensagem. A diferença entre o tempo da organização e o tempo do rcv é a diferença para este peer. No exemplo, o mestre 10.4.2.254 tem estes tempos: org time D36968B7.E74172BF (02:11:03.903 UTC Fri May 25 2012) A diferença é a diferença de 268,3044 ms. |
|||||||||||||||||||||||||||
tempo xmt |
Esse é o carimbo de data e hora de transmissão do pacote NTP que o cliente local envia para esse peer/servidor. |
|||||||||||||||||||||||||||
retardo |
Este é o atraso de ida e volta em milissegundos de cada amostra. Um exemplo é o último pacote NTP recebido. No exemplo, o mestre 10.4.2.254 tem estes valores: filtdelay = 2.99 2.88 976.61 574.65 984.71 220.26 168.12 2.72 Essas oito amostras correspondem ao valor do campo de alcance, que mostra se o cliente local recebeu os últimos oito pacotes NTP. |
show ntp status
Este é um exemplo de saída do comando show ntp status:
USSP-B33S-SW01#sho ntp status
Clock is synchronized, stratum 2, reference is 10.4.2.254
nominal freq is 250.0000 Hz, actual freq is 250.5630 Hz, precision is 2**18
reference time is D36968F7.7E3019A9 (02:12:07.492 UTC Fri May 25 2012)
clock offset is 417.2868 msec, root delay is 2.85 msec
root dispersion is 673.42 msec, peer dispersion is 261.80 msec
Os termos já definidos na seção show ntp association ou na seção show ntp association details não são repetidos.
| Termo | Explicação |
|---|---|
precisão |
A precisão é determinada automaticamente e medida como uma potência de dois. No exemplo, 2**18 significa 2^(-18), ou 3,8 microssegundos. A perda de sincronização entre peers NTP ou entre um mestre e um cliente pode ser devida a uma variedade de causas. O NTP evita a sincronização com uma máquina cujo tempo pode ser ambíguo destas maneiras:
|
Troubleshooting de NTP com Debugs
Algumas das causas mais comuns dos problemas de NTP são:
- Pacotes NTP não são recebidos.
- Os pacotes NTP são recebidos, mas não são processados pelo processo NTP no IOS.
- Os pacotes NTP são processados, mas fatores errados ou dados de pacote causam a perda de sincronização.
- O período de tempo do NTP é definido manualmente.
Comandos de depuração importantes que ajudam a isolar a causa desses problemas incluem:
- debug ip packets <acl>
- debug ntp packets
- debug ntp valid
- debug ntp sync
- debug ntp events
As próximas seções ilustram o uso de depurações para resolver esses problemas comuns.
Pacotes NTP não recebidos
Use o comando debug ip packet para verificar se os pacotes NTP são recebidos e enviados. Como a saída de depuração pode ser bate-papo, você pode limitar a saída de depuração com o uso de Access Control Lists (ACLs). O NTP usa a porta 123 do User Datagram Protocol (UDP).
- Criar ACL 101:
access-list 101 permit udp any any eq 123
Os pacotes NTP geralmente têm uma porta de origem e de destino igual a 123, portanto, isso ajuda a:
access-list 101 permit udp any eq 123 any
permit udp any eq 123 any eq 123
- Use esta ACL para limitar a saída do comando debug ip packet:
debug ip packet 101
- Se o problema estiver em pares específicos, restrinja a ACL 101 a esses pares. Se o peer for 172.16.1.1, altere a ACL 101 para:
access-list 101 permit udp host 172.16.1.1 any eq 123
access-list 101 permit udp any eq 123 host 172.16.1.1
Este exemplo de saída indica que os pacotes não estão sendo enviados:
241925: Apr 23 2012 15:46:26.101 ETE: IP: s=10.50.38.70 (Tunnel99), d=10.50.44.101, len 76,
input feature
241926: Apr 23 2012 15:46:26.101 ETE: UDP src=123, dst=123, Ingress-NetFlow(13), rtype 0,
forus FALSE, sendself FALSE, mtu 0
241927: Apr 23 2012 15:46:26.101 ETE: IP: s=10.50.38.70 (Tunnel99), d=10.50.44.101, len 76,
input feature
241928: Apr 23 2012 15:46:26.101 ETE: UDP src=123, dst=123, MCI Check(55), rtype 0,
forus FALSE, sendself FALSE, mtu 0
Depois de confirmar que os pacotes NTP não foram recebidos, você deve:
- Verifique se o NTP está configurado corretamente.
- Verifique se uma ACL está bloqueando pacotes NTP.
- Verifique se há problemas de roteamento para o IP de origem ou de destino.
Pacotes NTP não processados
Com os comandos debug ip packet e debug ntp packets ativados, você pode ver os pacotes que estão sendo recebidos e transmitidos, e você pode ver que o NTP está agindo sobre esses pacotes. Para cada pacote NTP recebido (como mostrado por debug ip packet), há uma entrada correspondente gerada por debug de pacotes ntp.
Esta é a saída de depuração quando o processo NTP funciona em pacotes recebidos:
Apr 20 00:16:34.143 UTC: IP: tableid=0, s=10.3.2.31 (local), d=10.1.2.254 (Vlan2), routed
via FIB
.Apr 20 00:16:34.143 UTC: IP: s=10.3.2.31 (local), d=10.1.2.254 (Vlan2), len 76, sending
.Apr 20 00:16:34.143 UTC: IP: s=10.3.2.31 (local), d=10.1.2.254 (Vlan2), len 76, sending
full packet
.Apr 20 00:16:34.143 UTC: NTP: xmit packet to 10.1.2.254:
.Apr 20 00:16:34.143 UTC: leap 3, mode 3, version 3, stratum 0, ppoll 64
.Apr 20 00:16:34.143 UTC: rtdel 0021 (0.504), rtdsp 1105E7 (17023.056), refid 0A0102FE
(10.1.2.254)
.Apr 20 00:16:34.143 UTC: ref D33B2922.24FEBDC7 (00:15:30.144 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Apr 20 00:16:34.143 UTC: rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Apr 20 00:16:34.143 UTC: xmt D33B2962.24CAFAD1 (00:16:34.143 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: IP: s=10.1.2.254 (Vlan2), d=10.3.2.31, len 76, rcvd 2
.Apr 20 00:16:34.143 UTC: NTP: rcv packet from 10.1.2.254 to 10.3.2.31 on Vlan2:
.Apr 20 00:16:34.143 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
.Apr 20 00:16:34.143 UTC: rtdel 0000 (0.000), rtdsp 009D (2.396), refid 47505300 (71.80.83.0)
.Apr 20 00:16:34.143 UTC: ref D33B2952.4CC11CCF (00:16:18.299 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: org D33B2962.24CAFAD1 (00:16:34.143 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: rec D33B2962.49D3724D (00:16:34.288 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: xmt D33B2962.49D997D0 (00:16:34.288 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: inp D33B2962.25010310 (00:16:34.144 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: IP: tableid=0, s=10.3.2.31 (local), d=10.8.2.254 (Vlan2), routed
via FIB
.Apr 20 00:16:36.283 UTC: IP: s=10.3.2.31 (local), d=10.8.2.254 (Vlan2), len 76, sending
.Apr 20 00:16:36.283 UTC: IP: s=10.3.2.31 (local), d=10.8.2.254 (Vlan2), len 76, sending
full packet
.Apr 20 00:16:36.283 UTC: NTP: xmit packet to 10.8.2.254:
.Apr 20 00:16:36.283 UTC: leap 3, mode 3, version 3, stratum 0, ppoll 64
.Apr 20 00:16:36.283 UTC: rtdel 002F (0.717), rtdsp 11058F (17021.713), refid 0A0102FE
(10.1.2.254)
.Apr 20 00:16:36.283 UTC: ref D33B2962.25010310 (00:16:34.144 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Apr 20 00:16:36.283 UTC: rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Apr 20 00:16:36.283 UTC: xmt D33B2964.48947E87 (00:16:36.283 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: IP: s=10.8.2.254 (Vlan2), d=10.3.2.31, len 76, rcvd 2
.Apr 20 00:16:36.283 UTC: NTP: rcv packet from 10.8.2.254 to 10.3.2.31 on Vlan2:
.Apr 20 00:16:36.283 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
.Apr 20 00:16:36.283 UTC: rtdel 0000 (0.000), rtdsp 0017 (0.351), refid 47505300 (71.80.83.0)
.Apr 20 00:16:36.283 UTC: ref D33B295B.8AF7FE33 (00:16:27.542 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: org D33B2964.48947E87 (00:16:36.283 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: rec D33B2964.4A6AD269 (00:16:36.290 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: xmt D33B2964.4A7C00D0 (00:16:36.290 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: inp D33B2964.498A755D (00:16:36.287 UTC Fri Apr 20 2012)
Este é um exemplo em que o NTP não funciona em pacotes recebidos. Embora os pacotes NTP sejam recebidos (como mostrado por debug ip packets), o processo NTP não age sobre eles. Para os pacotes NTP que são enviados, uma saída correspondente debug ntp packets está presente, porque o processo NTP precisa gerar o pacote. O problema é específico dos pacotes NTP recebidos que não estão sendo processados.
071564: Apr 23 2012 15:46:26.100 ETE: NTP: xmit packet to 10.50.44.101:
071565: Apr 23 2012 15:46:26.100 ETE: leap 0, mode 1, version 3, stratum 5, ppoll 1024
071566: Apr 23 2012 15:46:26.100 ETE: rtdel 07B5 (30.106), rtdsp 0855 (32.547), refid 0A32266A
(10.50.38.106)
071567: Apr 23 2012 15:46:26.100 ETE: ref D33FDB05.1A084831 (15:43:33.101 ETE Mon Apr 23 2012)
071568: Apr 23 2012 15:46:26.100 ETE: org 00000000.00000000 (01:00:00.000 HIVER Mon Jan 1 1900)
071569: Apr 23 2012 15:46:26.100 ETE: rec 00000000.00000000 (01:00:00.000 HIVER Mon Jan 1 1900)
071570: Apr 23 2012 15:46:26.100 ETE: xmt D33FDBB2.19D3457C (15:46:26.100 ETE Mon Apr 23 2012)
PCY_PAS1#
071571: Apr 23 2012 15:47:31.497 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76,
input feature
071572: Apr 23 2012 15:47:31.497 ETE: UDP src=123, dst=123, Ingress-NetFlow(13), rtype 0,
forus FALSE, sendself FALSE, mtu 0
071573: Apr 23 2012 15:47:31.497 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76,
input feature
071574: Apr 23 2012 15:47:31.497 ETE: UDP src=123, dst=123, MCI Check(55), rtype 0,
forus FALSE, sendself FALSE, mtu 0
071575: Apr 23 2012 15:47:31.497 ETE: FIBipv4-packet-proc: route packet from Tunnel99 src
10.50.38.78 dst 10.50.44.69
071576: Apr 23 2012 15:47:31.497 ETE: FIBfwd-proc: base:10.50.44.69/32 receive entry
PCY_PAS1#
071577: Apr 23 2012 15:47:31.497 ETE: FIBipv4-packet-proc: packet routing failed
071578: Apr 23 2012 15:47:31.497 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, rcvd 2
071579: Apr 23 2012 15:47:31.497 ETE: UDP src=123, dst=123
071580: Apr 23 2012 15:47:31.497 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, stop
process pak for forus packet
071581: Apr 23 2012 15:47:31.497 ETE: UDP src=123, dst=123
PCY_PAS1#
071582: Apr 23 2012 16:03:30.105 ETE: NTP: xmit packet to 10.50.44.101:
071583: Apr 23 2012 16:03:30.105 ETE: leap 0, mode 1, version 3, stratum 5, ppoll 1024
071584: Apr 23 2012 16:03:30.105 ETE: rtdel 0759 (28.702), rtdsp 087D (33.157), refid 0A32266A
(10.50.38.106)
071585: Apr 23 2012 16:03:30.105 ETE: ref D33FDF05.1B2CC3D4 (16:00:37.106 ETE Mon Apr 23 2012)
071586: Apr 23 2012 16:03:30.105 ETE: org 00000000.00000000 (01:00:00.000 HIVER Mon Jan 1 1900)
071587: Apr 23 2012 16:03:30.105 ETE: rec 00000000.00000000 (01:00:00.000 HIVER Mon Jan 1 1900)
071588: Apr 23 2012 16:03:30.105 ETE: xmt D33FDFB2.1B1D5E7E (16:03:30.105 ETE Mon Apr 23 2012)
PCY_PAS1#
071589: Apr 23 2012 16:04:35.502 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76,
input feature
071590: Apr 23 2012 16:04:35.506 ETE: UDP src=123, dst=123, Ingress-NetFlow(13), rtype 0,
forus FALSE, sendself FALSE, mtu 0
071591: Apr 23 2012 16:04:35.506 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76,
input feature
071592: Apr 23 2012 16:04:35.506 ETE: UDP src=123, dst=123, MCI Check(55), rtype 0, forus
FALSE, sendself FALSE, mtu 0
071593: Apr 23 2012 16:04:35.506 ETE: FIBipv4-packet-proc: route packet from Tunnel99 src
10.50.38.78 dst 10.50.44.69
071594: Apr 23 2012 16:04:35.506 ETE: FIBfwd-proc: base:10.50.44.69/32 receive entry
PCY_PAS1#
071595: Apr 23 2012 16:04:35.506 ETE: FIBipv4-packet-proc: packet routing failed
071596: Apr 23 2012 16:04:35.506 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, rcvd 2
071597: Apr 23 2012 16:04:35.506 ETE: UDP src=123, dst=123
071598: Apr 23 2012 16:04:35.506 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, stop
process pak for forus packet
071599: Apr 23 2012 16:04:35.506 ETE: UDP src=123, dst=123
PCY_PAS1#
Perda de sincronização
A perda de sincronização pode ocorrer se o valor de dispersão e/ou atraso de um servidor for muito alto. Valores altos indicam que os pacotes estão demorando muito para chegar ao cliente do servidor/peer em referência à raiz do relógio. Então, a máquina local não pode confiar na precisão do tempo presente no pacote, porque ela não sabe quanto tempo levou para o pacote chegar aqui.
O NTP é meticuloso em relação ao tempo e não será sincronizado com outro dispositivo em que não pode confiar ou não pode ajustar de uma forma que possa ser confiável.
Se houver um enlace saturado e o buffer ocorrer ao longo do caminho, os pacotes serão atrasados à medida que chegam ao cliente NTP. Assim, o carimbo de data e hora contido em um pacote NTP subsequente pode ocasionalmente variar muito, e o cliente local não pode realmente se ajustar para essa variação.
O NTP não oferece um método para desativar a validação desses pacotes, a menos que você use o SNTP (Simple Network Time Protocol). O SNTP pode não ser muito uma alternativa porque não é amplamente suportado no software.
Se você tiver perda de sincronização, deverá verificar os links:
- Eles estão saturados?
- Há algum tipo de descarte em seus links de rede de longa distância (WAN)?
- A criptografia está ocorrendo?
Monitore o valor de alcance do comando show ntp associations detail. O valor mais alto é 377. Se o valor for 0 ou baixo, os pacotes NTP estão sendo recebidos intermitentemente e o cliente local não está sincronizado com o servidor.
debug ntp valid
O comando debug ntp valid indica se o pacote NTP falhou na verificação de integridade ou validade e revela o motivo da falha. Compare essa saída com os testes de sanidade especificados no RFC1305 que são usados para testar o pacote NTP recebido de um servidor. São definidos oito testes:
| Teste | Máscara | Explicação |
|---|---|---|
| 1 | 0x01 | Pacote duplicado recebido |
| 2 | 0x02 | Pacote Bogus recebido |
| 3 | 0x04 | Protocolo não sincronizado |
| 4 | 0x08 | Verificação de limite de falha de dispersão/atraso de peer |
| 5 | 0x10 | Falha na autenticação de peer |
| 6 | 0x20 | Relógio de peer não sincronizado (comum para servidor não sincronizado) |
| 7 | 0x40 | Estrato de peer fora do limite |
| 8 | 0x80 | Falha na verificação de limite de atraso/dispersão da raiz |
Este é um exemplo de saída do comando debug ntp valid:
PCY_PAS1#debug ntp validity
NTP peer validity debugging is on
009585: Mar 1 2012 09:14:32.670 HIVER: NTP: packet from 192.196.113.57 failed validity tests 52
009586: Mar 1 2012 09:14:32.670 HIVER: Authentication failed
009587: Mar 1 2012 09:14:32.670 HIVER: Peer/Server Stratum out of bound
PCY_PAS1#
009588: Mar 1 2012 09:14:38.210 HIVER: NTP: packet from 192.168.56.1 failed validity tests 14
009589: Mar 1 2012 09:14:38.210 HIVER: Authentication failed
PCY_PAS1#
009590: Mar 1 2012 09:14:43.606 HIVER: NTP: packet from 163.110.103.27 failed validity tests 14
009591: Mar 1 2012 09:14:43.606 HIVER: Authentication failed
PCY_PAS1#
009592: Mar 1 2012 09:14:48.686 HIVER: NTP: packet from 192.196.113.57 failed validity tests 52
009593: Mar 1 2012 09:14:48.686 HIVER: Authentication failed
009594: Mar 1 2012 09:14:48.686 HIVER: Peer/Server Stratum out of bound
PCY_PAS1#
009596: Mar 1 2012 09:14:54.222 HIVER: NTP: packet from 163.110.103.35 failed validity tests 14
009597: Mar 1 2012 09:14:54.222 HIVER: Authentication failed
PCY_PAS1#
009598: Mar 1 2012 09:14:54.886 HIVER: NTP: synced to new peer 10.50.38.106
009599: Mar 1 2012 09:14:54.886 HIVER: NTP: 10.50.38.106 synced to new peer
PCY_PAS1#
009600: Mar 1 2012 09:14:59.606 HIVER: NTP: packet from 163.110.103.27 failed validity tests 14
009601: Mar 1 2012 09:14:59.606 HIVER: Authentication failed
PCY_PAS1#
009602: Mar 1 2012 09:15:04.622 HIVER: NTP: packet from 192.196.113.137 failed validity tests 52
009603: Mar 1 2012 09:15:04.622 HIVER: Authentication failed
009604: Mar 1 2012 09:15:04.622 HIVER: Peer/Server Stratum out of bound
PCY_PAS1#
009605: Mar 1 2012 09:15:10.238 HIVER: NTP: packet from 192.168.56.1 failed validity tests 14
009606: Mar 1 2012 09:15:10.238 HIVER: Authentication failed
PCY_PAS1#
009607: Mar 1 2012 09:15:15.338 HIVER: NTP: packet from 163.83.23.140 failed validity tests 52
009608: Mar 1 2012 09:15:15.338 HIVER: Authentication failed
009609: Mar 1 2012 09:15:15.338 HIVER: Peer/Server Stratum out of bound
PCY_PAS1#
009610: Mar 1 2012 09:15:20.402 HIVER: NTP: packet from 192.196.113.92 failed validity tests 74
009611: Mar 1 2012 09:15:20.402 HIVER: Authentication failed
009612: Mar 1 2012 09:15:20.402 HIVER: Peer/Server Clock unsynchronized
009613: Mar 1 2012 09:15:20.402 HIVER: Peer/Server Stratum out of bound
debug ntp packets
Você pode usar o comando debug ntp packets para ver o tempo que o peer/servidor lhe dá no pacote recebido. A máquina local de hora também informa o tempo que sabe ao peer/server no pacote transmitido.
| Campo | pacote rcv | pacote xmit |
|---|---|---|
| org | Data e hora do originador, que é a hora do servidor. | Carimbo de data e hora do originador (cliente) ao enviar o pacote. (O cliente origina um pacote para o servidor.) |
| cons | Carimbo de hora no cliente quando ele recebeu o pacote. | Hora atual do cliente. |
Neste exemplo de saída, os datadores no pacote recebido do servidor e no pacote enviado para outro servidor são os mesmos, o que indica que o NTP do cliente está em sincronização.
USSP-B33S-SW01#debug ntp packets
NTP packets debugging is on
USSP-B33S-SW01#
May 25 02:21:48.182 UTC: NTP: rcv packet from 10.1.2.254 to 10.3.2.31 on Vlan2:
May 25 02:21:48.182 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
May 25 02:21:48.182 UTC: rtdel 0000 (0.000), rtdsp 00F2 (3.693), refid 47505300 (71.80.83.0)
May 25 02:21:48.182 UTC: ref D3696B38.B722C417 (02:21:44.715 UTC Fri May 25 2012)
May 25 02:21:48.182 UTC: org D3696B3C.2EA179BA (02:21:48.182 UTC Fri May 25 2012)
May 25 02:21:48.182 UTC: rec D3696B3D.E58DE1BE (02:21:49.896 UTC Fri May 25 2012)
May 25 02:21:48.182 UTC: xmt D3696B3D.E594E7AF (02:21:49.896 UTC Fri May 25 2012)
May 25 02:21:48.182 UTC: inp D3696B3C.2EDFC333 (02:21:48.183 UTC Fri May 25 2012)
May 25 02:22:46.051 UTC: NTP: xmit packet to 10.4.2.254:
May 25 02:22:46.051 UTC: leap 0, mode 3, version 3, stratum 2, ppoll 64
May 25 02:22:46.051 UTC: rtdel 00C0 (2.930), rtdsp 1C6FA (1777.252), refid 0A0402FE (10.4.2.254)
May 25 02:22:46.051 UTC: ref D3696B36.33D43F44 (02:21:42.202 UTC Fri May 25 2012)
May 25 02:22:46.051 UTC: org D3696B37.E72C75AE (02:21:43.903 UTC Fri May 25 2012)
May 25 02:22:46.051 UTC: rec D3696B36.33D43F44 (02:21:42.202 UTC Fri May 25 2012)
May 25 02:22:46.051 UTC: xmt D3696B76.0D43AE7D (02:22:46.051 UTC Fri May 25 2012)
Este é um exemplo de saída quando os relógios não estão sincronizados. Observe a diferença de tempo entre o pacote de saída e o pacote de rcv. A dispersão de peer estará no valor máximo de 16000, e o alcance para o peer mostrará 0.
USSP-B33S-SW01#
.May 25 02:05:59.011 UTC: NTP: xmit packet to 10.4.2.254:
.May 25 02:05:59.011 UTC: leap 3, mode 3, version 3, stratum 0, ppoll 64
.May 25 02:05:59.011 UTC: rtdel 00A3 (2.487), rtdsp 1104D0 (17018.799), refid 0A0402FE
(10.4.2.254)
.May 25 02:05:59.011 UTC: ref D3696747.03D8661A (02:04:55.015 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.May 25 02:05:59.011 UTC: rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.May 25 02:05:59.011 UTC: xmt D3696787.03105783 (02:05:59.011 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: NTP: rcv packet from 10.4.2.254 to 10.3.2.31 on Vlan2:
.May 25 02:05:59.011 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
.May 25 02:05:59.011 UTC: rtdel 0000 (0.000), rtdsp 0014 (0.305), refid 47505300 (71.80.83.0)
.May 25 02:05:59.011 UTC: ref D3696782.C96FD778 (02:05:54.786 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: org D3696787.03105783 (02:05:59.011 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: rec D3696787.281A963F (02:05:59.156 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: xmt D3696787.282832C4 (02:05:59.156 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: inp D3696787.03C63542 (02:05:59.014 UTC Fri May 25 2012)
debug ntp sync and debug ntp events
O comando debug ntp sync produz saídas de uma linha que mostram se o relógio foi sincronizado ou se a sincronização foi alterada. O comando geralmente é ativado com debug ntp events.
O comando debug ntp events mostra todos os eventos NTP que ocorrem, o que ajuda a determinar se uma alteração no NTP disparou um problema, como relógios que estão fora de sincronia. (Em outras palavras, se seus relógios de sincronia felizes de repente enlouquecem, você sabe procurar por uma mudança ou um gatilho!)
Este é um exemplo de ambas as depurações. Inicialmente, os relógios do cliente foram sincronizados. O comando debug ntp events mostra que ocorreu uma alteração de stratum de peer NTP, e os relógios ficaram dessincronizados.
USSP-B33S-SW01#debug ntp sync
NTP clock synchronization debugging is on
USSP-B33S-SW01#
USSP-B33S-SW01#
USSP-B33S-SW01#debug ntp events
NTP events debugging is on
USSP-B33S-SW01#
USSP-B33S-SW01#
May 25 02:25:57.620 UTC: NTP: xmit packet to 10.4.2.254:
May 25 02:25:57.620 UTC: leap 0, mode 3, version 3, stratum 2, ppoll 64
May 25 02:25:57.620 UTC: rtdel 00D4 (3.235), rtdsp 26B26 (2418.549), refid 0A0402FE (10.4.2.254)
May 25 02:25:57.620 UTC: ref D3696BF5.C47EB880 (02:24:53.767 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: org D3696BF7.E5F91077 (02:24:55.898 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: rec D3696BF5.C47EB880 (02:24:53.767 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: xmt D3696C35.9ED1CE97 (02:25:57.620 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: NTP: rcv packet from 10.4.2.254 to 10.3.2.31 on Vlan2:
May 25 02:25:57.620 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
May 25 02:25:57.620 UTC: rtdel 0000 (0.000), rtdsp 000E (0.214), refid 47505300 (71.80.83.0)
May 25 02:25:57.620 UTC: ref D3696C37.D528800E (02:25:59.832 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: org D3696C35.9ED1CE97 (02:25:57.620 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: rec D3696C37.E5C7AB3D (02:25:59.897 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: xmt D3696C37.E5D1F273 (02:25:59.897 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: inp D3696C35.9F9EA2C4 (02:25:57.623 UTC Fri May 25 2012)
May 25 02:25:59.830 UTC: NTP: peer stratum change
May 25 02:25:59.830 UTC: NTP: clock reset
May 25 02:25:59.830 UTC: NTP: sync change
May 25 02:25:59.830 UTC: NTP: peer stratum change
May 25 02:26:05.817 UTC: NTP: xmit packet to 10.1.2.254:
May 25 02:26:05.817 UTC: leap 3, mode 3, version 3, stratum 0, ppoll 64
May 25 02:26:05.817 UTC: rtdel 00C2 (2.960), rtdsp 38E9C (3557.068), refid 0A0402FE (10.4.2.254)
May 25 02:26:05.817 UTC: ref D3696C35.9F9EA2C4 (02:25:57.623 UTC Fri May 25 2012)
May 25 02:26:05.817 UTC: org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
May 25 02:26:05.817 UTC: rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
May 25 02:26:05.817 UTC: xmt D3696C3D.D12D0565 (02:26:05.817 UTC Fri May 25 2012)
Período de relógio NTP definido manualmente
O site Cisco.com avisa que:
"O comando ntp clock-period é gerado automaticamente para refletir o fator de correção que muda constantemente quando o comando copy running-configuration startup-configuration é inserido para salvar a configuração na NVRAM. Não tente usar manualmente o comando ntp clock-period. Certifique-se de remover esta linha de comando ao copiar arquivos de configuração para outros dispositivos."
O valor do período de clock depende do hardware, portanto, é diferente para cada dispositivo.
O comando ntp clock-period aparece automaticamente na configuração quando você ativa o NTP. O comando é usado para ajustar o relógio do software. O 'valor de ajuste' compensa o intervalo de pulsos de 4 ms, de modo que, com o ajuste menor, você tenha 1 segundo no final do intervalo.
Se o dispositivo calculou que seu relógio do sistema está perdendo tempo (talvez seja necessário uma compensação de frequência do nível base do roteador), ele adiciona automaticamente esse valor ao relógio do sistema para manter sua sincronicidade.
O período de tempo padrão do NTP para um roteador é 17179869 e é essencialmente usado para iniciar o processo do NTP.
A fórmula de conversão é 17179869 * 2^(-32) = 0,0039999995715916156768798828125, ou aproximadamente 4 milhões segundos.
Por exemplo, o relógio do sistema para os roteadores Cisco 2611 (um dos Cisco 2600 Series Routers) foi considerado um pouco fora de sincronia e pode ser ressincronizado com este comando:
ntp clock-period 17208078
Isso equivale a 17208078 * 2^(-32) = 0,0040065678767859935760498046875, ou um pouco mais de 4 milissegundos d.
A Cisco recomenda que você deixe o roteador funcionar por uma semana ou mais em condições de rede normais e use o comando wr mem para salvar o valor. Isso fornece uma figura precisa para a próxima reinicialização e permite que o NTP sincronize mais rapidamente.
Use o comando no ntp clock-period quando você salvar a configuração para uso em outro dispositivo porque esse comando descarta o clock-period de volta para o padrão desse dispositivo específico. O valor verdadeiro será recalculado (mas reduzirá a precisão do relógio do sistema durante esse período de tempo de recálculo).
Lembre-se de que esse valor depende do hardware, portanto, se você copiar uma configuração e usá-la em dispositivos diferentes, poderá causar problemas. A Cisco planeja substituir o NTP versão 3 pela versão 4 para resolver esse problema.
Se não estiver ciente desses problemas, você pode decidir mexer manualmente com esse valor. Para migrar de um dispositivo para outro, você pode decidir copiar a configuração antiga e colá-la no novo dispositivo. Infelizmente, como o comando ntp clock-period aparece na configuração atual e na configuração de inicialização, o NTP clock-period é colado no novo dispositivo. Quando isso acontece, o NTP no novo cliente sempre sai fora de sincronia com o servidor com um alto valor de dispersão de peer.
Em vez disso, limpe o período de tempo do NTP com o comando no ntp clock-period e salve a configuração. O roteador eventualmente calcula um período de clock apropriado para si.
O comando ntp clock-period não está mais disponível no software Cisco IOS versão 15.0 ou posterior; o analisador agora rejeita o comando com o erro:
"%NTP: This configuration command is deprecated."
Portanto, você não tem permissão para configurar o período de tempo manualmente, e o período de tempo não é permitido na configuração atual. Como o analisador rejeita o comando se ele estava na configuração de inicialização (em versões anteriores do Cisco IOS, como 12.4), o analisador rejeita o comando quando copia a configuração de inicialização para a configuração de inicialização na inicialização.
O novo comando de substituição é ntp clear drift.
Informações Relacionadas
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
1.0 |
17-Aug-2013 |
Versão inicial |
Feedback