Edições do Network Time Protocol (NTP) que pesquisam defeitos e que debugam o guia
Índice
Introdução
Este documento descreve o uso do debuga a fim pesquisar defeitos edições do Network Time Protocol (NTP), assim como a saída do NTP chave da mostra comanda.
Comandos show NTP
Antes que você olhe a causa de problemas NTP, você deve compreender o uso de e a saída destes comandos:
- mostre a associação NTP
- mostre o detalhe da associação NTP
- mostre o estado NTP
mostre a associação NTP
Uma associação NTP pode ser uma associação de peer (um sistema é disposto sincronizar ao outro sistema ou permitir que o outro sistema lhe sincronize) ou uma associação do server (sincronizars de somente um sistema ao outro sistema e não à outra maneira ao redor).
Este é um exemplo de saída do comando da associação NTP da mostra:
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 caráteres antes do endereço têm estas definições:
| |
endereço | Este é o endereço IP de Um ou Mais Servidores Cisco ICM NT do par. No exemplo, a primeira entrada mostra 127.127.7.1. Isto indica que a máquina local tem sincronizado com se. Geralmente, somente sincronizações de um mestre NTP com se. |
pulso de disparo referência | Este é o endereço do relógio de referência para o par. No exemplo, os primeiros seis pares/server têm um IP privado como o relógio de referência, assim que seus mestres são provavelmente Roteadores, Switches, ou server dentro da rede local. Para as últimas quatro entradas, o relógio de referência é um IP do público, assim que seus mestres são provavelmente um origem de tempo público. |
st | O NTP usa o conceito de um estrato a fim descrever como longe (em saltos NTP) uma máquina é de uma fonte de tempo autoritária. Por exemplo, um Time Server do estrato 1 tem um rádio ou um relógio atômico anexado diretamente a ele. Envia seu tempo a um Time Server do estrato 2 com o NTP, e assim por diante até o estrato 16. Uma máquina que executa o NTP escolhe automaticamente a máquina com o mais baixo número de estrato com que pode se comunicar e usa o NTP como seu origem de tempo. |
quando | O tempo desde que o último pacote de NTP foi recebido de um par é relatado nos segundos. Este valor deve ser mais baixo do que o intervalo de polling. |
votação | O intervalo de polling é relatado nos segundos. O intervalo começa geralmente com um mínimo de intervalos de votação 64-second. O RFC especifica que não mais de uma transação NTP pelo minuto está precisada a fim sincronizar duas máquinas. Enquanto o NTP se torna estável entre um cliente e um server, o intervalo de votação pode aumentar em etapas pequenas de 64 segundos até 1024 segundos e estabiliza geralmente em algum lugar in-between. Mas, este valor muda dinamicamente, com base nas condições de rede entre o cliente e o server e a perda de pacotes de NTP. Se um server é inacessível por algum tempo, o intervalo de votação está aumentado nas etapas a 1024 segundos a fim reduzir a carga adicional de rede. Não é possível ajustar o intervalo de votação NTP em um roteador, porque o interno é determinado por algoritmos heurísticos. |
alcance | A alcançabilidade de peer é um string de bit relatado como um valor octal. Este campo mostra se os últimos oito pacotes estiveram recebidos pelo processo NTP no software do ® do Cisco IOS. Os pacotes devem ser recebidos, processado, e aceitado como válidos pelo processo NTP e não apenas pelo roteador ou pelo interruptor que recebe os pacotes IP NTP. O alcance usa o intervalo de votação para um intervalo a fim decidir se um pacote esteve recebido ou não. O intervalo de votação é o tempo que o NTP espera antes que conclua que um pacote esteve perdido. O tempo da votação pode ser diferente para pares diferentes, assim que o tempo antes que o alcance decida que um pacote esteve perdido pode igualmente diferente para pares diferentes. No exemplo, há quatro valores diferentes do alcance:
O alcance é um bom indicador de se os pacotes de NTP estão sendo deixados cair devido a um link deficiente, CPU emite e outros problemas intermitentes. Converso octal < - > o binário é um conversor em linha da unidade para este e muitas outras conversões. |
atraso | O retardo round trip a espreitar é relatado nos milissegundos. A fim ajustar mais exatamente o pulso de disparo, este atraso é levado em consideração quando o tempo é ajustado. |
offset | O offset é a diferença de tempo entre os pares ou entre o mestre e o cliente. Este valor é a correção que é aplicada a um pulso de disparo do cliente a fim o sincronizar. Um valor positivo indica que o pulso de disparo do server é mais alto. Um valor negativo indica que o pulso de disparo do cliente é mais alto. |
disp | A dispersão, relatada nos segundos, é a diferença de horário do relógio máximo que foi observada nunca entre o relógio local e o pulso de disparo do server. No exemplo, a dispersão é 0.3 para o server 10.50.36.42, assim que a diferença de tempo máximo observada nunca localmente entre o relógio local e o pulso de disparo do server é 0.3 segundos. Você pode esperar ver um alto valor quando os pulsos de disparo são em sincronismo inicialmente. Mas, se a dispersão é demasiado alta em outras épocas, o processo NTP no cliente não aceita mensagens de NTP do server. A dispersão máxima é 16000; no exemplo, aquela é a dispersão para server 10.50.44.69 e 10.50.44.133, assim que o cliente local não aceita o tempo destes server. Se o alcance é zero e a dispersão é muito alta, o cliente provavelmente não está aceitando mensagens desse server. Refira a segunda linha do exemplo: address ref clock st when poll reach delay offset disp Mesmo que o offset seja apenas -4.26, a dispersão é muito alta (talvez devido à após o evento), e o alcance é zero, assim que este cliente não aceita o tempo deste server. |
mostre o detalhe da associação NTP
Este é um exemplo de saída do comando detail da associação NTP da mostra:
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 da associação NTP da mostra não são repetidos.
Termo | Explicação | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
configurado | Este origem do relógio NTP foi configurado para ser um server. Este valor pode igualmente ser dinâmico, onde o par/server foi descoberto dinamicamente. | |||||||||||||||||||||||||||
our_master | O cliente local é sincronizado a este par. | |||||||||||||||||||||||||||
selecionado | O par/server está selecionado para a sincronização possível, quando o “our_master” falha ou o cliente perde a sincronização. | |||||||||||||||||||||||||||
são | Os testes da sanidade são usados a fim testar o pacote de NTP recebido de um server. Estes testes são especificados no RFC 1305, na especificação, na aplicação e na análise do protocolo Network Time Protocol (versão 3). Os testes são:
Os dados do pacote são válidos se os testes 1 4 são passados. Os dados são usados então a fim calcular o offset, o atraso, e a dispersão. O cabeçalho de pacote de informação é válido se os testes 5 a 8 são passados. Somente os pacotes com um encabeçamento válido podem ser usados para determinar se um par pode ser selecionado para a sincronização. | |||||||||||||||||||||||||||
insano | As verificações de sanidade falharam, assim que o tempo do server não é aceitado. O server unsynced. | |||||||||||||||||||||||||||
válido | O par/tempo de servidor é válidos. O cliente local aceita esta vez se este par se transforma o mestre. | |||||||||||||||||||||||||||
inválido | O par/tempo de servidor é inválidos, e o tempo não será aceitado. | |||||||||||||||||||||||||||
referência ID | Cada par/server é atribuído uma referência ID (etiqueta). | |||||||||||||||||||||||||||
tempo | O tempo é o selo de última vez recebido desses par/server. | |||||||||||||||||||||||||||
nosso modo do par do modo | Este é o estado do cliente local/par. | |||||||||||||||||||||||||||
nosso intvl da votação do par da votação intvl/ | Este é o intervalo de votação de nossa votação a este par ou do par à máquina local. | |||||||||||||||||||||||||||
atraso da raiz | O atraso da raiz é o atraso nos milissegundos à raiz da instalação NTP. Os pulsos de disparo do estrato 1 são considerados estar na raiz de um NTP setup/projeto. No exemplo, todos os três server podem ser a raiz porque estão no estrato 1. | |||||||||||||||||||||||||||
dispersão da raiz | A dispersão da raiz é a diferença de horário do relógio máximo que foi observada nunca entre o relógio local e o pulso de disparo da raiz. Refira a explicação do “disp” sob a seção da associação NTP da mostra para mais detalhes. | |||||||||||||||||||||||||||
dist da sincronização. | Esta é uma avaliação da diferença máxima entre o tempo na fonte do estrato 0 e o tempo medido pelo cliente; consiste nos componentes para o Round Trip Time, a precisão do sistema, e a alteração de relógio desde que o último real lidos da fonte do estrato. Em um grande NTP setup (servidores de NTP no estrato 1 no Internet, com server que tempo da fonte em estratos diferentes) com server/clientes em estratos múltiplos, a topologia da sincronização de NTP deve ser organizada a fim produzir a precisão a mais alta, mas deve nunca ser reservada formar um laço da sincronização de tempo. Um fator adicional é que cada incremento no estrato envolve um Time Server potencialmente incerto, que introduza erros de medida adicionais. O algoritmo de seleção usado no NTP usa uma variação do algoritmo de roteamento distribuído Pregoeiro-Ford a fim computar o mínimo-peso que mede - as árvores enraizadas nos servidores primários. A métrica da distância usada pelo algoritmo consiste no estrato mais a distância da sincronização, que própria consiste na dispersão mais um meio do retardo absoluto. Assim, o trajeto da sincronização toma sempre o número mínimo de server à raiz; os laços são resolved com base no erro máximo. | |||||||||||||||||||||||||||
atraso | Este é o retardo de round trip a espreitar. | |||||||||||||||||||||||||||
precisão | Esta é a precisão do pulso de disparo do par no hertz. | |||||||||||||||||||||||||||
versão | Este é o número de versão NTP usado pelo par. | |||||||||||||||||||||||||||
tempo do org | Este é o selo de tempo do autor do pacote de NTP; ou seja foi o selo de tempo deste par em que criou o pacote de NTP mas antes que enviou o pacote ao cliente local. | |||||||||||||||||||||||||||
tempo receptor | Este é o selo de tempo em que o cliente local recebeu a mensagem. A diferença entre o tempo do org e o tempo receptor é o offset para este par. No exemplo, 10.4.2.254 mestre tem estas épocas: org time D36968B7.E74172BF (02:11:03.903 UTC Fri May 25 2012) A diferença é o offset de 268.3044 milissegundos. | |||||||||||||||||||||||||||
tempo do xmt | Este é o selo de tempo transmitir para o pacote de NTP que o cliente local envia a estes par/server. | |||||||||||||||||||||||||||
filtdelay | Este é o retardo de round trip nos milissegundos de cada amostra. Uma amostra é o último pacote de NTP recebido. No exemplo, 10.4.2.254 mestre tem estes valores: filtdelay = 2.99 2.88 976.61 574.65 984.71 220.26 168.12 2.72 Estas oito amostras correspondem ao valor do campo do alcance, que mostra se o cliente local recebeu os últimos oito pacotes de NTP. |
mostre o estado NTP
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 da associação NTP da mostra ou na seção dos detalhes da associação NTP da mostra 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 pares NTP ou entre um mestre e um cliente pode ser devido a uma variedade de causas. O NTP evita a sincronização com uma máquina cuja a hora possa ser ambígua nestas maneiras:
|
Pesquisar defeitos o NTP com debuga
Algumas da maioria de causas comum de edições NTP são:
- Os pacotes de NTP não são recebidos.
- Os pacotes de NTP são recebidos, mas não processados pelo processo NTP nos IO.
- Os pacotes de NTP são processados, mas os fatores ou os dados do pacote errôneos causam a perda de sincronização.
- O pulso de disparo-período NTP é ajustado manualmente.
Comandos debug importantes que isolado que da ajuda a causa destas edições inclui:
- debugar o <acl> dos pacotes IP
- debugar pacotes NTP
- debugar a validez NTP
- debugar a sincronização de NTP
- debugar eventos NTP
As próximas seções ilustram o uso do debugam a fim resolver estes problemas comuns.
Pacotes de NTP não recebidos
Use o comando debug ip packet a fim verificar se os pacotes de NTP são recebidos e enviados. Desde que o resultado do debug pode ser tagarela, você pode limitar o resultado do debug com o uso do Access Control Lists (ACLs). O NTP usa a porta 123 do User Datagram Protocol (UDP).
- Crie o ACL 101:
access-list 101 permit udp any any eq 123
Os pacotes de NTP têm geralmente uma porta de origem e de destino de 123, assim que este ajuda:
access-list 101 permit udp any eq 123 any
permit udp any eq 123 any eq 123
- Use este ACL a fim limitar a saída do comando debug ip packet:
debug ip packet 101
- Se a edição é com peer particulares, reduza o ACL 101 para baixo 2 aqueles pares. Se o par é 172.16.1.1, mude o ACL 101 a:
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
Estas saídas de exemplo indicam 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
Uma vez que você confirma que os pacotes de NTP não estão recebidos, você deve:
- Verifique se o NTP é configurado corretamente.
- Verifique se um ACL está obstruindo pacotes de NTP.
- Verifique para ver se há questões de roteamento à fonte ou ao IP de destino.
Pacotes de NTP não processados
Com debugar o pacote IP e debugar os comandos packets NTP permitidos, você pode ver os pacotes que estão sendo recebidos e transmitidos, e você pode ver que o NTP está atuando em cima daqueles pacotes. Para cada pacote de NTP recebido (como mostrado por debugar o pacote IP), há uma entrada correspondente gerada por debuga pacotes NTP.
Este é o resultado do debug quando os trabalhos NTP 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 onde o NTP não trabalhe em pacotes recebidos. Embora os pacotes de NTP sejam recebidos (como mostrado por debugar pacotes IP), o processo NTP não atua neles. Para os pacotes de NTP que são mandados, uma correspondência debuga pacotes que NTP a saída esta presente, porque o processo NTP tem que gerar o pacote. A edição é específica aos pacotes de 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 pôde ocorrer se a dispersão e/ou o valor de atraso para um server vão muito altamente. Os altos valores indicam que os pacotes estão tomando demasiado por muito tempo para obter ao cliente do server/par na referência à raiz do pulso de disparo. Assim, a máquina local não pode confiar a precisão do tempo atual no pacote, porque não sabe quanto tempo tomou para que o pacote obtenha aqui.
O NTP é meticuloso sobre o tempo e não sincronizará com um outro dispositivo que não pode confiar nem não pode ajustar em uma maneira de modo que se possa confiar.
Se há um link saturado e a proteção ocorre ao longo do caminho, os pacotes obtêm atrasados enquanto vêm ao cliente de NTP. Assim, o timestamp contido em um pacote de NTP subsequente pode ocasionalmente variar muito, e o cliente local não pode realmente ajustar para essa variação.
O NTP não oferece um método desligar a validação destes pacotes a menos que você usar SNTP (protocolo de tempo de rede simples). O SNTP não pode ser muita de uma alternativa porque não é apoiado extensamente no software.
Se você experimenta a perda de sincronização, você deve verificar os links:
- São saturados?
- Há quaisquer tipos das gotas em seus links do Wide Area Network (WAN)
- A criptografia está ocorrendo?
Monitore o valor do alcance do comando show ntp associations detail. O valor o mais alto é 377. Se o valor é 0 ou baixo, os pacotes de NTP estão sendo recebidos intermitentemente, e o cliente local sai da sincronização com o server.
debugar a validez NTP
O comando da validez NTP debugar indica se o pacote de NTP falhou a sanidade ou as verificações de validade e revela a razão para a falha. Compare esta saída aos testes da sanidade especificados no RFC1305 que são usados a fim testar o pacote de NTP recebido de um server. Oito testes são definidos:
| Teste | Máscara | Explicação |
|---|---|---|
| 1 | 0x01 | Pacote duplicado recebido |
| 2 | 0x02 | Pacote falso recebido |
| 3 | 0x04 | Protocolo não-sincronizado |
| 4 | 0x08 | Atraso do par/verificação de limite falhada dispersão |
| 5 | 0x10 | Autenticação de peer falhada |
| 6 | 0x20 | Pulso de disparo do par não-sincronizado (comum para o server unsynched) |
| 7 | 0x40 | Estrato do par fora do limite |
| 8 | 0x80 | Atraso da raiz/verificação de limite falhada dispersão |
Este é exemplo de saída do comando da validez NTP debugar:
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
debugar pacotes NTP
Você pode usar o comando packets NTP debugar a fim ver o tempo que o par/server lhe dá no pacote recebido. A máquina local do tempo igualmente diz o tempo onde sabe ao par/server no pacote transmitido.
| Campo | pacote receptor | pacote do xmit |
|---|---|---|
| org | Selo de tempo do autor, que é o tempo de servidor. | Selo de tempo do autor (cliente) em que enviou o pacote. (O cliente origina um pacote ao server.) |
| rec | Selo de tempo no cliente quando recebeu o pacote. | Horas atual do cliente. |
Neste exemplo de saída, os selos de tempo no pacote recebido do server e o pacote enviado a um outro server são os mesmos, que indicam que o cliente NTP está na 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 pulsos de disparo não estão na sincronização. Observe a diferença de horário entre o pacote do xmit e o pacote receptor. A dispersão do par estará no valor máximo de 16000, e o alcance para o par 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)
debugar a sincronização de NTP e debugar eventos NTP
O comando da sincronização de NTP debugar produz as saídas da uma linha que mostram se o pulso de disparo tem sincronizado ou a sincronização mudou. O comando é permitido geralmente com debuga eventos NTP.
Os eventos NTP debugar comandam mostras todos os eventos NTP que ocorrerem, que o ajuda a determinar se uma mudança no NTP provocou uma edição tal como a saída dos pulsos de disparo da sincronização. (Ou seja se seus pulsos de disparo felizmente sincronizados vão de repente loucos, você sabe para procurar uma mudança ou um disparador!)
Este é um exemplo de ambos debuga. Inicialmente, os pulsos de disparo do cliente eram sincronizados. O comando dos eventos NTP debugar mostra que uma mudança do estrato do par NTP ocorreu, e os pulsos de disparo a seguir saíram da sincronização.
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)
Pulso de disparo-período NTP ajustado manualmente
A site da Web Cisco.com adverte aquela:
“O comando ntp clock-period está gerado automaticamente refletir o fator de correção constantemente em mudança quando o comando copy running-configuration startup-configuration é inscrito salvar a configuração ao NVRAM. Não tente usar manualmente o comando ntp clock-period. Assegure-se de que você remova esta linha de comando quando arquivos de configuração de copi aos outros dispositivos.”
O valor do pulso de disparo-período é dependente do hardware, assim que difere para cada dispositivo.
O comando ntp clock-period aparece automaticamente na configuração quando você permite o NTP. O comando é usado a fim ajustar o pulso de disparo de software. Do “o valor ajuste” compensa o intervalo do tiquetaque 4 milissegundos, de modo que, com o ajuste menor, você tenha 1 segundo no fim do intervalo.
Se o dispositivo calculou que seu relógio de sistema é perdedor o tempo (talvez precisa de estar uma compensação da frequência do nível baixo do roteador), adiciona automaticamente este valor ao relógio de sistema a fim manter sua sincronicidade.
O pulso de disparo-período do padrão NTP para um roteador é 17179869 e é usado essencialmente a fim começar o processo NTP.
A fórmula da conversão é 17179869 * 2^(-32) = 0.00399999995715916156768798828125, ou aproximadamente 4 milissegundos.
Por exemplo, o relógio de sistema para os Cisco 2611 Router (um dos Cisco 2600 Series Router) foi encontrado para ser levemente fora de sincronia e poderia ser ressincronizado com este comando:
ntp clock-period 17208078
Isto iguala 17208078 * 2^(-32) = 0.0040065678767859935760498046875, ou um pouco de sobre 4 milissegundos.
Cisco recomenda que você deixa o roteador ser executado por uma semana ou assim que em condições da rede normal e usar então o comando wr mem a fim salvar o valor. Isto dá-lhe uma figura exata para a repartição seguinte e permite-o que o NTP sincronize mais rapidamente.
Não use nenhum comando ntp clock-period quando você salvar a configuração para o uso em um outro dispositivo porque este comando deixa cair o pulso de disparo-período de volta ao padrão desse dispositivo particular. O valor verdadeiro será voltado a calcular (mas reduzirá a precisão do relógio de sistema durante esse período de tempo do novo cálculo).
Recorde que este valor é dependente de hardware, assim que se você copia uma configuração e a usa em dispositivos diferentes, você pode causar problemas. Cisco planeia substituir a versão 3 NTP com a versão 4 a fim resolver esta edição.
Se você não está ciente destas edições, você pode decidir consertar manualmente com este valor. A fim migrar de um dispositivo a outro, você pode decidir copiar a configuração antiga e colá-la no dispositivo novo. Infelizmente, porque o comando ntp clock-period aparece na executar-configuração e na partida-configuração, o pulso de disparo-período NTP é colado no dispositivo novo. Quando isto acontece, o NTP no cliente novo sai sempre da sincronização com o server com um valor alto da dispersão do par.
Em lugar de, cancele o pulso de disparo-período NTP com nenhum comando ntp clock-period, a seguir salvar a configuração. O roteador calcula eventualmente um pulso de disparo-período apropriado para se.
O comando ntp clock-period está já não disponível na versão 15.0 ou mais recente do Cisco IOS Software; o parser rejeita agora o comando com o erro:
"%NTP: This configuration command is deprecated."
Assim, não é permitido você configurar manualmente o pulso de disparo-período, e o pulso de disparo-período não é reservado na executar-configuração. Desde que o parser rejeita o comando se estava na configuração start-up (em versões do Cisco IOS mais adiantadas tais como 12.4), o parser rejeita o comando quando copia a configuração start-up à executar-configuração na inicialização.
O novo, comando da substituição é tração clara NTP.
Informações Relacionadas
FeedbackDeixe-nos ajudar
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)