Caja de herramientas de inteligencia artificial para la academia y la investi...
Proyecto: Monitorización de red con SNMP y MRTG
1. Monitorización de red
con SNMP y MRTG
Proyecto de síntesis
Daniel Lorenzo Alvarez
Tutor: Francesc Pérez
Proyecto de Síntesis
CFGS de Sistemas de Telecomunicaciones e Informáticos (2009 – 2011)
2. ÍNDICE
INTRODUCCIÓN ...................................................................................................... 2
Objetivos ................................................................................................................... 2
¿Por qué disponer de un sistema de monitorización? ................................................ 3
PROTOCOLO SIMPLE DE ADMINISTRACIÓN DE RED (SNMP)..................... 4
Administrador y Agente ............................................................................................. 5
SNMP y UDP .............................................................................................................. 6
RFCs y Versiones del protocolo SNMP ........................................................................ 6
Modelo de seguridad basado en comunidades .......................................................... 8
SNMPv3..................................................................................................................... 8
SMI y MIB ................................................................................................................ 10
MIB-II ...................................................................................................................... 10
Operaciones y mensajes SNMP ................................................................................ 12
RMON (Remote Network Monitoring)...................................................................... 14
MRTG (MULTI ROUTER TRAFFIC GRAPHER) ................................................ 16
Configuración .......................................................................................................... 17
RRDtool ................................................................................................................... 19
PROPUESTA DE SISTEMA DE MONITORIZACIÓN ......................................... 20
Esquema de red ....................................................................................................... 20
Requisitos: ............................................................................................................... 20
Administración remota del servidor (NMS): ............................................................. 21
IMPLEMENTACIÓN DE SNMP (AGENTE) ................................................................... 22
IMPLEMENTACIÓN DE SNMP (NMS) ........................................................................ 23
IMPLEMENTACIÓN DE MRTG ................................................................................... 23
ANÁLISIS ................................................................................................................. 25
CONCLUSIONES Y POSIBLES MEJORAS ......................................................... 28
ANEXOS ................................................................................................................... 29
NORMAS RFC ......................................................................................................... 34
GLOSARIO............................................................................................................... 35
REFERENCIAS ........................................................................................................ 36
3. INTRODUCCIÓN
Soy Daniel Lorenzo Álvarez, estudiante de CFGS de Sistemas de
Telecomunicaciones e Informáticos de Stucom, Barcelona (2009-2011) y realizo este
trabajo como Proyecto de síntesis.
En el siguiente trabajo se propone la implementación de un sistema de
monitorización de red mediante el uso del protocolo SNMP (Simple Network
Management Protocol) y el software de monitoreo MRTG (Multi Router Traffic
Grapher). Mediante el uso de software libre y gratuito se busca obtener un seguimiento
visual de equipos en una red y realizar un análisis.
En el primer capítulo se explica el protocolo SNMP, el cual se empleará en el
siguiente trabajo, así como las funcionalidades que ofrece. Se presentan sus versiones y
sus características como paquete de red. Aquí también se describen los conceptos de
MIB, SMI y RMON.
En el segundo capítulo se presentan las características de la aplicación que se
utilizará para llevar a cabo la monitorización, MRTG, así como sus funcionalidades y
configuraciones.
En el tercer capítulo se propone el sistema para la monitorización. Se describen
los requisitos y pasos a seguir para su implantación, y la configuración para la situación
propuesta.
En el cuarto capítulo se presenta un análisis, una vez implementado el sistema
donde se describe el comportamiento observado.
Por último, en los anexos se presentan en detalle los archivos de configuración
así como las opciones de MRTG empleadas. También se muestran fragmentos de las
MIBs utilizadas.
Objetivos
El trabajo está pensado con el objetivo último de una implementación real,
física. Se pretende conseguir monitorizar dispositivos en una red y conseguir con ello
una administración más eficaz.
En resumen, los objetivos son:
- Ampliar mis conocimientos sobre la administración de red y la
monitorización.
- Conocer el protocolo SNMP, su utilidad y funcionamiento.
- Conocer el software generador de gráficos MRTG.
4. - Implementar físicamente un sistema de monitorización: instalación y
configuración del protocolo SNMP y de MRTG.
- Monitorizar aquellos parámetros que al personal de administración interese y
obtener gráficas del comportamiento de los dispositivos gestionados.
- Analizar los resultados obtenidos.
¿Por qué disponer de un sistema de monitorización?
Las actuales redes de telecomunicación se caracterizan por un constante
incremento del número, complejidad y heterogeneidad de los recursos que las
componen.
Los principales problemas relacionados con la expansión de las redes son la
gestión de su correcto funcionamiento día a día y la planificación estratégica de su
crecimiento. Por ello, la gestión de red integrada, como conjunto de actividades
dedicadas al control y vigilancia de recursos bajo el mismo sistema de gestión, se ha
convertido en un aspecto de enorme importancia en el mundo de las
telecomunicaciones.
Un sistema para la monitorización es esencial en cualquier entorno donde sea
relevante cierto nivel de funcionamiento, donde se busque que el mantenimiento de los
enlaces de comunicación así como la administración de los equipos que conectan las
diferentes áreas de las organizaciones sea lo más eficiente posible.
5. 1. PROTOCOLO SIMPLE DE ADMINISTRACIÓN DE RED
(SNMP)
Fue introducido en 1988 debido a la necesidad creciente de un estándar para
administrar dispositivos sobre redes IP. Se trata de un protocolo de capa de aplicación
(capa 7, OSI) que facilita el intercambio de información de gestión entre dispositivos de
red.
Este protocolo es parte del conjunto de protocolos TCP/IP (Transmission
Control Protocol/Internet Protocol) y, por su amplia utilización en redes empresariales,
es considerado el estándar de facto en detrimento del protocolo CMIP (Common
Management Information Protocol) basado en el modelo OSI, más utilizado en las
grandes redes de las operadoras de telecomunicación. SNMP permite a los
administradores: gestionar el rendimiento, encontrar y solucionar problemas, y
planificar el crecimiento futuro de la red.
Si bien SNMP se diseñó, en un principio, con el propósito de hacer posible
supervisar de forma sencilla y resolver problemas en routers y bridges; con su
ampliación, este protocolo puede ser utilizado para supervisar y controlar: routers,
switches, bridges y hubs de la mayoría de fabricantes, además de servidores y
estaciones Windows y Unix, servidores de terminal, etc.
La información que se puede monitorizar son parámetros simples y
estandarizados para todos los routers y/o switches (independientemente del fabricante)
como por ejemplo la cantidad de tráfico de entrada y salida de una interfaz, el tiempo
que llevan encendidos, la carga de CPU, etc. Y parámetros más específicos
proporcionados por el fabricante del dispositivo, como puede ser la temperatura.
Se pueden resumir sus características en los siguientes puntos:
- Permite a los administradores gestionar el rendimiento de la red, buscar y
modificar la información de los dispositivos que la componen, encontrar y
diagnosticar problemas en la red, planificar su crecimiento y generar
informes sobre los nodos de la red.
- Es capaz de gestionar eficazmente dispositivos de diferentes fabricantes.
- Ofrece una simple combinación de solicitud-respuesta y un modo de
notificación activo, así como tiempo de espera y mecanismos de
retransmisión.
- Contiene pocos tipos de paquetes con un formato sencillo, facilitando su
resolución e implementación.
- Dispone de mecanismos de autenticación y privacidad como medidas de
seguridad.
6. Administrador y Agente
En el mundo SNMP existen dos entidades: las estaciones que gestionan,
denominadas NMS (Network Management Station) y los dispositivos que son
gestionados, denominados Agentes.
Un NMS procesa y muestra información sobre el estado de los dispositivos y la
red, que obtiene de los Agentes usando un protocolo de administración de red (SNMP).
En él se ejecuta una aplicación mediante la cual el administrador es capaz de supervisar
y controlar a los dispositivos administrados (aquellos que poseen el agente de SNMP).
Figura 1.1. Muestra la relación entre el NMS y el Agente
Los Agentes son módulos software que se instalan en los dispositivos que se
desean gestionar, y que obtienen información del estado del mismo desde la base de
información de administración (MIB). Puede ser un programa separado (un demonio, en
el lenguaje Unix), o puede ser incorporado en el sistema operativo (por ejemplo, en el
Sistema Operativo de un router CISCO). El agente se encarga de recopilar, mantener y
enviar la información de los dispositivos administrados a los NMS, respondiendo a las
solicitudes de éste o, también es capaz de enviar alertas o “traps” cuando sea necesario.
Un “trap” es la forma con la que el agente dice al NMS que algo ha pasado, una
notificación. Dado que se trata de alertas, son enviadas sin petición previa, de forma
asíncrona, al NMS; quien por su parte es adicionalmente responsable de realizar o
ejecutar una acción basada en la información que recibe del agente. Por ejemplo,
cuando el router que da acceso a Internet se cae, éste puede enviar un trap al NMS
informándole de tal hecho. El NMS por su parte puede tomar alguna acción, quizá
activar una alarma sonora para hacerle saber al encargado de la red que algo ha
ocurrido.
Algunos dispositivos, además, pueden enviar un correspondiente “trap” de “all
clear” cuando hay una transición de un mal estado a un buen estado, lo que puede
resultar útil para determinar cuándo se ha resuelto una situación problemática.
7. SNMP y UDP
SNMP es un protocolo basado en el estándar TCP/IP y emplea UDP (User
Datagram Protocol, RFC768) cómo protocolo de la capa de transporte, ya que no está
orientado a la conexión; esto es, no se realiza ninguna conexión extremo a extremo,
entre el Agente y el NMS, cuando se envían datagramas (paquetes de datos) de ida y
vuelta.
Este aspecto de UDP lo hace poco fiable, ya que no existe conocimiento de la
pérdida o llegada de los datagramas al nivel del protocolo. Pero ello supone un menor
tamaño del paquete y menos mecanismos empleados en la comunicación, por tanto más
rapidez a la hora de realizar operaciones y menor impacto en el rendimiento en general
de la red.
En cuanto a solicitudes de información se refiere, la naturaleza no confiable de
UDP no supone un problema real. Aunque se trate de una red muy congestionada,
siempre se debería optar por la velocidad y rendimiento que ofrece UDP (en contraste
con TCP, Transmission Control Protocol, RCF793), a la hora de, por ejemplo, emplear
SNMP como medio para la monitorización, sobre todo si son muchos los equipos a
administrar.
SNMP utiliza el puerto de UDP 161, para el envío y la recepción de solicitudes,
y el 162, para la recepción de “traps” de los Agentes, en los dispositivos administrados.
Figura 1.2. Muestra la comunicación entre el NMS y el Agente
empleando el protocolo UDP.
8. RFCs y Versiones del protocolo SNMP
El Grupo de Trabajo en Ingeniería de Internet o IETF (Internet Engineering Task
Force) es responsable de definir los protocolos estándar que conforman el tráfico de
Internet, incluyendo SNMP. La IETF publica RFCs (Request for Comments), que son
especificaciones para muchos de los protocolos que existen en el ámbito IP. Las
especificaciones o documentos entran a la lista de estándares primero como Propuestas
y luego reciben el estado de Draft. Cuando un Draft es eventualmente aprobado recibe
la condición de Estándar. Hay otras dos designaciones entre la lista de estándares:
histórica y experimental, definen respectivamente un documento que ha sido
reemplazado por uno nuevo y un documento que aún no está listo para convertirse en
estándar.
El requisito fundamental para el diseño de SNMP fue la sencillez, lo que si bien
facilitó su expansión, ha hecho necesarias varias revisiones para adaptar el protocolo a
las necesidades actuales, entre las que cabe destacar las exigencias en cuanto a la
seguridad del sistema.
Versión Descripción
Se desarrolló debido a la creciente necesidad de un mecanismo simple y
SNMPv1 estandarizado para la gestión y monitoreo de los equipos de la red y que no
supusiese cambios en el rendimiento de las redes.
Se desarrolló con la idea de mejorar la primera versión y solventar
problemas de seguridad y sobrecarga en las transferencias de datos. Sin
embargo solo se optimizó la transferencia de datos, por ello también se
denomina SNMPv2c, donde la “c” indica que se mantiene el esquema de
SNMPv2, seguridad basado en comunidades. Actualmente es el más empleado
SNMPv2c debido, sobre todo, a su facilidad de implantación y mantenimiento.
Se agrega soporte para la administración en redes distribuidas y centralizas.
Mejoras en el SMI y en las operaciones. Se implementan 2 nuevas PDUs:
GetBulkRequest, InformRequest.
Surge con el propósito de proveer un sistema de seguridad y administración
más robusto y flexible. Emplea un nuevo modelo de seguridad que asegura
SNMPv3 autenticación y encriptación. No supone cambios determinantes en cuanto a
la operatividad que ofrece SNMPv2, aparte de los cambios en cuanto a
seguridad.
Figura 1.3. Tabla resumen de las versiones de SNMP
9. Modelo de seguridad basado en comunidades
Tanto SNMPv1 como SNMPv2c emplean un esquema de seguridad basado en
comunidades (comunity-strings) para establecer la autenticación entre un NMS y los
Agentes. Las comunidades son esencialmente contraseñas, cadenas de texto que
permiten a cualquier aplicación basada en SNMP (y que conozca la cadena de texto)
acceder a la información de gestión del dispositivo cliente o Agente.
El conjunto de dispositivos que pueden acceder a la MIB de un Agente se define
por una lista de control de acceso que relaciona las direcciones IP con una palabra clave,
la comunidad.
Las estaciones administradoras se pueden configurar con tres tipos de permisos:
- De sólo lectura (read-only): permite leer los valores de datos, pero deniega
su modificación. Por ejemplo, permite leer el número de paquetes que se han
transmitido a través de los puertos de un router, pero no permite resetear este
contador.
- De lectura-escritura (read-write): se permite leer los valores de los datos y
realizar cambios en los elementos que tengan la propiedad de ser
modificables.
- De notificación (trap): se permite recibir notificaciones por parte del Agente.
La mayoría de los fabricantes envían su equipo con nombres de comunidad
predeterminados, típicamente “public” para la comunidad de read-only y “private” para
la comunidad de read-write. Es conveniente cambiarlas.
SNMPv3
La versión 3 del protocolo define un nuevo modelo de seguridad, concretamente
el Modelo de Seguridad de Usuario o USM (User Security Model). Este modelo
proporciona las siguientes características:
Integridad del mensaje: Garantizar que un paquete no ha sido alterado al
recorrer la red.
Autentificación: Determinar que el mensaje proviene de una fuente
válida.
Encriptación: Cifrar el contenido de un paquete a fin de evitar ser leído
por una fuente no autorizada.
En esta versión, el Agente, al igual que el NMS, se definen como entidades
SNMP, y consisten de un motor SNMP (snmp engine) y aplicaciones SNMP (las
operaciones SNMP en sí). Un motor SNMP consta de los siguientes componentes:
10. - El dispatcher: Envía y recibe mensajes SNMP. También trata de determinar
la versión de cada mensaje recibido (v1, v2, o v3) y, si se soporta la versión,
entrega los mensajes al Subsistema de procesado de mensajes.
- Subsistema de procesado de mensaje: Se encarga de preparar los mensajes
para ser enviados y extraer datos de aquellos recibidos.
- Subsistema de seguridad: Autentifica, cifra y descifra los mensajes. La
autenticación puede usar tanto comunidades (SNMPv1 y SNMPv2) como
USM de SNMPv3. La autenticación basada en USM emplea algoritmos
MD5 o SHA para autentificar a los usuarios sin enviar una contraseña en
texto plano. El servicio de privacidad usa el algoritmo DES (actualmente)
para cifrar y descifrar los mensajes SNMP.
- Subsistema de Control de Acceso: Determina cuales usuarios y operaciones
se les permite el acceso a los objetos administrados de la MIB.
SNMPv3 proporciona tanto modelos como niveles de seguridad. Un modelo de
seguridad es una estrategia de autenticación cuya configuración se basa en un usuario y
el grupo al que este pertenece, y un nivel de seguridad es el nivel permitido dentro de un
modelo de seguridad. La combinación de un modelo de seguridad y un nivel de
seguridad determina el mecanismo de seguridad que se emplea a la hora de manejar
paquetes SNMP.
Versión Descripción Autenticación Encriptación Nivel
Usa el modelo basado en Community No autenticación
SNMPv1 No
comunidades string No encriptación
SNMPv2, Usa el modelo basado en Community No autenticación
SNMPv2c No
comunidades string No encriptación
Utiliza nombres de usuarios USM (User No autenticación
SNMPv3 para comprobar la No
Security Model) No encriptación
autenticación.
Variante de SNMPv3 que
provee una autenticación USM + MD5 o Autenticación
SNMPv3 basada en los algoritmos de No
SHA No encriptación
HMAC-SHA o HMAC-
MD5
Configuración más segura
de SNMPv3 que provee USM + MD5 o
SNMPv3 algoritmos de autenticación DES Autenticación
SHA Encriptación
y encriptación DES de 56
bits
Figura 1.4. Tabla de los modelos y niveles de seguridad de SNMP
11. SMI y MIB
La SMI (Structure of Managemet Information) se encarga de definir un esquema
de nombres únicos para cada uno de los objetos administrados y su comportamiento
(denominado OID). El agente posee una lista de los objetos que son supervisados, como
puede ser el estado operacional de la interfaz de un router (“up” o “down”).
La MIB (Management Information Base) se puede considerar como una base de
datos que almacena información (los OIDs con su descripción) de los dispositivos
administrados. Al igual que el Agente reside en cada uno de los dispositivos
gestionados. Las MIBs contienen objetos que representan parámetros o variables de los
equipos gestionados y se ordenan de forma jerárquica siguiendo un esquema de árbol.
Estas colecciones de objetos relacionados, definidos como módulos de MIB. Estos
módulos están escritos en un lenguaje especial, definido en el estándar de Internet STD
58, y en los RFCs de Internet 2578, 2579 y 2580.
Cada elemento del árbol MIB se identifica por un OID (Object Identifier)
numérico o de texto. La lista completa de los objetos y su definición
correspondiente está definida en el RFC 1212.
Ejemplo de OID numérico El mismo OID en modo texto
.1.3.6.1.2.1.1.1 .iso.org.dod.internet.mgmt.mib-2.system.sysDescr
Figura 1.5. Esquema de árbol de una MIB
12. MIB-II
Un agente puede implementar varias MIBs, pero todos ellos implementan una en
particular llamada MIB-II (RFC1213). El principal objetivo de MIB-II es proporcionar
una MIB estandarizada capaz de almacenar datos comunes de gestión: información del
sistema, interfaces, protocolos, etc. para redes TCP/IP.
MIB-II se define como iso.org.dod.internet.mgmt.1, o 1.3.6.1.2.1. A partir de
aquí podemos ver que el grupo system es mib-2.system.0, o 1.3.6.1.2.1.1, y así
sucesivamente. La siguiente figura muestra el subárbol “mib-2” de la rama “mgmt”.
Figura 1.6. Subárbol “mib-2”
13. La siguiente tabla recoge una breve descripción de los grupos definidos en la
“MIB-II”:
Figura 1.7. Tabla conceptos de MIB-II
14. Operaciones y mensajes SNMP
El corazón de SNMP es una serie simple de operaciones (y la información que
estas obtienen) que les da a los administradores la capacidad de analizar los distintos
dispositivos administrados e interactuar con estos.
Las operaciones de SNMP son:
get-request Solicita el valor de una variable específica, mediante su OID.
Solicita el valor de una variable sin conocer su nombre exacto.
get-next-request
Útil para búsquedas secuenciales dentro de una rama MIB.
Solicita grandes bloques de datos, como por ejemplo varias
get-bulk-request
filas de un subárbol MIB.
Respuesta por parte del Agente a las operaciones de get-
get-response
request, get-next-request o set-request
set-request Almacena, altera un valor en una variable específica
inform-request Comunicación entre gestores SNMP, NMS
Mensaje no solicitado enviado por un Agente a un NMS
trap
cuando ocurre algún evento
Figura 1.8. Operaciones SNMP
Los mensajes utilizados por SNMP poseen el siguiente formato :
Figura 1.9. Estructura de PDU
- Versión: Número de versión de protocolo que se está utilizando (por
ejemplo 1 para SNMPv1)
- Comunidad: Nombre o palabra clave que se usa para la autenticación.
15. - SNMP PDU: indica el contenido de la PDU, el que depende de la operación
que se ejecute, que puede ser algún tipo de Request (como GetRequest,
GetNextRequest y SetRequest), un GetResponse o un Trap.
- Petición ID: usado para distinguir una solicitud con una identificación única,
entre las demás solicitudes.
- Error-status: usado para indicar que ha habido una excepción mientras se
procesaba una solicitud.
- Error-índice: cuando el error-status es diferente de cero (no hubo error)
puede proporcionar información adicional indicando que variable causó la
excepción.
- Campos variables: una lista de nombre de variables con sus
correspondientes valores. Normalmente contiene los datos solicitados por
una operación Get o Trap.
Como se aprecia en la Figura 1.9 un mensaje de tipo Trap tiene una estructura
diferente:
- Empresa (Enterprise): indica el tipo de objeto que genera el Trap.
- Dirección agente: indica la dirección IP del Agente que emite el Trap.
- Trap genérico: tipo de Trap que informa sobre un estado, válido para
cualquier dispositivo
- Trap específico: utilizado para Traps privados (de fabricantes), así como
para precisar la información de un determinado Trap genérico.
- Time-stamp: tiempo transcurrido entre la última vez que se reinició el
dispositivo de red y la generación del Trap.
Figura 1.10. Interacción y compatibilidad de las diferentes versiones y sus
operaciones
16. RMON (Remote Network Monitoring)
Si quisiéramos obtener información acerca de una red como un todo deberíamos
realizar sucesivas consultas individuales a cada nodo conectado en la red. Esto supone
un mayor consumo de recursos de la red (tiempo de procesamiento en agentes y el
gestor, y ancho de banda consumido por las constantes consultas/respuestas SNMP).
Con este motivo surge RMON, un protocolo para la monitorización de redes como un
conjunto.
RMON trabaja mediante un analizador de red, denominado monitor o sonda
RMON. Está diseñado para la monitorización “basada en el flujo”, mientras que SNMP
para la administración “basada en el dispositivo”. La sonda se encarga de solicitar,
recoger y guardar información sobre paquetes enviados o perdidos, velocidad de las
líneas, estadísticas del tráfico, etc. sobre el segmento de red en el que se encuentra (o
una LAN o WAN enteras), y ponerla a disposición del NMS.
La MIB de RMON se diseñó para permitir a las sondas RMON correr de forma
offline, esto es, sin necesidad de un NMS para recoger información sobre la red
constantemente. Se trata básicamente de una extensión a la MIB-II, lo que implica que
para que RMON funcione, SNMP debe estar habilitado y convenientemente
configurado.
- RMON1 definido en RFC 2819 (RMON2 en RFC 2021).
- SMON, versión para redes conmutadas está definido en RFC 2613.
Figura 1.11. MIB de RMON
17. 2. MRTG (MULTI ROUTER TRAFFIC GRAPHER)
Se trata de una herramienta para monitorizar diversos parámetros de red y
generar páginas HTML que contienen imágenes (con formato PNG) que proporcionan
una representación gráfica en vivo de los datos que obtiene del protocolo SNMP o de
scripts.
Figura 2.1. Gráfica creada con MRTG
Entre las características más importantes de MRTG tenemos las siguientes:
- MRTG es multiplataforma por lo que es compatible con la mayoría de
plataformas UNIX y Windows NT. Es además software libre bajo la licencia
GNU/GPL.
- Está escrito en Perl.
- Utiliza una aplicación SNMP portátil escrito completamente en Perl, por lo
que no hay necesidad de instalar ningún paquete externo SNMP.
- Las interfaces de routers pueden ser fácilmente identificadas por su dirección
IP, la descripción y la dirección Ethernet además de la interfaz de serie
normal.
- MRTG mantiene constante el tamaño de los archivos de registro (logfiles),
estos archivos no crecen en exceso gracias a la utilización de un único
algoritmo de consolidación de datos.
- Algunas rutinas están escritas en C para mejorar el rendimiento.
- Los gráficos son generados directamente en formato PNG
- El aspecto de las páginas web producidas por MRTG así como la
configuración de este son altamente configurables.
MRTG consiste en un script de Perl que utiliza el protocolo SNMP para
controlar cualquier variable que se elija, y un rápido programa en C que registra el
tráfico de datos y crea los gráficos para representarlos. Estos gráficos se incrustan
entonces en páginas web.
18. Configuración
El comportamiento en tiempo de ejecución de MRTG se rige por unos archivo
de configuración (por defecto se crea uno, mrtg.cfg bajo el directorio de /etc). Estos
archivos de configuración pueden ser generados automáticamente con el script
cfgmaker. Sin embargo, para configuraciones más elaboradas es necesario darle algunos
parámetros a este script.
El script de cfgmaker crea archivos de configuración basado en la información
extraídos de un enrutador u otro dispositivo SNMP disponible. Se ejecuta a través de la
línea de comandos y tiene la siguiente sintaxis:
$ sudo cfgmaker [OPCIONES] COMUNIDAD@IP_DISPOSITIVO
comunidad: es el nombre de la comunidad del dispositivo a configurar, según se
haya especificado en el archivo de configuración de SNMP. Por defecto se pone a
“public”.
dispositivo: hace referencia al nombre DNS o dirección IP del dispositivo con el
Agente SNMP.
opciones (variables globales): se pueden especificar las opciones para el fichero
a que se crea. En el Anexo de este documento se encuentran todas las posibles
configuraciones.
indexmaker es un script que puede crear páginas web que mostrará una serie de
enlaces hacia las páginas de las diferentes interfaces monitorizadas. El comando a
ejecutar para crear la página de índice tiene la siguiente sintaxis:
$ sudo indexmaker /var/www/mrtg/index.html /…/archivo.cfg /…/archivo1.cfg
El script se encarga de convertir los ficheros de configuración en ficheros html
visibles desde cualquier navegador.
19. Comando cfgmaker con el que se ha
creado el fichero de mrtg.cfg.
Opciones globales, variables que
afectan a todas las configuraciones
siguientes que se encuentran en el
fichero.
A partir de aquí se crean las configuraciones
específicas para cada elemento a
monitorizar o Target. Se especifican los
OIDs y el esquema que seguirá el gráfico.
También se pueden especificar opciones
específicas para una mejor interpretación y
funcionamiento.
Figura 2.2. Ejemplo de fichero de configuración de MRTG
Agente Agente
NMS - MRTG
Agente
Figura 2.3. Ejemplo implementación de MRTG
20. RRDtool
MRTG funciona perfectamente para la monitorización de redes simples, lo cual
fue su objetivo en un inicio, aunque actualmente se utiliza para monitorizar de todo,
desde tráfico de enlaces hasta la temperatura, memoria, etc. Sin embargo, hay una serie
de inconvenientes en MRTG. En el apartado de gráficos por ejemplo, estos siempre
comienzan por 0 en el eje vertical, y si únicamente quisieses ver datos relevantes en un
rango determinado, no podrías. Existen limitaciones en cuanto al número de valores que
pueden representarse, si se quisiera monitorizar el flujo de red de 10 servidores
diferentes, probablemente se deberían crear 10 gráficos; también en cuanto a la
velocidad de peticiones para los valores de los gráficos, un mínimo de 5 minutos… Los
detalles se suman y suman.
En este punto se crea RRDtool (Round Robin Database Tool), una herramienta
pensada para llenar todos los vacíos de MRTG, aunque falla en la simplicidad que este
último provee. RRDtool es la próxima generación de MRTG, con una completa
reimplementación de los gráficos y características de registro. Es un sistema que
permite almacenar y representar datos en intervalos temporales (ancho de banda, errores
en el tráfico, CPU, etc.) en forma de gráficos fácilmente inteligibles, siguiendo el
mismo principio que MRTG.
Funciona guardando los datos obtenidos con la ayuda del protocolo SNMP en
una “base de datos circular” (Data Source, DS) que no crece en el tiempo, ya que
contempla siempre la misma cantidad de datos; una vez llena toda la base de datos, los
nuevos valores sobreescriben a los antiguos. Con estos datos RRDtool es capaz de
generar simples y complejos gráficos, altamente personalizables y visibles desde
cualquier navegador web.
Figura 2.4. Gráfico creado con RRDtool
21. 3. PROPUESTA DE SISTEMA DE MONITORIZACIÓN
Esquema de red
A.34 Agente
192.168.1.3
172.16.255.120/16
172.16.255.130/16
10.10.127.223/24 A.25
NMS -MRTG
192.168.25.0/24
Figura 3.1. Esquema de red
Requisitos:
Estación administradora (NMS)
o Plataforma: Linux, Ubuntu 10.04
o Paquetes:
snmp: es un conjunto de aplicaciones para realizar las peticiones a
los diferentes dispositivos que tengan un agente SNMP y que
deseemos monitorizar. Operaciones: snmpget, snmpgetnext,
snmpset, snmpwalk, snmpnetstat, snmptrapd y snmptest.
MRTG. Se puede descargar el paquete de código fuente desde su
web (http://www.mrtg.org), aunque en la distribución de Ubuntu
ya viene por defecto en uno de los repositorios.
Apache2
OPCIONAL:
o Herramienta “mib browser”. Interfaz gráfica para operaciones snmp y
visor de MIBs. Software:
o openssh-server: para la administración remota de este servidor mediante
ssh
22. Equipo administrado (Agente)
o PC/ Servidor – Linux. Este equipo corre una máquina virtual, que es
a su vez el servidor Proxy para la red wifi.
snmpd: se trata de un Agente SNMP que se instala de forma local
en el dispositivo que se desea monitorizar.
En este proyecto se empleará: SNMPv1 y SNMPv2, debido a su amplia
compatibilidad, rapidez de implantación y no necesidad de un riguroso sistema de
seguridad para el entorno donde se pretende realizar su implementación.
Administración remota del servidor (NMS):
Por cuestiones de movilidad y comodidad se emplea la administración remota
para gestionar el NMS.
1. En la estación NMS instalamos un servidor de ssh
apt-get install openssh-server
2. En la otra estación instalamos el programa Putty (u otro cliente de ssh) para el
acceso remoto:
Figura 3.2. Conexión remota al NMS con Putty
23. IMPLEMENTACIÓN DE SNMP (AGENTE)
Por parte del Agente se debe instalar el paquete de snmpd, que implementa un
demonio cuya función es la de responder a las peticiones SNMP del NMS. La
instalación por defecto incluye MIBs para las interfaces de red, memoria, disco,
procesos y estadísticas de CPU.
apt-get install snmpd
Archivos de configuración:
/etc/defaults/snmpd
En este archivo debemos eliminar: 127.0.0.1
(con esto le decimos al Agente que escuche a peticiones por todos los puertos)
/etc/snmp/snmpd.conf
Se configura de la siguiente manera:
####
# sec. name source community
Se describen las reglas de seguridad,
com2sec readonly 172.16.0.0/16 public asignando las comunidades y las redes o
com2sec readwrite 172.16.255.130 private
equipos a los que se permite el acceso
####
# sec.model sec.name
group ROGroup v1 readonly Se crean grupos asociando las redes y las versiones
group ROGroup v2c readonly
group ROGroup usm readonly a emplear. Se proponen estos nombres distinguibles
fácilmente según los permisos que se les quiere
group RWGroup v1 readwrite
group RWGroup v2c readwrite proporcionar.
group RWGroup usm readwrite
####
# incl/excl subtree mask Se asignan las ramas MIB que se permiten ver
view all included .1 80
view system included .iso.org.dod.internet.mgmt.mib-2.system
####
# context sec.model sec.level match read write notif Ahora se asignan los permisos (lectura,
access ROGroup "" any noauth exact all none none escritura, notificación) a los grupos
access RWGroup "" any noauth exact all all none
creados anteriormente
####
# System contact information
syslocation Proxy-Wifi (configure /etc/snmp/snmpd.local.conf)
syscontact Root <root@localhost> (configure /etc/snmp/snmpd.local.conf)
Opcionalmente se puede aportar información
de contacto, útil para pruebas de conexión
Iniciar el agente con:
/etc/init.d/snmpd start
24. IMPLEMENTACIÓN DE SNMP (NMS)
Necesitamos el siguiente paquete para realizar las consultas al agente mediante
las operaciones de SNMP:
apt-get install snmp
Para comprobar si SNMP está funcionando correctamente utilizamos alguna
operación de snmp:
snmpget –v2c –c public 172.16.255.120 system.sysDescr.0
Operación Versión Comunidad IP del Target OID
Y devuelve:
SNMPv2-MIB::sysDescr.0 = STRING: Linux xen-wifi 2.6.26-2-xen-amd64 #1 SMP Tue Jan 25
06:13:50 UTC 2011 x86_64
En caso de que no devuelva información, se debe revisar que se han seguido
todos los pasos y verificar que la configuración es la correcta.
Si queremos averiguar alguna variable en particular podemos acceder a las MIBs
que se instalan con el paquete de snmp y encontrar el OID adecuado. Las MIBs se
guardan en el siguiente directorio:
/usr/share/snmp/mibs/
Figura 3.3. Ficheros MIB
25. IMPLEMENTACIÓN DE MRTG
Ubuntu contiene MRTG en uno de sus repositorios, así que no tenemos que
compilarlo y podemos proceder directamente a su instalación:
apt-get install mrtg apache2
La ventaja de instalar MRTG de esta manera es que automáticamente instala
todas las dependencias que necesita (GD, zlib, libpng). En el comando también
incluimos la instalación del servidor Apache.
Creamos las carpetas donde se guardarán los archivos utilizados por MRTG:
1. Para guardar las páginas HTML que se generen con el script de indexmaker.
mkdir –p /var/www/mrtg
2. Para guardar los archivos de configuración generados por cfgmaker.
mkdir /etc/mrtg
Como únicamente monitorizamos una estación podemos crear un solo archivo
de configuración. Este servirá para el monitoreo de las interfaces, la carga del sistema,
memoria RAM, etc. de este equipo.
cfgmaker --output /etc/mrtg/wifi.cfg public@172.16.255.121
Ejecutamos el siguiente comando para crear la página web index.html, con el
archivo de configuración MRTG especificado:
indexmaker --output=/var/www/mrtg/index.html /etc/mrtg/wifi.cfg
Ahora ejecutamos el siguiente comando para establecer la variable de entorno e
iniciar el demonio de MRTG
env LANG=C /usr/bin/mrtg /etc/mrtg/wifi.cfg
Y ahora queda comprobar que todo ha funcionado como se esperaba, para ello
en la barra de dirección de un navegador escribimos:
http://10.10.127.223/mrtg/index.html y debe aparecer la página index.html que antes
se generó con indexmaker. Haciendo click en uno los gráficos, se ofrece más
información sobre el elemento que se monitoriza, con datos diarios, semanales,
mensuales y anuales, además tendremos la leyenda de colores empleados con sus
significados.
Si es necesario cambiar algún parámetro en el fichero de configuración, se debe
reiniciar el demonio de MRTG, y si se cambia algún aspecto que modifique el gráfico,
se debe introducir el comando de indexmaker nuevamente.
26. 4. ANÁLISIS
Figura 4.1. Gráficos generados por MRTG
Una vez en la página index.html podemos ver todos los gráficos configurados en
el fichero de wifi.cfg. Como vemos en la imagen, se han creado gráficos para todas las
interfaces (las que están subidas), para la memoria RAM y para la carga del sistema.
Estos gráficos corresponden a datos actuales (diarios), que se renuevan cada 5 minutos
(como se indica en el fichero de configuración).
Para comprender lo que se representa en cada uno de los gráficos debemos clicar
en ellos y seguir la leyenda. Aquí observamos además gráficos que agrupan los datos
por semanas, por meses y por años. Los datos crecen de derecha a izquierda y el tiempo
se rige por 5 minutos para los gráficos diarios, por días para los semanales, por semanas
para los mensuales y por meses para los anuales.
Para este análisis se ha observado la actividad en un semana (desde 1 de junio de
2011, miércoles, hasta 8 de junio de 2011, miércoles).
Se ha monitorizado la actividad de los siguientes elementos:
- Interfaz eth0 (interfaz física, ip = 172.16.255.120)
- Interfaz eth1 (interfaz física, ip = 192.168.1.3)
- Memoria RAM
- Carga del sistema
27. Interfaz eth0:
Representa el tráfico de entrada o descarga (verde claro) y salida o subida (azul)
en esta interfaz, con IP: 172.16.255.120. Por aquí se espera que el tráfico de subida sea
mayor que el de bajada, ya que por este enlace se da servicio wifi a los alumnos. Como
observamos, concuerda; y distinguimos los tiempos de mayor actividad: entre las 8 y las
13:00, sólo los días laborables. Como nos encontramos a finales de curso y el número
de portátiles es bajo, no observamos mucho tráfico, con una media de 48b/s para
descargas y 64b/s para subidas. Se puede apreciar en el gráfico anual cuando se ha
empezado la monitorización.
Interfaz eth1:
Representa el tráfico de entrada o descarga (verde claro) y salida o subida (azul)
en esta interfaz, con IP: 192.168.1.3. En esta interfaz la tasa de descarga es mayor a la
de subida, lo cual es razonable ya que por aquí se redirige el tráfico hacia la interfaz
anterior. Podemos advertir de picos, aunque muy puntuales, en ciertas horas del día,
sobre todo en las horas de mañana, y solo en días laborables, coincidiendo con el
gráfico anterior. Este esquema sugiere que en esta interfaz hay un tráfico bajo que nos
indica que la línea empleada es adecuada, aunque como en la anterior, nos encontramos
a finales de curso, cuando la actividad es poca.
28. Memoria RAM:
Representa la memoria RAM total
(azul) y libre (verde claro), se deduce que
el espacio que queda en blanco es la
memoria RAM ocupada o activa. Podemos
decir que el equipo que se monitoriza tiene
5 GB de memoria RAM en total, y más de
4 GB quedan libres. Este resultado se ha
observado en la mayoría o la totalidad del
tiempo en el que se ha realizado la
monitorización. A juzgar por estos datos
este equipo posee más que suficiente memoria RAM para llevar a cabo éstas y un mayor
número de tareas.
Carga del sistema:
Representa el promedio, en el último
minuto, del porcentaje de tiempo en el que
los procesadores (4) tuvieron actividad. En
este caso no se representan 2 elementos sino
1, la carga del sistema en tanto por ciento
(azul y verde claro). Como se aprecia, no se
numera hasta el 100% ya que no se podría
distinguir la gráfica que oscila entre el 1% y
el 0% la mayoría del tiempo. Se debe
resaltar que las peticiones que realiza
MRTG se producen cada 5 minutos (el
mínimo permitido), con lo que sería difícil
toparse con picos puntuales. Como apreciamos, en general, la carga de este sistema es
muy baja, teniendo en cuenta que dentro corre una máquina virtual que sirve de proxy,
ello supone un impacto casi nulo en el rendimiento de este equipo.
Teniendo en cuenta lo anterior, este equipo es suficientemente capaz de
gestionar el tráfico que pasa por él, y de funcionar correctamente ya que el rendimiento
no se ha visto afectado en ningún momento, y las gráficas dan a entender que es capaz
de soportar una mayor cantidad de actividad, sin la necesidad de reemplazar los
componentes mencionados.
29. CONCLUSIONES Y POSIBLES MEJORAS
Con este proyecto se ha conseguido explicar en qué consiste un sistema de
monitorización basado en SNMP y MRTG. Se ha aportado información sobre los
mecanismos empleados y he comprendido su funcionamiento y su potencial.
Sobre el sistema de monitorización propuesto, se ha conseguido implantarlo
físicamente, observar su actividad y extraer conclusiones. También he podido
profundizar en una configuración más avanzada para obtener resultados más
específicos. Sus principales ventajas son:
- Resulta una herramienta muy útil para tener un cierto control sobre la red y
los dispositivos que la conforman, dándonos la posibilidad de supervisarlos
de una forma sencilla y visual.
- Poder visualizar los estados de los diferentes elementos administrados, desde
cualquier punto de la red utilizando un navegador web.
- Su bajo consumo de recursos y el ínfimo impacto en el rendimiento en
general de la red.
Mejoras:
- Implementar la última versión del protocolo SNMP, SNMPv3 y advertir de
sus mejoras, sobretodo en cuanto a seguridad
- Configuración más avanzada del software MRTG, introducir el RRDtool y
las ventajas que ofrece.
- Introducción a otras herramientas de monitorización, NAGIOS, Zenoss,
Cacti…
- Implementación a mayor escala.
- Función de notificaciones mediante traps.
30. ANEXOS
MRTG
Opciones Globales del fichero de configuración
WorkDir: especifica el directorio dónde se deben crear las páginas web.
Refresh (actualizar): son los segundos que el navegador tarda en actualizar la página
con las gráficas. Si esto no está definido, el valor por defecto es 300 segundos (5 min).
LoadMIBs: carga los archivos de la MIB y dispone de sus OIDs, como nombres
simbólicos. Para mayor eficiencia, una caché de MIBs se mantiene en el WorkDir.
RunAsDaemon: permite el funcionamiento en modo demonio. El objetivo de este
modo es que ejecute MRTG de manera automática cada cierto tiempo. Este comportamiento
ahorra recursos ya que la carga y análisis de los archivos de configuración ocurre sólo una vez,
según los intervalos establecidos. Es necesario, en este modo, reiniciar el proceso para activar
los cambios en el archivo de configuración, cada vez que este sea modificado.
Si se desea que MRTG pueda ejecutarse bajo un usuario en particular (no se recomienda
para ejecutar MRTG como root) se puede emplear el siguiente comando:
mrtg --user=USUARIO --group=GRUPO mrtg.cfg
Opciones específicas de los Targets
Title: Título para la página HTML.
PageTop: Título que se añade a la parte superior de la página HTML generada. Tenga
en cuenta que puede tener varias líneas de texto, siempre y cuando la primera columna esté
vacía. Tenga en cuenta que las líneas de continuación terminan en la misma línea en la página
HTML. Si desea saltos de línea en el HTML generado usa ' n'.
MaxBytes: El máximo valor que las dos variables pueden alcanzar. Si se supera, se
ignora. Importante a la hora de acotar los gráficos
AbsMax: El valor máximo absoluto que se puede alcanzar, si se supera MaxBytes.
Unscaled: Por defecto, cada gráfico se escala verticalmente para hacer los datos
actuales visibles, incluso cuando son mucho menores que MaxBytes.
WithPeak: Por defecto los gráficos sólo contienen los valores medios de las variables
de control - normalmente las velocidades de transferencia para el tráfico entrante y saliente. La
siguiente opción instruye a MRTG para mostrar los valores de pico de cinco minutos en los
gráficos de [w]eekly, [m]onthly y [y]early.
Suppress: Por defecto, MRTG produce 4 gráficos. Con esta opción puedes suprimir la
generación de los gráficos seleccionados.
31. Options:
growright: Las gráficas crecen hacia la izquierda. Esta opción cambia la dirección del
crecimiento de las gráficas, el tiempo y los valores históricos.
bits: Todos los valores de las variables se multiplican por 8. Esto también afecta al
etiquetado “por defecto” y a las unidades del Target.
nopercent: No presenta las variables en porcentajes.
gauge: Trata los valores obtenidos de las mediciones del Target como “estado actual”,
y no como por defecto, incremento de los contadores. Esto sería útil para monitorizar cosas
como espacio de disco, carga de procesador, temperatura, etc.
YLegend: La etiqueta del eje Y de la gráfica. Tenga en cuenta que un texto demasiado
largo para caber en el gráfico será ignorado.
ShortLegend: Las unidades (por defecto b/s) a usar por Max, Average and Current.
Legend[1234IO]: Texto de las leyendas de colores.
FICHERO DE CONFIGURACIÓN (wifi.cfg)
# Created by
# /usr/bin/cfgmaker --output=/etc/mrtg/wifi.cfg public@172.16.255.120
### Global Config Options
# for Debian
WorkDir: /var/www/mrtg
### Global Defaults
# to get bits instead of bytes and graphs growing to the right
Options[_]: growright, bits
EnableIPv6: no
RunAsDaemon: yes
Interval: 5
Refresh: 305
#Suppress[_]: y
WithPeak[_]: m
XSize[_]: 250
YSize[_]: 100
######################################################################
# System: xen-wifi
# Description: Linux xen-wifi 2.6.26-2-xen-amd64 #1 SMP Tue Jan 25 06:13:50 UTC
# Contact: Root <root@localhost> (configure /etc/snmp/snmpd.local.conf)
# Location: Unknown (configure /etc/snmp/snmpd.local.conf)
######################################################################
33. <td>Maintainer:</td>
<td>Root <root@localhost> (configure /etc/snmp/snmpd.local.conf)</td>
</tr>
<tr>
<td>Description:</td>
<td>eth0 </td>
</tr>
<tr>
<td>ifType:</td>
<td>ethernetCsmacd (6)</td>
</tr>
<tr>
<td>ifName:</td>
<td>eth0</td>
</tr>
<tr>
<td>Max Speed:</td>
<td>1250.0 kBytes/s</td>
</tr>
<tr>
<td>Ip:</td>
<td>192.168.1.3 ()</td>
</tr>
</table>
</div>
####RAM
LoadMIBs: /usr/share/snmp/mibs/ UCD-SNMP-MIB.txt
Target[wifi_mem]: memAvailReal.0&memTotalReal.0:public@172.16.255.120:::::2
PageTop[wifi_mem]:<h1>Memoria RAM libre</h1>
Options[wifi_mem]: nopercent,gauge,growright
Title[wifi_mem]: Memoria Libre
MaxBytes[wifi_mem]: 265300000000
YLegend[wifi_mem]: bytes
ShortLegend[wifi_mem]: bytes
LegendI[wifi_mem]: Libre
LegendO[wifi_mem]: Total
Legend1[wifi_mem]: Memoria libre
Legend2[wifi_mem]: Memoria total
####Carga del sistema (suma de los 4 procesadores)
LoadMIBs: /usr/share/snmp/mibs/HOST-RESOURCES-MIB.txt
Target[wifi_load]: hrProcessorLoad.768&hrProcessorLoad.768:public@172.16.255.120:::::2 +
hrProcessorLoad.769&hrProcessorLoad.769:public@172.16.255.120:::::2 +
hrProcessorLoad.770&hrProcessorLoad.770:public@172.16.255.120:::::2 +
hrProcessorLoad.771&hrProcessorLoad.771:public@172.16.255.120:::::2
MaxBytes[wifi_load]: 10
AbsMax[wifi_load]: 100
Title[wifi_load]: Carga del sistema
PageTop[wifi_load]: <h1>Carga del sistema %</h1>
Unscaled[wifi_load]: ymwd
ShortLegend[wifi_load]: %
YLegend[wifi_load]: Carga
Legend1[wifi_load]: Carga del sistema
LegendI[wifi_load]: Activo
Options[wifi_load]: nopercent,growright,gauge
34. MIBs
/usr/share/snmp/mibs/HOST-RESOURCES-MIB.txt
hrProcessorLoad OBJECT-TYPE
SYNTAX Integer32 (0..100)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The average, over the last minute, of the percentage of time that this processor was not
idle. Implementations may approximate this one minute smoothing period if necessary."
::= { hrProcessorEntry 2 }
/usr/share/snmp/mibs/UCD-SNMP-MIB.txt
memTotalReal OBJECT-TYPE
SYNTAX Integer32
UNITS "kB"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total amount of real/physical memory installed on this host."
::= { memory 5 }
memAvailReal OBJECT-TYPE
SYNTAX Integer32
UNITS "kB"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The amount of real/physical memory currently unused or available."
::= { memory 6 }
35. NORMAS RFC
http://tools.ietf.org/rfc/index (Ingles)
http://www.normes-internet.com/normes.php?rfc=rfc1157&lang=es (Traducción al
castellano)
RFC 1155 - Structure and Identification of Management Information for the TCP/IP-based
Internets
RFC 1156 - Management Information Base for Network Management of TCP/IP-based internets
RFC 1157 - Simple Network Management Protocol (SNMP)
RFC 1213 - Management Information Base for Network Management of TCP/IP-based internets:
MIB-II
RFC 1441 - Introduction to version 2 of the Internet-standard Network Management Framework
RFC 3410 - Introduction and Applicability Statements for Internet Standard Management
Framework.
RFC 3411 - An Architecture for Describing Simple Network Management Protocol (SNMP)
Management Frameworks
RFC 3412 - Message Processing and Dispatching for the Simple Network Management Protocol
(SNMP)
RFC 3413 - Simple Network Management Protocol (SNMP) Application
RFC 3414 - User-based Security Model (USM) for version 3 of the Simple Network
Management Protocol (SNMPv3)
RFC 3415 - View-based Access Control Model (VACM) for the Simple Network Management
Protocol (SNMP)
RFC 3416 - Version 2 of the Protocol Operations for the Simple Network Management Protocol
(SNMP)
RFC 3417 - Transport Mappings for the Simple Network Management Protocol (SNMP)
RFC 3418 - Management Information Base (MIB) for the Simple Network Management Protocol
(SNMP)
RFC 3584 (Best current practice) - Coexistence between Version 1, Version 2, and Version 3 of
the Internet-standard Network Management Framework
36. GLOSARIO
Servidor web HTTP de código abierto para plataformas Unix (BSD,
Apache
GNU/Linux, etc.), Windows, Macintosh y otras.
C Lenguaje de programación
Common Management Information Protocol (Protocolo de administración de
CMIP
información común)
DES Data Encryption Standard (Estándar de Cirfrado de Datos)
DNS Domain Name Server
Librería para la creación dinámica de imágenes principalmente en formato
GD
PNG y JPEG
GNU/GPL GNU General Public License (Licencia Pública General de GNU)
Keyed-Hash Message Authentication Code (Código de Autenticación de
HMAC
Mensajes mediante una función Hash
HMAC-MD5 HMAC que utiliza el algoritmo MD5
HMAC-SHA-1 HMAC que utiliza el algoritmo SHA-1
HTTP Hypertext Transport Protocol (Protocolo de Trasnferencia de Hipertexto)
IETF Internet Engineering Task Force (Grupo de Trabajo en Ingeniería de Internet)
IP Internet Protocol (Protocolo de Internet)
MD5 Message-Digest Algorithm 5 (Algoritmo de Resumen de Mensaje 5)
MIB Management Information Base (Base de Información de Administración)
MRTG Multi Router Traffic Grapher
NMS Network Management System (Systema de Administración de Red)
OSI Open Systems Interconnection
PDU Protocol Data Unit (Unidad de Datos de Protocolo)
Perl Lenguaje de programación
Portable Network Graphic. Formato gráfico basado en un algoritmo de
PNG
compresión sin pérdidas
RFC Request for Comments
SHA Secure Hash Algorithm (Algoritmo de Hash Seguro)
Structure Management Information (Estructura de Administración de la
SMI
Información)
Simple Network Management Protocol (Protocolo simple de administración de
SNMP
redes)
SSH Secure Shell (Intérprete de órdenes seguro)
TCP Transmission Control Protocol (Protocolo de Datagrama de Usuario)
Ubuntu Distribución de Linux basada en Debian
UDP User Datagram Protocol (Protocolo de Datagrama de Usuario)
