Sistema de monitorización open nms

7,866 views

Published on

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
7,866
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
264
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Sistema de monitorización open nms

  1. 1. Proyectos Multidisciplinares de las TIC-II. Máster en Telecomunicación 2012-2013.Autor: Julio Jornet Monteverde. 1
  2. 2. Índice de contenido.1. INTRODUCCIÓN. ............................................................................................................................ 3 1.1. SISTEMAS DE MONITOREO CON O SIN AGENTES .......................................................................................... 32. EL PROYECTO OPENNMS................................................................................................................. 53. FUNCIONALIDADES ........................................................................................................................ 6 3.1. GESTIÓN DE EVENTOS Y ALARMAS ........................................................................................................... 6 3.1.1. Recolección de Eventos ............................................................................................................ 6 3.1.2. Correlación de Alarmas ........................................................................................................... 7 3.1.3. Notificaciones de Usuario y Escalados Programados .............................................................. 9 3.1.4. Integración de Trouble Tickets ................................................................................................. 9 3.2. RENDIMIENTO Y GESTIÓN DE SLAS ........................................................................................................ 10 3.2.1. Rendimiento y Gestión de recolección de datos .................................................................... 10 3.2.2. Visualización de Datos ........................................................................................................... 10 3.2.3. Gestión de SLAs ..................................................................................................................... 11 3.3. INTEGRACIÓN Y GESTIÓN DE CONFIGURACIÓN ......................................................................................... 11 3.3.1. Configuración unificada ........................................................................................................ 11 3.3.2. Descubrimiento de la Red ...................................................................................................... 12 3.3.3. Configuración de Interfaces ................................................................................................... 13 3.3.4. Integración............................................................................................................................. 14 3.4. POLLER REMOTO ................................................................................................................................ 154. ARQUITECTURA ........................................................................................................................... 15 4.1. MEJORAS VERSIÓN 2.0. ....................................................................................................................... 165. IMPLEMENTACIÓN EN SPED.......................................................................................................... 176. OTROS SISTEMAS DE GESTIÓN DE RED .......................................................................................... 19 6.1. NAGIOS ............................................................................................................................................. 19 6.1.1. Características y funcionalidades .......................................................................................... 20 6.1.2. Funcionalidades básicas ........................................................................................................ 20 6.1.3. Estructura .............................................................................................................................. 217. BIBLIOGRAFÍA Y REFERENCIAS ...................................................................................................... 22 2
  3. 3. 1. Introducción.OpenNMS es una de las alternativas libres más destacadas para realizar tareas deadministración y gestión de redes, bajo sistemas Linux. Esta poderosa herramienta,incorpora un paquete de funciones, que permiten controlar por completo todo el tráfico dedatos que se transmite a través de la red. OpenNMS es una aplicación fácil de utilizar.Podemos manipular cada una de las características de la red, así como, analizar y detallarcada uno de los archivos que se transfieren, y realizar una serie de tareas de gestión y deconexiones de red.Este software realiza un análisis de cada una de las conexiones entrantes y salientes denuestra red, con el principal objetivo de verificar si existen conexiones no autorizadas.También, genera reportes completos de gestión, para documentar cada una de lassituaciones que se presenten en la red. Cuenta con una licencia de funcionamiento GPL.OpenNMS es una plataforma de gestión de red de nivel empresarial desarrollada en elmarco del modelo de código abierto. A diferencia de los productos de gestión de red queestán muy centrados en los elementos de red tales como los interfaces switches y routers,OpenNMS se centra en los recursos de red que ofrecen servicios: páginas web, acceso abases de datos, DNS, DHCP, etc (aunque la información sobre elementos de la redtambién está disponible ).Como la mayoría de los servicios de red se proporcionan a través del protocolo TCP / IP,OpenNMS está muy centrado en el nivel IP. El elemento básico de monitorización sellama "interfaz", y una interfaz se identifica por una dirección IP. Los servicios se asignana las interfaces, y si una serie de interfaces que se descubren pertenecen al mismodispositivo (ya sea a través de SNMP o SMB), éstas pueden agruparse juntas en un"nodo".1.1. Sistemas de monitoreo con o sin agentesEl agente de un sistema de monitoreo es un componente de software. Generalmente esuna pequeña aplicación que reside en el cliente y recoge datos. Los datos se envían alservidor central de la aplicación en base a 2 opciones. La primera opción es que el envíode datos sea administrado por el agente local, o este sea administrado por la estación de 3
  4. 4. monitoreo central.Los sistemas que tienen la política de envío de información al servidor administrada por elagente ubicado en el cliente, tienen como desventaja que pueden generar cargas detrabajo en los equipos clientes. Por lo tanto es deseable que las políticas de envío deinformación sean administradas por el servidor y no por el agente.En la tabla 1 se expone un cuadro de ventajas y desventajas de sistemas con agentes ysistemas sin agentes. Sistemas con agentes • Información más específica y más detallada. • Mayor flexibilidad para realizar monitoreos personalizable. • Posibilidad de crear soluciones de monitoreos que controlen estados de servicios o métricas no estándares sobre aplicaciones o hardware. Ventajas • El control de las aplicaciones y servicios se realiza directamente en el nodo monitoreado. • Mayor seguridad en la red ya que se manejan protocolos propietarios de encriptación. • Menor riesgo de detección de inactividades. • Puede provocar mayor carga de actividad en el cliente Desventajas • Se debe instalar el agente en todos los equipos que se van a monitorear. Sistemas sin agentes • No hay que instalar el agente en el cliente • No se genera carga de trabajo en el cliente Ventajas • Es una opción para casos en los que no es posible instalar aplicaciones en los clientes • Tiene métricas menos especificas por consiguiente se pueden realizar análisis menos detallados. • Pueden ser afectadas por hechos que sucedan en la Desventajas red. • El desarrollo de complementos puede ser mas complicado, o directamente imposibles de realizar. • No son seguros. Tabla 1: Ventajas y desventajas de los agentes en sistemas de monitoreo.Las soluciones basadas en agentes instalados en el cliente brindarán acceso a másinformación y con métricas más detalladas, este hecho puede ser importante paradisminuir el tiempo de detección de fallos, mientras que soluciones sin agentes lepermiten al fabricante evitar la etapa de desarrollo del agente pero con el riesgo de 4
  5. 5. obtener menos datos y en un entorno menos seguro. En base a lo expuesto, y teniendoen cuenta las ventajas y desventajas ya nombradas anteriormente de ambas solucionesse agrega como requerimiento no funcional la característica de tener en su estructura eluso de un agente en el cliente.2. El Proyecto OpenNMSComo ya se ha comentado, OpenNMS es un sistema de gestión de red orientado aagente, y es la primera plataforma desarrollada bajo código abierto, GPL.Está escrito en Java y por lo tanto es portable a todas las plataformas del mercado,Windows, Linux, Sun, Unix, etc. Su escalabilidad en los sistemas ha sido probada, pruebade ello son los resultados obtenidos: 300.000 puntos de datos cada 5 minutos y detecciónautomática de nodos centrales con más de 5000 interfaces.Existe una amplia comunidad de usuarios comerciales que utilizan OpenNMS en sussistemas, tales como: Swisscom, MySpace, Foxtel, Fox TV, BBC Monitoring, WindTelecomunications.La comunidad OpenNMS es muy activa y existen cerca de 1000 usuarios activossubscritos en las listas de discusión. En la actualidad tienen unos 35 desarrolladores conacceso a los repositorios. La comunidad está gestionada por la Orden del Polo Verde(OGP). Todos los miembros de dicha orden tienen un voto en la dirección del proyecto y 5
  6. 6. no existen restricciones de acceso.La licencia es del tipo GPL y la propiedad intelectual así como la marca es propiedad delGrupo OpenNMS. El objetivo del grupo es promover el proyecto.3. FuncionalidadesOpenNMS está dividido en una serie de funcionalidades que cumplen con unasdeterminadas características.3.1. Gestión de Eventos y Alarmas3.1.1. Recolección de EventosOpenNMS puede registrar todo tipo de eventos ocurridos: Trigers, evaluación de eventos,automatización de acciones en función del procesado de la tabla de alarmas.Los Nodos Pasivos se utilizan para representar servicios o recursos gestionados por otroagente. Existen dos procesos llamados Event Translator y Pasive Status que permiten alos eventos mapearse a estos nodos.El proceso Actiond se utiliza para generar acciones Java basados en la recepción deeventos. También se pueden enviar los eventos que se deseen via XML-RPC a otrosistema de gestión remoto. 6
  7. 7. Los eventos se controlan con el proceso Eventd el cual recibe y graba toda la información.Este proceso escucha el puerto 5817 por el cual los demás procesos envían peticiones eincluso se pueden enviar desde sistemas externos a OpenNMS. Listado de Eventos3.1.2. Correlación de AlarmasSe utiliza un mecanismo de Alarma para manejar traps de recolección de alarmas o trapsde anulación de alarmas en un entorno de gestión de alarmas cíclico. Cuando se recibe 7
  8. 8. por primera vez un trap o disparo se recoge una alarma. Si se reciben sucesivos traps,éstos se contarán en la misma alarma. Si se reconoce la alarma, se provocará un trap delimpieza de la alarma y ésta desaparecerá quedando el sistema preparado para recibir unnuevo evento. Este mecanismo de utilización es el más simple en un listado de alarmas.El usuario también puede configurar reglas más sofisticadas de tratamiento de eventos dealarmas incluso automatizándolo en función de un sofisticado análisis ya que posee unmotor de reglas. Listado de Alarmas Detalle de Alarma 8
  9. 9. 3.1.3. Notificaciones de Usuario y Escalados ProgramadosOpenNMS soporta múltiples usuarios y proporciona un mecanismo de Escalado deNotificaciones entre los usuarios. Si se detecta un evento severo, como una alarmaMayor, este mecanismo generará una Notificación que se escalará en el tiempo a travésde una lista de usuarios si la alarma no se reconoce en un periodo de tiempo definido porel usuario. El sistema también puede generar un sonido, un email o un mensajeinstantáneo para llamar la atención sobre la notificación. También existen mecanismos denotificación tales: - XMPP: Jabber, un protocolo de mensajería instantánea. - Programas externos - Traps SNMPs - HTTP GET/POST hacia una web site.Se pueden definir grupos de usuarios y roles a los cuales se les puede asociar cuentasemail genéricas. Listado de Notificaciones3.1.4. Integración de Trouble TicketsSi el mecanismo de escalado básico no es suficiente, OpenNMS también dispone de unainterface Trouble Ticket para integrarlo en el sistema con un número de incidencia. 9
  10. 10. 3.2. Rendimiento y Gestión de SLAs3.2.1. Rendimiento y Gestión de recolección de datosComo en otras herramientas de gestión de redes tales como Nagios o Cricket, OpenNMSalmacena datos en ficheros RRD. Se puede utilizar la herramienta RRD para hacer larecolección de datos pero la librería preferida es JRobin la cual es una implementaciónJava de RRD.OpenNMS ya lleva implementada una MIBS (base de datos SMNP) que soporta la granmayoría de fabricantes de equipamiento, pero los usuarios pueden definir sus propiasconfiguraciones. La comunidad de usuarios suelen compartir estos trabajos y susexperiencias con los nuevos equipos.Sin embargo, a diferencia de estas herramientas, toda la programación de la recolecciónde datos se controla totalmente por un proceso Java dentro de OpenNMS el cual haceque la solución sea muy escalable.Los datos pueden recogerse desde varias fuentes distintas: sondeo SNMP, traps degestión, mensajes ASCII tipo syslog, TL1, JMX. También existe una integración conNagios que permite la utilización de plugins de Nagios. OpenNMS también se haintegrado con SNORT.3.2.2. Visualización de DatosOpenNMS presenta los datos de rendimiento en forma de gráficos. Estos gráficos tambiénse pueden exportar en forma de informes de rendimiento.También se pueden definir umbrales que generan alarmas cuando hay cambios en losdatos. OpenNMS puede realizar transacciones sintéticas para comprobar la disponibilidadde servicios en los nodos. Esto se puede realizar de una manera centralizada o con unconjunto de rollers distribuidos remotamente. 10
  11. 11. 3.2.3. Gestión de SLAsSe pueden definir umbrales en los SLAs que generarán una alarma en cuanto se rebaseny pueden escalarse en función de las reglas definidas. A cada punto de recolección dedatos de rendimiento se le puede asignar dos umbrales, uo superior y otro inferior, paraevitar los rebotes de alarmas.3.3. Integración y Gestión de Configuración3.3.1. Configuración unificadaToda la configuración de OpenNMS está almacenada en archivos XML y se encuentradentro de un directorio. Muchas de estas configuraciones también se exponen en lainterface de usuario. Las configuraciones incluyen los tiempos de barrido, mapeado detraps del tipo eventos/alarmas, gestión de MIBs, etc. 11
  12. 12. 3.3.2. Descubrimiento de la RedDado un rango de direcciones, OpenNMS puede descubrir por si mismo los elementos yservicios dentro de una red. Automáticamente asocia puertos con nodos. La nomenclaturapor defecto de un nodo en la base de datos se rellenará con el nombre del dispositivodetectado por un escaneo SNMP del dispositivo.El proceso responsable de la tarea de detectar los servicios es Capsd y es capaz dedetectar los siguientes servicios: - Citrix - DHCP - DNS - Domino IIOP - FTP - General Purpose (script based) - HTTP - HTTPS - ICMP - IMAP - JBOSS (JMX) - JDBC - JDBC Stored Procedure - JSR160 - K5 - LDAP - Microsoft Exchange - MX4J - Notes HTTP - NSClient (Nagios Agent) - NRPE (Nagios Remote Plugin Executor) - NTP - POP3 - Radius - SMB - SMTP - SNMP - SSH - TCP - Windows Services (SNMP-based)Es posible importar la configuración de los servicios con un fichero tipo XML. Estaconfiguración deshabilitará los procesos de descubrimiento por medio de barridos ping. Elproceso Capsd es el responsable de descubrir todos los servicios a monitorizar sobre undispositivo. Recopila y almacena datos de diversas fuentes, incluyendo SNMP, JMX,HTTP y NSClient.Si el dispositivo tiene implementado SMNP, entonces es capaz de manejar todos los 12
  13. 13. servicios interrogando y registrando los tiempos de respuesta utilizando transaccionessintéticas.3.3.3. Configuración de InterfacesTambién se pueden utilizar archivos XML conteniendo la configuración de las interfaces yasí modificar el nombre y el inventario de la Red. Como ejemplo podemos comentar queesta interfaz la utiliza Swisscom para sincronizar OpenNMS con su red WIFI Europea deHotspots.OpenNMS implementa un mecanismo de provisionamiento automático que está integradocon el sistema RANCID (RANCID – Really Awesome New Cisco confIg Differhttp://www.shrubbery.net/rancid/), y también con PUPPET.(http://reductivelabs.com/trac/puppet). Ejemplo de Porvisionamiento Manual Ejemplo de Provisionamiento externo con XML 13
  14. 14. 3.3.4. IntegraciónOpenNMS posee numerosos puntos de integración para la paginación, sonidos dealarmas, email, tratamiento de tickets/incidencias, etc.El sistema está preparado para utilizar mapas para mostrar la topología de la red tal ycomo se refleja a continuación. 14
  15. 15. 3.4. Poller RemotoOpenNMS implementa una funcionalidad para poder realizar interrogaciones desdepuestos remotos. El cliente remoto se conecta al servidor OpenNMS y se descarga elplugin Remote Poller utilizando el Java Web Start. Una vez ejecutándose, el plugininterroga los servicios de los nodos centrales utilizando transacciones sintéticas. Una vezse tienen los resultados, se envían al servidor OpenNMS.4. ArquitecturaA continuación se muestra un diagrama de bloques de la arquitectura OpenNMS: 15
  16. 16. El sistema tiene una serie de APIs que son las siguientes: • API Servicio Detector: Detección de Servicios, Interface Java. • API Servicio Monitor: Plugin Poller para monitorizar los servicios detectados, Interface Java. • API Servicio Recolección: Plugin Collectd para crear los recolectores de datos de rendimiento. Interface Java. • API Servicio Thesholder: Plugin para crear umbrales de servicios detectados. Interface Java. • API Notificaciones estratégicas: Plugin para crear nuevos métodos de notificación. Interface Java. • API Reconocimiento: Plugin para leer las respuestas a las notificaciones. Interface Java. • API Provisión Adaptador: Plugin para la integración de CMS, EMS, sistemas de inventariado, etc. Interface Java.A continuación se muestra un ejemplo de cómo se comunican los procesos internos:4.1. Mejoras versión 2.0. - En la parte de provisionamiento se ha implementado una nueva arquitectura con un modo de descubrimiento de servicios y recursos en paralelo. - La interfaz de usuario se ha actualizado a un entorno Web (AJAX) 16
  17. 17. - Se ha mejorado el flujo de trabajo de las Alarmas y del Escalado. - Se ha implementado una API REST para poder acceder utilizando tecnologías web (Pearl, python, etc). - Se han implementado seguridad en las Listas de Control de Acceso a Usuarios (ACLs) permitiendo una granularidad fina del control de usuarios. - También se han reducido el número de reinicios requeridos en el sistema por cambios en la configuración. - Se ha implementado un módulo de soluciones de tolerancia a fallos.5. Implementación en SPEDTal y como se ha planteado el Sistema de Prevención, Extinción de incendios forestales yDetección de plantaciones irregulares (SPED), y una vez analizado en profundidad elfuncionamiento del sistema OpenNMS, podemos implementarlo para controlar y gestionarnuestros servidores de datos, servidores de grabación de imágenes y hasta en nuestrosdispositivos concentradores o routers Meshlium Xtreme ya que tienen un SO basado enLinux y por lo tanto podemos cargar el agente OpenNMS.El hecho de que podamos implementar OpenNMS en los routers Meshlium tambiénimplica que podamos supervisar las interfaces de éste y por ello nuestra red detransmisión compuesta de enlaces punto-punto o punto-multipunto.En cuanto a los Motes, no podemos utilizar el sistema OpenNMS ya que estosdispositivos están configurados para utilizar la tecnología ZigBee como medio decomunicación hasta el router y todavía no está soportado Zigbee en OpenNMS. Además,existe una restricción que hace que los Motes no puedan implementar un agente y es queel software de control está especialmente diseñado para tener un bajo consumo. Estoconlleva a que el Mote esté la mayor parte del tiempo en modo suspensión y solamentese despierte para enviar los valores de los sensores y para notificar al coordinador de suexistencia. También tenemos la limitación de la memoria ya que estos dispositivos tienenmuy poca memoria.Existe un modelo de Mote que implementa un interface WIFI para la comunicación y quenos permitiría gestionar en parte dicha comunicación con OpenNMS, pero el consumo sedispararía y ya no sería viable ya que los requerimientos de energía conllevarían unamayor batería y placa solar mayor. 17
  18. 18. Existe un SO que se ha diseñado para los dispositivos ZigBee y es el TinyOS que se tratade un sistema operativo de código abierto y el cual nos brindaría la posibilidad deimplementar un pequeño agente con su propia MIB dentro del módulo de comunicaciónZigBee, pero hay que tener en cuenta que la filosofía de gestión de OpenNMS es quequien realiza el Polling es el gestor OpenNMS hacia los dispositivos e interfaces y pordiseño esto no es operativo ya que la gran mayoría de veces nuestro Mote estaría ensuspensión. La idea a trabajar sería implementar la comunicación en sentido contrario, esdecir, quien inicia el polling debe ser nuestro dispositivo ZigBee para anunciar suexistencia al router coordinador y éste como sí que tiene implementado el agenteOpenNMS será el que controlará los tiempos de respuesta y demás datos.Una futura línea de investigación sería evaluar y probar todas las ideas expuestas ya quelos Motes son dispositivos muy versátiles y además existe software de código abierto queabre un sinfín de posibilidades. 18
  19. 19. 6. Otros Sistemas de Gestión de RedComo ya se ha mencionado en apartados anteriores, otro de los sistemas demonitorización es Nagios. Es el más popular en lo que a sistemas de monitorización decódigo abierto se refiere y se ha establecido como un estándar de facto.6.1. NagiosNagios es una popular herramienta de monitorización de servicios de red y dispositivos.Administradores de sistemas de todo el mundo dependen de Nagios y de su galería deplugins para mantener sus sistemas en funcionamiento y detectar los problemas antes deque ocurran. Pero Nagios tiene un par de problemas: - Nagios carece de un soporte adecuado para entornos de gran magnitud, así como de técnicas corporativas contemporáneas como pueda ser el clustering. - El código base en C de Nagios, con diez años de antigüedad, presenta limitaciones a la hora de adaptarlo a la rápida evolución de las redes de hoy en día.Existe una evolución de Nagios que soluciona los dos problemas mencionados y se tratade Shinken. El objetivo de Shinken es el de proporcionar un nuevo modelo multi-procesodistribuido que se adapte bien a entornos distribuidos y heterogéneos. El proyectoShinken se encuentra en una fase temprana y falta implementar más funcionalidades. Elobjetivo es asegurar una compatibilidad absoluta entre sus archivos y los de Nagios. 19
  20. 20. 6.1.1. Características y funcionalidadesNagios marca el estándar en la industria de monitoreo a grandes niveles por unas cuantasrazones. Este permite controlar la red informática y solucionar problemas antes que losusuarios los detecten. Nagios es un sistema estable, escalable, con soporte y extensible.Este sistema permite monitorear una importante cantidad de dispositivos y sistemas comopor ejemplo: Sistemas Operativos Windows, Sistemas Operativos Linux/Unix, Routers,Switches, Firewalls, Impresoras, Servicios y Aplicaciones.NAgios cuenta con una muy importante cantidad de addons desarrollados por lacomunidad (más de 200) que permiten extender las funcionalidades del sistema. Es unsoftware de código abierto, con acceso completo al código fuente, liberado bajo licenciaGPL.Nagios es un sistema que cuenta con más de 10 años en desarrollo, es un sistema quepermite escalar hasta monitorear más de 100,000 nodos, cuenta con gran reconocimiento,ganador de múltiples premios. Actualmente cuenta con más de 250.000 usuariosalrededor del mundo. Tiene una lista de correos activa y una amplia comunidad a travésdel website.6.1.2. Funcionalidades básicasSe destacan las siguientes características de funcionamiento: 20
  21. 21. • Enviar de forma inmediata notificaciones de problemas vía email, pager o teléfonos celulares. • Capacidad de notificar a múltiples usuarios. • Uso de su interfase web que permite ver información detallada de los estados de los distintos componentes, reconocer problemas de forma rápida. • Permite reiniciar automáticamente aplicaciones que hayan fallado, servicios y equipos. • Permite agendar actualizaciones de hosts, servicios y componentes de la red. • Permite planificar las capacidades de los componentes a través del monitoreo. • Permite generar reportes de disponibiidad SLA (Service Level Agreements), y reportes históricos de alertas y notificaciones. Además permite ver las tendencias de los informes a través de la integración con Cactus y RRD. • Múltiples usuarios pueden acceder a la interfase web, además cada usuario puede tener una vista única y restringida.6.1.3. EstructuraNagios tiene las siguientes características principales en cuanto a su estructura: • El sistema cuenta con un núcleo que forma la lógica de control de negocio de la aplicación, este contiene el software necesario para realizar la monitorización de los servicios y de las máquinas de la red. • El sistema hace uso de diversos componentes que ya vienen en el paquete de instalación con la aplicación, y puede hacer uso de otros componentes realizados por terceras personas. • El autor sostiene que aunque permite la captura de paquetes SNMP para notificar sucesos, pero no es un sistema de monitorización y gestión basado en SNMP, sino que realiza su labor basándose en una gran cantidad de pequeños módulos software que realizan chequeos de partes de la red. • Muestra los resultados de la monitorización y del uso de los diversos componentes en una interfaz web a través de un conjunto de CGI’s y de un conjunto de páginas HTML que vienen incorporadas, y que permiten al administrador una completa visión de lo qué ocurre, en dónde ocurre y en algunos casos el por qué ocurre. 21
  22. 22. • Por último, si se compila para ello, Nagios guardará los históricos en una base de datos para que al detener y reanudar el servicio de monitorización, todos los datos sigan sin cambios. • Nagios permite monitorizar sistemas Windows mediante la instalación de un agente en la máquina a monitorizar, aunque la parte servidor de Nagios debe residir en un servidor Unix/Linux.7. Bibliografía y Referencias - Proyecto SIGNA, Aplicaciones de Monitoreo. Estudio de alternativas de código abierto. - Introduction to OpenNMS. Craig Gallen, 2009. - Desarrollo de un entorno para configuración y monitorización de redes Zigbee. Proyecto Fin de Carrera, Sergio Lillo Moreno. - Informe Técnico: Protocolo ZigBee (802.15.4). Javier Martín y Daniel Ruiz. Junio 2007. - http://www.libelium.com/development/waspmote - http://www.opennms.org/ - http://www.nagios.org/ 22

×