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)

Í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

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.

- 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.

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.

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).

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.

Figura 1.1. Muestra la relación entre el NMS y el Agente

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.

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

SNMPv1

Se desarrolló debido a la creciente necesidad de un mecanismo simple y

estandarizado para la gestión y monitoreo de los equipos de la red y que no supusiese cambios en el rendimiento de las redes.

SNMPv2,

SNMPv2c

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 seguridad basado en comunidades. Actualmente es el más empleado

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.

SNMPv3

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

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

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:

- 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

SNMPv1 Usa el modelo basado en comunidades

Community string

No No autenticación No encriptación

SNMPv2,

SNMPv2c Usa el modelo basado en

comunidades

Community

string No

No autenticación

No encriptación

SNMPv3 Utiliza nombres de usuarios

para comprobar la autenticación.

USM (User

Security Model) No

No autenticación

No encriptación

SNMPv3

Variante de SNMPv3 que

provee una autenticación

basada en los algoritmos de HMAC-SHA o HMAC-

MD5

USM + MD5 o

SHA No

Autenticación

No encriptación

SNMPv3

Configuración más segura

de SNMPv3 que provee

algoritmos de autenticación

y encriptación DES de 56 bits

USM + MD5 o

SHA DES Autenticación

Encriptación

Figura 1.4. Tabla de los modelos y niveles de seguridad de SNMP

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

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”

La siguiente tabla recoge una breve descripción de los grupos definidos en la

“MIB-II”:

Figura 1.7. Tabla conceptos de MIB-II

Figura 1.9. Estructura de PDU

Figura 1.8. Operaciones SNMP

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.

get-next-request Solicita el valor de una variable sin conocer su nombre exacto.

Útil para búsquedas secuenciales dentro de una rama MIB.

get-bulk-request Solicita grandes bloques de datos, como por ejemplo varias

filas de un subárbol MIB.

get-response Respuesta por parte del Agente a las operaciones de get-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

trap Mensaje no solicitado enviado por un Agente a un NMS cuando ocurre algún evento

Los mensajes utilizados por SNMP poseen el siguiente formato:

- 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.

- 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

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

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.

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.

Figura 2.1. Gráfica creada con MRTG

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.

Figura 2.2. Ejemplo de fichero de configuración de MRTG

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.

Opciones globales, variables que

afectan a todas las configuraciones

siguientes que se encuentran en el

fichero.

Comando cfgmaker con el que se ha

creado el fichero de mrtg.cfg.

Figura 2.3. Ejemplo implementación de MRTG

NMS - MRTG

Agente Agente

Agente

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

3. PROPUESTA DE SISTEMA DE MONITORIZACIÓN

Esquema de red

10.10.127.223/24

172.16.255.120/16

A.25

A.34

192.168.25.0/24

172.16.255.130/16

192.168.1.3

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

Figura 3.1. Esquema de red

NMS -MRTG

Agente

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

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.

Archivos de configuración:

En este archivo debemos eliminar: 127.0.0.1

(con esto le decimos al Agente que escuche a peticiones por todos los puertos)

Se configura de la siguiente manera:

####

# sec. name source community com2sec readonly 172.16.0.0/16 public com2sec readwrite 172.16.255.130 private #### # sec.model sec.name group ROGroup v1 readonly group ROGroup v2c readonly group ROGroup usm readonly group RWGroup v1 readwrite group RWGroup v2c readwrite group RWGroup usm readwrite #### # incl/excl subtree mask 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 access ROGroup "" any noauth exact all none none access RWGroup "" any noauth exact all all none #### # System contact information syslocation Proxy-Wifi (configure /etc/snmp/snmpd.local.conf) syscontact Root <root@localhost> (configure /etc/snmp/snmpd.local.conf)

Iniciar el agente con:

apt-get install snmpd

/etc/defaults/snmpd

/etc/snmp/snmpd.conf

/etc/init.d/snmpd start

Se describen las reglas de seguridad,

asignando las comunidades y las redes o

equipos a los que se permite el acceso

Se crean grupos asociando las redes y las versiones

a emplear. Se proponen estos nombres distinguibles

fácilmente según los permisos que se les quiere

proporcionar.

Se asignan las ramas MIB que se permiten ver

Ahora se asignan los permisos (lectura,

escritura, notificación) a los grupos

creados anteriormente

Opcionalmente se puede aportar información

de contacto, útil para pruebas de conexión

IMPLEMENTACIÓN DE SNMP (NMS)

Necesitamos el siguiente paquete para realizar las consultas al agente mediante

las operaciones de SNMP:

Para comprobar si SNMP está funcionando correctamente utilizamos alguna

operación de snmp:

Y devuelve:

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:

apt-get install snmp

/usr/share/snmp/mibs/

snmpget –v2c –c public 172.16.255.120 system.sysDescr.0

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

Figura 3.3. Ficheros MIB

Operación Versión Comunidad IP del Target OID

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:

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.

2. Para guardar los archivos de configuración generados por cfgmaker.

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.

Ejecutamos el siguiente comando para crear la página web index.html, con el

archivo de configuración MRTG especificado:

Ahora ejecutamos el siguiente comando para establecer la variable de entorno e

iniciar el demonio de MRTG

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.

cfgmaker --output /etc/mrtg/wifi.cfg public@172.16.255.121

indexmaker --output=/var/www/mrtg/index.html /etc/mrtg/wifi.cfg

env LANG=C /usr/bin/mrtg /etc/mrtg/wifi.cfg

apt-get install mrtg apache2

mkdir –p /var/www/mrtg

mkdir /etc/mrtg

4. ANÁLISIS

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

Figura 4.1. Gráficos generados por MRTG

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.

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.

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.

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.

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)

######################################################################

########################

### Interface 12 >> Descr: 'eth0' | Name: 'eth0' | Ip: '172.16.255.120' | Eth: '$ Target[172.16.255.120_eth0]: #eth0:public@172.16.255.120:

SetEnv[172.16.255.120_eth0]: MRTG_INT_IP="172.16.255.120" MRTG_INT_DESCR="eth0"

MaxBytes[172.16.255.120_eth0]: 1250000 Title[172.16.255.120_eth0]: Traffic Analysis for eth0 -- xen-wifi

PageTop[172.16.255.120_eth0]: <h1>Traffic Analysis for eth0 -- xen-wifi</h1>

<div id="sysdetails">

<table> <tr>

<td>System:</td>

<td>xen-wifi in Unknown (configure /etc/snmp/snmpd.local.conf)</td> </tr>

<tr>

<td>Maintainer:</td> <td>Root &lt;root@localhost&gt; (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>172.16.255.120 ()</td> </tr>

</table>

</div>

### Interface 13 >> Descr: 'eth1' | Name: 'eth1' | Ip: '192.168.1.3' | Eth: '' ### Target[172.16.255.120_eth1]: #eth1:public@172.16.255.120:

SetEnv[172.16.255.120_eth1]: MRTG_INT_IP="192.168.1.3" MRTG_INT_DESCR="eth1"

MaxBytes[172.16.255.120_eth1]: 1250000

Title[172.16.255.120_eth1]: Traffic Analysis for eth1 -- xen-wifi PageTop[172.16.255.120_eth1]: <h1>Traffic Analysis for eth1 -- xen-wifi</h1>

<div id="sysdetails">

<table> <tr>

<td>System:</td>

<td>xen-wifi in Unknown (configure /etc/snmp/snmpd.local.conf)</td>

</tr> <tr>

<td>Maintainer:</td>

<td>Root &lt;root@localhost&gt; (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]: &nbsp;Libre&nbsp;

LegendO[wifi_mem]: &nbsp;Total&nbsp;

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

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 }

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

GLOSARIO

Apache Servidor web HTTP de código abierto para plataformas Unix (BSD,

GNU/Linux, etc.), Windows, Macintosh y otras.

C Lenguaje de programación

CMIP Common Management Information Protocol (Protocolo de administración de

información común)

DES Data Encryption Standard (Estándar de Cirfrado de Datos)

DNS Domain Name Server

GD Librería para la creación dinámica de imágenes principalmente en formato

PNG y JPEG

GNU/GPL GNU General Public License (Licencia Pública General de GNU)

HMAC Keyed-Hash Message Authentication Code (Código de Autenticación de

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

PNG Portable Network Graphic. Formato gráfico basado en un algoritmo de

compresión sin pérdidas

RFC Request for Comments

SHA Secure Hash Algorithm (Algoritmo de Hash Seguro)

SMI Structure Management Information (Estructura de Administración de la

Información)

SNMP Simple Network Management Protocol (Protocolo simple de administración de

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)

USM User-based Security Model (Modelo de seguridad Basado en Usuarios)

REFERENCIAS

Monitorización y SNMP:

http://docstore.mik.ua/orelly/networking_2ndEd/snmp/index.htm (Ingles)

https://www.ac.usc.es/docencia/ASRII/Tema_1html/index.html

http://es.wikipedia.org/wiki/Simple_Network_Management_Protocol

https://www.ac.usc.es/docencia/ASRII/Tema_1html/node13.html#SECTION000322000000000

00000

http://www.alcancelibre.org/staticpages/index.php/como-linux-snmp

http://www.coit.es/publicac/publbit/bit102/quees.htm

http://www2.linuxparatodos.net/web/comunidad/base-de-conocimiento

https://support.ipmonitor.com/snmp_center.aspx (Ingles)

http://docwiki.cisco.com/wiki/Simple_Network_Management_Protocol (Ingles)

http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_1-3/snmpv3.html

(Ingles)

http://www.ramonmillan.com/tutoriales/snmpv3.php#mejorassnmpv3

http://www.slideshare.net/lplinoperez/snmpv3-6601028

MRTG

http://libertonia.escomposlinux.org/story/2003/1/17/224253/241

http://linuxbasement.com/content/mrtg-ubuntu-server (Ingles)

http://www.ecualug.org/2005/06/23/blog/danmk3/guia_para_puesta_en_funcionamiento_a_

mrtg

http://www2.linuxparatodos.net/web/comunidad/base-de-conocimiento/-

/wiki/Base%20de%20Conocimiento/MRTG+(Multi+Router+Traffic+Grapher)+en+Debian-

Ubuntu

http://www.debianhelp.co.uk/mrtg.htm (Ingles)

http://oss.oetiker.ch/mrtg/doc/mrtg-reference.en.html (Ingles)

http://www.enterastream.com/whitepapers/mrtg/mrtg-manual.html (Ingles)

RRDtool

http://oss.oetiker.ch/mrtg/doc/mrtg-rrd.en.html (Ingles)

http://oss.oetiker.ch/rrdtool/ (Ingles)

Configuración en Ubuntu

http://pablosarubbi.blogspot.com/2008/12/configuracion-de-snmpd-en-ubuntu.html

http://www.it-slav.net/blogs/2009/02/05/install-and-configure-snmp-on-ubuntu/ (Ingles)

http://www.nosolounix.com/2010/05/instalar-y-configurar-mrtg-y-snmp-en.html

Listas OID

http://oss.oetiker.ch/mrtg-trac/wiki/OidList (Ingles)

https://support.ipmonitor.com/mibs_byoidtree.aspx?oid=1.3.6.1.2.1.2#h (Ingles)