Router Teldat. Cliente Syslog

Router Teldat Cliente Syslog Doc. DM753 Junio, 2007

ÍNDICE Capítulo 1 Introducción...1 1. Introducción al protocolo syslog... 2 2. Mensajes syslog...3 2.1. Campo [PRI]... 3 2.2. Campo [HEADER]... 4 2.3. Campo [MSG]... 4 3. El protocolo syslog en el Router Teldat... 6 Capítulo 2 Configuración...7 1. Configuración de la facilidad syslog cliente... 8 1.1.? (AYUDA)... 9 1.2. BUFFER-SIZE... 9 1.3. DISABLE... 9 1.4. ENABLE... 10 1.5. FACILITY... 10 1.6. INITIAL-DELAY... 11 1.7. LIST... 11 1.8. NO... 12 a) no buffer-size... 12 b) no facility... 12 c) no initial-delay... 13 d) no server... 13 e) no severity... 13 f) no source-address... 13 1.9. SERVER... 14 1.10. SEVERITY... 14 1.11. SOURCE-ADDRESS... 15 1.12. EXIT... 15 2. Notificación de eventos como mensajes syslog... 16 Capítulo 3 Monitorización...19 1. Monitorización de la facilidad syslog cliente... 20 1.1.? (AYUDA)... 20 1.2. LIST... 20 1.3. EXIT... 22 Capítulo 4 Ejemplo...23 1. Ejemplo de configuración del cliente syslog... 24 - ii -

Capítulo 1 Introducción

1. Introducción al protocolo syslog El protocolo syslog viene descrito en la RFC 3164 (The BSD syslog protocol). Proporciona un mecanismo de transporte que permite a un dispositivo enviar mensajes de notificación de eventos a través de redes IP dirigidos a colectores de esos mensajes, conocidos como servidores syslog. Una de las características fundamentales de este protocolo es su simplicidad: No es necesario confirmar la recepción de mensajes. No se exige ningún tipo de coordinación entre el cliente o transmisor y el servidor o receptor de hecho la transmisión de mensajes syslog puede comenzar en un dispositivo sin que haya sido configurado un servidor, o incluso sin que éste se encuentre presente físicamente. El mecanismo de transporte utilizado por el protocolo syslog es el protocolo UDP (User Datagram Protocol), y el puerto asignado es el 514. Se recomienda que el puerto origen sea también el 514, para indicar así que el mensaje procede del proceso syslog del transmisor (aunque el puerto origen podría ser cualquier otro). En la arquitectura o modelo de funcionamiento del syslog pueden distinguirse tres papeles: cliente o transmisor, servidor o receptor y relay. El relay recibe mensajes procedentes del cliente y los retransmite, bien a un servidor o bien a otro relay, siendo necesaria en algunos casos una modificación previa de los mismos por parte del dispositivo que realiza la función de relay. En un dispositivo que actúa como colector (o servidor), cualquier paquete destinado al puerto UDP 514 será tratado como un mensaje syslog, pero en cualquier caso se recomienda seguir un formato establecido si un relay recibe un paquete que se ajusta al mismo, debe enviarlo sin efectuar ningún tipo de modificación, y en caso de que no siga exactamente el patrón definido, debería modificarlo de modo que concuerde con el formato esperado antes de proceder a retransmitirlo. En cada sistema operativo o aplicación concreta es el propio programador o desarrollador el que debe decidir en qué punto o bajo qué circustancias debe ser generado un mensaje de notificación de un determinado evento considerado relevante. Estos mensajes pueden ser clasificados en alguna de entre diversas y amplias categorías, categorías generalmente consistentes en la facilidad que generó el evento junto con una indicación de la severidad del mensaje. De esta forma se facilita la labor de filtrado de mensajes, de modo que los más importantes y sensibles en cuanto al tiempo de reacción sean atendidos en primer lugar. I - 2

2. Mensajes syslog Un mensaje syslog puede considerarse constituido por tres partes: 2.1. Campo [PRI] Este campo consta de tres, cuatro o cinco caracteres, comenzando por el carácter <, finalizando con el carácter >, y entre ambos un número conocido como el valor de la prioridad, que representa tanto la facilidad como la severidad, y que consiste en uno, dos o tres enteros decimales. El código utilizado es un código ASCII de 7 bits en un campo de 8 bits, es decir, los códigos ASCII como se definen en el USA Standard Code for Information Interchange: el carácter < se define como la Augmented Backus-Naur Form (ABNF) %d60, el carácter > corresponde al valor ABNF %d62, y los dígitos que indican la prioridad toman valores ABNF entre %d48 ( 0 ) y %d57 ( 9 ) La facilidad y la severidad se codifican numéricamente con valores decimales. Algunos de los demonios y procesos de los sistemas operativos tienen asignado un valor de facilidad aquellos que no tengan un valor explícitamente asignado pueden utilizar uno de los valores de facilidades reservadas para uso local (local use x), o bien la facilidad user-level (1). A continuación se muestran las facilidades cuyos valores están específicamente designados junto con sus correspondientes códigos numéricos: Código numérico Facilidad 0 kernel messages 1 user-level messages 2 mail system 3 system daemons 4 security/authorization messages 5 messages generated internally by syslogd 6 line printer subsystem 7 network news subsystem 8 UUCP subsystem 9 clock daemon 10 security/authorization messages 11 FTP daemon 12 NTP subsystem 13 log audit 14 log alert 15 clock daemon 16 local use 0 (local0) 17 local use 1 (local1) 18 local use 2 (local2) 19 local use 3 (local3) 20 local use 4 (local4) 21 local use 5 (local5) 22 local use 6 (local6) 23 local use 7 (local7) I - 3

En cuanto al indicador del nivel de severidad, los valores decimales asociados a cada uno de los niveles son los siguientes: Código numérico Severidad 0 Emergency: el sistema se encuentra inutilizable 1 Alert: es preciso llevar a cabo una acción inmediatamente 2 Critical: condiciones críticas 3 Error: condiciones de error 4 Warning: situaciones cuya ocurrencia conviene advertir 5 Notice: condiciones normales pero significativas 6 Informational: mensajes de información 7 Debug: mensajes de depuración El valor de prioridad que debe introducirse en el correspondiente campo del mensaje (precedido por el carácter < y seguido del carácter > ) será el calculado multiplicando por 8 el valor numérico indicativo de la facilidad y sumando el número entero asociado a la severidad. El primer dígito que siga al carácter < nunca será un 0 salvo en el caso de que el valor de la prioridad sea 0. 2.2. Campo [HEADER] Contiene un timestamp y una indicación del hostname o dirección IP del dispositivo que envía el mensaje, cada uno en un campo y en ese orden, finalizando ambos con el carácter de espacio en blanco (ABNF %d32). El campo [TIMESTAMP] contiene el tiempo local, en el formato Mmm dd hh:mm:ss (sin las comillas), donde Mmm indica los tres primeros caracteres en inglés del mes del año, yendo el primero en mayúsculas (es decir, los valores posibles son: Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec), dd es el día del mes (si es menor que 10 se inserta un espacio antes del número de día), y hh:mm:ss representa la hora local, en formato de 24 horas. El campo [HOSTNAME] contiene el hostname o la dirección IP, siendo el valor preferido el hostname (NO el nombre de dominio) y estando prohibido que éste contenga espacios en blanco en su interior. Si el dispositivo no tiene hostname, se incluye en este campo su dirección IP en caso de que tuviese varias direcciones IP, suele escogerse la dirección IP de salida del mensaje, aunque otra posibilidad es utilizar una dirección configurada a este fin, independientemente del interfaz por el que se envíe el mensaje. El formato para direcciones IP es en notación decimal con puntos. 2.3. Campo [MSG] Incluye información adicional sobre el proceso que generó el mensaje. No existe delimitador final para esta parte, que contendrá caracteres visibles, usualmente en código ASCII de 7 bits en un campo, es decir, valores ABNF VCHAR (los comprendidos entre %d33 y %d126) y espacios (SP, de valor %d32). Sin embargo es posible también utilizar otro tipo de codificación, basando la selección del código a emplear en el tipo de receptor al que se enviarán los mensajes (siempre limitando el conjunto de caracteres permitidos a caracteres visibles y el espacio en blanco). I - 4

Se distinguen dos campos dentro de la parte [MSG]: El campo [TAG]: nombre del programa o proceso que generó el mensaje. Es una cadena de caracteres ABNF alfanuméricos de longitud máxima 32 caracteres. Cualquier carácter no alfanumérico termina esta cadena y marca el inicio del siguiente campo. El campo [CONTENT]: detalles del mensaje. Como se ha dicho anteriormente, el primer carácter de éste campo será el primer carácter no alfanumérico encontrado en la parte [MSG]. Lo más usual es que este primer carácter sea [, : o bien un espacio en blanco. I - 5

3. El protocolo syslog en el Router Teldat En el Router Teldat se encuentra implementada la funcionalidad de cliente syslog: el equipo es capaz de enviar notificaciones en forma de mensajes syslog dirigidas al servidor o servidores que se hayan configurado. La selección de las situaciones o puntos de funcionamiento donde debe generarse un mensaje syslog es común con el resto de métodos existentes en el equipo para la notificación de eventos es decir, además de poder habilitar eventos para su visualización como trazas y para la transmisión de traps SNMP, se permite también habilitar su envío en forma de mensajes syslog. Cuando se produce una situación en la que se determinó que debe originarse una notificación, esto es, que tiene un evento asociado, lo primero es comprobar que ese evento concreto está habilitado para su envío como mensaje syslog y que además se ha habilitado esa facilidad (por defecto estará deshabilitada). En caso afirmativo se compara la severidad que se haya configurado mediante el correspondiente parámetro (por defecto 6: Informational) con la asociada al evento, y en caso de que esta última sea igual o inferior al nivel establecido (comparando sus códigos numéricos), se procederá al envío del mensaje syslog con el que se transmite la información oportuna al servidor. La correspondencia entre el logging-level de un evento (tipo de evento o nivel de filtrado) y su severidad es la siguiente: Código numérico Severidad Logging-Level 0 Emergency UI-ERROR 1 Alert CI-ERROR 2 Critical UE-ERROR 3 Error CE-ERROR 4 Warning U-INFO 5 Notice U-TRACE 6 Informational C-INFO 7 Debug C-TRACE, P-TRACE El paquete dirigido a cada servidor syslog configurado se construye teniendo en cuenta estos otros datos: 1. El puerto destino es el UDP 514. 2. El puerto origen también es el UDP 514. 3. La dirección destino es la del servidor syslog que el usuario haya configurado (bien a través de una dirección IP o mediante un nombre de host). 4. La dirección origen es la especificada a través del correspondiente parámetro de configuración. Por defecto se toma la del interfaz de salida del paquete. 5. El campo [PRI] se determina en base a la severidad asociada al evento concreto (según la correspondencia con su logging-level) y al valor configurado para la facilidad, que por defecto será 23 (local7). 6. El timestamp se calcula a partir de la hora local del equipo, obtenida de la BIOS o de un servidor NTP, aplicándole el horario de verano si se ha configurado y procede. 7. En el campo [HOSTNAME] se introduce el hostname del equipo si es que se ha configurado si no existe hostname, en ese campo va la dirección IP configurada como de salida del paquete. 8. Por último, en el campo [MSG] se incluye el texto constituyente del evento, comenzando por el subsistema al que pertenece y que lo genera, dicho subsistema constituye el campo [TAG]. I - 6

Capítulo 2 Configuración

1. Configuración de la facilidad syslog cliente En este apartado se describen los pasos necesarios para configurar el cliente syslog. Una vez que se haya terminado de configurar esta facilidad, se debe guardar la configuración y reiniciar el equipo para que tenga efecto la nueva configuración. Para acceder al entorno de configuración del cliente syslog, se deben introducir los siguientes comandos: *process 4 Config>feature syslog -- SYSLOG client configuration -- O bien: *CONFIG Config>feature syslog -- SYSLOG client configuration -- Una vez que se ha accedido al menú de configuración del cliente syslog, los comandos disponibles son los que se describen a continuación: Comando Función? (AYUDA) Lista los comandos u opciones disponibles. BUFFER-SIZE Establece el tamaño del buffer donde se almacenan los mensajes en espera de ser enviados. DISABLE Deshabilita la funcionalidad de cliente syslog. ENABLE Habilita la funcionalidad de cliente syslog. FACILITY Configura la facilidad asociada a los mensajes syslog. Este parámetro, junto a la severidad del evento que origina el mensaje, se utiliza para calcular la prioridad del mismo. INITIAL-DELAY Retardo inicial antes de comenzar el envío periódico de mensajes. LIST Muestra la configuración del cliente syslog. NO Borra un servidor syslog previamente configurado o restaura los valores por defecto de los diversos parámetros de configuración. SERVER Añade un servidor syslog como destinatario de los mensajes transmitidos por el cliente. SEVERITY Establece el nivel de severidad. SOURCE-ADDRESS Dirección IP origen con que saldrán los mensajes syslog. EXIT Sale del menú de configuración del cliente syslog. II - 8

1.1.? (AYUDA) Este comando se utiliza para listar los comandos válidos en el nivel donde se está programando el router. Se puede también utilizar este comando después de un comando específico para listar las opciones disponibles.?? buffer-size disable enable facility initial-delay list no server severity source-address exit Set size of buffer used to store messages before sending Disable syslog client Enable syslog client Facility parameter for syslog messages Set initial delay before starting periodic sending List syslog client configuration parameters Negate a command or set its defaults Configure a syslog server Set severity level Set source ip address of syslog messages Exit syslog configuration menu 1.2. BUFFER-SIZE Establece el tamaño del buffer donde se almacenan los mensajes en espera de ser enviados. Cuando se produce una situación que lleva asociado un evento, si se cumplen todas las premisas para que sea notificado en forma de mensaje syslog, éste se guarda en un buffer del que periódicamente se van extrayendo y son enviados a los servidores que se hayan configurado. A la hora de elegir el tamaño del buffer que se va a utilizar debe tenerse en cuenta que cuanto mayor sea este valor más memoria se consume, y cuanto menor sea, más probabilidades hay de que el buffer se sature con la consiguiente pérdida de eventos. El rango de valores permitidos es <2..100>. buffer-size? <2..100> Value in the specified range buffer-size 60 Se recomienda no modificar el valor por defecto de este parámetro (50 mensajes) salvo en casos en que sea absolutamente necesario. 1.3. DISABLE Deshabilita la funcionalidad de cliente syslog: no se notifican eventos a través de dicho protocolo. Por defecto esta facilidad se encuentra deshabilitada. II - 9

disable? <cr> disable 1.4. ENABLE Habilita la funcionalidad de cliente syslog. Por defecto esta facilidad se encuentra deshabilitada. enable? <cr> enable 1.5. FACILITY Configura la facilidad asociada a los mensajes syslog. Este parámetro, junto a la severidad del evento que origina el mensaje, se utiliza para calcular la prioridad del mismo. Algunos de los demonios y procesos de los sistemas operativos tienen asignado un valor de facilidad, definido de forma estándar aquellos que no tengan un valor explícitamente asignado pueden utilizar uno de los valores de facilidades reservadas para uso local. En el caso del Router Teldat los valores permitidos para la facilidad (y configurables) son: Código numérico Facilidad 16 local use 0 (local0) 17 local use 1 (local1) 18 local use 2 (local2) 19 local use 3 (local3) 20 local use 4 (local4) 21 local use 5 (local5) 22 local use 6 (local6) 23 local use 7 (local7) Por defecto el valor de la facilidad es 23 (local7). facility? <0..23> Value in the specified range kernel Kernel messages user User-level messages mail Mail system daemon System daemons auth Security/authorization messages syslogd Messages generated internally by syslogd lpr Line printer subsystem news Network news subsystem II - 10

uucp UUCP subsystem clock Clock daemon auth2 Security/authorization messages (2) ftp FTP daemon ntp NTP subsystem audit Log audit alert Log alert clock2 Clock daemon (2) local0 Local use 0 (local0) local1 Local use 1 (local1) local2 Local use 2 (local2) local3 Local use 3 (local3) local4 Local use 4 (local4) local5 Local use 5 (local5) local6 Local use 6 (local6) local7 Local use 7 (local7) facility local0 1.6. INITIAL-DELAY Establece un retardo inicial antes de comenzar la búsqueda periódica en el buffer de mensajes syslog pendientes de envío para proceder a su transmisión dirigidos hacia los servidores configurados. Por defecto se espera un segundo antes de hacer una primera lectura del buffer de mensajes, y por medio de este parámetro se especifica un tiempo de espera, en segundos, que puede ser entre 1 y 4294967295 segundos. Lógicamente debe ponerse especial cuidado a la hora de elegir el valor de este parámetro, ya que un valor muy grande puede conducir a la pérdida de eventos durante un largo periodo de tiempo. initial-delay? <1..4294967295> Value in the specified range initial-delay 25 Es necesario configurar un cierto retardo antes de comenzar el envío de mensajes si se han habilitado para su notificación de esta forma los eventos producidos en los primeros momentos de arranque del equipo. En caso contrario se recomienda no modificar el valor por defecto de este parámetro (1 segundo). 1.7. LIST Permite visualizar la información de configuración de la facilidad syslog cliente. list? <cr> II - 11

list Syslog client global configuration: Syslog client status: ENABLED Facility: 16 (Local0) Severity: 3 (Error) Source IP address: 10.65.23.25 Syslog servers configured: IP address Domain name --------------- ----------- 0.0.0.0 pruebas.id.teldat.es 172.24.51.5 Storage and sending parameters: Buffer size: 60 messages Initial delay: 25 sec. 1.8. NO Con este comando es posible borrar un servidor previamente configurado o reestablecer el valor por defecto de alguno de los parámetros de configuración del cliente syslog. no? buffer-size facility initial-delay server severity source-address a) no buffer-size Set size of buffer used to store messages before sending Facility parameter for syslog messages Set initial delay before starting periodic sending Configure a syslog server Set severity level Set source ip address of syslog messages Configura el parámetro que indica el tamaño del buffer de almacenamiento de mensajes syslog en espera de ser enviados con su valor por defecto: 50 mensajes. no buffer-size? <cr> no buffer-size b) no facility Restaura el valor por defecto del parámetro que indica la facilidad que se asocia a los mensajes syslog: 23 (local7). no facility? <cr> II - 12

no facility c) no initial-delay Establece el valor por defecto para el retardo inicial antes de comenzar el procesamiento de los mensajes syslog almacenados en el buffer en espera de ser enviados: 1 segundo. no initial-delay? <cr> no initial-delay d) no server Permite borrar un servidor syslog de los anteriormente añadidos como destinatarios de los mensajes generados por el cliente. La identificación del servidor puede hacerse en base a su dirección IP o bien a su nombre de dominio. no server? <a.b.c.d> IP address of the logging host used as syslog server <1..255 chars> Domain name of the logging host used as syslog server no server 172.24.51.5 e) no severity Restaura el valor por defecto del nivel de severidad: 6 (Informational). no severity? <cr> no severity f) no source-address Borra la dirección IP establecida como origen de los mensajes syslog, si es que se había configurado. no source-address? <cr> no source-address II - 13

1.9. SERVER Configura un servidor syslog como destinatario de los mensajes generados y enviados por el cliente. La identificación del servidor puede hacerse en base a su dirección IP o bien a su nombre de dominio. Ejemplo 1: Ejemplo 2: server? <a.b.c.d> IP address of the logging host used as syslog server <1..255 chars> Domain name of the logging host used as syslog server server 172.24.51.5 server pruebas.id.teldat.es No existe limitación en el número de servidores syslog que pueden añadirse. 1.10. SEVERITY Asigna un valor al parámetro que indica el nivel de severidad manejado: se notifican mediante mensajes syslog aquellos eventos que, además de estar habilitados para su envío por medio de este protocolo (y estarlo asimismo la funcionalidad de cliente syslog), tengan una severidad cuyo código numérico sea inferior o igual a la establecida. La severidad de un evento está estrechamente ligada a su logging-level (tipo de evento o nivel de filtrado), en la forma en que se muestra a continuación: Código numérico Severidad Logging-Level 0 Emergency UI-ERROR 1 Alert CI-ERROR 2 Critical UE-ERROR 3 Error CE-ERROR 4 Warning U-INFO 5 Notice U-TRACE 6 Informational C-INFO 7 Debug C-TRACE, P-TRACE Para información más detallada acerca del tipo de eventos consúltese el manual Dm704 Configuración y Monitorización. severity? <0..7> Value in the specified range emergency System is unusable alert Immediate action needed critical Critical conditions error Error conditions warning Warning conditions notice Normal but significant conditions II - 14

informational debug severity error Informational messages Debug-level messages 1.11. SOURCE-ADDRESS Configura la dirección IP origen con que salen del equipo los mensajes syslog. En caso de no haber configurado un hostname en el router, en el campo [HOSTNAME] también aparece el valor de dicha dirección origen. source-address? <a.b.c.d> Ipv4 format source-address 10.65.23.25 1.12. EXIT Mediante este comando se sale del menú de configuración de la facilidad syslog cliente y se retorna al menú de configuración principal (Config>). exit exit Config> II - 15

2. Notificación de eventos como mensajes syslog Además de configurar la funcionalidad de syslog cliente, es preciso indicar qué eventos son notificados a través de mensajes syslog. Esto se lleva a cabo desde el menú de configuración del Sistema de Registro de Eventos (SRE). *p 4 Config>event -- ELS Config -- ELS config>enable? all Events as traps, syslog messages and on screen filter Enables events filtering snmp-trap Events as traps syslog Events as syslog messages trace Events on screen ELS config>enable syslog? event An individual event groups An entire group subsystem An entire subsystem with a filter level ELS config> Como puede observarse en la sintaxis, es posible habilitar para su envío a un servidor syslog (o a varios) un evento concreto, un subsistema completo o bien un grupo formado por un cierto conjunto de eventos elegidos por el usuario. En caso de introducir estos comandos desde el proceso de configuración (CONFIG o P 4), es necesario guardar la configuración y reiniciar el equipo para que tengan efecto los cambios y se active la nueva configuración. ELS config>enable syslog subsystem ppp all ELS config> En este ejemplo se habilitan todos los eventos del subsistema PPP para su notificación en forma de mensajes syslog, pero realmente provocan la transmisión de un mensaje hacia el servidor (o servidores) syslog aquellos cuya severidad (en relación con su logging-level, nivel de filtrado o tipo de evento, tal y como se ha visto) sea igual o inferior al nivel establecido en la configuración del cliente syslog (comparando sus códigos numéricos), y siempre que dicha funcionalidad esté habilitada, evidentemente. NOTA IMPORTANTE: Si se ha establecido el nivel de severidad DEBUG en la funcionalidad de cliente syslog, NO DEBEN HABILITARSE para su envío en forma de mensajes syslog LOS EVENTOS DEL SUBSISTEMA IP cuyo nivel de filtrado o logging-level sea DE TIPO TRACE (P-TRACE, U-TRACE, C-TRACE), ya que al estar el protocolo syslog basado en UDP, la simple transmisión de los mensajes provoca un elevado número de eventos de este tipo, llegando a saturarse el buffer (con la consiguiente pérdida de mensajes). Para deshabilitar eventos individuales, subsistemas completos o grupos de eventos configurados previamente para su transmisión en forma de mensajes syslog, basta con utilizar el comando DISABLE. II - 16

*p 4 Config>event -- ELS Config -- ELS config>disable? all Events as traps, syslog messages and on screen filter Disables events filtering snmp-trap Events as traps syslog Events as syslog messages trace Events on screen ELS config>disable syslog? event An individual event groups An entire group subsystem An entire subsystem with a filter level ELS config> ELS config>disable syslog subsystem ppp all ELS config> También es posible habilitar un evento individual, un subsistema completo o un grupo de eventos para su notificación mediante mensajes syslog desde el menú de monitorización del Sistema de Registro de Eventos (SRE), en el proceso P 3 (o MONITOR). *P 3 +event -- ELS Monitor -- ELS+enable? all Events as traps, syslog messages and on screen filter Enables events filtering snmp-trap Events as traps syslog Events as syslog messages trace Events on screen ELS+enable syslog? event An entire subsystem with a filter level groups An entire group subsystem An entire subsystem with a filter level ELS+ En este caso los cambios toman efecto inmediatamente y por tanto a partir de ese momento aquellos eventos habilitados para su envío utilizando el protocolo syslog comienzan a ser transmitidos en forma de mensajes syslog al darse las circunstancias que provocan la generación de esos eventos, siempre que se cumplan las restantes premisas requeridas: que esté habilitada la funcionalidad de cliente syslog, que el nivel de severidad establecido tenga un código numérico igual o superior al asociado al evento (en función de su logging-level), etc. ELS+enable syslog subsystem ppp all ELS+ Del mismo modo que se hacía desde el menú de configuración del SRE, también es posible deshabilitar dinámicamente la notificación mediante mensajes syslog de eventos individuales, subsistemas completos o grupos de eventos, con efecto inmediato: II - 17

*P 3 +event -- ELS Monitor -- ELS+disable? all Events as traps, syslog messages and on screen filter Enables events filtering snmp-trap Events as traps syslog Events as syslog messages trace Events on screen ELS+disable syslog? event An entire subsystem with a filter level groups An entire group subsystem An entire subsystem with a filter level ELS+ ELS+disable syslog subsystem ppp all ELS+ Para más información acerca de la forma de habilitar y deshabilitar eventos, subsistemas o grupos de eventos, o de las diferentes maneras en que pueden ser notificados, consúltese el manual Dm704 Configuración y Monitorización. II - 18

Capítulo 3 Monitorización

1. Monitorización de la facilidad syslog cliente Para acceder al menú de monitorización asociado a la facilidad syslog cliente se debe introducir el comando FEATURES SYSLOG en el menú de monitorización general (+). +features syslog -- SYSLOG client console -- SYSLOG+ Una vez que se ha accedido al entorno de monitorización del cliente syslog, se pueden introducir los comandos que se describen a continuación: Comando Función? (AYUDA) Lista los comandos u opciones disponibles. LIST Muestra información de monitorización del cliente syslog. EXIT Sale del menú de monitorización del cliente syslog. 1.1.? (AYUDA) Este comando se utiliza para listar los comandos válidos en el nivel donde se está programando el router. Se puede también utilizar este comando después de un comando específico para listar las opciones disponibles. SYSLOG+? SYSLOG+? list exit SYSLOG+ Show monitoring information 1.2. LIST Muestra información acerca de la configuración activa del cliente syslog, así como estadísticos relevantes. SYSLOG+list SYSLOG+list Syslog client active configuration: Syslog client status: ENABLED Facility: 16 (Local0) Severity: 3 (Error) III - 20

Source IP address: 10.65.23.25 Active syslog servers: IP address Domain name --------------- ----------- 0.0.0.0 pruebas.id.teldat.es 172.24.51.5 Syslog client statistics: Total number of transmitted messages: 0 Emergency messages: 0 Alert messages: 0 Critical messages: 0 Error messages: 0 Warning messages: 0 Notice messages: 0 Informational messages: 0 Debug messages: 0 Events with severity greater than established level: 6167 Lost messages due to buffer overflow: 0 SYSLOG+ Como puede observarse, al ejecutar el comando LIST desde el menú de monitorización del cliente syslog se muestran datos acerca de la configuración activa de dicha funcionalidad: Syslog client status: Si se ha habilitado o no la facilidad. Facility: Valor de la facilidad que se asocia a los mensajes syslog. Severity: Nivel de severidad establecido. Este valor se utiliza junto con el de la facilidad para calcular la prioridad de los mensajes syslog. Source IP address: Dirección IP origen con que salen los mensajes del equipo, si es que se ha configurado este parámetro (es decir, no toma el valor 0.0.0.0) si no se ha indicado esta dirección, los paquetes salen del router con dirección origen la del interfaz por el que son transmitidos. Si el equipo no tiene configurado un hostname, esa dirección es también la incluida en el campo [HOSTNAME] de los mensajes syslog originados. Servidores hacia los que se dirigen los mensajes enviados por el cliente. En el caso de servidores identificados por su nombre de dominio, si éste ha sido resuelto correctamente por alguno de los servidores DNS encargados de efectuar esta traducción (y que deben estar configurados en el equipo), la dirección IP obtenida se muestra junto a dicho nombre. Además se almacenan una serie de estadísticos: Número total de mensajes transmitidos, considerando los enviados a todos los servidores configurados. Número de eventos correspondientes a cada tipo de mensajes (en función de su severidad) que se han generado en el cliente. En este caso se contabiliza cada evento generado, no cada mensaje transmitido es decir, un mismo mensaje enviado a varios servidores incrementa en una unidad el contador asociado a su nivel de filtrado o severidad. Eventos cuyo nivel de severidad es mayor que el establecido (comparando sus códigos numéricos) y que por tanto no provocan el envío de un mensaje syslog a cada servidor configurado. Igual que en el caso anterior, se contabiliza cada evento producido, no cada mensaje que deja de ser transmitido. Número de eventos que no han podido ser notificados debido a la saturación del buffer donde se guardan los mensajes syslog en espera de ser enviados. Este contador se incrementa con cada mensaje perdido, independientemente del número de notificaciones que cada uno de ellos generaría según el número de servidores hacia los que deberían enviarse. III - 21

Si la funcionalidad de syslog cliente está deshabilitada no se generan mensajes, y por tanto todos estos estadísticos tomarán siempre el valor 0. 1.3. EXIT Mediante este comando se sale del menú de monitorización del cliente syslog y se retorna al menú principal de monitorización (+). SYSLOG+exit SYSLOG+exit + III - 22

Capítulo 4 Ejemplo

1. Ejemplo de configuración del cliente syslog En este apartado se presenta un ejemplo de configuración de la funcionalidad de cliente syslog: *config Config>show config Showing System Configuration for access-level 15... ATLAS Router 2 156 Version 10.7.1 log-command-errors no configuration set data-link astm serial0/0 set data-link x25 serial0/1 set data-link x25 serial0/2 time summer-time recurring 4 sun mar 02:00 4 sun oct 03:00 network ethernet0/0 -- Ethernet Interface User Configuration -- ip address 172.24.78.118 255.255.0.0 exit network x25-node -- X25-node interface configuration -- no ip address exit event -- ELS Config -- enable syslog event GW.001 enable syslog event GW.021 enable syslog event GW.023 enable syslog subsystem TCP ALL enable syslog subsystem UDP ALL enable syslog subsystem ARP ALL exit protocol ip -- Internet protocol user configuration -- route 0.0.0.0 0.0.0.0 172.24.0.98 exit feature ntp -- NTP Protocol user configuration -- protocol peer address 1 172.24.51.36 exit feature dns -- DNS resolver user configuration -- server 172.24.51.36 exit IV - 24

feature syslog -- SYSLOG client configuration -- enable buffer-size 60 facility local0 initial-delay 25 server pruebas.id.teldat.es server 172.24.51.5 severity error source-address 10.65.23.25 exit dump-command-errors end --- end --- Config> En este caso se ha establecido el nivel de severidad en error (3), lo que implica que son notificados como mensajes syslog aquellos eventos habilitados cuyo nivel de filtrado o logging-level sea UI- ERROR, CI-ERROR, UE-ERROR o CE-ERROR, además de los de tipo ALWAYS: en este ejemplo concreto se transmitirían mensajes syslog dirigidos hacia los servidores identificados por la dirección IP 172.24.51.5 y por el nombre de dominio pruebas.id.teldat.es (siempre que éste último haya sido previamente resuelto por alguno de los sevidores DNS configurados, en este caso el de dirección IP 172.24.51.36), mensajes generados al producirse las situaciones que dan origen a los eventos GW.001, GW.021, GW.023 y los pertenecientes a los subsistemas ARP, TCP y UDP cuyo tipo o nivel de filtrado sea uno de los anteriormente especificados. La facilidad empleada junto con el nivel de severidad de cada evento concreto para calcular el valor de la prioridad con que saldrá el mensaje correspondiente será local0 (16) y la dirección origen de los mensajes será la 10.65.23.25. Puesto que se han habilitado los eventos GW.001 y GW.021, que se producen al arrancar el equipo (el GW.001 indica el arranque del equipo y el GW.021 que un interfaz se ha levantado), para que esos eventos se transmitan correctamente y no se pierdan por el hecho de producirse antes de que el equipo haya terminado de inicializarse, se ha fijado un cierto retardo inicial antes de comenzar el proceso de lectura del buffer y transmisión de los mensajes en él almacenados pendientes de envío: 25 segundos. Recuérdese que si no se han habilitado estos eventos que se producen al inicio, no es necesario modificar el valor por defecto de este parámetro (initial-delay). También se ha cambiado el valor por defecto del tamaño del buffer de almacenamiento de los mensajes (60 en vez de los 50 mensajes que se pueden guardar por defecto), aunque como se comentó en el correspondiente apartado no suele ser necesario modificar dicho valor por defecto. En lo que respecta al resto de la configuración, señalar que es necesario configurar al menos un servidor DNS para resolver los nombres de dominio de los servidores syslog identificados de esa forma. El utilizar el protocolo NTP para averiguar la fecha y hora actuales no es necesario, ya que en caso de no habilitar esa funcionalidad se utilizaría el reloj local del equipo a la hora de construir el campo [TIMESTAMP] de los mensajes syslog, y lo mismo respecto a la corrección debida al horario de verano, configurada en el ejemplo para mayor generalidad. IV - 25