Proyectos Multidisciplinares de las TIC-II.

Máster en Telecomunicación 2012-2013.

Autor: Julio Jornet Monteverde.

1
Índice de contenido.

1. INTRODUCCIÓN. ............................................................................................................................ 3
1.1. SISTEMAS DE MONITOREO CON O SIN AGENTES .......................................................................................... 3
2. EL PROYECTO OPENNMS................................................................................................................. 5
3. 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 ................................................................................................................................ 15
4. ARQUITECTURA ........................................................................................................................... 15
4.1. MEJORAS VERSIÓN 2.0. ....................................................................................................................... 16
5. IMPLEMENTACIÓN EN SPED.......................................................................................................... 17
6. 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 .............................................................................................................................. 21
7. BIBLIOGRAFÍA Y REFERENCIAS ...................................................................................................... 22

2
1. Introducción.
OpenNMS es una de las alternativas libres más destacadas para realizar tareas de
administració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 de
datos 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 detallar
cada uno de los archivos que se transfieren, y realizar una serie de tareas de gestión y de
conexiones de red.

Este software realiza un análisis de cada una de las conexiones entrantes y salientes de
nuestra 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 las
situaciones 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 el

marco del modelo de código abierto. A diferencia de los productos de gestión de red que
está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 a
bases de datos, DNS, DHCP, etc (aunque la información sobre elementos de la red
tambié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 se
llama "interfaz", y una interfaz se identifica por una dirección IP. Los servicios se asignan
a las interfaces, y si una serie de interfaces que se descubren pertenecen al mismo
dispositivo (ya sea a través de SNMP o SMB), éstas pueden agruparse juntas en un
"nodo".

1.1. Sistemas de monitoreo con o sin agentes

El agente de un sistema de monitoreo es un componente de software. Generalmente es

una pequeña aplicación que reside en el cliente y recoge datos. Los datos se envían al
servidor central de la aplicación en base a 2 opciones. La primera opción es que el envío
de datos sea administrado por el agente local, o este sea administrado por la estación de

3
monitoreo central.

Los sistemas que tienen la política de envío de información al servidor administrada por el
agente ubicado en el cliente, tienen como desventaja que pueden generar cargas de
trabajo en los equipos clientes. Por lo tanto es deseable que las políticas de envío de
informació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 y

sistemas 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ás

información y con métricas más detalladas, este hecho puede ser importante para
disminuir el tiempo de detección de fallos, mientras que soluciones sin agentes le
permiten al fabricante evitar la etapa de desarrollo del agente pero con el riesgo de

4
obtener menos datos y en un entorno menos seguro. En base a lo expuesto, y teniendo
en cuenta las ventajas y desventajas ya nombradas anteriormente de ambas soluciones
se agrega como requerimiento no funcional la característica de tener en su estructura el
uso de un agente en el cliente.

2. El Proyecto OpenNMS
Como ya se ha comentado, OpenNMS es un sistema de gestión de red orientado a
agente, 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, prueba
de ello son los resultados obtenidos: 300.000 puntos de datos cada 5 minutos y detección
automática de nodos centrales con más de 5000 interfaces.

Existe una amplia comunidad de usuarios comerciales que utilizan OpenNMS en sus
sistemas, tales como: Swisscom, MySpace, Foxtel, Fox TV, BBC Monitoring, Wind
Telecomunications.

La comunidad OpenNMS es muy activa y existen cerca de 1000 usuarios activos

subscritos en las listas de discusión. En la actualidad tienen unos 35 desarrolladores con
acceso 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
no existen restricciones de acceso.

La licencia es del tipo GPL y la propiedad intelectual así como la marca es propiedad del
Grupo OpenNMS. El objetivo del grupo es promover el proyecto.

3. Funcionalidades
OpenNMS está dividido en una serie de funcionalidades que cumplen con unas
determinadas características.

3.1. Gestión de Eventos y Alarmas

3.1.1. Recolección de Eventos

OpenNMS 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 otro
agente. Existen dos procesos llamados Event Translator y Pasive Status que permiten a
los eventos mapearse a estos nodos.

El proceso Actiond se utiliza para generar acciones Java basados en la recepción de

eventos. También se pueden enviar los eventos que se deseen via XML-RPC a otro
sistema de gestión remoto.

6
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 e
incluso se pueden enviar desde sistemas externos a OpenNMS.

Listado de Eventos

3.1.2. Correlación de Alarmas

Se utiliza un mecanismo de Alarma para manejar traps de recolección de alarmas o traps
de anulación de alarmas en un entorno de gestión de alarmas cíclico. Cuando se recibe

7
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 de
limpieza de la alarma y ésta desaparecerá quedando el sistema preparado para recibir un
nuevo 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 de
alarmas incluso automatizándolo en función de un sofisticado análisis ya que posee un
motor de reglas.

Listado de Alarmas

Detalle de Alarma

8
3.1.3. Notificaciones de Usuario y Escalados Programados
OpenNMS soporta múltiples usuarios y proporciona un mecanismo de Escalado de
Notificaciones entre los usuarios. Si se detecta un evento severo, como una alarma
Mayor, este mecanismo generará una Notificación que se escalará en el tiempo a través
de una lista de usuarios si la alarma no se reconoce en un periodo de tiempo definido por
el usuario. El sistema también puede generar un sonido, un email o un mensaje
instantáneo para llamar la atención sobre la notificación. También existen mecanismos de
notificació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 cuentas
email genéricas.

Listado de Notificaciones

3.1.4. Integración de Trouble Tickets

Si el mecanismo de escalado básico no es suficiente, OpenNMS también dispone de una
interface Trouble Ticket para integrarlo en el sistema con un número de incidencia.

9
3.2. Rendimiento y Gestión de SLAs

3.2.1. Rendimiento y Gestión de recolección de datos

Como en otras herramientas de gestión de redes tales como Nagios o Cricket, OpenNMS
almacena datos en ficheros RRD. Se puede utilizar la herramienta RRD para hacer la
recolección de datos pero la librería preferida es JRobin la cual es una implementación
Java de RRD.

OpenNMS ya lleva implementada una MIBS (base de datos SMNP) que soporta la gran
mayoría de fabricantes de equipamiento, pero los usuarios pueden definir sus propias
configuraciones. La comunidad de usuarios suelen compartir estos trabajos y sus
experiencias con los nuevos equipos.

Sin embargo, a diferencia de estas herramientas, toda la programación de la recolección

de datos se controla totalmente por un proceso Java dentro de OpenNMS el cual hace
que la solución sea muy escalable.

Los datos pueden recogerse desde varias fuentes distintas: sondeo SNMP, traps de
gestión, mensajes ASCII tipo syslog, TL1, JMX. También existe una integración con
Nagios que permite la utilización de plugins de Nagios. OpenNMS también se ha
integrado con SNORT.

3.2.2. Visualización de Datos

OpenNMS presenta los datos de rendimiento en forma de gráficos. Estos gráficos también
se pueden exportar en forma de informes de rendimiento.

También se pueden definir umbrales que generan alarmas cuando hay cambios en los
datos. OpenNMS puede realizar transacciones sintéticas para comprobar la disponibilidad
de servicios en los nodos. Esto se puede realizar de una manera centralizada o con un
conjunto de rollers distribuidos remotamente.

10
3.2.3. Gestión de SLAs
Se pueden definir umbrales en los SLAs que generarán una alarma en cuanto se rebasen
y pueden escalarse en función de las reglas definidas. A cada punto de recolección de
datos de rendimiento se le puede asignar dos umbrales, uo superior y otro inferior, para
evitar los rebotes de alarmas.

3.3. Integración y Gestión de Configuración

3.3.1. Configuración unificada

Toda la configuración de OpenNMS está almacenada en archivos XML y se encuentra
dentro de un directorio. Muchas de estas configuraciones también se exponen en la
interface de usuario. Las configuraciones incluyen los tiempos de barrido, mapeado de
traps del tipo eventos/alarmas, gestión de MIBs, etc.

11
3.3.2. Descubrimiento de la Red
Dado un rango de direcciones, OpenNMS puede descubrir por si mismo los elementos y
servicios dentro de una red. Automáticamente asocia puertos con nodos. La nomenclatura
por defecto de un nodo en la base de datos se rellenará con el nombre del dispositivo
detectado por un escaneo SNMP del dispositivo.

El proceso responsable de la tarea de detectar los servicios es Capsd y es capaz de

detectar 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. Esta
configuración deshabilitará los procesos de descubrimiento por medio de barridos ping. El
proceso Capsd es el responsable de descubrir todos los servicios a monitorizar sobre un
dispositivo. 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
servicios interrogando y registrando los tiempos de respuesta utilizando transacciones
sintéticas.

3.3.3. Configuración de Interfaces

También se pueden utilizar archivos XML conteniendo la configuración de las interfaces y
así modificar el nombre y el inventario de la Red. Como ejemplo podemos comentar que
esta interfaz la utiliza Swisscom para sincronizar OpenNMS con su red WIFI Europea de
Hotspots.

OpenNMS implementa un mecanismo de provisionamiento automático que está integrado

con el sistema RANCID (RANCID – Really Awesome New Cisco confIg Differ
http://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
3.3.4. Integración
OpenNMS posee numerosos puntos de integración para la paginación, sonidos de
alarmas, email, tratamiento de tickets/incidencias, etc.

El sistema está preparado para utilizar mapas para mostrar la topología de la red tal y
como se refleja a continuación.

14
3.4. Poller Remoto

OpenNMS implementa una funcionalidad para poder realizar interrogaciones desde

puestos remotos. El cliente remoto se conecta al servidor OpenNMS y se descarga el
plugin Remote Poller utilizando el Java Web Start. Una vez ejecutándose, el plugin
interroga los servicios de los nodos centrales utilizando transacciones sintéticas. Una vez
se tienen los resultados, se envían al servidor OpenNMS.

4. Arquitectura
A continuación se muestra un diagrama de bloques de la arquitectura OpenNMS:

15
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
 - 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 SPED
Tal y como se ha planteado el Sistema de Prevención, Extinción de incendios forestales y
Detección de plantaciones irregulares (SPED), y una vez analizado en profundidad el
funcionamiento del sistema OpenNMS, podemos implementarlo para controlar y gestionar
nuestros servidores de datos, servidores de grabación de imágenes y hasta en nuestros
dispositivos concentradores o routers Meshlium Xtreme ya que tienen un SO basado en
Linux y por lo tanto podemos cargar el agente OpenNMS.

El hecho de que podamos implementar OpenNMS en los routers Meshlium también

implica que podamos supervisar las interfaces de éste y por ello nuestra red de
transmisión compuesta de enlaces punto-punto o punto-multipunto.

En cuanto a los Motes, no podemos utilizar el sistema OpenNMS ya que estos

dispositivos están configurados para utilizar la tecnología ZigBee como medio de
comunicació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 que
el software de control está especialmente diseñado para tener un bajo consumo. Esto
conlleva a que el Mote esté la mayor parte del tiempo en modo suspensión y solamente
se despierte para enviar los valores de los sensores y para notificar al coordinador de su
existencia. También tenemos la limitación de la memoria ya que estos dispositivos tienen
muy poca memoria.

Existe un modelo de Mote que implementa un interface WIFI para la comunicación y que
nos permitiría gestionar en parte dicha comunicación con OpenNMS, pero el consumo se
dispararía y ya no sería viable ya que los requerimientos de energía conllevarían una
mayor batería y placa solar mayor.

17
Existe un SO que se ha diseñado para los dispositivos ZigBee y es el TinyOS que se trata
de un sistema operativo de código abierto y el cual nos brindaría la posibilidad de
implementar un pequeño agente con su propia MIB dentro del módulo de comunicación
ZigBee, pero hay que tener en cuenta que la filosofía de gestión de OpenNMS es que
quien realiza el Polling es el gestor OpenNMS hacia los dispositivos e interfaces y por
diseño esto no es operativo ya que la gran mayoría de veces nuestro Mote estaría en
suspensión. La idea a trabajar sería implementar la comunicación en sentido contrario, es
decir, quien inicia el polling debe ser nuestro dispositivo ZigBee para anunciar su
existencia al router coordinador y éste como sí que tiene implementado el agente
OpenNMS 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 que
los Motes son dispositivos muy versátiles y además existe software de código abierto que
abre un sinfín de posibilidades.

18
6. Otros Sistemas de Gestión de Red
Como ya se ha mencionado en apartados anteriores, otro de los sistemas de
monitorización es Nagios. Es el más popular en lo que a sistemas de monitorización de
código abierto se refiere y se ha establecido como un estándar de facto.

6.1. Nagios

Nagios 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 de
plugins para mantener sus sistemas en funcionamiento y detectar los problemas antes de
que 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 trata
de Shinken. El objetivo de Shinken es el de proporcionar un nuevo modelo multi-proceso
distribuido que se adapte bien a entornos distribuidos y heterogéneos. El proyecto
Shinken se encuentra en una fase temprana y falta implementar más funcionalidades. El
objetivo es asegurar una compatibilidad absoluta entre sus archivos y los de Nagios.

19
6.1.1. Características y funcionalidades
Nagios marca el estándar en la industria de monitoreo a grandes niveles por unas cuantas
razones. Este permite controlar la red informática y solucionar problemas antes que los
usuarios los detecten. Nagios es un sistema estable, escalable, con soporte y extensible.

Este sistema permite monitorear una importante cantidad de dispositivos y sistemas como
por 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 la
comunidad (más de 200) que permiten extender las funcionalidades del sistema. Es un
software de código abierto, con acceso completo al código fuente, liberado bajo licencia
GPL.

Nagios es un sistema que cuenta con más de 10 años en desarrollo, es un sistema que
permite 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 usuarios
alrededor del mundo. Tiene una lista de correos activa y una amplia comunidad a través
del website.

6.1.2. Funcionalidades básicas

Se destacan las siguientes características de funcionamiento:

20
 • 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. Estructura
Nagios 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
 • 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