Problemas del Network Time Protocol (NTP) que resuelven problemas y que hacen el debug de la guía
Contenido
Introducción
Este documento describe el uso de los debugs para resolver problemas los problemas del Network Time Protocol (NTP), así como la salida del NTP dominante de la demostración ordena.
Comandos show NTP
Antes de que usted mire la causa de los problemas NTP, usted debe entender el uso de y la salida de estos comandos:
- muestre la asociación NTP
- muestre el detalle de la asociación NTP
- muestre el estatus NTP
muestre la asociación NTP
Una asociación NTP puede ser una asociación de peers (un sistema está dispuesto a sincronizar al otro sistema o a permitir que el otro sistema sincronice a él) o una asociación del servidor (solamente un sistema sincroniza al otro sistema y no a la otra manera alrededor).
Esto es un ejemplo de salida del comando de la asociación NTP de la demostración:
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
| Término | Explicación |
|---|---|
Los caracteres antes del direccionamiento tienen estas definiciones:
|
|
direccionamiento |
Ésta es la dirección IP del par. En el ejemplo, la primera entrada muestra 127.127.7.1. Esto indica que la máquina local ha sincronizado consigo mismo. Generalmente, solamente un master NTP sincroniza consigo mismo. |
reloj referencia |
Éste es el direccionamiento del reloj de referencia para el par. En el ejemplo, los primeros seis pares/los servidores tienen un IP privado como el reloj de referencia, así que sus masters son probablemente Routers, Switches, o servidores dentro de la red local. Para las cuatro entradas más recientes, el reloj de referencia es un IP del público, así que sus masters son probablemente una fuente horaria pública. |
st |
El NTP utiliza el concepto de un estrato para describir hasta dónde lejos (en los saltos NTP) una máquina es de una fuente de tiempo válida. Por ejemplo, un Servidor de tiempo del estrato 1 tiene una radio o un reloj atómico asociado directamente a él. Envía su tiempo a un Servidor de tiempo del estrato 2 con el NTP, y así sucesivamente hasta el estrato 16. Una máquina que ejecuta el NTP elige automáticamente la máquina con el número de estrato más bajo con el cual puede comunicar y utiliza el NTP como su fuente horaria. |
cuando |
El tiempo puesto que el paquete NTP más reciente fue recibido de un par está señalado en los segundos. Este valor debe ser más bajo que el intervalo de sondeo. |
encuesta |
El intervalo de sondeo está señalado en los segundos. El intervalo comienza generalmente con un mínimo de intervalos de encuesta 64-second. El RFC especifica que no más que una transacción NTP por el minuto es necesaria para sincronizar dos máquinas. Mientras que el NTP llega a ser estable entre un cliente y un servidor, el intervalo de encuesta puede aumentar de los pequeños pasos a partir de 64 segundos hasta 1024 segundos y se estabiliza generalmente en alguna parte mientras tanto. Pero, este valor cambia dinámicamente, sobre la base de los estados de la red entre el cliente y el servidor y la pérdida de paquetes NTP. Si un servidor es inalcanzable por algún tiempo, el intervalo de encuesta se aumenta de los pasos a 1024 segundos para reducir la tara de red. No es posible ajustar el intervalo de encuesta NTP en un router, porque el interno es determinado por los algoritmos heurísticos. |
alcance |
El alcance del peer es una cadena de bits señalada como valor octal. Este campo muestra si los ocho paquetes más recientes fueron recibidos por el proceso NTP en el software del ® del Cisco IOS. Los paquetes se deben recibir, procesar, y validar como válidos por el proceso NTP y no apenas por el router o el Switch que recibe los paquetes del IP NTP. El alcance utiliza el intervalo de encuesta para un descanso para decidir a si un paquete fue recibido o no. El intervalo de encuesta es el tiempo que el NTP espera antes de que concluya que un paquete fue perdido. El tiempo de la encuesta puede ser diferente para diversos pares, así que el tiempo antes de que el alcance decida a que un paquete fue perdido puede también diferente para diversos pares. En el ejemplo, hay cuatro diversos valores del alcance:
El alcance es un buen indicador de si los paquetes NTP se están cayendo debido a un link pobre, CPU publica y otros problemas intermitentes. Convertido octal < - > el binario es un convertidor en línea de la unidad para esto y muchas otras conversiones. |
demora |
El retardo de ida y vuelta a mirar está señalado en los milisegundos. Para fijar el reloj más exactamente, se tiene en cuenta este retardo cuando se fija la Hora del reloj. |
desplazamiento |
El desplazamiento es la diferencia de Hora del reloj entre los pares o entre el master y el cliente. Este valor es la corrección que se aplica a un reloj del cliente para sincronizarlo. Un valor positivo indica que el reloj del servidor es más alto. Un valor negativo indica que el reloj del cliente es más alto. |
disp |
La dispersión, señalada en los segundos, es la diferencia de tiempo del reloj máximo que fue observada nunca entre el reloj local y el reloj del servidor. En el ejemplo, la dispersión es 0.3 para el servidor 10.50.36.42, así que la diferencia de tiempo máximo observada nunca localmente entre el reloj local y el reloj del servidor es 0.3 segundos. Usted puede esperar ver un valor alto cuando los relojes están sincronizando inicialmente. Pero, si la dispersión es demasiado alta en otros momentos, el proceso NTP en el cliente no valida los mensajes NTP del servidor. La dispersión máxima es 16000; en el ejemplo, ésa es la dispersión para los servidores 10.50.44.69 y 10.50.44.133, así que el cliente local no valida el tiempo de estos servidores. Si el alcance es cero y la dispersión es muy alta, el cliente no está validando probablemente los mensajes de ese servidor. Refiera a la segunda línea del ejemplo: address ref clock st when poll reach delay offset disp Aunque el desplazamiento es apenas -4.26, la dispersión es muy alta (quizás debido a más allá del evento), y el alcance es cero, así que este cliente no valida el tiempo de este servidor. |
muestre el detalle de la asociación NTP
Esto es un ejemplo de salida del comando detail de la asociación NTP de la demostración:
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
Los términos definidos ya en la sección de la asociación NTP de la demostración no se relanzan.
Término |
Explicación | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
configurado |
Esta fuente de reloj NTP se ha configurado para ser un servidor. Este valor puede también ser dinámico, donde descubrieron al par/el servidor dinámicamente. |
|||||||||||||||||||||||||||
our_master |
Sincronizan al cliente local a este par. |
|||||||||||||||||||||||||||
seleccionado |
Seleccionan al par/el servidor para la sincronización posible, cuando el “our_master” falla o el cliente pierde sincroniza. |
|||||||||||||||||||||||||||
sano |
Las pruebas de la cordura se utilizan para probar el paquete NTP recibido de un servidor. Estas pruebas se especifican en el RFC 1305, protocolo Network Time Protocol (especificación, implementación y análisis de la versión 3). Las pruebas son:
Los datos del paquete son válidos si se pasan las pruebas 1 a 4. Los datos entonces se utilizan para calcular el desplazamiento, el retardo, y la dispersión. El encabezado de paquete es válido si se pasan las pruebas 5 a 8. Solamente los paquetes con una encabezado válida se pueden utilizar para determinar si un par puede ser seleccionado para la sincronización. |
|||||||||||||||||||||||||||
insano |
Las verificaciones de integridad han fallado, así que el tiempo del servidor no se valida. El servidor unsynced. |
|||||||||||||||||||||||||||
válido |
El par/la hora del servidor es válidos. El cliente local valida este vez si este par hace el master. |
|||||||||||||||||||||||||||
inválido |
El par/la hora del servidor es inválidos, y el tiempo no será validado. |
|||||||||||||||||||||||||||
referencia ID |
Asignan cada par/servidor una referencia ID (escritura de la etiqueta). |
|||||||||||||||||||||||||||
hora |
El tiempo es el sello de la última vez recibido de ese par/servidor. |
|||||||||||||||||||||||||||
nuestro modo del par del modo |
Éste es el estado del cliente local/del par. |
|||||||||||||||||||||||||||
nuestro intvl de la encuesta del par de la encuesta intvl/ |
Éste es el intervalo de encuesta de nuestra encuesta a este par o del par a la máquina local. |
|||||||||||||||||||||||||||
retardo de la raíz |
El retardo de la raíz es el retardo en los milisegundos a la raíz de la configuración NTP. Los relojes del estrato 1 se consideran estar en la raíz de un NTP puesto/diseño. En el ejemplo, los tres servidores pueden ser la raíz porque están en el estrato 1. |
|||||||||||||||||||||||||||
dispersión de la raíz |
La dispersión de la raíz es la diferencia de tiempo del reloj máximo que fue observada nunca entre el reloj local y el reloj de la raíz. Refiera a la explicación del “disp” bajo sección de la asociación NTP de la demostración para más detalles. |
|||||||||||||||||||||||||||
sincronice el dist. |
Ésta es una estimación de la diferencia máxima entre el tiempo en la fuente del estrato 0 y el tiempo medido por el cliente; consiste en los componentes para el Round Trip Time, la precisión del sistema, y el desvío del reloj puesto que el real más reciente leídos de la fuente del estrato. En un NTP grande puesto (los servidores NTP en el estrato 1 en Internet, con los servidores que tiempo de la fuente en diversos estratos) con los servidores/los clientes en los estratos múltiples, la topología de la sincronización NTP se debe ordenar para producir la exactitud más alta, pero se debe nunca permitir formar un loop de la sincronización horaria. Un factor adicional es que cada incremento en el estrato implica a un Servidor de tiempo potencialmente no fiable, que introduce los errores de medida adicionales. El algoritmo de selección usado en el NTP utiliza una variante del algoritmo de ruteo distribuido Botones-Ford para computar la mínimo-ponderación que atraviesa - los árboles arraigados en los servidores primarios. El métrico de la distancia usado por el algoritmo consiste en el estrato más la distancia de la sincronización, que sí mismo consiste en la dispersión más una mitad del retraso absoluto. Así, la ruta de sincronización lleva siempre el número mínimo de servidores la raíz; los lazos se resuelven en base del error máximo. |
|||||||||||||||||||||||||||
demora |
Éste es el retardo de ida y vuelta a mirar. |
|||||||||||||||||||||||||||
precisión |
Ésta es la precisión del reloj del par en los herzios. |
|||||||||||||||||||||||||||
versión |
Éste es el número de la versión NTP usado por el par. |
|||||||||||||||||||||||||||
tiempo del org |
Éste es el sello de fecha/hora del terminal original del paquete NTP; es decir es el sello de fecha/hora de este par en que creó el paquete NTP pero antes de que envió el paquete al cliente local. |
|||||||||||||||||||||||||||
tiempo receptor |
Éste es el sello de fecha/hora en que el cliente local recibió el mensaje. La diferencia entre el tiempo del org y el tiempo receptor es el desplazamiento para este par. En el ejemplo, 10.4.2.254 principal tiene estas épocas: org time D36968B7.E74172BF (02:11:03.903 UTC Fri May 25 2012) La diferencia es el desplazamiento de 268.3044 milisegundos. |
|||||||||||||||||||||||||||
tiempo del xmt |
Éste es el sello de fecha/hora del transmitir para el paquete NTP que el cliente local envía a este par/servidor. |
|||||||||||||||||||||||||||
filtdelay |
Éste es el retardo de ida y vuelta en los milisegundos de cada muestra. Una muestra es el paquete NTP más reciente recibido. En el ejemplo, 10.4.2.254 principal tiene estos valores: filtdelay = 2.99 2.88 976.61 574.65 984.71 220.26 168.12 2.72 Estas ocho muestras corresponden al valor del campo del alcance, que muestra si el cliente local recibió los ocho paquetes NTP más recientes. |
muestre el estatus NTP
Esto es un ejemplo de salida del 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
Los términos definidos ya en la sección de la asociación NTP de la demostración o la sección de los detalles de la asociación NTP de la demostración no se relanzan.
| Término | Explicación |
|---|---|
precisión |
La precisión se determina automáticamente y se mide como poder de dos. En el ejemplo, 2**18 significa 2^(-18), o 3.8 microsegundos. La pérdida de sincronización entre los pares NTP o entre un master y un cliente puede ser debido a una variedad de causas. El NTP evita la sincronización con una máquina cuya hora pudo ser ambigua de estas maneras:
|
Resolver problemas el NTP con los debugs
Algunas de la mayoría de las causas comunes de los problemas NTP son:
- Los paquetes NTP no se reciben.
- Los paquetes NTP son recibidos, pero no procesados por el proceso NTP en el IOS.
- Se procesan los paquetes NTP, pero los factores o los datos del paquete erróneos causan la pérdida de sincronización.
- El reloj-período NTP se fija manualmente.
Comandos debug importantes que aislante de la ayuda que la causa de estos problemas incluye:
- <acl> de los paquetes del IP del debug
- paquetes NTP del debug
- validez NTP del debug
- el NTP del debug sincroniza
- eventos NTP del debug
Las siguientes secciones ilustran el uso de los debugs para resolver estos problemas frecuentes.
Paquetes NTP no recibidos
Utilice el comando debug ip packet para marcar si se reciben y se envían los paquetes NTP. Puesto que la salida de los debugs puede ser habladora, usted puede limitar la salida de los debugs con el uso del Listas de control de acceso (ACL). El NTP utiliza el puerto 123 del User Datagram Protocol (UDP).
- Cree el ACL 101:
access-list 101 permit udp any any eq 123
Los paquetes NTP tienen generalmente un puerto de origen y de destino de 123, esto ayudan tan:
access-list 101 permit udp any eq 123 any
permit udp any eq 123 any eq 123
- Utilice este ACL para limitar la salida del comando debug ip packet:
debug ip packet 101
- Si el problema está con los peeres particulares, estreche el ACL 101 abajo a esos pares. Si el par es 172.16.1.1, cambie el 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
Esta salida de ejemplo indica que los paquetes no se están enviando:
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
Una vez que usted confirma que los paquetes NTP no están recibidos, usted debe:
- Marque si el NTP se configura correctamente.
- Marque si un ACL está bloqueando los paquetes NTP.
- Marque para saber si hay problemas de ruteo a la fuente o al IP de destino.
Paquetes NTP no procesados
Con los comandos packets NTP del paquete y del debug del IP del debug habilitados, usted puede ver los paquetes se están recibiendo y se están transmitiendo que, y usted puede ver que el NTP está actuando sobre esos paquetes. Para cada paquete NTP recibido (como se muestra por el paquete del IP del debug), hay una entrada correspondiente generada por los paquetes NTP del debug.
Ésta es la salida de los debugs cuando los procesos funciona NTP en los paquetes recibidos:
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)
Esto es un ejemplo donde el NTP no trabaja en los paquetes recibidos. Aunque se reciban los paquetes NTP (como se muestra por los paquetes del IP del debug), el proceso NTP no actúa en ellos. Para los paquetes NTP se envían que, una salida correspondiente de los paquetes NTP del debug está presente, porque el proceso NTP tiene que generar el paquete. El problema es específico a los paquetes NTP recibidos que no se están procesando.
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#
Pérdida de sincronización
La pérdida de sincronización pudo ocurrir si va la dispersión y/o el valor de retraso para un servidor muy arriba. Los valores altos indican que los paquetes están durando demasiado para conseguir al cliente del servidor/del par en referencia a la raíz del reloj. Así pues, la máquina local no puede confiar en la exactitud del tiempo presente en el paquete, porque no sabe cuánto tiempo tomó para que el paquete consiga aquí.
El NTP es meticuloso sobre el tiempo y no sincronizará con otro dispositivo que no puede confiar en ni que puede ajustar de una manera para poder confiar en.
Si hay un link saturado y ocurre el mitigar a lo largo del camino, los paquetes consiguen retrasados mientras que vienen al cliente NTP. Así pues, el grupo fecha/hora contenido en un paquete NTP subsiguiente puede variar de vez en cuando mucho, y el cliente local no puede ajustar realmente para que haya esa variación.
El NTP no ofrece un método para apagar la validación de estos paquetes a menos que usted utilice SNTP (protocolo de tiempo de la red sencillo). El SNTP puede no ser mucha de una alternativa porque no se soporta extensamente en el software.
Si usted experimenta la pérdida de sincronización, usted debe marcar los links:
- ¿Se saturan?
- Hay cualesquiera clases de descensos en sus links del Red de área ancha (WAN)
- ¿El cifrado está ocurriendo?
Monitoree el valor del alcance del comando show ntp associations detail. El valor más alto es 377. Si el valor es 0 o bajo, los paquetes NTP se están recibiendo intermitentemente, y el cliente local sale de sincroniza con el servidor.
validez NTP del debug
El comando de la validez NTP del debug indica si el paquete NTP falló la cordura o las comprobaciones de validez y revela la razón del error. Compare esta salida a las pruebas de la cordura especificadas en el RFC1305 que se utilizan para probar el paquete NTP recibido de un servidor. Se definen ocho pruebas:
| Prueba | Máscara | Explicación |
|---|---|---|
| 1 | 0x01 | Paquete duplicado recibido |
| 2 | 0x02 | Paquete falso recibido |
| 3 | 0x04 | Protocolo unsynchronized |
| 4 | 0x08 | Retardo del par/control de límite fallado dispersión |
| 5 | 0x10 | Autenticación de peer fallada |
| 6 | 0x20 | Reloj del par unsynchronized (común para el servidor unsynched) |
| 7 | 0x40 | Estrato del par fuera del límite |
| 8 | 0x80 | Retardo de la raíz/control de límite fallado dispersión |
Ésta es salida de muestra del comando de la validez NTP del debug:
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
paquetes NTP del debug
Usted puede utilizar el comando packets NTP del debug para ver el tiempo que el par/el servidor le da en el paquete recibido. La máquina local del tiempo también dice el tiempo que sabe al par/al servidor en el paquete transmitido.
| Campo | paquete receptor | paquete del xmit |
|---|---|---|
| org | Sello de fecha/hora del terminal original, que es la hora del servidor. | Sello de fecha/hora del terminal original (cliente) en que envió el paquete. (El cliente origina un paquete al servidor.) |
| rec | Sello de fecha/hora en el cliente cuando recibió el paquete. | Hora actual del cliente. |
En esta salida de muestra, los sellos de fecha/hora en el paquete recibido del servidor y el paquete enviado a otro servidor son lo mismo, que indica que es el cliente NTP adentro sincroniza.
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)
Esto es un ejemplo de salida cuando los relojes no son adentro sincronizar. Note la diferencia de tiempo entre el paquete del xmit y el paquete receptor. La dispersión del par estará en el valor máximo de 16000, y el alcance para el 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)
el NTP del debug sincroniza y hace el debug de los eventos NTP
El comando synchronization NTP del debug produce las salidas uno lines que muestran si el reloj tiene synced o el sincronizar ha cambiado. El comando se habilita generalmente con los eventos NTP del debug.
Los eventos NTP del debug ordenan las demostraciones cualquier evento NTP que ocurra, que le ayuda a determinar si un cambio en el NTP accionó un problema tal como relojes que la salida de sincroniza. (Es decir si su sincronizó feliz los relojes van repentinamente locos, usted sabe para buscar un cambio o un activador!)
Éste es un ejemplo de ambos debugs. Inicialmente, los relojes del cliente eran synced. El comando de los eventos NTP del debug muestra que ocurrió un cambio del estrato del par NTP, y los relojes después salieron de sincronizan.
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)
Reloj-período NTP fijado manualmente
El sitio Web de Cisco.com advierte eso:
“Generan al comando ntp clock-period automáticamente de reflejar el factor de corrección constantemente cambiante cuando ingresan al comando copy running-configuration startup-configuration de salvar la configuración al NVRAM. No intente utilizar manualmente el comando ntp clock-period. Asegúrese de que usted quite esta línea de comando cuando los archivos de configuración de copiado a los otros dispositivos.”
El valor del reloj-período es dependiente en el hardware, así que diferencia para cada dispositivo.
El comando ntp clock-period aparece automáticamente en la configuración cuando usted habilita el NTP. El comando se utiliza para ajustar el reloj de software. El “valor del ajuste” compensa el intervalo de la señal 4 milisegundos, de modo que, con el ajuste de menor importancia, usted tenga 1 segundo en el final del intervalo.
Si el dispositivo ha calculado que su reloj del sistema es perdidoso el tiempo (quizás necesita ser una remuneración de la frecuencia del nivel bajo del router), agrega automáticamente este valor al reloj del sistema para mantener su synchronicity.
El reloj-período del valor por defecto NTP para un router es 17179869 y esencialmente se utiliza para comenzar el proceso NTP.
La fórmula de la conversión es 17179869 * 2^(-32) = 0.00399999995715916156768798828125, o aproximadamente 4 milisegundos.
Por ejemplo, el reloj del sistema para los Cisco 2611 Router (uno de los Cisco 2600 Series Router) fue encontrado para ser hacia fuera-de-sincroniza y se podría levemente resincronizar con este comando:
ntp clock-period 17208078
Esto iguala 17208078 * 2^(-32) = 0.0040065678767859935760498046875, o un poco durante 4 milisegundos.
Cisco recomienda que usted deja al router ejecutarse por una semana o así que en las condiciones de la red normal y después utilizar el comando wr mem para salvar el valor. Esto le da una figura exacta para la reinicialización siguiente y permite que el NTP sincronice más rápidamente.
No utilice el ningún comando ntp clock-period cuando usted salva la configuración para el uso en otro dispositivo porque este comando cae el reloj-período de nuevo al valor por defecto de ese dispositivo determinado. El valor verdadero será recalculado (pero reducirá la exactitud del reloj del sistema durante ese período de tiempo del cálculo).
Recuerde que este valor es dependiente del hardware, así que si usted copia una configuración y la utiliza en diversos dispositivos, usted puede causar los problemas. Cisco planea substituir la versión 3 NTP por la versión 4 para resolver este problema.
Si usted no es consciente de estos problemas, usted puede decidir ocuparse vanamente manualmente con este valor. Para emigrar a partir de un dispositivo a otro, usted puede decidir copiar la antigua configuración y pegarla en el nuevo dispositivo. Desafortunadamente, porque el comando ntp clock-period aparece en los ejecutar-config y los lanzamiento-config, el reloj-período NTP se pega en el nuevo dispositivo. Cuando sucede esto, el NTP en el nuevo cliente sale siempre de sincroniza con el servidor con un alto valor de la dispersión del par.
En lugar, borre el reloj-período NTP con el ningún comando ntp clock-period, después salve la configuración. El router calcula eventual un reloj-período apropiado para sí mismo.
El comando ntp clock-period está no más disponible en la versión del Cisco IOS Software 15.0 o más adelante; el analizador de sintaxis ahora rechaza el comando con el error:
"%NTP: This configuration command is deprecated."
Así pues, a le no se permite configurar el reloj-período manualmente, y el reloj-período no se da un plazo en los ejecutar-config. Puesto que el analizador de sintaxis rechaza el comando si estaba en los config de lanzamiento (en versiones deL Cisco IOS anteriores tales como 12.4), el analizador de sintaxis rechaza el comando cuando copia los config de lanzamiento a los ejecutar-config en el arranque inicial.
El nuevo, comando del reemplazo es deriva clara NTP.
Información Relacionada
ComentariosDéjenos ayudarlo
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)