|
Este artículo apareció por primera vez
en Linux Journal.
Lo hemos reimpreso y traducido con permiso del autor
Introducción
En el mundo actual, en el que la informática gira en torno al
concepto de red, el trabajo de los administradores de sistemas
es muy complejo. Su misión consiste en mantener en funcionamiento
recursos tales como encaminadores (routers), concentradores
(hubs), servidores, así como cada dispositivo crítico que
conforma la red.
Hay gran cantidad de motivos por los cuales un administrador
necesita monitorizar entre otros : la
utilización del ancho de banda, el estado de funcionamiento de
los enlaces, la detección de cuellos de botella, detectar y
solventar problemas con el cableado, administrar la información
de encaminamiento entre máquinas, etc. La monitorización de la
red es también un buen punto desde el que comenzar el estudio de
los problemas de seguridad.
En muchos casos, la red de una organización está enlazada
mediante costosos enlaces a redes de área extensa (WAN) o con la
Internet, y cuyos costes dependen del volumen de tráfico. Es muy
importante mantener un registro estadístico del tráfico que
circula por estos enlaces. Ésta situación es bastante común en
Europa, donde los enlaces X.25 son todavía de uso corriente. La
tarificación de este tipo de líneas se realiza en función del
número de paquetes enviados y recibidos.
Otros tipos de enlaces, como los punto a punto (Frame relay),
son de tarifa plana. En éstos la compañía telefónica ha de
garantizar un ancho de banda, el cual es importante
monitorizar.
En la última parte de este artículo, se presenta una herramienta
que permite hacer un seguimiento gráfico del tráfico en los
encaminadores (router). Ésta es fácilmente configurable para
poder monitorizar otras clases de información de la red.
¿ Qué es SNMP ?
La respuesta a todas las necesidades antes expuestas, es el
protocolo llamado Simple Network Management Protocol (SNMP).
Diseñado en los años 80, su principal objetivo fue el integrar la
gestión de diferentes tipos de redes mediante un diseño sencillo y
que produjera poca sobrecarga en la red.
SNMP opera en el nivel de aplicación, utilizando el protocolo de
transporte TCP/IP, por lo que ignora los aspectos específicos
del hardware sobre el que funciona. La gestión se lleva a cabo
al nivel de IP, por lo que se pueden controlar dispositivos que
estén conectados en cualquier red accesible desde la Internet, y
no únicamente aquellos localizados en la propia red local.
Evidentemente, si alguno de los dispositivos de encaminamiento
con el dispositivo remoto a controlar no funciona correctamente,
no será posible su monitorización ni reconfiguración.
El protocolo SNMP está compuesto por dos elementos: el agente
(agent), y el gestor (manager). Es una arquitectura
cliente-servidor, en la cual el agente desempeña el papel de
servidor y el gestor hace el de cliente.
El agente es un programa que ha de ejecutase en cada nodo de red
que se desea gestionar o monitorizar. Ofrece un interfaz de
todos los elementos que se pueden configurar. Estos elementos se
almacenan en unas estructuras de datos llamadas "Management
Information Base" (MIB), se explicarán más adelante. Representa
la parte del servidor, en la medida que tiene la información que
se desea gestionar y espera comandos por parte del cliente.
El gestor es el software que se ejecuta en la estación encargada
de monitorizar la red, y su tarea consiste en consultar los
diferentes agentes que se encuentran en los nodos de la red los
datos que estos han ido obteniendo.
Hay un comando especial en SNMP, llamado trap, que
permite a un agente enviar datos que no han sido solicitados de
forma explícita al gestor, para informar de eventos tales como:
errores, fallos en la alimentación eléctrica, etc.
En esencia, el SNMP es un protocolo muy sencillo puesto que
todas las operaciones se realizan bajo el paradigma de
carga-y-almacenamiento (load-and-store), lo que permite un juego
de comandos reducido. Un gestor puede realizar sólo dos tipos
diferentes de operaciones sobre un agente: leer o escribir un
valor de una variable en el MIB del agente. Estas dos
operaciones se conocen como petición-de-lectura (get-request) y
petición-de-escritura (set-request). Hay un comando para
responder a una petición-de-lectura llamado respuesta-de-lectura
(get-response), que es utilizado únicamente por el agente.
La posibilidad de ampliación del protocolo está directamente
relacionado con la capacidad del MIB de almacenar nuevos
elementos. Si un fabricante quiere añadir un nuevo comando a un
dispositivo, como puede ser un encaminador, tan sólo tiene que
añadir las variables correspondientes a su base de datos
(MIB).
Casi todos los fabricantes implementan versiones agente de SNMP
en sus dispositivos: encaminadores, hubs, sistemas operativos,
etc. Linux no es una excepción, existen varios agentes SNMP
disponibles públicamente en la Internet.
La cuestión de la seguridad
SNMP ofrece muy poco soporte para la autentificación. Tan sólo
ofrece el esquema de dos palabras clave (two-passwords). La
clave pública permite a los gestores realizar peticiones de
valores de variables, mientras que la clave privada permite
realizar peticiones de escritura. A estas palabras clave se les
llama en SNMP communities. Cada dispositivo conectado
con una red gestionada con SNMP, ha de tener configuradas estas
dos communities.
Es muy común tener asignando por defecto el valor "public" al
community público, y "private" al privado. Por lo que es
muy importante cambiar estos valores para proteger la seguridad
de tu red.
¿ Qué es el MIB ?
SNMP define un estándar separado para los datos gestionados por
el protocolo. Este estándar define los datos mantenidos por un
dispositivo de red, así como las operaciones que están
permitidas. Los datos están estructurados en forma de árbol; en
el que sólo hay un camino desde la raíz hasta cada
variable. Esta estructura en árbol se llama Management
Information Base (MIB) y se puede encontrar información sobre
ella en varios RFC's.
La versión actual de TCP/IP MIB es la 2 (MIB-II) y se encuentra
definida en el RFC-1213. En ella se divide la información que un
dispositivo debe mantener en ocho categorías (ver Tabla
1). Cualquier variable ha de estar en una de estas categorías.
Tabla 1. Categorías TCP/IP
| Categoría | Información |
|---|
| system | Información del host del sistema de encaminamiento |
| interfaces | Información de los interfaces de red |
| addr-translation | Información de traducción de direcciones |
| ip | Información sobre el protocolo IP |
| icmp | Información sobre el protocolo ICMP |
| tcp | Información sobre el protocolo TCP |
| udp | Información sobre el protocolo UDP |
| egp | Información sobre el protocolo (Exterior Gateway) |
La definición de un elemento concreto MIB implica la
especificación del tipo de dato que puede contener. Normalmente,
los elementos de un MIB son enteros, pero también pueden
almacenar cadenas de caracteres o estructuras más complejas como
tablas. A los elementos de un MIB se les llama "objetos". Los
objetos son los nodos hoja del árbol MIB, si bien, un objeto
puede tener más de una instancia, como por ejemplo un objeto
tabla. Para referirse al valor contenido en un objeto, se ha
de añadir el número de la instancia. Cuando sólo exista una
instancia del objeto, está es la instancia cero.
Por ejemplo, el objeto ifNumber de la categoría
"interfaces" es un entero que representa el número de interfaces
presentes en el dispositivo; mientras el objeto
ipRoutingTable de la categoría "ip" contiene la tabla
de encaminamiento del dispositivo.
Hay que acordarse de utilizar el número de la instancia para
leer el valor de un objeto. En este caso, el número de
interfaces presentes en un encaminador puede ser observado
mediante la instancia ifNumber.0.
En el caso de ser un objeto tabla, se ha de utilizar el índice a
la tabla como último número para especificar la instancia (fila
de la tabla).
Existe otro estándar que define e identifica las variables MIB,
llamado "Structure of Management Information" (SMI). SMI
especifica las variables MIB, éstas se declaran empleando un
lenguaje formal ISO llamado ASN.1, que hace que tanto la forma
como los contenidos de estas variables sean no ambiguos.
El espacio de nombres ISO (árbol) está situado dentro de un
espacio de nombres junto con otros árboles de otros estándares
de otras organizaciones. Dentro del espacio de nombres ISO hay
una rama específica para la información MIB. Dentro de esta rama
MIB, los objetos están a su vez jerarquizados en subárboles para
los distintos protocolos y aplicaciones, de forma que esta
información puede representarse unívocamente.
La Figura 1 muestra el espacio de nombres del MIB del TCP/IP,
éste está situado justo bajo el espacio del IAB "mgmt". La
jerarquía también específica el número para cada nivel.
Figura 1. TCP/IP Organizational Tree
|
Es importante constatar que la mayor parte del software necesita
el punto raíz (.) para localizar el objeto en el MIB. Si no se
incluye el punto raíz, se asume que el path es relativo desde
.iso.org.dod.internet.mgmt.mib-2.
De esta forma, el objeto ifNumber de la categoría
"interfaces" se puede llamar:
.iso.org.dod.internet.mgmt.mib-2.interfaces.ifnumber
o el equivalente numérico:
.1.3.6.1.2.1.2.1
y la instancia es:
.iso.org.dod.internet.mgmt.mib-2.interfaces.ifnumber.0
o el equivalente numérico:
.1.3.6.1.2.1.2.1.0
Adicionales MIB se pueden añadir a este árbol conforme los
vendedores definen nuevos objetos y publican los correspondientes
RFC.
¿ Cuál es el futuro de SNMP ?
Una nueva especificación llamada SNMPv2 está actualmente en
rápido desarrollo. Esta versión trata de solucionar la laguna
existente en cuestiones de seguridad del protocolo actual
mediante mecanismos que se centran en la privacidad, la
autentificación y el control de acceso. También permitirá un
complejo mecanismo de especificación de variables, así como
algunos comandos nuevos. El problema del SNMPv2 es que aún no es
un estándar ampliamente aceptado, a diferencia del SNMPv1. No es
fácil encontrar versiones de SNMPv2 de agentes ni de software
que haga uso de los nuevos comandos. Dejemos que pase el tiempo
y ya veremos que sucede en el futuro próximo...
SNMP en Linux
Uno de los paquetes más populares de SNMP es el
CMU-SNMP. Diseñado originalmente en la Universidad de Carnegie
Mellon, ha sido transportado a Linux por Juergen Schoenwaelder y
Erik Schoenfelder. Es completamente compatible con el estándar
SNMPv1 e incluye algunas de las nuevas funcionalidades de
SNMPv2.
La distribución contiene algunas herramientas de gestión que
permiten, desde la línea de comandos, enviar peticiones a
dispositivos que ejecuten agentes SNMP. También contiene un
programa agente SNMP, diseñado para ejecutarse sobre Linux, que
ofrece a gestores ejecutándose en la red (o en el propio sistema),
información sobre el estado de los interfaces, tablas de
encaminamiento, instante de inicio (uptime), información de
contacto, etc.
Una valiosa característica añadida que viene con CMU-SNMP es un
SNMP C-API, que permite a los programadores construir complejas
herramientas de gestión basadas en las capacidades de red de la
distribución.
La instalación en un sistema Linux es sencilla, si bien algo
diferente de la instalación original. Existe una distribución
con los ejecutables pre-compilados de las herramientas de
gestión, el demonio y la biblioteca API.
Lo primero que se ha de hacer es decidir si "bajarse" la
distribución con los fuentes, o la distribución con los
ejecutables. No es difícil encontrar este paquete en la
Internet. La distribución binaria se instala y ejecuta sin
problema alguno en los Linux que soporten ELF. Si bien
explicaremos cómo instalar la distribución binaria, es una buena
práctica el bajarse las distribuciones binarias únicamente de
servidores Internet de confianza para evitar caballos de Troya y
otros problemas de seguridad.
Copia el fichero cmu-snmp-linux-3.4-bin.tar.gz en el
directorio raíz (/). Descomprímelo y extrae los fichero del tar
con con la siguiente orden:
tar zxvf cmu-snmp-linux-3.4-bin.tar.gz
Ahora tendrás todas las utilidades y bibliotecas correctamente
instaladas en el sistema, a excepción del fichero de configuración
del agente: /etc/snmpd.conf. Lo puedes crear ejecutando
el siguiente "script":
/tmp/cmu-snmp-linux-3.4/etc/installconf
con los siguientes parámetros:
/tmp/cmu-snmp-linux-3.4/etc/installconf -mini password
donde password es la palabra clave pública
(community) que se vaya a utilizar. Ahora se puede editar
el nuevo fichero de configuración /etc/snmpd.conf. En él,
se pueden cambiar el valor de puerto UDP empleado por el agente,
las variables systemContact, sysLocation y
sysName, así como los parámetros de velocidad del
interface para las tarjetas de red y los puertos PPP.
Las herramientas más importantes de gestión de este paquete son:
-
/usr/bin/snmpget Un programa diseñado para
consultar un valor concreto a un agente MIB de la red (una
encaminador, un hub, etc).
-
/usr/bin/snmpgetnext Permite leer el siguiente
objeto de un árbol MIB sin necesidad de conocer el nombre.
-
/usr/bin/snmpset Una herramienta para escribir
valores en los objetos de agentes remotos.
-
/usr/bin/snmpwalk Herramienta que lee un
objeto completo o una serie de objetos sin necesidad de
especificar la instancia exacta. Es útil para pedir objetos
tipo tabla.
-
/usr/bin/snmpnetstat
-
/usr/bin/snmptrapd Demonio que escucha los
"traps"de los agentes.
-
/usr/bin/snmptest Herramienta interactiva
diseñada para demostrar las posibilidades del API.
El agente se encuentra en el directorio
/usr/sbin/snmpd.
CMU_SNMP también instala un fichero MIB en
/usr/lib/mib.txt. Éste es un buen lugar en donde buscar
qué tipo de información se le puede pedir a un dispositivo de
red.
El agente se tiene que lanzar a ejecución cuando se pone en
marcha la máquina. Ésto se puede hacer añadiendo el siguiente
comando en alguno de los ficheros de arranque (por ejemplo en
/etc/rc.f/rc.local):
/usr/sbin/snmpd -f ; echo 'Arrancando snmpd'
Una vez se tiene el agente SNMP en ejecución en la máquina Linux,
se puede comprobar su funcionamiento con alguna de las
herramientas de gestión, por ejemplo:
/usr/bin/snmpget localhost public interfaces.ifNumber.0
la cual retornará el número de interfaces configurados en el
sistema, y:
/usr/bin/snmpwalk localhost public system
devuelve todos los valores en el subárbol "system" del MIB. (Véase
en la Figura 2 el resultado de esta orden).
Figura 2
dragon:~$ /usr/bin/snmpwalk
usage: snmpwalk gateway-name community-name object-identifier
dragon:~$ /usr/bin/snmpwalk localhost public system
system.sysDescr.0 = "Linux version 2.0.24 (root@dragon)
(gcc version 2.7.2) #6 Mon Nov 25 15:08:40 MET 1996"
system.sysObjectID.0 = OID: enterprises.tubs.ibr.linuxMIB
system.sysUpTime.0 = Timeticks: (39748002) 4 days, 14:24:40
system.sysContact.0 = "David Guerrero"
system.sysName.0 = "dragon "
system.sysLocation.0 = "Madrid (SPAIN)"
system.sysServices.0 = 72
system.sysORLastChange.0 = Timeticks: (39748006) 4 days, 14:24:40
system.sysORTable.sysOREntry.sysORID.1 = OID: enterprises.tubs.ibr.linuxMIB.linuxAgents.1
system.sysORTable.sysOREntry.sysORDescr.1 = "LINUX agent"
system.sysORTable.sysOREntry.sysORUpTime.1 = Timeticks: (39748007) 4 days, 14:24:40
dragon:~$
|
El C-API está en el directorio /lib/libsnmp.so.3.4.
Se pueden ojear los ficheros de cabecera relacionados con la
biblioteca en :
-
/usr/include/snmp/snmp.h
-
/usr/include/snmp/snmp_impl.h
-
/usr/include/snmp/asn1.h
-
/usr/include/snmp/snmp_api.h
Se puede encontrar más información en las páginas del manual
snmp_api(3) y varibles(5).
Existe también un módulo Perl de interface con CMU C_API con el
que se pueden realizar fácilmente llamadas a esta biblioteca
desde programas Perl (Perl-scripts).
MRTG: Multi Router Traffic Grapher
MRTG es una avanzada utilidad gráfica escrita por Tobias Oetiker
y Dave Rand para representar gráficamente los datos que los
gestores SNMP leen de los agentes SNMP. Produce unas vistosas
págimas HTML con gráficos GIF sobre el tráfico entrante y
saliente en los interfaces de red prácticamente tiempo real. Con
esta herramienta se evita el tener que trabajar directamente con
las utilidades CMU-SNMP mediante línea de comandos. Ésta es la
herramienta más potente y fácil de utilizar que he encontrado en
la Internet.
MRTG utiliza una implemantación de SNMP escrita completamente en
Perl, por tanto, no es necesario instalar otros paquetes. El
programa principal está escrito en "C" para acelerar el proceso
de toma de muestras y la generación de imágenes GIF. Los gráficos
son generados con la ayuda de la biblioteca GD escrita por
Thomas Boutell, autor de la FAQ WWW.
El paquete contiene algunas utilidades para analizar los
interfaces de enlace, extraer sus características y generar los
ficheros de configuración base, que luego se pueden modificar
para adaptarlos a las necesidades concretas.
Otra característica interesante del MRTG es la cantidad de
información que produce. Permite cuatro niveles de detalle para
cada interface: tráfico en las últimas 24 horas, la última
semana, el último mes y un gráfico anual. Ésto permite recoger
información para realizar estadísticas. Guarda toda esta
información en una base de datos utilizando un algoritmo de
consolidación que impide que los ficheros crezcan de forma
desmesurada.
También genera una página principal que contiene las imágenes
GIF de los detalles diarios de cada interface del encaminador,
lo que permite hacerse una idea general de qué es lo que está
pasando en el encaminador con un sólo vistazo. Se puede ver la
página principal generada por MRTG en las Figuras 3 y 4.
| Figura 3. Interfaz de la página principal |
Figura 4. Interfaz de la página detallada del interface |
|
|
|
Haz click en las figuras para verlas en grande.
|
Veamos el procedimiento básico de instalación. Lo primero que se
necesita es la distribución. En el momento de escribir este
artículo, la última versión es la 2.5.1 (está disponible en
castellano (español) y pre-compilada); puedes encontrar la
dirección URL del servidor principal al final de este artículo.
Antes de comenzar la instalación del MRTG es necesario instalar
la biblioteca GD la dirección URL también está al final del
artículo. La versión actual es la 1.2 y no deberían haber
problemas en compilarla e instalarla. Sencillamente hay que
ejecutar make en el directorio en el que se ha
desempaquetado la distribución y se genera como resultado el
fichero llamado libgd.a. Se copia este fichero al
directorio /usr/local/lib y los ficheros con extensión
.h al directorio /usr/local/include/gd.
En este punto el paquete GD debe estar correctamente
instalado. Ahora se puede compilar el paquete MRTG. Extrae la
distribución y edita el fichero ../../common/January1998/Makefile para indicar donde se
encuentra la biblioteca y los archivos de cabecera de GD, así
como cual es el fichero ejecutable Perl 5.003: normalmente se
encuentra en /usr/bin/perl o en
/usr/local/bin/perl.
Construye el programa principal tecleando make rateup;
cuando termine la compilación, teclea make substitute
para incluir el path correcto del interprete de Perl en los
scripts de Perl que utiliza MRTG.
Copia los siguientes ficheros su directorio destino final (por
ejemplo: /usr/local/mrtg): BER.pm,
SNMP_Session.pm, mrtg y rateup.
También se han de copiar en este directorio los dos ficheros de
configuración: indexmaker y cfgmaker.
Asegúrese que todos los programas tienen permiso de ejecución.
Ya está todo listo para crear un fichero de configuración
sencillo. Es necesario tener acceso SNMP de lectura al
encaminador. Para un encaminador de la marca Cisco, las líneas
de configuración que dan permiso son:
access-list 99 permit 193.147.0.8
access-list 99 permit 193.147.0.9
access-list 99 permit 193.147.0.130
snmp-server community public RO 99
Esto permite peticiones de sólo lectura desde las direcciones
especificadas en la lista 99, empleando la palabra clave "public"
como community. Si lo que se quiere es permitir el acceso
desde cualquier máquina en modo sólo lectura al encaminador,
entonces la línea ha de ser la siguiente:
snmp-server community public RO
Si el encaminador de la red es de otra marca, entonces se ha de
consultar el manual para determinar cómo permitir el acceso
SNMP.
El script cfgmaker simplifica mucho la tarea de
construir el fichero de configuración. Todo lo que hay que hacer
es ejecutarlo con los siguientes parámetros:
cfgmaker <community>@<router-host-name or IP>
Por ejemplo:
cfgmaker public@mec-router.rediris.es > mrtg.cfg
Localizará todos los interfaces del encaminador
mec-router.rediris.es y escribirá una sección en el
fichero con las especificaciones del número de interfaces,
velocidad máxima, descripción, etc., junto con algunas etiquetas
HTML para que puedan ser incluidas en la página detallada. Es
posible editar este fichero HTML para traducirlo al idioma y
preferencias propias. Se puede ver en la Figura 5 la salida de
uno de los interfaces de mi encaminador.
Figura 5
Target[mec-router.1]: 1:public@mec-router
MaxBytes[mec-router.1]: 1250000
Title[mec-router.1]: mec-router.rediris.es (mec-router.mec.es): Ethernet0
PageTop[mec-router.1]: <H1>Estadisticas del puerto Ethernet0<BR>
Red del MEC (MECNET)</H1>
<TABLE>
<TR><TD>System:</TD><TD>mec-router.rediris.es en RedIRIS </TD></TR>
<TR><TD>Maintainer:</TD><TD>david@mec.es</TD></TR>
<TR><TD>Interface:</TD><TD>Ethernet0 (1)</TD></TR>
<TR><TD>IP:</TD><TD>mec-router.mec.es (193.147.0.1)</TD></TR>
<TR><TD>Max Speed:</TD>
<TD>1250.0 kBytes/s (ethernetCsmacd)</TD></TR>
</TABLE>
|
Ahora se puede ejecutar el programa mrtg por primera
vez. Sencillamente ejecuta:
./mrtg mrtg.cfg
Si todo va bien, el programa se pondrá en contacto con el
encaminador, pedirá algunos valores y generará algunos ficheros
de registro y algunos ficheros GIF en el directorio actual. No
hay que sorprenderse por las quejas respecto los ficheros de
registro y de gráficos que no ha encontrado, esto sólo sucede la
primera vez que se ejecuta. Elimina los ficheros de gráficos que
genera y vuelve a ejecutar el programa otra vez. El gráfico
generado mostrará el tráfico producido en el intervalo desde la
última ejecución del programa. También genera páginas HTML para
cada interface.
Ahora vamos a indicarle a MRTG como ejecutarse adecuadamente en
el sistema. Primero se ha de crear un directorio dentro del
directorio principal del web servidor (suponiendo que en el
sistema haya un servidor web en funcionamiento) para contener
las páginas y gráficos que MRTG generará cada vez que se
ejecute. Añade este directorio en la cabecera del fichero de
configuración con la directiva WorkDir:
/usr/local/web/mrtg (suponiendo que el directorio raíz está
situado en /usr/local/web). La próxima vez que MRTG se
ejecute, creará los ficheros de registro y de gráficos en este
directorio, pudiendo accederse vía
http://your_host.domain/mrtg.
Ahora vamos a construir la página principal para todos los
interfaces como la que aparece en la Figura 3. Ésto se puede
llevar a cabo con la utilidad indexmaker. Ejecuta:
indexmaker mrtg.cfg <router-name regexp> >
/usr/local/web/mrtg/index.html
Se generará un documento HTML con gráficos diarios de aquellos
interfaces cuyo nombre de encaminador coincida con la expresión
regular anterior y los enlaza con la página individual
detallada.
Como se puede imaginar, el programa MRTG se ha de ejecutar a
intervalos regulares para recoger datos en cada intervalo y
generar los gráficos periódicamente, de forma que de la
impresión de ser una monitorización en tiempo real. Esto se
puede conseguir mediante la siguiente línea en el fichero
/etc/crontab (suponiendo /usr/local/mrtg-bin
como el directorio donde reside el programa mrtg):
0,5,10,15,20,25,30,35,40,45,50,55 * * * * \
/usr/local/mrtg-bin/mrtg \
/usr/local/mrtg-bin/mrtg.cfg > \
/dev/null 2>&1
En caso de tratarse de una distribución Red Hat, la línea que se
tendría que añadir sería:
0,5,10,15,20,25,30,35,40,45,50,55 * * * * root \
/usr/local/mrtg-bin/mrtg \
/usr/local/mrtg-bin/mrtg.cfg > \
/dev/null 2>&1
Si no se ha producido ningún problema, ahora se puede dedicar
algún tiempo para acabar de configurar y ajustar la página
índice HTML. Una buena mejora consiste en incluir en la sección
de cabecera de esta página un código <META .....> para
obligar al visor web a recargar la información cada 300
segundos.
Otra mejora que se puede incluir en el fichero de configuración
es la directiva WriteExpire, que fuerza a MRTG a crear
ficheros ".meta" para cada fichero GIF y página HTML, eliminando
innecesarias operaciones de "cache" tanto en los servidores
proxy como en los propios visores web. Para ello también es
necesario configurar el servidor Apache (suponiendo que sea éste
el servidor) para que lea estos ficheros ".meta" y envíe
correctamente las cabeceras "Expire" con la directiva
MetaDiren el fichero XXXX.
Se pueden encontrar más directivas en el fichero de
configuración ejemplo que viene con la distribución; que por
cierto, está muy bien documentado. Es posible modificar la
disposición de las imágenes generadas por MRTG.
Espero que te guste este programa, si es así, enviarle a los
autores una tarjeta; puedes encontrar su dirección en la página
web de MRTG.
Otros Programas
Existe un programa similar llamado Router-Stats, escrito por Iain
Lea, el autor del famoso programa lector de correo
"tin". Router-Stats actualiza los gráficos una vez al día y
muestra información estadística muy interesante sobre la
utilización por horas y otros aspectos. El único problema es que
se apoya en muchos programas externos. (SMU-SNMP para las tareas
con SNMP, GNUPLOT para trazar gráficos, NetPBM y GIFTOOL para
trabajar con gráficos).
Hay otra categoría de software que da un paso más allá en la
tarea de gestión de redes, ofreciendo una solución completa tanto
para monitorizar como para configurar toda la red. Este tipo de
solución permite obtener una compleja representación gráfica de
la red y ojear fácilmente los nodos que la componen, verificando
detalles de configuración específicos y otras cuestiones de
interés.
A este nivel podemos hablar de dos soluciones comerciales
ampliamente utilizadas: "HP-OpenView" de Hewlett-Packard y
"SunNet Manager" de Sun. Estas herramientas ofrecen una
plataforma integrada para la gestión de los recursos de red, a
través de impresionantes interfaces gráficos. Entre otras
utilidades, disponen de herramientas para localizar los nodos de
la red en los que se están ejecutándo agentes SNMP. Otra
característica importante es la capacidad de integrar productos
de otros fabricantes, como el CiscoWork de Cisco, que permite al
administrador mantener una base de datos con todas las
configuraciones de los encaminadores e incluso monitorizar
gráficamente los paneles traseros de los encaminadores con todas
sus conexiones.
Los dos inconvenientes fundamentales de estos productos es que
son comerciales y no están disponibles para Linux. Pero por
supuesto que existen soluciones disponibles públicamente con una
funcionalidad más o menos similar. Uno de los paquetes que he
encontrado es el Scotty. Scotty es un paquete basado en TCL que
permite crear programas específicos a las necesidades de la red
propia, empleando un API de alto nivel de cadenas de
caracteres. Un paquete similar es el Tkined. Es un editor de red
que ofrece extensiones para crear un entorno de trabajo
completo, integrando algunas herramientas para localizar redes
IP, soporte para el proceso de instalación de la red o
resolución de problemas en redes IP utilizando SNMP en
combinación con otras utilidades estándar (por ejemplo
traceroute). Scotty también incluye un visor gráfico
MIB que permite explorar fácilmente información MIB.
Puedes encontrar referencias tanto de paquetes comerciales como
de software libre al final del artículo.
Conclusiones
SNMP es un protocolo sencillo pero potente que puede ayudar a
monitorizar los recursos de red sin sobrecargar mucho la
red. Quizás las extensiones que se están llevando a cabo
actualmente incrementarán la complejidad y las posibilidades de
esta herramienta pero a cambio incrementará los recursos
necesarios para implementarla.
En este artículo, se han presentado dos herramientas que se
pueden encontrar en la Internet. Existe una multitud de
herramientas que se están desarrollando continuamente. Consulta
el grupo de noticias de Usenet comp.protocols.snmp para
estar al tanto sobre anuncios sobre nuevo software y MIBs.
|
![[LinuxFocus Image]](../../common/January1998/border-short.jpg)
![[Navegation Bar]](../../common/January1998/Navegator-bar.gif){kind=small}