09:31, 21 May 2010

Informe Final CTM2
Resumen-Palabras clave—
compilar el software descargado ya que puede existir
incompatibilidad de versiones, y pedirnos librerías que no
se encuentran en determinadas versiones.
I. INTRODUCCIÓN
B. IDENTIFICACIÓN DEL ROUTER
II. GESTIÓN SISTEMAS DE RED : MONITORIZACIÓN MRTG
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 ello hemos
tenido que instalar, configurar y poner en marcha la
aplicación de monitorización MRTG (Multi Router Traffic
Grapher). Una vez instalado y configurado el MRTG, éste
nos muestra el tráfico de red del router de la ETSIT. En este
documento 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.
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
[http://www.boutell.com/gd/]
crear
Para poder monitorizar algún parámetro del router primero
debemos saber cómo comunicarnos con él. Para ello
necesitamos obtener los OID de los parámetros que
queremos obtener, y averiguar si el agente SNMP del router
los tiene implementados.
Para ello, necesitamos conocer las características del router
de la escuela (marca y modelo). Para averiguarlo hacemos
uso del comando snmpget:
snmpget -v1 -c ltmlab 157.88.130.250 system.sysDescr.0
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
[http://tools.cisco.com/ITDIT/MIBS/servlet/index], donde
introduciremos los parámetros obtenidos para obtener las
MIBs correspondientes:
gráficos
Libpng: Es un librería requerida por gd para producir
archivos
gráficos
en
formato
PNG.
[http://www.libpng.org/pub/png/libpng.html]
RELEASE: 12.1(22)EA10b
Platform Family: C3550
Feature Set: C3550 EMI IOS IMAGE
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/mrtgunix-guide.en.html]. Para instalar las librerías usamos los
comandos:
configure --prefix /home/labs/ctm2/ctm2x03/MRTG,
make
make install
C. Estudio árbol OIDs.
No entramos en detalles sobre la instalación ya que en
[http://oss.oetiker.ch/mrtg/doc/mrtg-unix-guide.en.html]
vienen perfectamente explicadas. Lo único que podemos
comentar es que hay que tener cuidado a la hora de
Se define el OID (Object Identificier) en la recomendación
X.208 (ASN.1) de la ITU-T [http://www.itu.int/rec/T-RECX.208-198811-W/en capitulo 28]. 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
[http://www.rediris.es/rid/oid/]:




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 OID 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 [ref 2863 y 3418].
Según lo explicado anteriormente, la MIB actúa como
traductor de OID 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 [Apuntes asignatura tema SNMP],
mencionada anteriormente y en la que nos centraremos una
vez escogido un OID para monitorizar.
En nuestro caso de estudio, recorrimos la rama CISCO del
árbol de OID, 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 casar en
claro que las MIBs que consultaremos son privadas. 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 [web wiki donde cuelga el arbol MIB] 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 [http://www.arcesio.net/snmp/asn1.html]
Tras recorrer el árbol de OID, 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 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:
[http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?l
ocal=en] 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:
Specific Object Informatiom
Object
locIfipOutPkts
OID
1.3.6.1.4.1.9.2.2.1.1.43
Tipo
Counter
Permisos
read-only
Estado
mandatory
MIB
OLD-CISCOINTERFACES-MIB
Descripció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
[http://net-
snmp.sourceforge.net/docs/man/snmpwalk.html] como en el
de snmpcmd, nosotros usamos las siguientes:
-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. ---> de la página
MRTA
En nuestro caso ejecutamos:
ctm2x03@balbas:~>
snmpwalk
-v1
157.88.130.250 1.3.6.1.4.1.9.2.2.1.1.43
Object
ciscoMemoryPoolUsed
OID
1.3.6.1.4.1.9.9.48.1.1.1.5
Tipo
Permisos
Estado
MIB
Gauge32
read-only
current
OLD-MEMORY-POOLMIB
"Indicates the number of
bytes from the memory pool
that are currently in use by
applications on the managed
device”
Descripción
-c
ltmlab
Donde Ltmlab es la contraseña SNMP y 157.88.130.250 es
la direción IP del router Cisco que estamos gestionando
(máquina balbas de la escuela).
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 )
Specific Object Informatiom
C. Configuración para la monitorización
El siguiente paso realizado en el proceso para conseguir
monitorizar el tráfico de distintas variables del router de la
ETSIT es crear un archivo de configuración (mrtg.cfg) que
se adapte a nuestras necesidades. Creamos dicho archivo de
configuración ayudándonos del script cfgmaker.cfg
incluido en MRTG, 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
/home/labs/ctm2/ctm2x03/MRTG/salida'
'Options[_]:
bits,growright'
/home/labs/ctm2/ctmx/MRTG/cfg/mrtg.cfg
ltmlab@157.88.130.250
'WorkDir:
--global
--output
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).
La creación de este archivo de configuración es el primer
paso para llevar a cabo nuestro objetivo de monitorización.
A continuación 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 modificamos el fichero en el que se encuentra
el crontab (para ello usamos el comando crontab -e):
*/5 * * * * /home/labs/ctm2/ctm2x03/MRTG/mrtg2.16.3/bin/mrtg
/home/labs/ctm2/ctm2x03/MRTG/cfg/mrtg.cfg.
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. Nosotros hemos escogido
ejecutar el archivo de configuración todos los días cada 5
minutos.
El último paso que hemos realizado para la configuración
nos sirve para ordenar en un solo fichero html las
numerosas gráficas generadas y poder visualizarlas todas de
una manera más sencilla. Para ello utilizamos la herramienta
indexmaker:
El motivo de tener que introducir dos OID y no uno
[http://oss.oetiker.ch/mrtg/doc/cfgmaker.en.html]
y
[http://www.mrtg.jp/en/es_es/referencia.html],
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
./indexmaker /home/labs/ctm2/ctm2x03/MRTG/cfg/mrtg.cfg
--output /home/labs/ctm2/ctm2x03/MRTG/salida/indice
En él hemos indicado la ruta en la que tenemos el fichero de
configuración (mrtg.cfg) y la ruta en la que queremos
guardar el archivo .html que nos va a crear (al que hemos
llamado índice).
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. Éstos OID eran de tipo counter, y
no sabemos por qué, pero no nos mostraban ninguna
actividad en las gráficas, por ello usamos los OID tipo
gauge32 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]: 125000000
Title[157.88.130.250]: Traffic Analysis for parametro
seleccionado -- va-3550-tel-PBI-2
PageTop[157.88.130.250]: Traffic Analysis for parametro
seleccionado – va-3550-tel-PBI-2
De éste código lo mas interesante es la siguiente linea
[http://oss.oetiker.ch/mrtg/doc/mrtg-reference.en.html]:
Target[myrouter]:OID1&OID2:public@myrouter:
Donde myrouter es la dirección IP del router que estamos
monitorizando, los OID corresponden a los parámetros que
miden la memoria usada por el procesador del router y la
memoria usada para entrada/salida, y public es el nombre de
la comunidad.
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 tenr que instalar una red mejor, con sólo
entender bien lo que esta sucediendo.
....
....