0% del curso completado
Syslog: severidades, facilities e interpretación de mensajes (5.6)
📋 En esta lección
Los logs que llevas leyendo desde el Módulo 5, sistematizados: el formato de cada mensaje de IOS, las ocho severidades (con la mnemotecnia para no olvidarlas), los destinos del logging (consola, buffer, servidor central) y la configuración que convierte un montón de equipos parlanchines en un sistema de registro operativo.
El mensaje de IOS, diseccionado
Todo mensaje de log de IOS sigue el mismo patrón — ya has leído decenas:
*Sep 18 03:12:44.123 CET: %LINEPROTO-5-UPDOWN: Line protocol on Interface Gi0/1, changed state to down
└── timestamp ──────┘ └FACILITY┘│└MNEMONIC┘ └────────────── descripción ──────────────┘
└ SEVERIDAD (5)
- Timestamp — fiable gracias a NTP (lección 8.4) y al comando
service timestamps log datetime msec localtime. - Facility (
LINEPROTO,LINK,SYS,OSPF,DUAL,SPANTREE…) — qué subsistema habla. No confundir con las "facilities numéricas" del protocolo syslog clásico (local0-7…), que en IOS solo importan al etiquetar mensajes hacia el servidor. - Severidad — el número tras el guion: la gravedad, de 0 a 7.
- Mnemonic (
UPDOWN,CONFIG_I,NATIVE_VLAN_MISMATCH) — qué evento concreto. Facility + mnemonic identifican el mensaje de forma única — y son googleables tal cual.
Las ocho severidades
La tabla que hay que saberse con números:
| Nivel | Nombre | Significado típico |
|---|---|---|
| 0 | Emergencies | Sistema inutilizable |
| 1 | Alerts | Actuar ya |
| 2 | Critical | Fallo crítico |
| 3 | Errors | Error (interfaz caída: LINK-3) |
| 4 | Warnings | Aviso (err-disable: PM-4) |
| 5 | Notifications | Evento normal significativo (protocolo up/down: LINEPROTO-5; config: SYS-5) |
| 6 | Informational | Información rutinaria (traducciones NAT, ACL logging) |
| 7 | Debugging | Salida de los debug |
💡 💡 Mnemotecnia clásica
Every Awesome Cisco Engineer Will Need Ice cream Daily — Emergencies, Alerts, Critical, Errors, Warnings, Notifications, Informational, Debugging (0→7).
La regla que gobierna todo: configurar el nivel N incluye todo lo de N hacia abajo (más grave). logging trap 4 = severidades 0-4. "Subir el nivel" (4→6) significa más mensajes, no menos — la confusión clásica.
Dos detalles que el examen y la vida real explotan: una interfaz que cae es LINK-3 (error) pero su line protocol es LINEPROTO-5 (notification) — el mismo evento produce mensajes de severidades distintas; y todo debug emite a nivel 7 — por eso un logging console 7 con debugs activos hace ilegible (o inutilizable) la consola.
Los destinos del logging
IOS puede enviar sus mensajes a cinco sitios, cada uno con su nivel independiente:
R1(config)# logging console 3 ← consola: solo errores o peor (¡no la inundes!)
R1(config)# logging monitor 5 ← sesiones VTY (requiere "terminal monitor")
R1(config)# logging buffered 64000 6 ← buffer en RAM: tu historial local
R1(config)# logging host 10.1.30.40 ← servidor syslog central (UDP 514)
R1(config)# logging trap 5 ← qué severidades se ENVÍAN al servidor
Los papeles de cada uno:
- Console: lo que ves conectado por el cable azul. Nivel bajo (3) para que las urgencias se vean sin que el ruido entierre la CLI.
- Monitor: lo mismo para SSH — silencioso hasta que pides
terminal monitor(lección 5.11). - Buffered: el historial en RAM que consulta
show logging— tu primera parada de diagnóstico desde el Módulo 5. Dale tamaño (64-512 KB) y nivel 6; se pierde al reiniciar — otra razón para el servidor central. - Host + trap: el envío al servidor syslog central (UDP 514) — donde los logs de toda la red se almacenan, se buscan y sobreviven a los reinicios (y a los atacantes que borran huellas locales).
R1(config)# service timestamps log datetime msec localtime show-timezone
R1(config)# service sequence-numbers ← numera los mensajes (detecta huecos)
R1(config)# logging source-interface Loopback0 ← identidad estable hacia el servidor
El servidor central: por qué es innegociable
Con 40 equipos, los buffers locales son 40 historiales amnésicos e inconexos. El syslog central da:
- Correlación — la línea temporal única de toda la red (NTP mediante): el enlace cayó en R1 y por eso OSPF reconvergió en R3.
- Persistencia — el buffer se borra con cada reload; el servidor, no. La avería de anoche sigue ahí por la mañana.
- Evidencia — un intruso puede limpiar el buffer del equipo comprometido; lo ya enviado al servidor está fuera de su alcance.
- Alertas y búsqueda — grep sobre toda la red, y alarmas sobre patrones (todo err-disable, cualquier %SYS-5-CONFIG_I fuera de horario…).
El trío completo de la operación (lección 8.4): SNMP mide, los traps alarman, syslog relata — y NTP los pone de acuerdo.
Leer logs como un profesional
Los mensajes que ya conoces, ahora con lectura completa:
%SYS-5-CONFIG_I: Configured from console by admin on vty0 (10.1.30.5)
Quién, desde dónde y por dónde tocó la configuración. En el servidor central, la auditoría de cambios de toda la red es un filtro por CONFIG_I.
%LINK-3-UPDOWN: Interface Gi0/1, changed state to down
%LINEPROTO-5-UPDOWN: Line protocol on Interface Gi0/1, changed state to down
La pareja habitual: capa física (severidad 3) y protocolo de línea (5). Si se repiten en ráfaga: link flapping — cable, SFP o dúplex (lección 2.4).
%PM-4-ERR_DISABLE: bpduguard error detected on Fa0/7, putting Fa0/7 in err-disable state
El warning (4) que resolvió el caso de la lección 5.11 — con la causa dentro del propio mensaje.
Método general ante un mensaje desconocido: severidad primero (¿es grave?), facility-mnemonic después (¿de qué habla?), y la pareja completa a la documentación de Cisco si hace falta — cada mensaje está documentado con causa y acción recomendada.
Relación con otros conceptos
show loggingcomo segundo comando de todo diagnóstico: lección 5.11 — esta lección explica lo que allí leías.- NTP hace correlacionables los timestamps (8.4); el servidor central es la pieza operativa que faltaba.
terminal monitorpara ver logs por SSH y el peligro de los debug a nivel 7: lecciones 3.2 y 5.11.- La auditoría de CONFIG_I y la protección de la evidencia enlazan con la seguridad operativa del Módulo 10.
Resumen
Formato IOS: timestamp %FACILITY-SEVERIDAD-MNEMONIC: descripción — facility+mnemonic identifican el evento (y se googlea tal cual). Severidades 0-7 (Every Awesome Cisco Engineer Will Need Ice cream Daily); configurar nivel N incluye 0-N; LINK es 3 y LINEPROTO 5 para el mismo evento físico; los debug emiten a 7. Destinos independientes: logging console (bajo), monitor (SSH + terminal monitor), buffered (el historial de show logging — volátil), y logging host + logging trap hacia el servidor central UDP 514 — correlación, persistencia, evidencia y alertas. Con service timestamps ... msec localtime, secuencia y source-interface estable. SNMP mide, los traps alarman, syslog relata, NTP los sincroniza.