Monitorización de red con SNMP y MRTG

  • 11,080 views
Uploaded on

Proyecto final de ciclo, en Sistema de Telecomunicaciones e Informáticos, del alumno Daniel Lorenzo. Ver más en …

Proyecto final de ciclo, en Sistema de Telecomunicaciones e Informáticos, del alumno Daniel Lorenzo. Ver más en http://www.francescperez.net/html/proyectos/articulos/art_4_Monitorizacion_de_red_con_SNMP_y_MRTG.html

Ver más en http://francescperez.net/html/proyectos/articulos/art_4_Monitorizacion_de_red_con_SNMP_y_MRTG.html

More in: Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
11,080
On Slideshare
0
From Embeds
0
Number of Embeds
4

Actions

Shares
Downloads
483
Comments
2
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Monitorización de redcon SNMP y MRTGProyecto de síntesis Daniel Lorenzo Alvarez Tutor: Francesc Pérez Proyecto de Síntesis CFGS de Sistemas de Telecomunicaciones e Informáticos (2009 – 2011)
  • 2. ÍNDICEINTRODUCCIÓN ...................................................................................................... 2 Objetivos ................................................................................................................... 2 ¿Por qué disponer de un sistema de monitorización? ................................................ 3PROTOCOLO 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)...................................................................... 14MRTG (MULTI ROUTER TRAFFIC GRAPHER) ................................................ 16 Configuración .......................................................................................................... 17 RRDtool ................................................................................................................... 19PROPUESTA 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 ................................................................................... 23ANÁLISIS ................................................................................................................. 25CONCLUSIONES Y POSIBLES MEJORAS ......................................................... 28ANEXOS ................................................................................................................... 29NORMAS RFC ......................................................................................................... 34GLOSARIO............................................................................................................... 35REFERENCIAS ........................................................................................................ 36
  • 3. INTRODUCCIÓN Soy Daniel Lorenzo Álvarez, estudiante de CFGS de Sistemas deTelecomunicaciones e Informáticos de Stucom, Barcelona (2009-2011) y realizo estetrabajo como Proyecto de síntesis. En el siguiente trabajo se propone la implementación de un sistema demonitorización de red mediante el uso del protocolo SNMP (Simple NetworkManagement Protocol) y el software de monitoreo MRTG (Multi Router TrafficGrapher). Mediante el uso de software libre y gratuito se busca obtener un seguimientovisual 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 elsiguiente trabajo, así como las funcionalidades que ofrece. Se presentan sus versiones ysus características como paquete de red. Aquí también se describen los conceptos deMIB, SMI y RMON. En el segundo capítulo se presentan las características de la aplicación que seutilizará para llevar a cabo la monitorización, MRTG, así como sus funcionalidades yconfiguraciones. En el tercer capítulo se propone el sistema para la monitorización. Se describenlos requisitos y pasos a seguir para su implantación, y la configuración para la situaciónpropuesta. En el cuarto capítulo se presenta un análisis, una vez implementado el sistemadonde se describe el comportamiento observado. Por último, en los anexos se presentan en detalle los archivos de configuraciónasí como las opciones de MRTG empleadas. También se muestran fragmentos de lasMIBs 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 ellouna administración más eficaz. En resumen, los objetivos son: - Ampliar mis conocimientos sobre la administración de red y la monitorización. - Conocer el protocolo SNMP, su utilidad y funcionamiento. - Conocer el software generador de gráficos MRTG.
  • 4. - Implementar físicamente un sistema de monitorización: instalación y configuración del protocolo SNMP y de MRTG. - Monitorizar aquellos parámetros que al personal de administración interese y obtener gráficas del comportamiento de los dispositivos gestionados. - Analizar los resultados obtenidos. ¿Por qué disponer de un sistema de monitorización? Las actuales redes de telecomunicación se caracterizan por un constanteincremento del número, complejidad y heterogeneidad de los recursos que lascomponen. Los principales problemas relacionados con la expansión de las redes son lagestión de su correcto funcionamiento día a día y la planificación estratégica de sucrecimiento. Por ello, la gestión de red integrada, como conjunto de actividadesdedicadas al control y vigilancia de recursos bajo el mismo sistema de gestión, se haconvertido en un aspecto de enorme importancia en el mundo de lastelecomunicaciones. Un sistema para la monitorización es esencial en cualquier entorno donde searelevante cierto nivel de funcionamiento, donde se busque que el mantenimiento de losenlaces de comunicación así como la administración de los equipos que conectan lasdiferentes áreas de las organizaciones sea lo más eficiente posible.
  • 5. 1. PROTOCOLO SIMPLE DE ADMINISTRACIÓN DE RED (SNMP) Fue introducido en 1988 debido a la necesidad creciente de un estándar paraadministrar 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 dered. Este protocolo es parte del conjunto de protocolos TCP/IP (TransmissionControl Protocol/Internet Protocol) y, por su amplia utilización en redes empresariales,es considerado el estándar de facto en detrimento del protocolo CMIP (CommonManagement Information Protocol) basado en el modelo OSI, más utilizado en lasgrandes redes de las operadoras de telecomunicación. SNMP permite a losadministradores: gestionar el rendimiento, encontrar y solucionar problemas, yplanificar el crecimiento futuro de la red. Si bien SNMP se diseñó, en un principio, con el propósito de hacer posiblesupervisar de forma sencilla y resolver problemas en routers y bridges; con suampliació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 yestaciones Windows y Unix, servidores de terminal, etc. La información que se puede monitorizar son parámetros simples yestandarizados 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 tiempoque llevan encendidos, la carga de CPU, etc. Y parámetros más específicosproporcionados por el fabricante del dispositivo, como puede ser la temperatura. Se pueden resumir sus características en los siguientes puntos: - Permite a los administradores gestionar el rendimiento de la red, buscar y modificar la información de los dispositivos que la componen, encontrar y diagnosticar problemas en la red, planificar su crecimiento y generar informes sobre los nodos de la red. - Es capaz de gestionar eficazmente dispositivos de diferentes fabricantes. - Ofrece una simple combinación de solicitud-respuesta y un modo de notificación activo, así como tiempo de espera y mecanismos de retransmisión. - Contiene pocos tipos de paquetes con un formato sencillo, facilitando su resolución e implementación. - Dispone de mecanismos de autenticación y privacidad como medidas de seguridad.
  • 6. Administrador y Agente En el mundo SNMP existen dos entidades: las estaciones que gestionan,denominadas NMS (Network Management Station) y los dispositivos que songestionados, denominados Agentes. Un NMS procesa y muestra información sobre el estado de los dispositivos y lared, 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 supervisary controlar a los dispositivos administrados (aquellos que poseen el agente de SNMP). Figura 1.1. Muestra la relación entre el NMS y el Agente Los Agentes son módulos software que se instalan en los dispositivos que sedesean gestionar, y que obtienen información del estado del mismo desde la base deinformación de administración (MIB). Puede ser un programa separado (un demonio, enel lenguaje Unix), o puede ser incorporado en el sistema operativo (por ejemplo, en elSistema Operativo de un router CISCO). El agente se encarga de recopilar, mantener yenviar la información de los dispositivos administrados a los NMS, respondiendo a lassolicitudes 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, unanotificación. Dado que se trata de alertas, son enviadas sin petición previa, de formaasíncrona, al NMS; quien por su parte es adicionalmente responsable de realizar oejecutar 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 NMSinformá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 haocurrido. Algunos dispositivos, además, pueden enviar un correspondiente “trap” de “allclear” cuando hay una transición de un mal estado a un buen estado, lo que puederesultar útil para determinar cuándo se ha resuelto una situación problemática.
  • 7. SNMP y UDP SNMP es un protocolo basado en el estándar TCP/IP y emplea UDP (UserDatagram 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 yvuelta. Este aspecto de UDP lo hace poco fiable, ya que no existe conocimiento de lapérdida o llegada de los datagramas al nivel del protocolo. Pero ello supone un menortamaño del paquete y menos mecanismos empleados en la comunicación, por tanto másrapidez a la hora de realizar operaciones y menor impacto en el rendimiento en generalde la red. En cuanto a solicitudes de información se refiere, la naturaleza no confiable deUDP 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 contrastecon TCP, Transmission Control Protocol, RCF793), a la hora de, por ejemplo, emplearSNMP como medio para la monitorización, sobre todo si son muchos los equipos aadministrar. SNMP utiliza el puerto de UDP 161, para el envío y la recepción de solicitudes,y el 162, para la recepción de “traps” de los Agentes, en los dispositivos administrados. Figura 1.2. Muestra la comunicación entre el NMS y el Agente empleando el protocolo UDP.
  • 8. RFCs y Versiones del protocolo SNMP El Grupo de Trabajo en Ingeniería de Internet o IETF (Internet Engineering TaskForce) es responsable de definir los protocolos estándar que conforman el tráfico deInternet, incluyendo SNMP. La IETF publica RFCs (Request for Comments), que sonespecificaciones para muchos de los protocolos que existen en el ámbito IP. Lasespecificaciones o documentos entran a la lista de estándares primero como Propuestasy luego reciben el estado de Draft. Cuando un Draft es eventualmente aprobado recibela 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 sidoreemplazado por uno nuevo y un documento que aún no está listo para convertirse enestándar. El requisito fundamental para el diseño de SNMP fue la sencillez, lo que si bienfacilitó su expansión, ha hecho necesarias varias revisiones para adaptar el protocolo alas necesidades actuales, entre las que cabe destacar las exigencias en cuanto a laseguridad del sistema. Versión Descripción Se desarrolló debido a la creciente necesidad de un mecanismo simple y SNMPv1 estandarizado para la gestión y monitoreo de los equipos de la red y que no supusiese cambios en el rendimiento de las redes. Se desarrolló con la idea de mejorar la primera versión y solventar problemas de seguridad y sobrecarga en las transferencias de datos. Sin embargo solo se optimizó la transferencia de datos, por ello también se denomina SNMPv2c, donde la “c” indica que se mantiene el esquema de SNMPv2, seguridad basado en comunidades. Actualmente es el más empleado SNMPv2c debido, sobre todo, a su facilidad de implantación y mantenimiento. Se agrega soporte para la administración en redes distribuidas y centralizas. Mejoras en el SMI y en las operaciones. Se implementan 2 nuevas PDUs: GetBulkRequest, InformRequest. Surge con el propósito de proveer un sistema de seguridad y administración más robusto y flexible. Emplea un nuevo modelo de seguridad que asegura SNMPv3 autenticación y encriptación. No supone cambios determinantes en cuanto a la operatividad que ofrece SNMPv2, aparte de los cambios en cuanto a seguridad. Figura 1.3. Tabla resumen de las versiones de SNMP
  • 9. Modelo de seguridad basado en comunidades Tanto SNMPv1 como SNMPv2c emplean un esquema de seguridad basado encomunidades (comunity-strings) para establecer la autenticación entre un NMS y losAgentes. Las comunidades son esencialmente contraseñas, cadenas de texto quepermiten 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 definepor 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 comunidadpredeterminados, típicamente “public” para la comunidad de read-only y “private” parala comunidad de read-write. Es conveniente cambiarlas. SNMPv3 La versión 3 del protocolo define un nuevo modelo de seguridad, concretamenteel Modelo de Seguridad de Usuario o USM (User Security Model). Este modeloproporciona 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 entidadesSNMP, y consisten de un motor SNMP (snmp engine) y aplicaciones SNMP (lasoperaciones SNMP en sí). Un motor SNMP consta de los siguientes componentes:
  • 10. - El dispatcher: Envía y recibe mensajes SNMP. También trata de determinar la versión de cada mensaje recibido (v1, v2, o v3) y, si se soporta la versión, entrega los mensajes al Subsistema de procesado de mensajes. - Subsistema de procesado de mensaje: Se encarga de preparar los mensajes para ser enviados y extraer datos de aquellos recibidos. - Subsistema de seguridad: Autentifica, cifra y descifra los mensajes. La autenticación puede usar tanto comunidades (SNMPv1 y SNMPv2) como USM de SNMPv3. La autenticación basada en USM emplea algoritmos MD5 o SHA para autentificar a los usuarios sin enviar una contraseña en texto plano. El servicio de privacidad usa el algoritmo DES (actualmente) para cifrar y descifrar los mensajes SNMP. - Subsistema de Control de Acceso: Determina cuales usuarios y operaciones se les permite el acceso a los objetos administrados de la MIB. SNMPv3 proporciona tanto modelos como niveles de seguridad. Un modelo deseguridad es una estrategia de autenticación cuya configuración se basa en un usuario yel grupo al que este pertenece, y un nivel de seguridad es el nivel permitido dentro de unmodelo de seguridad. La combinación de un modelo de seguridad y un nivel deseguridad determina el mecanismo de seguridad que se emplea a la hora de manejarpaquetes SNMP.Versión Descripción Autenticación Encriptación Nivel Usa el modelo basado en Community No autenticaciónSNMPv1 No comunidades string No encriptaciónSNMPv2, Usa el modelo basado en Community No autenticaciónSNMPv2c No comunidades string No encriptación Utiliza nombres de usuarios USM (User No autenticaciónSNMPv3 para comprobar la No Security Model) No encriptación autenticación. Variante de SNMPv3 que provee una autenticación USM + MD5 o AutenticaciónSNMPv3 basada en los algoritmos de No SHA No encriptación HMAC-SHA o HMAC- MD5 Configuración más segura de SNMPv3 que provee USM + MD5 oSNMPv3 algoritmos de autenticación DES Autenticación SHA Encriptación y encriptación DES de 56 bits Figura 1.4. Tabla de los modelos y niveles de seguridad de SNMP
  • 11. SMI y MIB La SMI (Structure of Managemet Information) se encarga de definir un esquemade 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, comopuede ser el estado operacional de la interfaz de un router (“up” o “down”). La MIB (Management Information Base) se puede considerar como una base dedatos que almacena información (los OIDs con su descripción) de los dispositivosadministrados. Al igual que el Agente reside en cada uno de los dispositivosgestionados. Las MIBs contienen objetos que representan parámetros o variables de losequipos gestionados y se ordenan de forma jerárquica siguiendo un esquema de árbol.Estas colecciones de objetos relacionados, definidos como módulos de MIB. Estosmódulos están escritos en un lenguaje especial, definido en el estándar de Internet STD58, 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óncorrespondiente está definida en el RFC 1212. Ejemplo de OID numérico El mismo OID en modo texto .1.3.6.1.2.1.1.1 .iso.org.dod.internet.mgmt.mib-2.system.sysDescr Figura 1.5. Esquema de árbol de una MIB
  • 12. MIB-II Un agente puede implementar varias MIBs, pero todos ellos implementan una enparticular llamada MIB-II (RFC1213). El principal objetivo de MIB-II es proporcionaruna MIB estandarizada capaz de almacenar datos comunes de gestión: información delsistema, 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 deaquí podemos ver que el grupo system es mib-2.system.0, o 1.3.6.1.2.1.1, y asísucesivamente. La siguiente figura muestra el subárbol “mib-2” de la rama “mgmt”. Figura 1.6. Subárbol “mib-2”
  • 13. La siguiente tabla recoge una breve descripción de los grupos definidos en la“MIB-II”: Figura 1.7. Tabla conceptos de MIB-II
  • 14. Operaciones y mensajes SNMP El corazón de SNMP es una serie simple de operaciones (y la información queestas obtienen) que les da a los administradores la capacidad de analizar los distintosdispositivos administrados e interactuar con estos. Las operaciones de SNMP son: get-request Solicita el valor de una variable específica, mediante su OID. Solicita el valor de una variable sin conocer su nombre exacto. get-next-request Útil para búsquedas secuenciales dentro de una rama MIB. Solicita grandes bloques de datos, como por ejemplo varias get-bulk-request filas de un subárbol MIB. Respuesta por parte del Agente a las operaciones de get- get-response request, get-next-request o set-request set-request Almacena, altera un valor en una variable específica inform-request Comunicación entre gestores SNMP, NMS Mensaje no solicitado enviado por un Agente a un NMS trap cuando ocurre algún evento Figura 1.8. Operaciones SNMP Los mensajes utilizados por SNMP poseen el siguiente formato : Figura 1.9. Estructura de PDU - Versión: Número de versión de protocolo que se está utilizando (por ejemplo 1 para SNMPv1) - Comunidad: Nombre o palabra clave que se usa para la autenticación.
  • 15. - SNMP PDU: indica el contenido de la PDU, el que depende de la operación que se ejecute, que puede ser algún tipo de Request (como GetRequest, GetNextRequest y SetRequest), un GetResponse o un Trap. - Petición ID: usado para distinguir una solicitud con una identificación única, entre las demás solicitudes. - Error-status: usado para indicar que ha habido una excepción mientras se procesaba una solicitud. - Error-índice: cuando el error-status es diferente de cero (no hubo error) puede proporcionar información adicional indicando que variable causó la excepción. - Campos variables: una lista de nombre de variables con sus correspondientes valores. Normalmente contiene los datos solicitados por una operación Get o Trap. Como se aprecia en la Figura 1.9 un mensaje de tipo Trap tiene una estructuradiferente: - Empresa (Enterprise): indica el tipo de objeto que genera el Trap. - Dirección agente: indica la dirección IP del Agente que emite el Trap. - Trap genérico: tipo de Trap que informa sobre un estado, válido para cualquier dispositivo - Trap específico: utilizado para Traps privados (de fabricantes), así como para precisar la información de un determinado Trap genérico. - Time-stamp: tiempo transcurrido entre la última vez que se reinició el dispositivo de red y la generación del Trap. Figura 1.10. Interacción y compatibilidad de las diferentes versiones y sus operaciones
  • 16. RMON (Remote Network Monitoring) Si quisiéramos obtener información acerca de una red como un todo deberíamosrealizar sucesivas consultas individuales a cada nodo conectado en la red. Esto suponeun mayor consumo de recursos de la red (tiempo de procesamiento en agentes y elgestor, 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 unconjunto. RMON trabaja mediante un analizador de red, denominado monitor o sondaRMON. Está diseñado para la monitorización “basada en el flujo”, mientras que SNMPpara 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 laslíneas, estadísticas del tráfico, etc. sobre el segmento de red en el que se encuentra (ouna 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 formaoffline, esto es, sin necesidad de un NMS para recoger información sobre la redconstantemente. Se trata básicamente de una extensión a la MIB-II, lo que implica quepara que RMON funcione, SNMP debe estar habilitado y convenientementeconfigurado. - RMON1 definido en RFC 2819 (RMON2 en RFC 2021). - SMON, versión para redes conmutadas está definido en RFC 2613. Figura 1.11. MIB de RMON
  • 17. 2. MRTG (MULTI ROUTER TRAFFIC GRAPHER) Se trata de una herramienta para monitorizar diversos parámetros de red ygenerar páginas HTML que contienen imágenes (con formato PNG) que proporcionanuna representación gráfica en vivo de los datos que obtiene del protocolo SNMP o descripts. Figura 2.1. Gráfica creada con MRTG Entre las características más importantes de MRTG tenemos las siguientes: - MRTG es multiplataforma por lo que es compatible con la mayoría de plataformas UNIX y Windows NT. Es además software libre bajo la licencia GNU/GPL. - Está escrito en Perl. - Utiliza una aplicación SNMP portátil escrito completamente en Perl, por lo que no hay necesidad de instalar ningún paquete externo SNMP. - Las interfaces de routers pueden ser fácilmente identificadas por su dirección IP, la descripción y la dirección Ethernet además de la interfaz de serie normal. - MRTG mantiene constante el tamaño de los archivos de registro (logfiles), estos archivos no crecen en exceso gracias a la utilización de un único algoritmo de consolidación de datos. - Algunas rutinas están escritas en C para mejorar el rendimiento. - Los gráficos son generados directamente en formato PNG - El aspecto de las páginas web producidas por MRTG así como la configuración de este son altamente configurables. MRTG consiste en un script de Perl que utiliza el protocolo SNMP paracontrolar cualquier variable que se elija, y un rápido programa en C que registra eltráfico de datos y crea los gráficos para representarlos. Estos gráficos se incrustanentonces en páginas web.
  • 18. Configuración El comportamiento en tiempo de ejecución de MRTG se rige por unos archivode configuración (por defecto se crea uno, mrtg.cfg bajo el directorio de /etc). Estosarchivos de configuración pueden ser generados automáticamente con el scriptcfgmaker. Sin embargo, para configuraciones más elaboradas es necesario darle algunosparámetros a este script. El script de cfgmaker crea archivos de configuración basado en la informaciónextraídos de un enrutador u otro dispositivo SNMP disponible. Se ejecuta a través de lalí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 sehaya 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 elAgente SNMP. opciones (variables globales): se pueden especificar las opciones para el ficheroa que se crea. En el Anexo de este documento se encuentran todas las posiblesconfiguraciones. indexmaker es un script que puede crear páginas web que mostrará una serie deenlaces hacia las páginas de las diferentes interfaces monitorizadas. El comando aejecutar 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 htmlvisibles desde cualquier navegador.
  • 19. Comando cfgmaker con el que se ha creado el fichero de mrtg.cfg. Opciones globales, variables que afectan a todas las configuraciones siguientes que se encuentran en el fichero. A partir de aquí se crean las configuraciones específicas para cada elemento a monitorizar o Target. Se especifican los OIDs y el esquema que seguirá el gráfico. También se pueden especificar opciones específicas para una mejor interpretación y funcionamiento.Figura 2.2. Ejemplo de fichero de configuración de MRTG Agente Agente NMS - MRTG Agente Figura 2.3. Ejemplo implementación de MRTG
  • 20. RRDtool MRTG funciona perfectamente para la monitorización de redes simples, lo cualfue 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 seriede inconvenientes en MRTG. En el apartado de gráficos por ejemplo, estos siemprecomienzan por 0 en el eje vertical, y si únicamente quisieses ver datos relevantes en unrango determinado, no podrías. Existen limitaciones en cuanto al número de valores quepueden representarse, si se quisiera monitorizar el flujo de red de 10 servidoresdiferentes, probablemente se deberían crear 10 gráficos; también en cuanto a lavelocidad de peticiones para los valores de los gráficos, un mínimo de 5 minutos… Losdetalles se suman y suman. En este punto se crea RRDtool (Round Robin Database Tool), una herramientapensada 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 completareimplementación de los gráficos y características de registro. Es un sistema quepermite almacenar y representar datos en intervalos temporales (ancho de banda, erroresen el tráfico, CPU, etc.) en forma de gráficos fácilmente inteligibles, siguiendo elmismo principio que MRTG. Funciona guardando los datos obtenidos con la ayuda del protocolo SNMP enuna “base de datos circular” (Data Source, DS) que no crece en el tiempo, ya quecontempla siempre la misma cantidad de datos; una vez llena toda la base de datos, losnuevos valores sobreescriben a los antiguos. Con estos datos RRDtool es capaz degenerar simples y complejos gráficos, altamente personalizables y visibles desdecualquier navegador web. Figura 2.4. Gráfico creado con RRDtool
  • 21. 3. PROPUESTA DE SISTEMA DE MONITORIZACIÓN Esquema de red A.34 Agente 192.168.1.3 172.16.255.120/16172.16.255.130/16 10.10.127.223/24 A.25NMS -MRTG 192.168.25.0/24 Figura 3.1. Esquema de red Requisitos: Estación administradora (NMS) o Plataforma: Linux, Ubuntu 10.04 o Paquetes:  snmp: es un conjunto de aplicaciones para realizar las peticiones a los diferentes dispositivos que tengan un agente SNMP y que deseemos monitorizar. Operaciones: snmpget, snmpgetnext, snmpset, snmpwalk, snmpnetstat, snmptrapd y snmptest.  MRTG. Se puede descargar el paquete de código fuente desde su web (http://www.mrtg.org), aunque en la distribución de Ubuntu ya viene por defecto en uno de los repositorios.  Apache2 OPCIONAL: o Herramienta “mib browser”. Interfaz gráfica para operaciones snmp y visor de MIBs. Software: o openssh-server: para la administración remota de este servidor mediante ssh
  • 22. Equipo administrado (Agente) o PC/ Servidor – Linux. Este equipo corre una máquina virtual, que es a su vez el servidor Proxy para la red wifi.  snmpd: se trata de un Agente SNMP que se instala de forma local en el dispositivo que se desea monitorizar. En este proyecto se empleará: SNMPv1 y SNMPv2, debido a su ampliacompatibilidad, rapidez de implantación y no necesidad de un riguroso sistema deseguridad 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 remotapara gestionar el NMS. 1. En la estación NMS instalamos un servidor de ssh apt-get install openssh-server 2. En la otra estación instalamos el programa Putty (u otro cliente de ssh) para el acceso remoto: Figura 3.2. Conexión remota al NMS con Putty
  • 23. IMPLEMENTACIÓN DE SNMP (AGENTE) Por parte del Agente se debe instalar el paquete de snmpd, que implementa undemonio cuya función es la de responder a las peticiones SNMP del NMS. Lainstalación por defecto incluye MIBs para las interfaces de red, memoria, disco,procesos y estadísticas de CPU. apt-get install snmpd Archivos de configuración: /etc/defaults/snmpd En este archivo debemos eliminar: 127.0.0.1 (con esto le decimos al Agente que escuche a peticiones por todos los puertos) /etc/snmp/snmpd.conf Se configura de la siguiente manera: #### # sec. name source community Se describen las reglas de seguridad, com2sec readonly 172.16.0.0/16 public asignando las comunidades y las redes o com2sec readwrite 172.16.255.130 private equipos a los que se permite el acceso #### # sec.model sec.name group ROGroup v1 readonly Se crean grupos asociando las redes y las versiones group ROGroup v2c readonly group ROGroup usm readonly a emplear. Se proponen estos nombres distinguibles fácilmente según los permisos que se les quiere group RWGroup v1 readwrite group RWGroup v2c readwrite proporcionar. group RWGroup usm readwrite #### # incl/excl subtree mask Se asignan las ramas MIB que se permiten ver view all included .1 80 view system included .iso.org.dod.internet.mgmt.mib-2.system #### # context sec.model sec.level match read write notif Ahora se asignan los permisos (lectura, access ROGroup "" any noauth exact all none none escritura, notificación) a los grupos access RWGroup "" any noauth exact all all none creados anteriormente #### # System contact information syslocation Proxy-Wifi (configure /etc/snmp/snmpd.local.conf) syscontact Root <root@localhost> (configure /etc/snmp/snmpd.local.conf) Opcionalmente se puede aportar información de contacto, útil para pruebas de conexión Iniciar el agente con: /etc/init.d/snmpd start
  • 24. IMPLEMENTACIÓN DE SNMP (NMS) Necesitamos el siguiente paquete para realizar las consultas al agente mediantelas operaciones de SNMP: apt-get install snmp Para comprobar si SNMP está funcionando correctamente utilizamos algunaoperación de snmp: snmpget –v2c –c public 172.16.255.120 system.sysDescr.0 Operación Versión Comunidad IP del Target OID Y devuelve: SNMPv2-MIB::sysDescr.0 = STRING: Linux xen-wifi 2.6.26-2-xen-amd64 #1 SMP Tue Jan 25 06:13:50 UTC 2011 x86_64 En caso de que no devuelva información, se debe revisar que se han seguidotodos los pasos y verificar que la configuración es la correcta. Si queremos averiguar alguna variable en particular podemos acceder a las MIBsque se instalan con el paquete de snmp y encontrar el OID adecuado. Las MIBs seguardan en el siguiente directorio: /usr/share/snmp/mibs/ Figura 3.3. Ficheros MIB
  • 25. IMPLEMENTACIÓN DE MRTG Ubuntu contiene MRTG en uno de sus repositorios, así que no tenemos quecompilarlo y podemos proceder directamente a su instalación: apt-get install mrtg apache2 La ventaja de instalar MRTG de esta manera es que automáticamente instalatodas las dependencias que necesita (GD, zlib, libpng). En el comando tambiénincluimos la instalación del servidor Apache. Creamos las carpetas donde se guardarán los archivos utilizados por MRTG: 1. Para guardar las páginas HTML que se generen con el script de indexmaker. mkdir –p /var/www/mrtg 2. Para guardar los archivos de configuración generados por cfgmaker. mkdir /etc/mrtg Como únicamente monitorizamos una estación podemos crear un solo archivode configuración. Este servirá para el monitoreo de las interfaces, la carga del sistema,memoria RAM, etc. de este equipo. cfgmaker --output /etc/mrtg/wifi.cfg public@172.16.255.121 Ejecutamos el siguiente comando para crear la página web index.html, con elarchivo de configuración MRTG especificado: indexmaker --output=/var/www/mrtg/index.html /etc/mrtg/wifi.cfg Ahora ejecutamos el siguiente comando para establecer la variable de entorno einiciar el demonio de MRTG env LANG=C /usr/bin/mrtg /etc/mrtg/wifi.cfg Y ahora queda comprobar que todo ha funcionado como se esperaba, para elloen 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 antesse generó con indexmaker. Haciendo click en uno los gráficos, se ofrece másinformación sobre el elemento que se monitoriza, con datos diarios, semanales,mensuales y anuales, además tendremos la leyenda de colores empleados con sussignificados. Si es necesario cambiar algún parámetro en el fichero de configuración, se debereiniciar el demonio de MRTG, y si se cambia algún aspecto que modifique el gráfico,se debe introducir el comando de indexmaker nuevamente.
  • 26. 4. ANÁLISIS Figura 4.1. Gráficos generados por MRTG Una vez en la página index.html podemos ver todos los gráficos configurados enel fichero de wifi.cfg. Como vemos en la imagen, se han creado gráficos para todas lasinterfaces (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 clicaren ellos y seguir la leyenda. Aquí observamos además gráficos que agrupan los datospor semanas, por meses y por años. Los datos crecen de derecha a izquierda y el tiempose rige por 5 minutos para los gráficos diarios, por días para los semanales, por semanaspara los mensuales y por meses para los anuales. Para este análisis se ha observado la actividad en un semana (desde 1 de junio de2011, miércoles, hasta 8 de junio de 2011, miércoles). Se ha monitorizado la actividad de los siguientes elementos: - Interfaz eth0 (interfaz física, ip = 172.16.255.120) - Interfaz eth1 (interfaz física, ip = 192.168.1.3) - Memoria RAM - Carga del sistema
  • 27. Interfaz eth0: Representa el tráfico de entrada o descarga (verde claro) y salida o subida (azul)en esta interfaz, con IP: 172.16.255.120. Por aquí se espera que el tráfico de subida seamayor que el de bajada, ya que por este enlace se da servicio wifi a los alumnos. Comoobservamos, concuerda; y distinguimos los tiempos de mayor actividad: entre las 8 y las13:00, sólo los días laborables. Como nos encontramos a finales de curso y el númerode portátiles es bajo, no observamos mucho tráfico, con una media de 48b/s paradescargas y 64b/s para subidas. Se puede apreciar en el gráfico anual cuando se haempezado 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 lade subida, lo cual es razonable ya que por aquí se redirige el tráfico hacia la interfazanterior. 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 elgráfico anterior. Este esquema sugiere que en esta interfaz hay un tráfico bajo que nosindica que la línea empleada es adecuada, aunque como en la anterior, nos encontramosa finales de curso, cuando la actividad es poca.
  • 28. Memoria RAM: Representa la memoria RAM total(azul) y libre (verde claro), se deduce queel espacio que queda en blanco es lamemoria RAM ocupada o activa. Podemosdecir que el equipo que se monitoriza tiene5 GB de memoria RAM en total, y más de4 GB quedan libres. Este resultado se haobservado en la mayoría o la totalidad deltiempo en el que se ha realizado lamonitorización. A juzgar por estos datoseste equipo posee más que suficiente memoria RAM para llevar a cabo éstas y un mayornúmero de tareas. Carga del sistema: Representa el promedio, en el últimominuto, del porcentaje de tiempo en el quelos procesadores (4) tuvieron actividad. Eneste caso no se representan 2 elementos sino1, la carga del sistema en tanto por ciento(azul y verde claro). Como se aprecia, no senumera hasta el 100% ya que no se podríadistinguir la gráfica que oscila entre el 1% yel 0% la mayoría del tiempo. Se deberesaltar que las peticiones que realizaMRTG se producen cada 5 minutos (elmínimo permitido), con lo que sería difíciltoparse con picos puntuales. Como apreciamos, en general, la carga de este sistema esmuy 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 degestionar el tráfico que pasa por él, y de funcionar correctamente ya que el rendimientono se ha visto afectado en ningún momento, y las gráficas dan a entender que es capazde soportar una mayor cantidad de actividad, sin la necesidad de reemplazar loscomponentes mencionados.
  • 29. CONCLUSIONES Y POSIBLES MEJORAS Con este proyecto se ha conseguido explicar en qué consiste un sistema demonitorización basado en SNMP y MRTG. Se ha aportado información sobre losmecanismos empleados y he comprendido su funcionamiento y su potencial. Sobre el sistema de monitorización propuesto, se ha conseguido implantarlofísicamente, observar su actividad y extraer conclusiones. También he podidoprofundizar en una configuración más avanzada para obtener resultados másespecíficos. Sus principales ventajas son: - Resulta una herramienta muy útil para tener un cierto control sobre la red y los dispositivos que la conforman, dándonos la posibilidad de supervisarlos de una forma sencilla y visual. - Poder visualizar los estados de los diferentes elementos administrados, desde cualquier punto de la red utilizando un navegador web. - Su bajo consumo de recursos y el ínfimo impacto en el rendimiento en general de la red. Mejoras: - Implementar la última versión del protocolo SNMP, SNMPv3 y advertir de sus mejoras, sobretodo en cuanto a seguridad - Configuración más avanzada del software MRTG, introducir el RRDtool y las ventajas que ofrece. - Introducción a otras herramientas de monitorización, NAGIOS, Zenoss, Cacti… - Implementación a mayor escala. - Función de notificaciones mediante traps.
  • 30. ANEXOS MRTG Opciones Globales del fichero de configuración WorkDir: especifica el directorio dónde se deben crear las páginas web. Refresh (actualizar): son los segundos que el navegador tarda en actualizar la páginacon 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 nombressimbólicos. Para mayor eficiencia, una caché de MIBs se mantiene en el WorkDir. RunAsDaemon: permite el funcionamiento en modo demonio. El objetivo de estemodo es que ejecute MRTG de manera automática cada cierto tiempo. Este comportamientoahorra 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 activarlos 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 recomiendapara 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. Tengaen 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áginaHTML. 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, seignora. 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 datosactuales visibles, incluso cuando son mucho menores que MaxBytes. WithPeak: Por defecto los gráficos sólo contienen los valores medios de las variablesde control - normalmente las velocidades de transferencia para el tráfico entrante y saliente. Lasiguiente opción instruye a MRTG para mostrar los valores de pico de cinco minutos en losgráficos de [w]eekly, [m]onthly y [y]early. Suppress: Por defecto, MRTG produce 4 gráficos. Con esta opción puedes suprimir lageneración de los gráficos seleccionados.
  • 31. Options: growright: Las gráficas crecen hacia la izquierda. Esta opción cambia la dirección del crecimiento de las gráficas, el tiempo y los valores históricos. bits: Todos los valores de las variables se multiplican por 8. Esto también afecta al etiquetado “por defecto” y a las unidades del Target. nopercent: No presenta las variables en porcentajes. gauge: Trata los valores obtenidos de las mediciones del Target como “estado actual”, y no como por defecto, incremento de los contadores. Esto sería útil para monitorizar cosas como espacio de disco, carga de procesador, temperatura, etc. YLegend: La etiqueta del eje Y de la gráfica. Tenga en cuenta que un texto demasiado largo para caber en el gráfico será ignorado. ShortLegend: Las unidades (por defecto b/s) a usar por Max, Average and Current. Legend[1234IO]: Texto de las leyendas de colores. FICHERO DE CONFIGURACIÓN (wifi.cfg)# Created by# /usr/bin/cfgmaker --output=/etc/mrtg/wifi.cfg public@172.16.255.120### Global Config Options# for DebianWorkDir: /var/www/mrtg### Global Defaults# to get bits instead of bytes and graphs growing to the rightOptions[_]: growright, bitsEnableIPv6: noRunAsDaemon: yesInterval: 5Refresh: 305#Suppress[_]: yWithPeak[_]: mXSize[_]: 250YSize[_]: 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)######################################################################
  • 32. ########################### 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]: 1250000Title[172.16.255.120_eth0]: Traffic Analysis for eth0 -- xen-wifiPageTop[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]: 1250000Title[172.16.255.120_eth1]: Traffic Analysis for eth1 -- xen-wifiPageTop[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>
  • 33. <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>####RAMLoadMIBs: /usr/share/snmp/mibs/ UCD-SNMP-MIB.txtTarget[wifi_mem]: memAvailReal.0&memTotalReal.0:public@172.16.255.120:::::2PageTop[wifi_mem]:<h1>Memoria RAM libre</h1>Options[wifi_mem]: nopercent,gauge,growrightTitle[wifi_mem]: Memoria LibreMaxBytes[wifi_mem]: 265300000000YLegend[wifi_mem]: bytesShortLegend[wifi_mem]: bytesLegendI[wifi_mem]: &nbsp;Libre&nbsp;LegendO[wifi_mem]: &nbsp;Total&nbsp;Legend1[wifi_mem]: Memoria libreLegend2[wifi_mem]: Memoria total####Carga del sistema (suma de los 4 procesadores)LoadMIBs: /usr/share/snmp/mibs/HOST-RESOURCES-MIB.txtTarget[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:::::2MaxBytes[wifi_load]: 10AbsMax[wifi_load]: 100Title[wifi_load]: Carga del sistemaPageTop[wifi_load]: <h1>Carga del sistema %</h1>Unscaled[wifi_load]: ymwdShortLegend[wifi_load]: %YLegend[wifi_load]: CargaLegend1[wifi_load]: Carga del sistemaLegendI[wifi_load]: ActivoOptions[wifi_load]: nopercent,growright,gauge
  • 34. MIBs/usr/share/snmp/mibs/HOST-RESOURCES-MIB.txthrProcessorLoad 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.txtmemTotalReal OBJECT-TYPE SYNTAX Integer32 UNITS "kB" MAX-ACCESS read-only STATUS current DESCRIPTION "The total amount of real/physical memory installed on this host." ::= { memory 5 }memAvailReal OBJECT-TYPE SYNTAX Integer32 UNITS "kB" MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of real/physical memory currently unused or available." ::= { memory 6 }
  • 35. NORMAS RFC http://tools.ietf.org/rfc/index (Ingles) http://www.normes-internet.com/normes.php?rfc=rfc1157&lang=es (Traducción alcastellano)  RFC 1155 - Structure and Identification of Management Information for the TCP/IP-based Internets  RFC 1156 - Management Information Base for Network Management of TCP/IP-based internets  RFC 1157 - Simple Network Management Protocol (SNMP)  RFC 1213 - Management Information Base for Network Management of TCP/IP-based internets: MIB-II  RFC 1441 - Introduction to version 2 of the Internet-standard Network Management Framework  RFC 3410 - Introduction and Applicability Statements for Internet Standard Management Framework.  RFC 3411 - An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks  RFC 3412 - Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)  RFC 3413 - Simple Network Management Protocol (SNMP) Application  RFC 3414 - User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)  RFC 3415 - View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)  RFC 3416 - Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)  RFC 3417 - Transport Mappings for the Simple Network Management Protocol (SNMP)  RFC 3418 - Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)  RFC 3584 (Best current practice) - Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework
  • 36. GLOSARIO Servidor web HTTP de código abierto para plataformas Unix (BSD, Apache GNU/Linux, etc.), Windows, Macintosh y otras. C Lenguaje de programación Common Management Information Protocol (Protocolo de administración de CMIP información común) DES Data Encryption Standard (Estándar de Cirfrado de Datos) DNS Domain Name Server Librería para la creación dinámica de imágenes principalmente en formato GD PNG y JPEG GNU/GPL GNU General Public License (Licencia Pública General de GNU) Keyed-Hash Message Authentication Code (Código de Autenticación de HMAC Mensajes mediante una función Hash HMAC-MD5 HMAC que utiliza el algoritmo MD5HMAC-SHA-1 HMAC que utiliza el algoritmo SHA-1 HTTP Hypertext Transport Protocol (Protocolo de Trasnferencia de Hipertexto) IETF Internet Engineering Task Force (Grupo de Trabajo en Ingeniería de Internet) IP Internet Protocol (Protocolo de Internet) MD5 Message-Digest Algorithm 5 (Algoritmo de Resumen de Mensaje 5) MIB Management Information Base (Base de Información de Administración) MRTG Multi Router Traffic Grapher NMS Network Management System (Systema de Administración de Red) OSI Open Systems Interconnection PDU Protocol Data Unit (Unidad de Datos de Protocolo) Perl Lenguaje de programación Portable Network Graphic. Formato gráfico basado en un algoritmo de PNG compresión sin pérdidas RFC Request for Comments SHA Secure Hash Algorithm (Algoritmo de Hash Seguro) Structure Management Information (Estructura de Administración de la SMI Información) Simple Network Management Protocol (Protocolo simple de administración de SNMP redes) SSH Secure Shell (Intérprete de órdenes seguro) TCP Transmission Control Protocol (Protocolo de Datagrama de Usuario) Ubuntu Distribución de Linux basada en Debian UDP User Datagram Protocol (Protocolo de Datagrama de Usuario)
  • 37. USM User-based Security Model (Modelo de seguridad Basado en Usuarios) REFERENCIASMonitorización y SNMP:http://docstore.mik.ua/orelly/networking_2ndEd/snmp/index.htm (Ingles)https://www.ac.usc.es/docencia/ASRII/Tema_1html/index.htmlhttp://es.wikipedia.org/wiki/Simple_Network_Management_Protocolhttps://www.ac.usc.es/docencia/ASRII/Tema_1html/node13.html#SECTION00032200000000000000http://www.alcancelibre.org/staticpages/index.php/como-linux-snmphttp://www.coit.es/publicac/publbit/bit102/quees.htmhttp://www2.linuxparatodos.net/web/comunidad/base-de-conocimientohttps://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#mejorassnmpv3http://www.slideshare.net/lplinoperez/snmpv3-6601028MRTGhttp://libertonia.escomposlinux.org/story/2003/1/17/224253/241http://linuxbasement.com/content/mrtg-ubuntu-server (Ingles)http://www.ecualug.org/2005/06/23/blog/danmk3/guia_para_puesta_en_funcionamiento_a_mrtghttp://www2.linuxparatodos.net/web/comunidad/base-de-conocimiento/-/wiki/Base%20de%20Conocimiento/MRTG+(Multi+Router+Traffic+Grapher)+en+Debian-Ubuntuhttp://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)
  • 38. RRDtoolhttp://oss.oetiker.ch/mrtg/doc/mrtg-rrd.en.html (Ingles)http://oss.oetiker.ch/rrdtool/ (Ingles)Configuración en Ubuntuhttp://pablosarubbi.blogspot.com/2008/12/configuracion-de-snmpd-en-ubuntu.htmlhttp://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.htmlListas OIDhttp://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)