Monitoreo de redes. Ing. Diego Córdoba Pagina 1 de 6

Transcripción

1 Monitoreo de redes Ing. Diego Córdoba Pagina 1 de 6

2 Manejo de traps Hasta ahora hemos visto una arquitectura de polling, en la que instalamos una consola central de monitoreo de recursos de red, llamada NMS (Network Management System) y una serie de agentes en los equipos a monitorear, llamados nodos administrados. Hemos utilizado el protocolo SNMP por ser un protocolo libre y extendido, con gran documentación, implementaciones, y casos de uso. En esta arquitectura el agente snmp que corre en los equipos administrados mantiene una base de datos llamada MIB: Management Information Base, y en la que se estructuran de manera jerárquica, una serie de variables agrupadas en diferentes grupos según los datos o las características de la información que representan. La consola de monitoreo es la encargada de consultar periódicamente a los agentes snmp por ciertas y determinadas variables de interés, y luego almacena esta información en una base de datos centralizada. El NMS también es el encargado de generar gráficas, mapas y reportes en los que el administrador pueda apreciar a simple vista el estado de los recursos de la red que administra. En el caso de haber alguna excepción, que una variable se pase de cierto rango, o que se apague una interfaz de red, etc, es el NMS el encargado de darse cuenta el problema, para informar al administrador. Hay eventos cuyo cambio es muy poco frecuente, como puede ser, por ejemplo, una impresora que se queda sin papel, o un servicio estable deja repentinamente de atender. Para estos casos aislados, el tráfico de red que genera una consola de monitoreo por medio de polling puede llegar a ser molesto, y hasta perjudicial en cuanto a congestión de los enlaces de red. En esta oportunidad vamos a ver cómo podemos configurar un agente snmp para que informe, sin necesidad de ser consultado por un NMS, el valor de una variable, utilizando el mecanismo de traps en snmp. Utilizando traps, es el nodo administrado quien inicia el proceso, no la consola de monitoreo. Para el NMS el trap es un evento asíncrono enviado desde un agente snmp. Es un mecanismo que le permite al agente snmp disparar una alarma generada por alguna condición especial. El NMS al recibir este mensaje de trap, podría ejecutar una acción de respuesta, como por ejemplo, enviar un correo electrónico al administrador, o simplemente loguear el evento. Ing. Diego Córdoba Pagina 2 de 6

3 Gestión de traps en snmp Primero vamos a activar el demonio de traps para que pueda procesarlos. vim /etc/default/snmp: SNMPDRUN=no TRAPDRUN=yes Luego le seteamos el community de traps, y también seteamos una función manejadora de traps, que, como es nuestro caso, puede ser un script del bash: vim /etc/snmp/snmptrapd.conf authcommunity log,execute public traphandle default /root/script_trap.sh Y ahora deberíamos crear el script /root/script_trap.sh El mensaje de trap se compone de varias líneas de información, por ejemplo, un mensaje podría ser el siguiente: localhost UDP: [ ]:49070->[ ] SNMPv2-SMI::mib :0:33:53.88 SNMPv2-SMI::snmpModules SNMPv2-SMI::snmpModules SNMPv2-SMI::mib SNMPv2-SMI::snmpModules SNMPv2-SMI::snmpModules "public" SNMPv2-SMI::snmpModules SNMPv2-SMI::enterprises El script va a leer estas lineas como si se tratase de una entrada por la entrada estandar, o stdin, y para ello podríamos utilizar la función read de la siguiente forma: #!/bin/bash echo ">>>>>>> TRAP--" >> /tmp/traps while read line do echo $line >> /tmp/traps done echo "<<<<<<< TRAP--" >> /tmp/traps Deberíamos darle permisos de ejecución al script: chmod 755 script_trap.sh Y ahora, desde cualquier equipo, podemos enviarle un trap al agente capaz de procesarlos utilizando el comando snmptrap de la siguiente forma: snmptrap -v1 -c community-trap ip-nms enterprise-oid sender-ip generic-trap specific-trap uptime [OID Ing. Diego Córdoba Pagina 3 de 6

4 TYPE VALUE] Donde: ip-nms es la dirección ip o nombre del equipos nms que recibirá el trap. community-trap es el community seteado para el envío de traps en el archivo /etc/snmp/snmptrapd.conf enterprise-oid es el oid completo del trap que quiero enviar, por lo general en formato numérido. Puede omitirse. Sender-ip es la dirección ip del host que envía el trap. En el caso de omitir el parámetro, la dirección ip que almacenará el nms para este trap es la del emisor del paquete. Puede parecer superfluo el dato, pero si entre el sender y el nms tenemos un proxy, y omitimos este parámetro, en nms almacenará la dirección ip del proxy como si fuese el sender del trap. Si especificamos una dirección aquí, el nms tomará esta dirección, omitiendo la del sender del datagrama, y va a poder identificar la dirección ip de los nodos que estén enviando traps. Generic-trap Un número entre 0 y 6 que especifica el número de trap genérico de la siguiente tabla. 0-coldStart Indica que el agente fue reiniciado, que todas las variables de la MIB fueron reseteadas. Por defecto, un dispositivo que se enciende envía automaticamente este trap por anmp. 1-warmStart Indica que se reinicializó el agente, pero que no se resetearon las variables. 2-linkDown Se envía cuando una interfaz de dispositivo se cae (down) 3-linkUp Se envía cuando una interfaz de dispositivo se levanta (up) 4-authenticationFailure Se envía cuando se produce un error de autenticación en el agente snmp. Por ejemplo, cuando alguien trata de realizar una consulta al agente y especifica erróneamente el community de consulta. 5-egpNeighborLoss Indica que el protocolo de puerta de enlace exterior (EGP - Exterior Gateway Protocol) está en estado down. 6-EnterpriseSpecific Indica que el trap es un enterprise especific, y utiliza el otro valor numérico. Los fabricantes o usuarios suelen tener sus propios traps específicos que enviar. specific-trap especifica el trap especifico a enviar. Si se encuentra especificado el trap genérico, este se ignora Es el número específico de trap, por ejemplo, en el oid , el specific trap es Ing. Diego Córdoba Pagina 4 de 6

5 3003. uptime Marca de tiempo en la que se genera el trap. Puede ignorarse. [OID TYPE VALUE] Especifica el OID enviado en el trap, el tipo de valor, y el valor que estoy enviando para esa variable. Los tipos son los siguientes: i INTEGER u UNSIGNED c COUNTER32 s STRING x HEX STRING d DECIMAL STRING n NULLOBJ o OBJID t TIMETICKS a IPADDRESS b BITS Ejemplo de uso: snmptrap -v 1 -c public "" "" 2 0 "" IF-MIB::ifOperStatus.1 i 1 Donde: -v1 especifica la versión 1 del protocolo snmp -c public especifica el community de trap es la dirección ip del equipo que va a recibir el trap enterprise oid, se omite dirección ip del emisor del trap, también se omite 2 generic trap, en este caso, especifica un linkdown 0 especific trap, es 0 porque al haber enviado un generic trap, este parámetro se omite uptime, también se omite IF-MIB::ifOperStatus.1 es el oid de la variable que estoy informando con el trap, la interfaz específica i es el tipo de valor a informar, en este caso, un INTEGER 1 es el valor a informar para la variable ifoperstatus.1. Este comando envía un trap al equipos que tiene configurado un handler para manejarlo, y este handler en nuestro caso solamente escribe el contenido del trap en el archivo /tmp/trap: tuta2 UDP: [ ]:44201->[ ] iso :23:58:11.70 iso iso iso iso #oid de la variable, y su valor #dirección ip del sender Ing. Diego Córdoba Pagina 5 de 6

6 iso "public" iso iso <<<<<<< TRAP #community utilizado para el trap Ejemplo de configuración de un handler de traps en un NMS: JFFNMS Para configurar a jffnms para que reciba traps, primero tenemos que crear un nuevo tipo de evento. Para ello vamos a la consola de Administración, hacemos clic en Internal Configuration -> Event Analyzer y luego en Event Types. En la pantalla veremos los tipos de eventos definidos. Deberemos crear uno nuevo haciendo clic en Add. Para fines prácticos no es necesario modificar ningún campo. Únicamente copiar el ID del nuevo evento ya que lo usaremos luego. En nuestro caso, el ID es Deberemos crear un poller backend para que administre las alarmas de nuestro evento. Para ello, en la consola de administración, hacemos clic en Internal Configuration -> Polling & Discovery -> Poller Backends. Al crear el poller backend, primero vamos a especificarle una descripción genérica del poller. En el campo de comando (Poller Command) vamos a decirle que ejecute un evento especificando event, y para indicarle el tipo de evento particular, en el campo de parámetro vamos a pasarle el ID del tipo de evento que creamos previamente, es decir, Acto seguido, ya tenemos el evento creado, y el poller backend que va a utilizarlo, solo nos resta crear un receptor de traps para jffnms. Para ello vamos a la consola de administración nuevamente, dentro de Internal Configuration -> Event Analyzer tenemos la opción SNMP Trap Receivers. Luego de haber seteado el trap receiver, ya está listo nuestro jffnms para recibir traps!! Nos resta solamente configurar el demonio de recepción de traps del snmp para indicarle que el handler que va a recibir los traps es un script de jffnms. vim /etc/snmp/snmptrapd.conf traphandle default /usr/share/jffnms/engine/trap_receiver.sh A este punto ya tenemos perfectamente configurado nuestro JFFNMS para trabajar los traps, y el demonio de traps snmptrapd configurado con el handler del jffnms, con lo cual, ahora si enviamos un trap al NMS, éste deberia procesarlo, en el caso de jffnms, lo mostrará como un evento. Ing. Diego Córdoba Pagina 6 de 6