Administración de Dispositivos

Se explica cómo los mensajes de syslog se pueden capturar y enviar a un servidor syslog para facilitar las tareas de administración de dispositivos.

1. Configuración del reloj del sistema

El reloj de software de un router o un switch se inicia cuando arranca el sistema y es de donde el sistema extrae la hora. Es importante sincronizar la hora en todos los dispositivos de la red porque todos los aspectos de administración, seguridad, solución de problemas, y planificación de redes requieren una marca de hora precisa. Cuando no se sincroniza la hora entre los dispositivos, será imposible determinar el orden de los eventos y la causa de un evento.

Generalmente, las configuraciones de fecha y hora en un router o un switch se pueden configurar de una de las siguientes maneras:

• Configure manualmente la fecha y hora, tal como se muestra en la figura.
• Configurar protocolo de tiempo de red (NTP).

A medida que una red crece, se hace difícil garantizar que todos los dispositivos de infraestructura operen con una hora sincronizada. Incluso en un entorno de red más pequeño, el método manual no es lo ideal. ¿Cómo obtener una fecha y una marca de hora precisas si se reinicia un router?

R1# clock set 20:36:00 dec 29 2017
R1#
*Dec 11 20:36:00.000: %SYS-6-CLOCKUPDATE: System clock has been
updated from 21:32:31 UTC Fri Dec 29 2017 to 20:36:00 UTC Fri Dec 29
2017, configured from console by console.

Una mejor solución es configurar el NTP en la red. Este protocolo permite que los routers de la red sincronicen sus ajustes de hora con un servidor NTP. Si un grupo de clientes NTP obtiene información de fecha y hora de un único origen, tendrá ajustes de hora más consistentes. Cuando se implementa NTP en la red, se lo puede configurar para sincronizarse con un reloj maestro privado o se puede sincronizar con un servidor NTP disponible públicamente en Internet.

2. Funcionamiento de NTP

Las redes NTP utilizan un sistema jerárquico de fuentes horarias. Cada nivel en este sistema jerárquico se denomina estrato. El nivel de estrato se define como la cantidad de saltos desde fuente autorizada. La hora sincronización se distribuye en la red mediante el protocolo NTP. En la figura muestra una red NTP modelo.

Servidores NTP dispuestos en tres niveles que muestran los tres estratos. El estrato 1 está conectado a relojes del estrato 0.

• Estrato 0: Una red NTP obtiene la hora de fuentes horarias autorizadas. Estas fuentes autorizadas, conocidas como dispositivos de estrato 0, son dispositivos de cronometraje de alta precisión que son presuntamente precisos y con poco o ningún retraso asociado con los mismos. Los dispositivos del estrato 0 están representados por el reloj en la figura.
• Estrato 1: Los dispositivos del estrato 1 están conectados directamente a las fuentes horarias válidas. Actúan como el estándar horario de la red principal.
• Estrato 2 y más bajos: Los servidores del estrato 2 están conectados a dispositivos del estrato 1 a través de conexiones de red. Los dispositivos del estrato 2, como clientes de NTP, sincronizan su horario con los paquetes NTP desde servidores del estrato 1. Podrían también actuar como servidores para dispositivos del estrato 3.

Los números más bajos de estratos indican que el servidor está más cerca de la fuente horaria autorizada que los números de estrato más altos. Cuanto mayor sea el número de estrato, menor es el nivel del estrato. El recuento de saltos máximo es 15. El estrato 16, el nivel de estrato inferior, indica que un dispositivo no está sincronizado. Los servidores horarios en el mismo nivel de estrato pueden configurarse para actuar como un par con otros servidores horarios en el mismo nivel de estratos para la verificación o la copia de respaldo del horario.

3. Configuración del NTP

Antes de configurar NTP en la red, el comando show clock muestra la hora actual en el reloj del software. Con la opción detail, también se muestra la fuente de la hora. Como puede verse a continuación, el reloj del software se ha configurado manualmente. Utilice el comando ntp server dirección-ip en el modo de configuración global para configurar 209.165.200.225 como el servidor NTP para R1. Para verificar que la fuente de la hora esté definida en NTP, vuelva a utilizar el comando show clock detail.

R1# show clock detail
20:55:10.207 UTC Fri Dec 29 2017
Time source is user configuration
R1(config)# ntp server 209.165.200.225
R1(config)# end
R1# show clock detail
21:01:34.563 UTC Fri Dec 29 2017
Time source is NTP

Tal como se indica en el siguiente resultado, utilice los comandos show ip ntp associations y show ntp status para verificar que R1 esté sincronizado con el servidor NTP en 209.165.200.225. Observe que el R1 está sincronizado con un servidor NTP de estrato 1 en 209.165.200.225, que se sincroniza con un reloj GPS. El comando show ntp status indica que R1 ahora es un dispositivo de estrato 2 sincronizado con el servidor NTP en 209.165.220.225.

R1# show ntp associations
 
 address ref clock st when poll reach delay offset disp
*~209.165.200.225 .GPS. 1 61 64 377 0.481 7.480 4.261
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
 
R1# show ntp status
Clock is synchronized, stratum 2, reference is 209.165.200.225
nominal freq is 250.0000 Hz, actual freq is 249.9995 Hz, precision is 2**19
ntp uptime is 589900 (1/100 of seconds), resolution is 4016
reference time is DA088DD3.C4E659D3 (13:21:23.769 PST Tue Dec 1 2015)
clock offset is 7.0883 msec, root delay is 99.77 msec
root dispersion is 13.43 msec, peer dispersion is 2.48 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.000001803 s/s
system poll interval is 64, last update was 169 sec ago.

4. Verificación del NTP

El reloj de S1 está configurado para sincronizarse con R1. La salida del comando show ntp associations verifica que el reloj de S1 ahora esté sincronizado con R1 en 192.168.1.1 por medio de NTP. El R1 es un dispositivo de estrato 2 y un servidor NTP para el S1. Ahora el S1 es un dispositivo de estrato 3 que puede proporcionar el servicio NTP a otros dispositivos en la red, por ejemplo terminales.

S1(config)# ntp server 192.168.1.1
S1(config)# end
S1# show ntp associations
 
 address ref clock st when poll reach delay offset disp
*~C192.168.1.1 209.165.200.225 2 12 64 377 1.066 13.616 3.840
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
 
S1# show ntp status
Clock is synchronized, stratum 3, reference is 192.168.1.1
nominal freq is 119.2092 Hz, actual freq is 119.2088 Hz, precision is 2**17
reference time is DA08904B.3269C655 (13:31:55.196 PST Tue Dec 1 2015)
clock offset is 18.7764 msec, root delay is 102.42 msec
root dispersion is 38.03 msec, peer dispersion is 3.74 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.000003925 s/s
system poll interval is 128, last update was 178 sec ago.

5. Introducción a syslog

Cuando ocurren ciertos eventos en una red, los dispositivos de red tienen mecanismos de confianza para notificar mensajes detallados del sistema al administrador. Estos mensajes pueden ser importantes o no. Los administradores de red tienen una variedad de opciones para almacenar, interpretar y mostrar estos mensajes, así como para recibir esos mensajes que podrían tener el mayor impacto en la infraestructura de la red.

El método más común para acceder a los mensajes del sistema es utilizar un protocolo denominado syslog.

El término “syslog” se utiliza para describir un estándar. También se utiliza para describir el protocolo desarrollado para ese estándar. El protocolo syslog se desarrolló para los sistemas UNIX en la década de los ochenta, pero la IETF lo registró por primera vez como RFC 3164 en 2001. Syslog usa el puerto UDP 514 para enviar mensajes de notificación de eventos a través de redes IP a recopiladores de mensajes de eventos, como se muestra en la ilustración.

Muchos dispositivos de red admiten syslog, incluidos routers, switches, servidores de aplicación, firewalls y otros dispositivos de red. El protocolo syslog permite que los dispositivos de red envíen los mensajes del sistema a servidores de syslog a través de la red.

Existen varios paquetes de software diferentes de servidores de syslog para Windows y UNIX. Muchos de ellos son freeware.

El servicio de registro de syslog proporciona tres funciones principales:

• La capacidad de recopilar información de registro para el control y la resolución de problemas
• La capacidad de seleccionar el tipo de información de registro que se captura
• La capacidad de especificar los destinos de los mensajes de syslog capturados

5.1. Funcionamiento de syslog

En los dispositivos de red Cisco, el protocolo syslog comienza enviando los mensajes del sistema y el resultado del comando debug a un proceso de registro local interno del dispositivo. La forma en que el proceso de registro administra estos mensajes y resultados se basa en las configuraciones del dispositivo. Por ejemplo, los mensajes de syslog se pueden enviar a través de la red a un servidor de syslog externo. Estos mensajes se pueden recuperar sin necesidad de acceder al dispositivo propiamente dicho. Los resultados y los mensajes de registro almacenados en el servidor externo se pueden incluir en varios informes para facilitar la lectura.

Por otra parte, los mensajes de syslog se pueden enviar a un búfer interno. Los mensajes enviados al búfer interno solo se pueden ver mediante la CLI del dispositivo.

Por último, el administrador de red puede especificar que solo se envíen determinados tipos de mensajes del sistema a varios destinos. Por ejemplo, se puede configurar el dispositivo para que reenvíe todos los mensajes del sistema a un servidor de syslog externo. Sin embargo, los mensajes del nivel de depuración se reenvían al búfer interno, y solo el administrador puede acceder a ellos desde la CLI.

Como se muestra en la ilustración, los destinos comunes para los mensajes de syslog incluyen lo siguiente:

• Búfer de registro (RAM dentro de un router o switch)
• Línea de consola
• Línea de terminal
• Servidor de syslog

Es posible controlar los mensajes del sistema de manera remota viendo los registros en un servidor de syslog o accediendo al dispositivo mediante Telnet, SSH o a través del puerto de consola.

5.2. Nivel de gravedad de Syslog

Los dispositivos de Cisco generan mensajes de syslog como resultado de los eventos de red. Cada mensaje de syslog contiene un nivel de gravedad y una instalación.

Cuanto más bajos son los números de nivel, más fundamentales son las alarmas de syslog. El nivel de gravedad de los mensajes se puede establecer para controlar dónde se muestra cada tipo de mensaje (es decir, en la consola o los otros destinos). En la figura 1, se muestra la lista completa de los niveles de syslog.

Cada nivel de syslog tiene su propio significado:

• Nivel de advertencia 4 – Nivel de emergencia 0: Estos mensajes son mensajes de error sobre desperfectos de software o hardware; indican que la funcionalidad del dispositivo está afectada. La gravedad del problema determina el nivel real de syslog que se aplica.
• Nivel de notificación 5: El nivel de notificaciones es para eventos normales, pero significativos. Por ejemplo: las transiciones para activar o desactivar interfaces y los mensajes para reiniciar el sistema se muestran en el nivel de notificaciones.
• Nivel informativo 6: Un mensaje informativo normal que no afecta la funcionalidad del dispositivo. Por ejemplo: cuando un dispositivo Cisco está arrancando, se podría ver el siguiente mensaje informativo: %LICENSE-6-EULA_ACCEPT_ALL: The Right to Use End User License Agreement is accepted.
• Nivel de depuración 7: Este nivel indica que los mensajes son generados como salida a partir de la ejecución de diversos comandos debug (de depuración).

5.3. Formato de mensaje de Syslog

Además de especificar la gravedad, los mensajes de syslog también contienen información sobre la instalación. Las instalaciones de syslog son identificadores de servicios que identifican y categorizan los datos de estado del sistema para informar los mensajes de error y de eventos. Las opciones de instalación de registro disponibles son específicas del dispositivo de red. Por ejemplo, los switches Cisco de la serie 2960 que ejecutan el IOS de Cisco versión 15.0(2) y los routers Cisco 1941 que ejecutan el IOS de Cisco versión 15.2(4) admiten 24 opciones de instalación que se categorizan en 12 tipos de instalación.

Algunas instalaciones comunes de mensajes de syslog que se informan en los routers con IOS de Cisco incluyen lo siguiente:

• IP
• Protocolo OSPF
• Sistema operativo SYS
• Seguridad IP (IPsec)
• IP de interfaz (IF)

De manera predeterminada, el formato de los mensajes de syslog en el software IOS de Cisco es el siguiente:

seq no: timestamp: %facility-severity-MNEMONIC: description

Los campos incluidos en el mensaje de syslog del software IOS de Cisco se explican en la Imagen 6.

Por ejemplo, el resultado de ejemplo de un switch Cisco para un enlace EtherChannel que cambia al estado activo es el siguiente:

00:00:46: %LINK-3-UPDOWN: Interface Port-channel1, changed state to up

Aquí la instalación es LINK, y el nivel de gravedad es 3, con con MNEMONIC UPDOWN.

5.4. Marca de hora del servicio

De manera predeterminada, los mensajes de registro no tienen marca de hora. Por ejemplo: en el siguiente resultado, la interfaz GigabitEthernet 0/0 de R1 está apagada. El mensaje que se registra en la consola no identifica cuándo se modificó el estado de la interfaz. Los mensajes de registro deben tener marcas de hora de manera que, cuando se envían a otro destino, como un servidor syslog, haya un registro del momento en el que se generó el mensaje.

R1# conf t
R1(config)# interface g0/0
R1(config-if)# shutdown
%LINK-5-CHANGED: Interface GigabitEthernet0/0, changed state to 
administratively down
%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, 
changed state to down
R1(config-if)# exit
R1(config)# service timestamps log datetime
R1(config)# interface g0/0
R1(config-if)# no shutdown
*Mar 1 11:52:42: %LINK-3-UPDOWN: Interface GigabitEthernet0/0, 
changed state to down
*Mar 1 11:52:45: %LINK-3-UPDOWN: Interface GigabitEthernet0/0, 
changed state to up
*Mar 1 11:52:46: %LINEPROTO-5-UPDOWN: Line protocol on Interface
GigabitEthernet0/0, changed state to up
R1(config-if)#

Utilice el comando service timestamps log datetime para obligar a los eventos registrados a que indiquen la fecha y hora. Como puede verse en la figura, cuando se vuelve a activar la interfaz GigabitEthernet 0/0 de R1, los mensajes de registros contienen la fecha y hora.

Nota: Cuando se utiliza la palabra datetime, se debe configurar el reloj del dispositivo de red, ya sea manualmente o a través de NTP, tal como se analizó anteriormente.

6. Configuración de syslog

Para ver los mensajes de syslog, se debe instalar un servidor de syslog en una estación de trabajo en la red. Hay varias versiones de freeware y shareware de syslog, así como versiones empresariales para comprar. En la Imagen 7, se muestra una versión de evaluación del daemon de syslog Kiwi en una máquina con Windows 7.

El servidor de syslog proporciona una interfaz relativamente fácil de usar para ver el resultado de syslog. El servidor analiza el resultado y coloca los mensajes en columnas predefinidas para interpretarlos con facilidad. Si se configuran las marcas de hora en el dispositivo de red que origina los mensajes de syslog, se muestra la fecha y hora de cada mensaje en el resultado del servidor de syslog, como se muestra en la Imagen 8.

Los administradores de red pueden navegar fácilmente a través de una gran cantidad de datos que se recopilan en un servidor de syslog. Una ventaja de ver los mensajes de syslog en un servidor de syslog es la capacidad de realizar búsquedas granulares a través de los datos. Además, un administrador de red puede eliminar rápidamente de la base de datos los mensajes de syslog que no son importantes.

6.1. Registro predeterminado