Protocolo de Tiempo de Red de Cisco (NTP)

NTP (Protocolo de tiempo de red) se utiliza para permitir que los dispositivos de red sincronicen sus relojes con un reloj de fuente central. Para dispositivos de red como enrutadores, conmutadores o cortafuegos, esto es muy importante porque queremos asegurarnos de que la información de registro y las marcas de tiempo tengan la hora y la fecha precisas. Si alguna vez tiene problemas de red o es pirateado, debe asegurarse de saber exactamente qué y cuándo sucedió.

Normalmente, un enrutador o conmutador se ejecutará en modo cliente NTP, lo que significa que ajustará su reloj en función de la hora de un servidor NTP. Básicamente, el protocolo NTP describe el algoritmo que los clientes NTP utilizan para sincronizar sus relojes con el servidor NTP y los paquetes que se utilizan entre ellos.

Un buen ejemplo de un servidor NTP es ntp.pool.org. Este es un clúster de servidores NTP que muchos servidores y dispositivos de red utilizan para sincronizar sus relojes.

NTP utiliza un concepto llamado «estrato» que define cuántos saltos NTP de distancia está un dispositivo de una fuente de tiempo autorativa. Por ejemplo, un dispositivo con estrato 1 es un dispositivo muy preciso y podría tener un reloj atómico conectado a él. Otro servidor NTP que está utilizando este servidor de estrato 1 para sincronizar su propio tiempo sería un dispositivo de estrato 2 porque es un salto NTP más lejos de la fuente. Cuando configura varios servidores NTP, el cliente preferirá el servidor NTP con el valor de estrato más bajo.

Los routers y switches Cisco pueden usar 3 modos NTP diferentes:

• Modo cliente NTP.
• Modo de servidor NTP.
• Modo activo simétrico NTP.

El modo activo simétrico se usa entre dispositivos NTP para sincronizarse entre sí, se usa como mecanismo de respaldo cuando no pueden llegar al servidor NTP (externo).

En el resto de esta lección, demostraré cómo configurar NTP en un enrutador y conmutadores Cisco.

Configuración

Esta es la topología que usaré:

El enrutador en la parte superior se llama «CoreRouter» y es el borde de mi red. Está conectado a Internet y utilizará uno de los servidores NTP de pool.ntp.org para sincronizar su reloj. La red también tiene dos conmutadores internos que requieren relojes sincronizados. Ambos conmutadores se convertirán en clientes NTP del CoreRouter, lo que convierte al CoreRouter en un servidor NTP.

Configuración del router

Primero configuraremos el CoreRouter en la parte superior. Usaré pool.ntp.org como servidor NTP externo para este ejemplo. Necesitamos asegurarnos de que el enrutador sea capaz de resolver nombres de host:

CoreRouter(config)#ip name-server 8.8.8.8

Usaré DNS de Google para esto. Nuestro siguiente paso es configurar el servidor NTP:

CoreRouter(config)#ntp server pool.ntp.org

Eso fue bastante fácil, solo un comando y sincronizaremos nuestro reloj con el servidor público. Podemos verificar nuestro trabajo de esta manera:

CoreRouter#show ntp associations address ref clock st when poll reach delay offset disp ~146.185.130.223 .INIT. 16 - 64 0 0.000 0.000 16000. * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

Arriba vemos el comando mostrar asociaciones ntp que nos dice si nuestro reloj está sincronizado o no. El ~ delante de la dirección IP nos dice que hemos configurado este servidor pero que aún no estamos sincronizados. Puede ver esto porque no hay un * delante de la dirección IP y el campo» st » (estrato) es actualmente 16.

Hay un comando más que nos da más información sobre la configuración de NTP:

CoreRouter#show ntp statusClock is unsynchronized, stratum 16, no reference clocknominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**24reference time is 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)clock offset is 0.0000 msec, root delay is 0.00 msecroot dispersion is 0.16 msec, peer dispersion is 0.00 msecloopfilter state is 'FSET' (Drift set from file), drift is 0.000000000 s/ssystem poll interval is 64, never updated.

El router nos dice que no estamos sincronizados y que no hay reloj de referencia just solo esperaremos un par de minutos y echaremos un vistazo a estos comandos de nuevo:

CoreRouter#show ntp associations address ref clock st when poll reach delay offset disp*~146.185.130.223 193.79.237.14 2 26 64 1 10.857 -5.595 7937.5 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

Unos minutos más tarde y la salida ha cambiado. El * delante de la dirección IP nos dice que hemos sincronizado y el estrato es 2, lo que significa que este servidor NTP está bastante cerca de una fuente de tiempo confiable. El campo «encuesta» nos dice que intentaremos sincronizar el tiempo cada 64 segundos. Vamos a comprobar el otro comando que acabamos de ver:

CoreRouter#show ntp status Clock is synchronized, stratum 3, reference is 146.185.130.22nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**24reference time is D76513B4.66A4CDA6 (12:40:20.400 UTC Mon Jul 7 2014)clock offset is -5.5952 msec, root delay is 13.58 msecroot dispersion is 7966.62 msec, peer dispersion is 7937.50 msecloopfilter state is 'CTRL' (Normal Controlled Loop), drift is -0.000000018 s/ssystem poll interval is 64, last update was 43 sec ago.

Nuestro reloj se ha sincronizado y nuestro propio estrato es 3, eso tiene sentido ya que el servidor público de estrato tiene un estrato de 2 y estamos a un «salto» de él.

Los routers Cisco tienen dos relojes diferentes, tienen un reloj de software y un reloj de hardware y funcionan por separado. He aquí cómo ver ambos relojes:

CoreRouter#show clock 12:41:25.197 UTC Mon Jul 7 2014

CoreRouter#show calendar 12:43:24 UTC Mon Jul 7 2014

El comando mostrar reloj me muestra el reloj de software, mientras que el comando mostrar calendario me da el reloj de hardware. Los dos relojes no están sincronizados, así que esto es algo que deberíamos arreglar, puedes hacerlo así:

CoreRouter#(config)ntp update-calendar

El comando ntp update-calendar actualizará el reloj de hardware con la hora del reloj de software, aquí está el resultado:

CoreRouter#show clock 12:42:31.853 UTC Mon Jul 7 2014

CoreRouter#show calendar 12:42:30 UTC Mon Jul 7 2014

Eso es todo lo que quería configurar en el CoreRouter por ahora. Todavía tenemos que configurar dos interruptores para sincronizar sus relojes.

Configuración de conmutadores

Los dos conmutadores se configurarán para usar el CoreRouter como servidor NTP y también los configuraré para sincronizar sus relojes entre sí. Vamos a configurar el uso de los CoreRouter primera:

SW1(config)#ntp server 192.168.123.3

Una vez más, puede tardar unos minutos en sincronizarse, pero esto es lo que verá:

SW1#show ntp associations address ref clock st when poll reach delay offset disp*~192.168.123.3 146.185.130.223 3 21 64 1 2.5 1.02 15875. * master (synced), # master (unsynced), + selected, - candidate, ~ configured

SW1#show ntp status Clock is synchronized, stratum 4, reference is 192.168.123.3nominal freq is 119.2092 Hz, actual freq is 119.2089 Hz, precision is 2**18reference time is D765271D.D6021302 (14:03:09.835 UTC Mon Jul 7 2014)clock offset is 1.0229 msec, root delay is 14.31 msecroot dispersion is 16036.00 msec, peer dispersion is 15875.02 msec

El reloj de SW1 ha sido sincronizado y su estrato es 4. Esto tiene sentido, ya que es un «salto» más lejos de su servidor NTP (CoreRouter). Hagamos lo mismo con el SW2:

SW2(config)#ntp server 192.168.123.3

Seamos pacientes por unos minutos más y esto es lo que obtendremos:

SW2#show ntp associations address ref clock st when poll reach delay offset disp*~192.168.123.3 146.185.130.223 3 17 64 37 3.4 1.89 875.8 * master (synced), # master (unsynced), + selected, - candidate, ~ configured

SW2#show ntp status Clock is synchronized, stratum 4, reference is 192.168.123.3nominal freq is 119.2092 Hz, actual freq is 119.2084 Hz, precision is 2**18reference time is D765274D.D51A0546 (14:03:57.832 UTC Mon Jul 7 2014)clock offset is 1.8875 msec, root delay is 15.18 msecroot dispersion is 1038.39 msec, peer dispersion is 875.84 msec

SW1 y SW2 ahora están usando CoreRouter para sincronizar sus relojes. También vamos a configurarlos para que se usen entre sí para la sincronización. Este es el modo activo simétrico que mencioné antes, básicamente los dos interruptores se «ayudarán» entre sí para sincronizarse this esto podría ser útil en caso de que el CoreRouter falle algún día:

SW1(config)#ntp peer 192.168.123.2

SW2(config)#ntp peer 192.168.123.1

Después de esperar unos minutos, verá que SW1 y SW2 se han sincronizado entre sí:

SW1#show ntp associations address ref clock st when poll reach delay offset disp*~192.168.123.3 146.185.130.223 3 59 64 37 3.0 -0.74 877.4+~192.168.123.2 192.168.123.3 4 50 128 376 2.2 -2.04 1.3 * master (synced), # master (unsynced), + selected, - candidate, ~ configured

SW2#show ntp associations address ref clock st when poll reach delay offset disp*~192.168.123.3 146.185.130.223 3 45 128 377 2.9 1.95 1.0 ~192.168.123.1 192.168.123.3 4 67 1024 376 1.8 2.40 1.4 * master (synced), # master (unsynced), + selected, - candidate, ~ configured

Genial, ahora todo está sincronizado.

hostname CoreRouter!interface FastEthernet0/0 ip address 192.168.123.3 255.255.255.0!ip name-server 8.8.8.8!ntp server pool.ntp.orgntp update-calendar!end

hostname SW1!interface FastEthernet0/24 ip address 192.168.123.1 255.255.255.0!ntp server 192.168.123.3ntp peer 192.168.123.2!end

hostname SW2!interface FastEthernet0/24 ip address 192.168.123.2 255.255.255.0!ntp server 192.168.123.3ntp peer 192.168.123.1!end

Se nos hace? Todavía no…hay algunas cosas más que podemos hacer con NTP. El CoreRouter y los dos conmutadores utilizan unidifusión (puerto UDP 123) para la sincronización, pero también puede utilizar multidifusión o difusión. Permítanme darles un ejemplo Multidifusión y difusión

Si tiene más de 20 dispositivos de red o un enrutador que tiene memoria de sistema limitada o recursos de CPU, es posible que desee considerar el uso de NTP broadcast o multidifusión, ya que requiere menos recursos. Podemos habilitar multidifusión o difusión en la interfaz level.To demuestre esto, agregaré dos enrutadores debajo de SW1 y SW2 que se sincronizarán mediante multidifusión o difusión. Esto es lo que parece:

Configuraré SW1 para usar la dirección de multidifusión 239.1.1.1 y SW2 enviará actualizaciones NTP a través de difusión: