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.

¡Bienvenido a CCNA desde Cero!: Este tema forma parte del Capítulo 10 del curso de Cisco CCNA 2, para un mejor seguimiento del curso puede ir a la sección CCNA 2 para guiarse del índice.

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.

NTP utiliza el puerto 123 de UDP y se documenta en RFC 1305.

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.

Etiquetas de estratos de NTP

Imagen 1: Etiquetas de estratos de NTP

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.

Configuración del servidor NTP de estrato 2

Imagen 2: Configuración del servidor NTP de estrato 2

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.

syslog

Imagen 3: syslog

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.

Funcionamiento de syslog

Imagen 4: Funcionamiento de syslog

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.

Nivel de gravedad de syslog

Imagen 5: Nivel de gravedad 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.

Formato de mensaje de Syslog

Imagen 6: Formato de mensaje de Syslog

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.

Servidor Syslog

Imagen 7: Servidor Syslog

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.

Servidor Syslog Windows

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

De manera predeterminada, los routers y switches de Cisco envían mensajes de registro a la consola para todos los niveles de gravedad. En algunas versiones del IOS, el dispositivo también almacena en búfer los mensajes de registro de manera predeterminada. Para habilitar estas dos configuraciones, utilice los comandos de configuración global logging console y logging buffered, respectivamente.

El comando show logging muestra la configuración predeterminada del servicio de registro en un router Cisco, como se muestra en la ilustración. En las primeras líneas del resultado, se proporciona información sobre el proceso de registro, y al final del resultado se indican los mensajes de registro.

R1# show logging 
Syslog logging: enabled (0 messages dropped, 2 messages rate-limited, 0 
flushes, 0 overruns, xml disabled, filtering disabled) 
No Active Message Discriminator. 
No Inactive Message Discriminator. 
Console logging: level debugging, 32 messages logged, xml disabled, 
filtering disabled 
Monitor logging: level debugging, 0 messages logged, xml disabled, 
filtering disabled 
Buffer logging: level debugging, 32 messages logged, xml disabled, 
filtering disabled 
Exception Logging: size (4096 bytes) 
Count and timestamp logging messages: disabled 
Persistent logging: disabled 
No active filter modules. 
Trap logging: level informational, 34 message lines logged 
Logging Source-Interface: VRF Name: 
Log Buffer (8192 bytes): 
*Jan 2 00:00:02.527: %LICENSE-6-EULA_ACCEPT_ALL: The Right to Use End 
UserLicense Agreement is accepted 
*Jan 2 00:00:02.631: %IOS_LICENSE_IMAGE_APPLICATION-6-LICENSE_LEVEL: Module 
name = c1900 Next reboot level = ipbasek9 and License = ipbasek9 
*Jan 2 00:00:02.851: %IOS_LICENSE_IMAGE_APPLICATION-6-LICENSE_LEVEL: Module 
name = c1900 Next reboot level = securityk9 and License = securityk9 
*Jun 12 17:46:01.619: %IFMGR-7-NO_IFINDEX_FILE: Unable to open 
nvram:/ifIndex-table No such file or directory 
<se omitió el resultado>

En la primera línea resaltada, se indica que este router se registra en la consola y se incluyen mensajes de depuración. Esto en realidad significa que todos los mensajes del nivel de depuración, así como cualquier mensaje de nivel inferior (como los mensajes del nivel de notificación), se registran en la consola. En la mayoría de los routers Cisco IOS, el nivel de gravedad predeterminado es 7: depuración. El resultado también indica que se registraron 32 de estos mensajes.

En la segunda línea resaltada, se indica que este router se registra en un búfer interno. Dado que en este router se habilitó el registro en un búfer interno, el comando show logging también indica los mensajes en ese búfer. Puede ver algunos de los mensajes del sistema que se registraron al final del resultado.

6.2. Comandos de router y switch para los clientes syslog

Existen tres pasos para configurar el router para que envíe los mensajes del sistema a un servidor de syslog donde se puedan almacenar, filtrar y analizar:

  • Paso 1: En el modo de configuración global, utilice el comando logging para configurar el nombre de host del destino o la dirección IPv4 del syslog.
  • Paso 2: Controle los mensajes que se enviarán al servidor syslog con el comando logging trap level en el modo de configuración global. Por ejemplo, para limitar los mensajes a los niveles 4 e inferiores (0 a 4), utilice uno de los dos comandos equivalentes.
  • Paso 3: Opcionalmente, configure la interfaz de origen con el comando logging source-interface tipo-interfaz número-interfaz comando global configuration mode. Esto especifica que los paquetes de syslog incluyen la dirección IPv4 o IPv6 de una interfaz específica, independientemente de la interfaz que use el paquete para salir del router.

A continuación, el R1 se configuró para enviar mensajes de registro de los niveles 4 e inferiores al servidor de syslog en 192.168.1.3. La interfaz de origen se estableció en la interfaz G0/0. Se crea una interfaz loopback, se desactiva y se vuelve a activar. El resultado de la consola refleja estas acciones.

R1(config)# logging 192.168.1.3
R1(config)# logging trap 4
R1(config)# logging source-interface gigabitEthernet 0/0
R1(config)# interface loopback 0
R1(config-if)#
*Jun 12 22:06:02.902: %LINK-3-UPDOWN: Interface Loopback0,
changed state to up
*Jun 12 22:06:03.902: %LINEPROTO-5-UPDOWN: Line protocol on
Interface Loopback0, changed state to up
*Jun 12 22:06:03.902: %SYS-6-LOGGINGHOST_STARTSTOP: Logging to
host 192.168.1.3 port 514 started - CLI initiated
R1(config-if)# shutdown
R1(config-if)#
*Jun 12 22:06:49.642: %LINK-5-CHANGED: Interface Loopback0,
changed state to administratively down
*Jun 12 22:06:50.642: %LINEPROTO-5-UPDOWN: Line protocol on
Interface Loopback0, changed state to down
R1(config-if)# no shutdown
R1(config-if)#
*Jun 12 22:09:18.210: %LINK-3-UPDOWN: Interface Loopback0,
changed state to up
*Jun 12 22:09:19.210: %LINEPROTO-5-UPDOWN: Line protocol on
Interface Loopback0, changed state to up
R1(config-if)#

Como puede verse en la Imagen 9, el servidor syslog Tftpd32 se ha configurado en una máquina con Windows 7 con la siguiente dirección IPv4: 192.168.1.3. Como puede observar, los únicos mensajes que aparecen en el servidor de syslog son aquellos con un nivel de gravedad de 4 o menos (más graves). Los mensajes con un nivel de gravedad de al menos 5 (menos graves) aparecen en la salida de la consola del router, pero no en la salida del servidor syslog; esto se debe a que logging traplimita los mensajes de syslog que se envían al servidor syslog en función de su gravedad.

Resultado del servidor de syslog

Imagen 9: Resultado del servidor de syslog

6.3. Verificación de syslog

Puede utilizar el comando show logging para ver cualquier mensaje que se registre. Cuando el búfer de registro es grande, resulta útil utilizar la opción de la barra vertical (|) con el comando show logging. La opción de la barra vertical permite que el administrador indique específicamente qué mensajes se deben mostrar. Por ejemplo: puede utilizar la barra vertical para filtrar solo los mensajes con include changed state to up

R1# show logging | include changed state to up
*Jun 12 17:46:26.143: %LINK-3-UPDOWN: InterfaceGigabitEthernet0/1, changed state to up
*Jun 12 17:46:26.143: %LINK-3-UPDOWN: Interface Serial0/0/1,changed state to up
*Jun 12 17:46:27.263: %LINEPROTO-5-UPDOWN: Line protocol onInterface GigabitEthernet0/1, changed state to up
*Jun 12 17:46:27.263: %LINEPROTO-5-UPDOWN: Line protocol onInterface Serial0/0/1, changed state to up
*Jun 12 20:28:43.427: %LINK-3-UPDOWN: InterfaceGigabitEthernet0/0, changed state to up
*Jun 12 20:28:44.427: %LINEPROTO-5-UPDOWN: Line protocol onInterface GigabitEthernet0/0, changed state to up
*Jun 12 22:04:11.862: %LINEPROTO-5-UPDOWN: Line protocol onInterface Loopback0, changed state to up
*Jun 12 22:06:02.902: %LINK-3-UPDOWN: Interface Loopback0,changed state to up
*Jun 12 22:06:03.902: %LINEPROTO-5-UPDOWN: Line protocol onInterface Loopback0, changed state to up
*Jun 12 22:09:18.210: %LINK-3-UPDOWN: Interface Loopback0,changed state to up
*Jun 12 22:09:19.210: %LINEPROTO-5-UPDOWN: Line protocol onInterface Loopback0, changed state to up
*Jun 12 22:35:55.926: %LINK-3-UPDOWN: Interface Loopback0,changed state to up
*Jun 12 22:35:56.926: %LINEPROTO-5-UPDOWN: Line protocol onInterface Loopback0, changed state to up
R1# show logging | begin Jun 12 22:35
*Jun 12 22:35:46.206: %LINK-5-CHANGED: Interface Loopback0,changed state to administratively down
*Jun 12 22:35:47.206: %LINEPROTO-5-UPDOWN: Line protocol onInterface Loopback0, changed state to down
*Jun 12 22:35:55.926: %LINK-3-UPDOWN: Interface Loopback0,changed state to up
*Jun 12 22:35:56.926: %LINEPROTO-5-UPDOWN: Line protocol onInterface Loopback0, changed state to up
*Jun 12 22:49:52.122: %SYS-5-CONFIG_I: Configured from console byconsole
*Jun 12 23:15:48.418: %SYS-5-CONFIG_I: Configured from console byconsole
R1#

Desplácese hacia abajo la salida anterior para ver otro ejemplo de filtrado. Para ver solo los mensajes que se registraron en el búfer a partir del día 12 de junio a las 10:35 p. m. inclusive, utilizaría el siguiente filtro: begin June 12 22:35.

Deja un Comentario

CLOSE
CLOSE