Acabo de notar por pura casualidad que uno de mis conmutadores Cisco 4500 tiene su reloj funcionando mal: tiene más de 2 minutos de retraso a pesar de un ntp aparentemente funcional. En mi opinión, incluso un solo segundo no debe considerarse aceptable para los sistemas involucrados. Además, no habría notado la diferencia con el diagnóstico si no lo hubiera comparado con un simple reloj de pared.
Algunos detalles
Aquí hay información ntp para algunos de mis hosts (10.0.99.1, 10.0.99.2, 10.0.1.119, 10.0.99.241) que se refieren en parte entre sí para el retroceso, pero principalmente deberían sincronizarse con 10.0.0.1, que nuevamente tira del tiempo desde afuera. Por lo tanto, la discrepancia de tiempo no puede ser el resultado de diferentes fuentes de tiempo originales. Como las observaciones me hicieron un tanto paranoico, "tiene la hora correcta" en los siguientes medios: show clock(o date) produjo una salida que coincide con mi reloj de pared y mi reloj del sistema local (que está bien de acuerdo con http://time.is ) con un error ciertamente por debajo de 1 segundo (precisión de mí presionando ENTER mientras veo mi reloj local)
10.0.1.119 (Ubuntu) tiene la hora correcta
$ ntpq -np
remote refid st t when poll reach delay offset jitter
==============================================================================
+10.0.99.1 10.0.0.1 3 u 855 1024 377 0.904 -2.658 0.113
*10.0.0.1 130.149.17.8 2 u 266 1024 377 0.253 0.909 0.127
10.0.99.241 (Cisco 2960) tiene la hora correcta
#sho ntp associations
address ref clock st when poll reach delay offset disp
*~10.0.99.1 10.0.0.1 3 28 64 377 1.462 85.288 19.758
+~10.0.99.2 10.0.1.119 4 29 64 377 1.297 83.515 5.369
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
10.0.99.2 (Cico 4500) tiene la hora correcta
#sho ntp associations
address ref clock st when poll reach delay offset disp
+~10.0.99.1 10.0.0.1 3 6 1024 111 1.148 -1.618 42.875
*~10.0.1.119 10.0.0.1 3 31 1024 377 0.043 1.687 1.064
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
10.0.99.1 (Cisco 4500) se queda atrás unos 2 minutos y 6 segundos
#sho ntp associations
address ref clock st when poll reach delay offset disp
*~10.0.0.1 130.149.17.8 2 274 1024 377 15.625 3.681 30.403
+~10.0.99.2 10.0.1.119 4 415 1024 376 15.625 0.855 33.276
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
#sho ntp status
Clock is synchronized, stratum 3, reference is 10.0.0.1
nominal freq is 250.0000 Hz, actual freq is 249.9988 Hz, precision is 2**6
reference time is DAD8B428.54C6BAEA (20:36:24.331 MESZ Sat May 7 2016)
clock offset is 3.6818 msec, root delay is 32.80 msec
root dispersion is 71.74 msec, peer dispersion is 30.40 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.000004720 s/s
system poll interval is 1024, last update was 683 sec ago.
Preguntas
- ¿Cómo es que 10.0.99.1 está tan lejos?
- ¿Cómo es que los sistemas que se sincronizan con 10.0.99.1 son correctos?
- ¿Cómo debo aprender de la salida de
sho ntp status10.0.99.1 que el reloj no está totalmente sincronizado (en comparación con todos los hosts y relojes de referencia mencionados ensho ntp asso)? Para mí, la salida se ve totalmente como un muy elaborado "Estoy totalmente feliz".
EDITAR: Por demanda popular, la salida desho clock detail
10.0.99.1
#sho clock detail
13:06:38.605 MESZ Tue May 10 2016
Time source is NTP
Summer time starts 02:00:00 MEZ Sun Mar 27 2016
Summer time ends 03:00:00 MESZ Sun Oct 30 2016
10.0.99.2
#sho clock detail
13:10:54.083 MESZ Tue May 10 2016
Time source is NTP
Summer time starts 02:00:00 MEZ Sun Mar 27 2016
Summer time ends 03:00:00 MESZ Sun Oct 30 2016
fuente
10.0.0.1). Pero no creo que ninguna de mis observaciones pueda explicar directamente la causa de su problema actual.Respuestas:
Soy un poco reacio a publicar esto como respuesta porque la causa original aún no está clara. Sin embargo, el problema parece estar resuelto, al menos por el momento.
Tras los comentarios realizados por htm11h , decidí actualizar el firmware. Y de hecho, ahora que estoy ejecutando con un firmware más nuevo, el reloj parece coincidir con la hora correcta.
¿Pero eso significa que el nuevo firmware fue la solución? Lamentablemente no. En mi primer intento de cargar el nuevo firmware, olvidé cambiar el registro de configuración, que todavía estaba en sus valores predeterminados de fábrica. Por lo tanto, mi primer reinicio terminó en la misma imagen ROM original que el enrutador había estado funcionando durante casi cuatro años (es decir, desde su encendido inicial). Y, sin embargo, esto fue suficiente para que el reloj hiciera un gran ajuste y luego permaneciera sincronizado. Esto sugiere que un simple reinicio podría haber ayudado, temporalmente. A su vez, esto significa que la hora correcta ahora que se muestra con el firmware más reciente aún puede desviarse del tiempo ntp en los próximos años. Pasarán unos días hasta que pueda decir con seguridad si el reloj perdió o no unos 5 segundos por día ...
Por ahora, el caso está cerrado.
fuente
He trabajado bastante con el proyecto NTP Pool desde mediados de los 90 y ejecuto varios servidores NTP Stratum-1 GPS Synced aquí. Como otros han dicho, necesita más de 2 servidores para obtener tiempo. Usualmente uso 4 aquí por las razones expuestas anteriormente por Ron Maupin. Además, como se indica en la lista, debe buscar bucles y configurar cosas como servidores frente a pares.
La deriva del tiempo podría deberse a un error conocido en IOS que se corrigió en esta actualización de IOS que trata de que ntp.drift no se elimine o actualice correctamente y, por lo tanto, el problema de la deriva. Además, 4 AÑOS sin reinicio ni actualización deben haberlo dejado en un lugar bastante malo en cuanto a seguridad, ya que las actualizaciones de seguridad de iOS salen con bastante frecuencia.
Aquí hay una excelente publicación sobre la configuración de NTP en Cisco IOS http://packetlife.net/blog/2011/mar/28/cisco-ios-clocks-and-ntp/
Espero que esto sea útil. Por favor pregunte si tiene más preguntas o problemas.
fuente
Divulgación completa: solo ocasionalmente manipulé configuraciones de conmutadores, y de ninguna manera soy un experto en NTP.
Dicho esto, solía ver el demonio NTP en los sistemas RHEL 5.x (sí, volveré, pero dijiste que tu switch tenía una imagen de ~ 4 años ...) atascado en un estado "feliz" , donde parecía pensar que estaba perfectamente sincronizado pero claramente no lo estaba. Usaríamos una sesión ClusterSSH para ejecutar "date" en todos los sistemas simultáneamente, y eso a veces mostraría hasta 5 minutos de deriva entre sistemas. Si no recuerdo mal, parece que solo podríamos solucionar el problema reiniciando el demonio y, en última instancia, simplemente hicimos que cron reiniciara el servicio todas las noches ...
De ninguna manera es una solución ideal, pero es posible que pueda adoptar un enfoque similar con un trabajo cron para conectarse al conmutador e iniciar un reinicio, o de alguna manera "patear" el demonio NTP en el conmutador.
¡Espero que esto ayude!
fuente