jueves, 9 de julio de 2009
Sincronización de relojes (NTP)
En los post anteriores se analizó en funcionamiento de varios routers en conjunto, cosa que hubiese sido muy difícil si los relojes de los equipos no hubiesen estado sincronizados. Para lograr ésto existe un protocolo denominado NTP (RFC 1305), cuyo funcionamiento en detalle se describe en el RFC 1129 (archivo PDF). Toda la documentación al respecto se puede revisar en la página dedicada a este protocolo: www.ntp.org.
Se define en NTP que cada reloj reside en un stratum. Un reloj atómico (atomic clock) es una fuente de tiempo que reside en el stratum cero. Un equipo directamente conectado a es éste reside en el stratum uno. Un equipo que aprende el tiempo del anterior; stratum dos y así sucesivamente. Un reloj operando en stratum 16 es considerado como no sincronizado.
Existen servidores públicos en stratum uno de donde sincronizar, por ejemplo los que se encuentran en: Stratum One Time Servers y NIST Internet Time Servers.
La configuración básica en dispositivos Cisco es bastante sencilla. Primero que nada para redes sin conexión a Internet, por tanto no pueden obtener el tiempo de servidores como los que se enunciaron en los links anteriores, pueden configurar un dispositivo para ser la fuente para el resto de los equipos en la red con el comando ntp master, que setea al equipo en stratum 8 (ojo que puede tardar varios minutos en sincronizar).
Otro comando relevante es ntp update-calendar, el cual permite que los equipos que cuentan con un reloj interno a batería puedan tener este reloj actualizado además. De este modo, si el reloj a nivel de software es sincronizado con una fuente externa, es una práctica recomendad utilizar este comando de modo de mantener el reloj a nivel de hardware actualizado, el cual será utilizado como fuente ante el reinicio del equipo si no cuenta más con una fuente externa. Para revisar ambos relojes se utilizan los comandos show calendar y show clock.
router#sh clock detail
*20:49:00.151 UTC Tue Jul 7 2009
Time source is hardware calendar
router#
Pero quizás el comando más importante es ntp server. Éste permite sincronizar con un servidor especificado (o bien otro equipo), el cual no se sincronizará de vuelta, a no ser que sea configurado de esta forma con ntp peer. Para el análisis del estatus del reloj y la asociaciones se pueden usar: show ntp associations y show ntp status.
A continuación un par de ejemplos sencillos. El primero muestra a R3 configurado con ntp master, R1 se sincronizará con R3 y a su vez R2 con R3.
R1#sh run | i ntp
ntp clock-period 17179858
ntp server 10.3.3.3
R1#
R1#sh ntp ass
address ref clock st when poll reach delay offset disp
*~10.3.3.3 127.127.7.1 8 28 64 377 32.0 -20.13 27.2
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
R1#
R1#sh ntp sta
Clock is synchronized, stratum 9, reference is 10.3.3.3
nominal freq is 250.0000 Hz, actual freq is 250.0001 Hz, precision is 2**24
reference time is CE00ADDF.E4E511E8 (17:56:47.894 UTC Thu Jul 9 2009)
clock offset is -71.8808 msec, root delay is 103.99 msec
root dispersion is 88.90 msec, peer dispersion is 16.98 msec
R1#
R2#sh run | i ntp
ntp clock-period 17179290
ntp server 10.1.1.1
R2#
R2#sh ntp ass
address ref clock st when poll reach delay offset disp
*~10.1.1.1 10.3.3.3 9 51 64 3 60.0 12.07 7895.8
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
R2#
R2#sh ntp sta
Clock is synchronized, stratum 10, reference is 10.1.1.1
nominal freq is 250.0000 Hz, actual freq is 250.0084 Hz, precision is 2**18
reference time is CE00AE18.F601E396 (17:57:44.960 UTC Thu Jul 9 2009)
clock offset is -5.6303 msec, root delay is 180.11 msec
root dispersion is 1026.26 msec, peer dispersion is 931.72 msec
R2#
R3#sh run | i ntp
ntp clock-period 17180915
ntp master
R3#
R3#sh ntp ass
address ref clock st when poll reach delay offset disp
*~127.127.7.1 127.127.7.1 7 24 64 377 0.0 0.00 0.0
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
R3#
Se ve que efectivamente el que actúa como NTP master queda en stratum ocho, además genera un servidor interno con la dirección IP 127.127.7.1 al que le hace las consultas. Desde ese momento escucha las requerimientos de sincronizmo de cualquier otro dispositivo. R1 sincroniza y queda en stratum nueve, por lo que queda atento a los requerimientos que en este caso vienen desde R2 que queda en stratum diez.
Lo anterior denota que debe aplicarse alguna medida de seguridad. Existen dos métodos; Limitar el acceso con listas de acceso (ACL) o bien utilizar autentificación. Ambos procesos se describen claramente en: NTP Access Control.
El segundo ejemplo simplemente muestra cómo un router con conexión a Internet sincroniza con servidores en stratum uno.
router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
router(config)#ntp server 207.200.81.113
router(config)#
000016: *Jul 7 20:52:07.859 UTC: NTP: Initialized interface FastEthernet0/0
000017: *Jul 7 20:52:07.859 UTC: NTP: Initialized interface FastEthernet0/1
000018: *Jul 7 20:52:07.859 UTC: NTP: Initialized interface NVI0
000019: *Jul 7 20:52:11.863 UTC: IP: tableid=0, s=X.X.X.X (local), d=207.200.81.113 (FastEthernet0/1), routed via FIB
000020: *Jul 7 20:52:11.863 UTC: IP: s=X.X.X.X (local), d=207.200.81.113 (FastEthernet0/1), len 76, sending
000021: *Jul 7 20:52:11.863 UTC: UDP src=123, dst=123
000022: *Jul 7 20:52:12.055 UTC: IP: tableid=0, s=207.200.81.113 (FastEthernet0/1), d=X.X.X.X (FastEthernet0/1), routed via RIB
000023: *Jul 7 20:52:12.055 UTC: IP: s=207.200.81.113 (FastEthernet0/1), d=X.X.X.X (FastEthernet0/1), len 76, rcvd 3
000024: *Jul 7 20:52:12.055 UTC: UDP src=123, dst=123
router#sh clock detail
.19:54:59.039 UTC Tue Jul 7 2009
Time source is NTP
router#sh ntp associations
address ref clock st when poll reach delay offset disp
~207.200.81.113 .ACTS. 1 49 64 0 173.7 1.13 16000.
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
router(config)#ntp server 69.25.96.13
router(config)#
router#sh ntp associations
address ref clock st when poll reach delay offset disp
*~207.200.81.113 .ACTS. 1 44 64 1 190.4 -1.58 15875.
~69.25.96.13 .ACTS. 1 41 64 0 188.5 -3.95 16000.
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
router#
Simplemente destacar que los mensajes de NTP se intecambian usando el puerto UDP 123. La lista completa de puertos asociados a las distintas aplicaciones en: PORT NUMBERS.
Es un muy buen blog el tuyo... felicitaciones..
solo comentar que existen posibilidades de securizar el NTP con claves y ademas lo ideal es sincronizar un equipo principal dentro de tu red con un clock NTP que este en internet para tener la hora exacta. Por ejemplo en Chile la direccion del SHOA (ntp.shoa.cl) pero debes tener ojo que este servidor NTP te entrega la hora UTC, por lo que debes modificar la hora restandole 4 horas en caso de Chile y modificando segun el horario de verano.
Esto lo hago de la siguiente forma:
clock timezone CHILE -4
clock summer-time CHILE-HORARIO-VERANO recurring 2 Sun Oct 0:00 2 Sun Mar 0:00
Se adelanta la hora (UTC -3) la segunda semana de Octubre y se vuelve a la hora normal el segundo sabado de marzo.
Ojo que pongo SUN (domingo) porque se cambia la hora el dia sabado a las 12 de la noche que realmente ya es domingo) probe varias opciones y esta fue la mas optima.
Switchcito#sh clock
11:30:46.483 CHILE Fri Sep 24 2010
La autentificacion puede ser de la sgte forma:
ntp authentication-key 1 md5 [Password]
ntp authenticate
ntp trusted-key 1
ntp server [Ip servidor NTP] key 1
Excelente explicacion. Soy Alessandro de Guatemala y tengo una duda....Si R1 no se configura con NTP, ¿es posible sincronizar R2 hasta R3 aunque R1 no se haya sincronizado? (siguiendo la misma ruta del diagrama)
Los mensajes de NTP son UDP, puerto 123. No necesitas los dispositivos estén directamente conectados, sólo que tengan conectividad IP y por cierto ningún Firewall entremedio que esté bloqueando el puerto.
Programming IOS-XR with gRPC and Go
gRPC library for Cisco IOS XR