Palabras clave— SNMP, MRTG, OID, MIB, CISCO

I. INTRODUCCIÓN

En el documento se presenta un caso estudio sobre la monitorización de un router de la escuela utilizando MRTG (Multi Router Traffic Grapher). Con ello se pretende lograr que el lector comprenda la necesidad y la importancia de la monitorización para gestionar distintos dispositivos. Para ello, a lo largo de todo el documento se dan en primer lugar unas nociones teóricas, con el fin de explicar y justificar el uso de cada una de las aplicaciones utilizadas en los pasos realizados; en segundo lugar, se explican los resultados obtenidos para el caso de estudio que nos ocupa sobre cada una de dichas aplicaciones.

Para realizar esta tarea hemos dividido en cuatro puntos nuestro informe. En el punto siguiente se presenta el contexto teórico de la gestión de redes. Posteriormente se presentan las nociones básicas sobre el protocolo de gestión SNMP (Simple Network Management Protocol), para terminar hablando de las herramientas usadas en la monitorización, y en concreto, en el caso que nos compete: MRTG.

En el punto tres nos centramos en los pasos seguidos el caso de estudio del laboratorio. En primer lugar explicamos los pasos seguidos en la instalación de MRTG, Posteriormente, explicamos el significado del árbol de OID (Object Identificier), y explicamos como a partir de este se pueden averiguar parámetros fundamentales relacionados con la gestión de dispositivos gracias a MIB (Management Information Base), En el último subapartado de este punto realizamos la configuración para la monitorización, además explicamos el uso de otras herramientas como el Idexmaker o el crontab de Linux.

Para finalizar adjuntamos las capturas obtenidas con el uso MRTG.

II. GESTIÓN SISTEMAS DE RED: MONITORIZACIÓN MRTG

El incipiente crecimiento de las redes de comunicación en los últimos años ha producido que la información manejada de los sistemas de información sea cada vez mayor y esté localizada de forma dispersa, además de este problema de volumen existe cierta complejidad de los recursos a gestionar debido a la

heterogeneidad de los múltiples fabricantes de tecnologías existentes en el mercado. La gestión de red está orientada a mejorar la eficiencia, la disponibilidad y desempeño de las redes.

Los sistemas de gestión de red han ido evolucionando con el tiempo, en un principio la gestión autónoma gestionaba de forma local un nodo, más tarde la gestión homogénea se usaba en una red constituida por dispositivos de la misma clase, pero hoy en día es obligatorio una gestión heterogénea puesto que los elementos que la constituyen son diferentes, el problema que surge aquí es la ineficiencia debida a la gestión que se ha de hacer en cada red, y la complejidad que conlleva, sin olvidarse del alto coste que supone.

Por ello hoy se habla de gestión integrada cuyo

concepto se basa en la normalización de la comunicación, esto es un protocolo para el dialogo entre elementos de red y el gestor, y de la información a intercambiar. Lo que se consigue con una gestión integrada es solventar los problemas asociados a la gestión heterogénea el uso de

Actualmente el ámbito donde es de vital importancia la gestión de redes es el empresarial, puesto que depende más que nunca de su infraestructura informática y con una buena gestión de red la empresa obtiene una calidad de servicio exigida a un precio razonable, podemos decir que en la mayoría de los casos la gestión de red es el eje principal del negocio. Además ante la presencia de cualquier problema se disminuye el tiempo de detección de fallos de hardware y de las posibles reparaciones. El objetivo es, por tanto, asegurar un uso de la red a los usuarios, desempeño operacional y una explotación óptima de los servicios de telecomunicaciones.

Para llevar a cabo la gestión de las redes son necesarios ciertos recursos que ayuden a facilitar esta tarea, se dispone de:

Recursos humanos que son los encargados de que la red funcione de forma correcta, es necesario que dispongan de una buena cualificación y experiencia.

Métodos de trabajo en los que se describan las actuaciones a llevar a cabo ante determinados problemas.

CTMx03 Componentes:

Laura de la Cuesta, Alberto González, Ana María Lozano, Diego Rioja.

Monitorización vía MRTG

Desarrollo tecnológico donde se especifica qué diseño de red se ha implementado con qué perspectivas de diseño y puesta a punto de la misma.

Herramientas de gestión que faciliten la exportación de datos para su tratamiento. El presente documento se centrará en una de estas herramientas para la gestión de la red.

Los elementos que forman parte de un sistema de gestión de red son un gestor (NMS, Network Management Station) donde se ejecuta la aplicación gestora, se encarga de pedir datos de interés relevante de la red, un agente (MN, Managed Nodes) que responda a dichas peticiones y un protocolo de gestión en el que se definan unas reglas normalizadas para dicha comunicación (SNMP, Simple Network Management Protocol). Por ultimo es necesaria una base de información de gestión (MIB) en los dispositivos que contiene información de los mismos.

Ilustración 1 Elementos de un sistema de gestión

Para definir el formato con el que se va a definir y construir una MIB se utiliza la SMI (Estructura de la información de gestión) que especifica el tipo de datos que puede ser usado en la MIB y la manera de nombrar sus objetos.

Mediante el protocolo SNMP se obtienen consultas a cualquier dispositivo de la red para obtener el estado del mismo, con estado nos referimos tanto a variables estándares como a variables especificas del fabricante, en nuestro caso las consultas se realizarán al router de la escuela, y el parámetro sobre el que se obtendrán datos serán referentes a la ocupación de la memoria del router, si bien en un principio se pensó en otros que finalmente no se pudieron obtener y cuyas razones se expondrán más adelante.

La monitorización del tráfico de una red no es posible hacerla a mano por lo que se requerirá el uso de herramientas con el fin de obtener información relevante en una red, aunque en este documento tan sólo se llevará a cabo la monitorización de un parámetro, en general, el objetivo no es otro que el de detección de anomalías y

conocimiento del comportamiento de los recursos de la red.

La herramienta que se va utilizar para la monitorización del tráfico es MRTG, aunque existen otras como RRDTool, Cacto o Nagios.

Aunque MRTG en un principio fue diseñado para adquirir información sobre el ancho de banda relacionada a los interfaces de red en un host, hoy en día es capaz de sondear múltiples variables mediante el identificador objeto (siempre que tengan el soporte del protocolo SNMP activado). MRTG es capaz de medir el tráfico, el consumo de ancho de banda, y detectar anomalías en la conexión, además de la gestión de fallos, configuración incidencias, rendimiento y seguridad.

MRTG genera gráficos en formato HTML cada cierto tiempo, de forma que estos se actualizan y son almacenados de forma local o remota, la ventaja del formato HTML es que cualquier usuario que disponga de un navegador web podrá visualizar la información. MRTG es de libre distribución y compatible con los S.O. Windows, Unix y Linux [3]. El desarrollo de la práctica se ha llevado a cabo sobre este último S.O.

Algunas de las limitaciones de MRTG son que no es capaz de proveer información de la aplicación o del host que puede estar causando el cuello de botella, y que no ofrece información sobre el tipo de tráfico y estadísticas de los protocolos [2].

III. Caso de estudio

El objetivo principal de la práctica es el de monitorizar el tráfico de red del router de la escuela, para introducirmos así en el mundo de la gestión, comprendiendo mejor el funcionamiento y la relación entre OID y MIB. Para ello hemos tenido que instalar, configurar y poner en marcha la aplicación de monitorización MRTG. Una vez instalado y configurado el MRTG, éste nos muestra el tráfico de red del router de la ETSIT. Nosotros, intentamos ir un paso mas allá y tratamos de abordar la monitorización de otras variables de gestión que no estén necesariamente relacionadas con el tráfico en la red, como son los paquetes IP enviados a través del router (parámetro tipo Counter) o el número de bytes de memoria usados por el procesador o la E/S. En este proceso de monitorización han surgido diversos problemas de los que también se trata en este apartado, el más importante de todos ellos es la imposibilidad de monitorizar los paquetes IP enviados, hecho sobre el que se discute al final de este punto.

 Para realizar la monitorización hemos contado con el

material del laboratorio L2009 de la escuela. En concreto, el dispositivo a monitorizar es el router balbas de la

escuela. Se trata de un router CISCO modelo C3550, versión 12.1(22)EA10b.

A. INSTALACIÓN

El primer paso es instalar una serie de librerías para que la aplicación MRTG pueda funcionar usando el protocolo SNMP. Dichas librerías [http://oss.oetiker.ch/mrtg/doc/mrtg-unix-guide.en.html] son:

Gd: Librería para crear gráficos [http://www.boutell.com/gd/]

Libpng: Es un librería requerida por gd para producir archivos gráficos en formato PNG. [http://www.libpng.org/pub/png/libpng.html]

Zlib: Es otra librería que necesita libpng para comprimir los gráficos que ésta ha creado. [http://www.gzip.org/zlib]

Una vez descargadas de cada uno de los enlaces anteriores, y previamente a su instalación se compilan dichas librerías tal y como se indica en [http://oss.oetiker.ch/mrtg/doc/mrtg-unix-guide.en.html]. Para instalar las librerías usamos los comandos:

configure --prefix /home/labs/ctm2/ctm2x03/MRTG, makemake install

No entramos en detalles sobre la instalación ya que en [3] vienen perfectamente explicadas. Lo único que podemos comentar es que hay que tener cuidado a la hora de compilar el software descargado ya que puede existir incompatibilidad de versiones, y pedirnos librerías que no se encuentran en determinadas versiones.

B. Estudio árbol OIDs.

Se define el OID (Object Identificier) en la recomendación X.208 (ASN.1) de la ITU-T [4]. De dicha recomendación podemos extraer la siguiente definición como conclusión: Un OID es un código numérico que describe en forma única cierto grupo de información.

 Se utilizan estos identificadores para multitud de

protocolos; sus usos mas destacados son los siguientes [5]: 

        Objetos y atributos que se gestionan vía SNMP.        Clases, sintaxis y atributos en el Directorio (LDAP)        Árboles de indexación en CIP (Common Indexing Protocol)        Elementos dentro de una PKI (Public Key Infraestructure)

 En nuestro caso, nos centramos en los OID como

identificador de objetos que se gestionan vía SNMP.

Antes de embarcarnos en los OIDs que nos conciernen nos parece necesario explicar un poco mas la idea del OID, cuya estructura es en forma de árbol. De esta forma se describen los diferentes nodos estructurales como "ramas" del árbol de las que cuelgan nuevas "ramas".  Cada "rama" será un número separado por puntos de su "rama" superior e inferior.

Cada uno de estos nodos estructurales tiene asignado un nombre MIB del que hablaremos mas tarde. Así vamos avanzando por las distintas ramas del árbol OID hasta llegar a los nodos finales, conocidos como "nodos hoja", que son los nodos con información basados en la macro OBJECT TYPE [6].

 Según lo explicado anteriormente, la MIB actúa como

traductor de OIDS para extraer información SNMP. Para lograr comprender la información que se nos ofrece es necesário conocer la estructura de los valores de la macro OBJECT TYPE [7], mencionada anteriormente y en la que nos centraremos una vez escogido un OID para monitorizar.

 El primer paso es saber sobre que tipo de dispositivo

queremos realizar la monitorización. En concreto, debemos conocer la marca y modelo del dispositivo en cuestión. En nuestro caso, debemos conocer dichos parámetros del router de la escuela. Con tal fin ejecutamos el comando snmpget según se muestra: [8] snmpget -v1 -c [Community string][IP Router] [OID] Donde las opciones que utilizamos son: -v1 : Especifica la versión del protocolo SNMP a utilizar, en nuestro caso usamos la 1 (RFCs 1155-1157).-c : Especifica la "community string" o password, que en nuestro caso será ltmlab. Una "community string" es una contraseña SNMP que se utiliza para consultas SNMP, en nuestro caso para leer o escribir a la MIB.

Volviendo a nuestro caso de estudio Ltmlab es la contraseña SNMP y  157.88.130.250 es la direción IP del router que estamos gestionando (máquina balbas de la escuela). En cuanto al OID a introducir para conocer los parámetros del router, introducimos directamente el MIB: system.sysDescr.0. Acudimos a la web de cisco para ver el significado de este MIB y nos encontramos con que es un objeto de tipo DisplayString en el que se almacena información acerca del disposivo a consultar, como puede ser el nombre completo o la versión y tipo de hardware y software. Por lo tanto ejecutamos snmpget de la siguiente forma: 

snmpget -v1 -c ltmlab 157.88.130.250 system.sysDescr.0 

Como era de esperar nos aparece una descripción del router, donde se nos indica que es un router CISCO:

SNMPv2-MIB::sysDescr.0 = STRING: Cisco Internetwork Operating System Software IOS (tm) C3550 Software (C3550-I5Q3L2-M), Version 12.1(22)EA10b, RELEASE SOFTWARE (fc1) Copyright (c) 1986-2007 by cisco Systems, Inc. Compiled Thu 25-Oct-07 20:56 by antonino.

A continuación entramos en la web de CISCO [10], donde introduciremos los parámetros obtenidos para obtener las MIBs correspondientes:     RELEASE: 12.1(22)EA10b  Platform Family:  C3550  Feature Set: C3550 EMI IOS IMAGE

Ilustración 2 Captura de la página de CISCO

 Asi que, recorrimos la rama CISCO del árbol de OIDS,

cuya rama raíz es:  iso (1)  .  org (3)  .  dod (6)  .  internet (1) . private (4) . entrerprise (1) . cisco (9) 

De estos niveles de ramas del árbol OID podemos sacar en claro que las MIBs que consultaremos son privadas. (Lo cual es lógico ya que el dispositivo a monitorizar proviene de la empresa privada CISCO). Si miramos las etiquetas macro nos aparecen unas líneas como las que siguen:               entrerprises OBJECT IDENTIFIER                            :: = { internet private(4) 1} 

En las ramas posteriores se ofrece información acerca de la gestión de diversos dispositivos y de la red, acudimos a la web [11] para recorrer este árbol en busca de un parámetro interesante a monitorizar. En concreto, podríamos utilizar los datos tipo Gauge o tipo Counter. El tipo Counter es un número entero, sin signo, de 32 bits. Representa un entero no negativo que se incrementa monótonamente hasta alcanzar un valor máximo, luego se reinicia y vuelve a comenzar desde cero. Por otro lado, el tipo Gauge representa un entero no negativo que puede

incrementarse o decrementarse sin sobrepasar un valor máximo, que al igual que el Counter está fijado en 232-1. 

Tras recorrer el árbol de OID´s, nos hemos centrado en dos parámetro tipo Counter y en dos parámetros tipo Gauge. Explicaremos cada uno de ellos: 

En cuanto a los valores tipo Counter, sus OID´s son: 1.3.6.1.4.1.9.2.2.1.1.43.33 y 1.3.6.1.4.1.9.2.2.1.1.43.34 

Escogimos estos en primer lugar por el interés que nos despertaba su nodo estructural: 1.3.6.1.4.1.9.2.2.1.1.43. Si introducimos este OID en el traductor de CISCO: [13] nos aparece en primer lugar las ramas anteriores de las que cuelga, que partiendo de la rama de Cisco son: local(2) . Linterfaces (2) . Liftable (1) . LifEntry(1) 

Donde lifTable es una tabla con las entradas a la interfaz del router Cisco, y lifEntry es una fila de la tabla anterior que contiene una colección de objetos adicionales de la interfaz. De ella analizamos locIfipOutPkts (43), que son los paquetes de salida del protocolo ip. Sobre esta rama se nos ofrece la siguiente información:

 

Tabla 1 OID 1.3.6.1.4.1.9.2.2.1.1.43

Specific Object InformatiomObject locIfipOutPktsOID 1.3.6.1.4.1.9.2.2.1.1.43Tipo Counter

Permisos read-onlyEstado mandatoryMIB OLD-CISCO-INTERFACES-

MIBDescripción ip protocol output packet

count 

De esta tabla podemos extraer en la fila de permisos que el parámetro es de solo lectura, en la fila de estado, se nos indica que es obligatorio incorporar este objeto si se quiere ser compatible con MIBII (aunque luego no se utilice).

 Una vez escogida una rama de interés utilizamos el

comando snmpwalk de la siguiente forma: snmpwalk -v1 -c [Community string] [IP ROUTER] [OID] 

Las opciones a utilzar se pueden encontrar tanto en el manual de snmpwalk [14] como en el de snmpcmd, nosotros usamos las mismas que al ejecutar snmpget (-v1 –c [community string]. Por lo tanto ejecutamos:  

ctm2x03@balbas:~> snmpwalk -v1 -c ltmlab 157.88.130.250 1.3.6.1.4.1.9.2.2.1.1.43  

Obtenemos como respuesta al comando un recorrido por todos los OIDs que cuelgan de esa rama, que este caso son “nodos hoja” pues ya nos ofrecen información. Mostramos un fragmento de la captura con las dos entradas de los dos OID Counter a monitorizar: SNMPv2-SMI::enterprises.9.2.2.1.1.43.33 = Counter32: 1201075

SNMPv2-SMI::enterprises.9.2.2.1.1.43.34 = Counter32: 1200819

Para ver si los parámetros escogidos varían de forma apreciable ejecutamos repetidamente snmpwalk.

En cuanto los OIDs tipo Gauge, la mayoría de los encontrado no nos dan permisos de lectura o no están implementados en balbas. Encontramos los siguientes OIDs válidos:

1.3.6.1.4.1.9.9.48.1.1.1.5.1 y 1.3.6.1.4.1.9.9.48.1.1.1.5.2

Las ramas de las que cuelga partiendo de la rama CISCO del router a analizar son las siguientes:

ciscoMgmt(9) . CiscoMemoryPoolMIB (48) ciscoMemoryPoolObject(1) . CiscoMemoryPoolTable(1). CiscoMemoryPoolEntry(1) . CiscoMemoryPoolUsed (5)

Los objetos pertenecientes a esta OID se utilizaran para medir en bytes las memoria usada. En concreto, los OIDs escogidos nos hablan del la memoria usada por el procesador (1.3.6.1.4.1.9.9.48.1.1.1.5.1 ) y usada por la E/S (1.3.6.1.4.1.9.9.48.1.1.1.5.2 )

Tabla 2 OID 1.3.6.1.4.1.9.9.48.1.1.1.5

Specific Object InformatiomObject ciscoMemoryPoolUsed

OID 1.3.6.1.4.1.9.9.48.1.1.1.5

Tipo Gauge32Permisos read-onlyEstado currentMIB OLD-MEMORY-POOL-MIB

  

Descripción

"Indicates the number of bytes from the memory pool that are currently in use by

applications on the managed device”

 

De esta tabla podemos destacar el valor del campo estado, que en este caso es current, lo que nos indica que la definición es actual.

En los pasos posteriores actuamos de la misma manera que con los campos tipo Counter: ejecutamos snmpwalk en la rama elegida repetidas veces y comprobamos que los dos OIDs seleccionados para la monitorización varían con bastante periodicidad. Es importante reiterar que, al tratarse en este caso de datos tipo Gauge, estos aumentan y disminuyen.

C. Configuración para la monitorización

Una vez elegidos los parámetros a monitorizar, creamos un archivo de configuración que se adapte a nuestras necesidades. Creamos  nuestro archivo de configuración ayudándonos del script cfgmaker.cfg  incluido en MRTG [http://oss.oetiker.ch/mrtg/doc/cfgmaker.en.html], que nos evita tener que crear el fichero de configuración de forma manual. Con todo ello el comando ejecutado quedaría de la siguiente manera: ./cfgmaker --global 'WorkDir: /home/labs/ctm2/ctm2x03/MRTG/salida' --global 'Options[_]: bits,growright' --output /home/labs/ctm2/ctmx/MRTG/cfg/mrtg.cfg ltmlab@157.88.130.250 

En él hemos indicado la ruta del directorio de trabajo que hemos creado (--output), la ruta en la que queremos guardar las gráficas generadas por MRTG (WorkDir) y podemos incluir algunas opciones para la visualización de las gráficas (Options). En nuestro caso hemos incluido que los datos se muestren en bits (bits) y que las gráficas crezcan de derecha a izquierda (growright). Por último tenemos que incluir también la dirección del router del que queremos llevar a cabo la monitorización de sus parámetros (157.88.130.250), además del nombre de la comunidad (ltmlab).

 El problema presentado en este punto de la

monitorización está en que deberemos ejecutar el mrtg.cfg cada vez que queramos obtener datos con los que el MRTG pueda realizar las gráficas. Para evitar tener que ejecutarlo de forma manual hacemos uso de otra herramienta de linux: el cron o para ser mas concretos, el

fichero crontab. Se trata de un administrador regular de procesos en segundo plano que ejecuta procesos a intervalos regulares. Si se consulta el manual de línea de cron [15] se observa que para modificar el fichero contab se debe ejecutar el comando seguido de la opción –e (edit): 

crontab -e 

En dicho fichero tenemos diferentes campos que nos permiten elegir la frecuencia con la que queremos ejecutar el mrtg.cfg. En primer lugar está el número de minutos en el que se quiere ejecutar, después las horas, el día del mes, el mes y el día de la semana. Mostramos un esquema explicativo: minuto (0-59),                                                            |  hora (0-23),                                                              |  | día del mes (1-31),                                              |  |  |    mes (1-12),                                                  |  |  |  |    día de la semana (0-6 donde 0=Domingo)   |  |   |   |   |                                                                   5 *  *  *  * 

Nosotros hemos escogido ejecutar el archivo de configuración todos los días cada 5 minutos, los asteriscos en el resto de las opciones indican que se activan todas las posibilidades, es decir, cada hora de cada dia de la semana de cada mes. Para ello modificamos el crontab de la siguiente manera: */5 * * * * /home/labs/ctm2/ctm2x03/MRTG/mrtg-2.16.3/bin/mrtg /home/labs/ctm2/ctm2x03/MRTG/cfg/mrtg.cfg. 

El último paso, al igual que el anterior se  realiza para facilitar el proceso de monitorización. En concreto buscamos ordenar en un solo fichero html las numerosas gráficas generadas para poder visualizarlas todas de una manera más sencilla. Para ello utilizamos la herramienta indexmaker de la siguiente forma [3]: 

indexmaker [options] mrtg.cfg [other.cfg ...] Donde en las opciones especificamos: --output: Ruta y nombre del fichero html de salida, que nosotros llamamos indice. Ejecutando por tanto lo siguiente en la línea de comandos: ./indexmaker /home/labs/ctm2/ctm2x03/MRTG/cfg/mrtg.cfg --output /home/labs/ctm2/ctm2x03/MRTG/salida/indice Para monitorizar otras variables de gestión del router de la ETSIT no necesariamente relacionadas con el tráfico de red, debemos modificar el archivo de configuración mrtg.cfg, añadiendo el código necesario para monitorizar dicho parámetro. En un principio hemos intentado monitorizar los paquetes de salida del protocolo ip. Al realizar la monitorización no se mostraba ninguna actividad en las gráficas, por lo que hicimos algunas pruebas para resolver el problema: Capturamos el tráfico UDP en el puerto usado por SNMP (161) [7] utilizando la herramienta TCPdump, y observamos que únicamente se capturaban los paquetes del

OID: 1.3.6.1.4.1.9.2.2.1.1.43.33. Consultamos diversa bibliografía en línea para intentar comprender más afondo como monitorizaba MRTG pero no encontramos ninguna conclusión clara. Por tanto, ya que no conseguimos una correcta monitorización con OID´s de tipo counter, usamos los OID tipo gauge32 también usados por MTRG_B, con los cuales sí que obtenemos una correcta visualización de las gráficas. Para ello hemos añadido el siguiente código al final del archivo mrtg.cfg:

Target[157.88.130.250]:1.3.6.1.4.1.9.9.48.1.1.1.5.1&1.3.6.1.4.1.9.9.48.1.1.1.5.2:ltmlab@157.88.130.250:MaxBytes[157.88.130.250]: 125000000Title[157.88.130.250]: Traffic Analysis for  parametro seleccionado -- va-3550-tel-PBI-2PageTop[157.88.130.250]: <h1>Traffic Analysis for parametro seleccionado – va-3550-tel-PBI-2 De éste código lo mas interesante es la siguiente línea [3]:

Target[myrouter]:OID1&OID2:public@myrouter:

Donde myrouter es la dirección IP del router que estamos monitorizando (157.88.130.250), los OID corresponden a los parámetros que miden la memoria usada por el procesador del router (1.3.6.1.4.1.9.9.48.1.1.1.5.1) y la memoria usada para entrada/salida (1.3.6.1.4.1.9.9.48.1.1.1.5.2), y public es el nombre de la comunidad (ltmlab).

El motivo de tener que introducir dos OID y no uno [3] y [16] es que “MRTG necesita dos variables para hacer el gráfico, por lo que es preciso especificar dos OID como temperatura y humedad o errores entrantes y salientes. "

Una vez realizados dichas modificaciones del archivo de configuración, y comprobando que las gráficas de monitorización se muestran correctamente dejamos que se monitoricen los datos durante unos días para posteriormente mostrar los resultados, los cuáles se muestran en el siguiente apartado.

D. Monitorización

Los resultados obtenidos gracias a la monitorización con MRTG están compuestos por una página de índice, la que se creó con el indexmaker, en ella podemos ver las gráficas del tráfico de entrada y salida de cada una de las interfaces del router de la ETSIT. Además, si pulsamos sobre ellas, accedemos a otras gráficas en las que se muestran los gráficos del tráfico medio del último día, la última semana, el último mes y el último año. Éstas se muestran de derecha a izquierda (debido al uso de la opción growright), en bits por segundo (opción bits) y muestran en verde el tráfico de entrada y en azul el de salida. Además en el índice también se muestra la variable que

hemos monitorizado nosotros, es decir, la memoria, mostrándose la memoria usada por el procesador en verde tal y la usada por la E/S en azul.

Todo ello se muestra a continuación:

MRTG Index Page

Traffic Analysis for 1 – va-3550-tel-PBI-2

Traffic Analysis for 2 – va-3550-tel-PBI-2

Traffic Analysis for Memoria – va-3550-tel-PBI-2

Traffic Analysis for Memoria -- va-3550-tel-PBI-2

THE STATISTICS WERE LAST UPDATED FRIDAY, 21 MAY 2010 AT 10:50, AT WHICH TIME 'VA-3550-TEL-PBI-2' HAD BEEN UP FOR 42 DAYS, 23:34:08.

`DAILY' GRAPH (5 MINUTE AVERAGE)

`Weekly' Graph (30 Minute Average)

`Monthly' Graph (2 Hour Average)

`YEARLY' GRAPH (1 DAY AVERAGE)

No vamos a analizar los resultados obtenidos en cada gráfica ya que ese no es el objetivo de este informe.

IV. Conclusiones

La monitorización lleva a una reducción de los costes en cuanto a que los administradores de red, antes de llevar a

efecto cualquier solución ante cualquier problema, pueden entender lo que realmente esta sucediendo en la red y anticiparse a éste, ya que con la monitorización pueden detectarse tendencias de la red por ejemplo a congestionarse, o problemas de otro tipo. Todo ello puede desembocar en la obtención la mayor eficiencia en la red, sin necesidad de tener que instalar una red mejor, con sólo entender bien lo que esta sucediendo.

Una de las mayores dificultades con la que nos hemos encontrado es que la MIB que usa el router es de CISCO, es decir, una MIB privada, que cuelga de la rama enterprises, por lo que no es estándar y las OID que hemos estado mirando no nos servirían para analizar la memoria de un router diferente a este.........

V. Bibliografía

[1]http://www.slideshare.net/ucsp/proyecto-de-investigacion-gestion-de-redes-autodema. Gestión de redes - Autodema. Última visita 21 de Mayo de 2010.

[2] sdu.ictp.it/lowbandwidth/program/abiona/BOW.ppt. Bandwidth Monitoring & Measurement. Department of Computer Science & Engineering. Última visita 21 de Mayo de 2010.

[3] http://oss.oetiker.ch/mrtg/. Web de Oetiker´s MRTG. Última visita 21 de Mayo de 2010.

[4] http://www.itu.int/rec/T-REC-X.208-198811-W/. Web ITU-T. [Capitulo 28]. Última visita 21 de Mayo de 2010.

[5] http://www.rediris.es/rid/oid. Web RedIRIS. Object Identifiers. Última visita 21 de Mayo de 2010.

[6]http://www.faqs.org/rfcs/rfc3418.html. RFC3418 - Management Information Base (MIB) for the Simple Netw. Última visita 21 de Mayo de 2010.

[7] Apuntes asignatura tema SNMP

[9] http://www.net-snmp.org/docs/man/snmpget.html. Manual snmpget. Última visita 21 de Mayo de 2010.

[10] http://tools.cisco.com/ITDIT/MIBS/servlet/index. Web Cisco. Última visita 21 de Mayo de 2010.

[11] web wiki donde cuelga el arbol MIB

[12] http://www.arcesio.net/snmp/asn1.html

[13] http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en. Web de CISCO. Última visita 21 de Mayo de 2010.

[14] http://net-snmp.sourceforge.net/docs/man/snmpwalk.html. Manual snmpwalk. Última visita 21 de Mayo de 2010.

[16] http://www.mrtg.jp/en/es_es/referencia.html . Manual MRTG. Última visita 21 de Mayo de 2010.