MONET

SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP)

EDWARD FOSTER GUTIERREZ

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERIA

DEPARTAMENTO DE SISTEMAS PREGRADO

BOGOTA 2003

ISC-2003-2-13

2

MONET

SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP)

EDWARD FOSTER GUTIERREZ

TESIS DE GRADO

PROFESORA: BEATRIZ ACOSTA

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERIA

DEPARTAMENTO DE SISTEMAS PREGRADO

BOGOTA 2003

ISC-2003-2-13

3

Dedico esta Tesis a mi mamá, mi papá y a mi hermano por su apoyo incondicional que siempre estuvo ahí cuando lo necesitaba.

ISC-2003-2-13

4

CONTENIDO MONET...................................................................................................................................................... 1 SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) .............................................................. 1 MONET...................................................................................................................................................... 2 SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) .............................................................. 2 CONTENIDO............................................................................................................................................. 4 LISTA DE FIGURAS................................................................................................................................. 6 LISTA DE TABLAS................................................................................................................................... 7 INTRODUCCIÓN...................................................................................................................................... 8 1. OBJETIVOS...................................................................................................................................... 8 2. HISTORIA ........................................................................................................................................ 9 3. LOS DIFERENTES ACTORES ..................................................................................................... 10 4. VERSIONES DE SNMP ................................................................................................................. 11 5. MENSAJES SNMP ......................................................................................................................... 12

5.1. NIVELES DE SEGURIDAD CON SNMP BÁSICO.............................................................................. 13 6. ¿CÓMO FUNCIONA LA COMUNICACIÓN DEL PROTOCOLO?........................................... 14

6.1. TRANSPORTE SOBRE UDP: ........................................................................................................ 14 6.2. MENSAJES TRAPS ASINCRÓNICOS:............................................................................................. 15

7. VENTAJAS DE SNMP: .................................................................................................................. 16 8. TIPO DE INFORMACIÓN QUE SE PUEDE OBTENER Y SU UTILIDAD:.............................. 16 9. ALCANCES DEL PROGRAMA MONET:.................................................................................... 18 10. HERRAMIENTAS EN EL MERCADO .................................................................................... 18

10.1. OPENVIEW DE HP..................................................................................................................... 18 10.2. CISCO VIEW DE CISCO............................................................................................................... 18 10.3. NETWORKIT 2.0 DE COMPUTER ASSOCIATES ............................................................................. 19

11. PROGRAMAS QUE USAN SNMP............................................................................................ 19 11.1. MRTG: MULTI ROUTER TRAFFIC GRAPHER............................................................................... 19 11.2. CRICKET................................................................................................................................ 20 11.3. RMONX .................................................................................................................................. 20 11.4. GET IF..................................................................................................................................... 20 11.5. SNMP MANAGER ..................................................................................................................... 20 11.6. SNMP TRAP WATCHER ............................................................................................................ 21 11.7. JFFNMS .................................................................................................................................. 21 11.8. CONCLUSIONES DE APLICACIONES ............................................................................................. 22

12. ANÁLISIS DE MONET ............................................................................................................. 22 12.1. REQUERIMIENTOS FUNCIONALES DE MONET............................................................................ 22 12.2. ANÁLISIS DE CASOS DE USOS .................................................................................................... 26 12.3. DIAGRAMA DE CLASES.............................................................................................................. 30 12.4. DIAGRAMAS DE SECUENCIA ...................................................................................................... 31

ISC-2003-2-13

5

13. CONCLUSIONES Y TRABAJO FUTURO............................................................................... 34 REFERENCIAS ....................................................................................................................................... 36

ISC-2003-2-13

6

LISTA DE FIGURAS FIGURE 1. COMUNICACIÓN HACIA AGENTE .................................................................................................. 15 FIGURE 2. COMUNICACIÓN HACIA DIRECTOR ............................................................................................... 15 FIGURE 3. COMUNICACIÓN A TRAVÉS DE TRAPS........................................................................................... 15 FIGURE 4. GRAFICA DEL TRÁFICO DE UNA TARJETA DE RED POR HORA. ......................................................... 22 FIGURE 5. GRAFICA DEL TRÁFICO DE UNA TARJETA DE RED POR SEMANA. ..................................................... 23 FIGURE 6. GRAFICA DEL USO DE LA MEMORIA POR HORA .............................................................................. 23 FIGURE 7. GRAFICA DEL MONITOREO DE LOS PROCESOS EN EL SERVIDOR POR HORA....................................... 23 FIGURE 8. GRAFICA DEL MONITOREO DE LOS PROCESOS EN EL SERVIDOR POR SEMANA .................................. 23 FIGURE 9. GRAFICA DEL MONITOREO DE LOS USUARIOS EN EL SERVIDOR POR HORA....................................... 23 FIGURE 10: PARTE DEL MANEJADOR ............................................................................................................ 24 FIGURE 11: PARTE DEL MONITOR ................................................................................................................ 25 FIGURE 12: MENU PRINCIPAL ...................................................................................................................... 25 FIGURE 13. DIAGRAMA DE CASOS DE USOS .................................................................................................. 26 FIGURE 14. DIAGRAMA DE CLASES............................................................................................................... 31 FIGURE 15. DIAGRAMA DE SECUENCIA DEL CASO DE USO CONSULTAR DISPOSITIVO ..................................... 32 FIGURE 16. DIAGRAMA DE SECUENCIA DEL CASO DE USO CONFIGURAR DISPOSITIVO .................................... 32 FIGURE 17. DIAGRAMA DE SECUENCIAS DEL CASO DE USO REGISTRAR DISPOSITIVOS.................................... 33 FIGURE 18. DIAGRAMA DE SECUENCIAS DEL CASO DE USO DE CARGAR DISPOSITIVOS ................................... 33

ISC-2003-2-13

7

LISTA DE TABLAS TABLE 1. CASO DE USO REGISTRAR DISPOSITIVO ......................................................................................... 26 TABLE 2. CASO DE USO CONSULTAR DISPOSITIVO........................................................................................ 27 TABLE 3. CASO DE USO CONFIGURAR DISPOSITIVO ...................................................................................... 27 TABLE 4. CASO DE USO CREAR ARCHIVO DE CONFIGURACIÓN ..................................................................... 28 TABLE 5. CASO DE USO EJECUTAR MONITOR ............................................................................................... 29 TABLE 6. CASO DE USO PARAR MONITOR .................................................................................................... 29 TABLE 7. CASO DE USO QUITAR DISPOSITIVO .............................................................................................. 30

ISC-2003-2-13

8

INTRODUCCIÓN Uno de los problemas más grandes que encuentran los administradores de hoy en día es ¿como administrar de forma eficiente una red? Especialmente cuando vemos que cada día las redes se están volviendo de unos tamaños supremamente grandes, lo cual no ayuda a resolver el problema. Este proyecto busca darle solución a este tipo de problemas dando una herramienta que ayude a centralizar un poco esa administración. Las redes hoy en día se ven por todos lados, de los cuales tienen gran funcionalidad para nuestras vidas. Por esto es de gran importancia el poder administrar estas redes de forma eficiente sin importar su tamaño, que tanta influencia tienen en nuestras vidas, para que mantengan un buen funcionamiento y evitar posibles catástrofes informáticos. Los beneficios de este proyecto son grandes ya que nos brinda una administración remota de diferentes dispositivos de redes. La idea de poder administrar remotamente los dispositivos es una gran ventaja para un administrador ya que puede estar en varias partes de la red, para hacer cualquier tipo de cambios de configuración de los dispositivos, al mismo tiempo evitando la pérdida de tiempo que pueda existir en el caso de tener que ir a cada dispositivo y configurar cada dispositivo. Esto vendría siendo una administración centralizada donde uno tiene la ventaja de poder administrar y configurar toda la red desde un mismo sitio. Adicionalmente se tiene toda la información de la red concentrada lo cual ayuda mucho a la hora de tomar decisiones sobre la misma red. De este modo podemos dirigirnos al problema de administrar eficientemente una red de gran tamaño. Además de esto también brinda un tipo de monitoreo de la red lo cual es de gran ayuda para cuando uno necesite tomar decisiones sobre cambios en ella misma. De esta forma el administrador obtiene una segunda ventaja, la de poder administrar remotamente los dispositivos, también se encuentra con la posibilidad de tener una herramienta que le de información actual del estado de la red para poder estar pendiente de cualquier problema que pase o simplemente para tener mayor información a la hora de tomar decisiones.

1. OBJETIVOS El objetivo de este proyecto es obtener una herramienta que permita realizar tareas administrativas de dispositivos de red de forma centralizada a través de Internet. Estas tareas incluirían el poder hacer cambios en las configuraciones en los dispositivos de redes, monitoreo de la red como tal, etc. En general, se espera estudiar las diferentes formas o protocolos de comunicación que hay con dispositivos de red, empezando con protocolos como SNMP, para así modelar y aplicar todas las funcionalidades que se necesitarían en la aplicación para que sea un apoyo efectivo para los administradores de redes. También se espera profundizar en los diferentes estándares y tecnologías desarrolladas en el campo de las redes y las comunicaciones. El producto final del proyecto debe ser el diseño y la implementación de la aplicación, tomando como base la investigación sobre los protocolos de comunicación. La aplicación consta de un administrador y varios nodos donde el programa administrador sería codificado en un lenguaje de programación que se comunicaría a través de un estándar

ISC-2003-2-13

9

como el protocolo SNMP. También se deberá entregar la documentación detallada del proyecto para que pueda ser modificado o adaptado en futuros trabajos. Además de la utilidad práctica que representa el proyecto para la realización de la administración de los dispositivos de redes, con SNMP, también se analizan diferentes estándares y formas de comunicación con los diferentes dispositivos. Esto permitirá el análisis de cada uno y la contribución que cada estándar o protocolo aporta a la administración de redes. También se puede llegar a buscar respuestas a preguntas como; la facilidad de implementación de cada estrategia, las diferencias de rendimiento entre cada protocolo y la funcionalidad entre ellos. Otro punto importante dentro de este proyecto es dar la posibilidad de integrar este proyecto con otros en el área de redes. Por lo tanto, es de gran importancia lograr obtener información de los dispositivos que puedan ser usados en otros proyectos. Un ejemplo de esto podría ser información del tráfico que se maneja en un dispositivo. Esto vendría de gran utilidad para un proyecto que esté centrado en análisis del tráfico. Este proyecto surge de la necesidad de administrar muchos nodos dentro de una red de forma remota, con el uso de SNMP. Esta herramienta debe proporcionar las herramientas necesarias para la administración de diferentes dispositivos dentro de la red de forma automática. Por lo tanto se comenzará con una investigación y un entendimiento del protocolo SNMP, seguido por una investigación de diferentes alternativas a SNMP y finalmente el diseño y el desarrollo de la aplicación integrando estas dos investigaciones.

2. HISTORIA SNMP fue desarrollado en 1988 y gracias a la simplicidad del protocolo se ha vuelto el estándar para la administración de redes. Desde un comienzo existió unos aspectos importantes que se tomaron en cuenta para la creación del protocolo SNMP lo cual lo hizo un buen protocolo para la administración de dispositivos en una red:

1. El protocolo es compatible en las diferentes plataformas. Es un estándar que se maneja igual entre los diferentes proveedores de dispositivos de red. Lo importante aquí es que las reglas para comunicarse con un dispositivo Cisco deben ser las mismas que las de 3 com.

2. La comunicación de este protocolo no debería consumir mucho ancho de banda de la red.

3. Debería ser rápido 4. El sistema debería funcionar como un sistema cliente-servidor.

En la creación de este protocolo se generó un Estructura de Manejo de la Información (SMI). El SMI es una estructura en forma de árbol lo cual fue usado para responder la pregunta de ¿cómo iba saber el administrador de la red con que elementos se iba a

ISC-2003-2-13

10

comunicar? Este diagrama también ayudó en definir las relaciones administrativas, organizar los datos de la administración de la red y asignar un identificador único a cada variable de la administración de la red.

3. LOS DIFERENTES ACTORES Existen dos tipos de identidades en SNMP: los nodos administradores (Directores) y los nodos administrados (Agentes). Los directores son nodos que tienen una función activa sobre la red. Estos solicitan e interpretan información de los diferentes dispositivos y del tráfico de la red. También tienen la posibilidad de hacer alteraciones sobre los agentes cambiando las diferentes variables de estos agentes. Los agentes SNMP son aplicaciones que están dentro de los diferentes dispositivos de red o diferentes Servidores en la red, encargados de la comunicación con los directores. El nodo es representado como un objeto administrado teniendo varias variables definidas por el MIB (Management Information Base). El MIB es una base de datos que contiene todas las variables de configuración del dispositivo de red. Unos ejemplos de estas variables podrían ser variables de las tarjetas de red que tenga el dispositivo o la versión del ROM del dispositivo. Estos agentes tienen dos funciones básicas [13]:

1. Responder las peticiones de los directores y hacer los cambios a las variables que el director le haya pedido.

2. Generar trampas, “traps”, para alertar a los directores de eventos importantes que haya tenido el nodo, como algún fallo en dispositivo.

La interacción entre estas dos identidades es simple: El director se comunica con el agente a través de SNMP, haciendo sus peticiones. Para esto el director no tiene que saber los detalles internos del agente. De la misma forma el agente no necesita saber el contexto de la petición del director. Simplemente el agente valida la petición, la procesa y luego entra a un estado pasivo esperando la siguiente petición. La división de las responsabilidades es lo que simplifica el manejo de este tipo de soluciones. Normalmente el director es el que hace las peticiones y el agente responde, pero hay ocasiones especiales en las cuales el agente manda mensajes sin haber tenido una petición. Esto es llamado “traps”, trampas. Estos mensajes sólo se usan en ocasiones especiales, como por ejemplo, cuando hay alguna falla en el sistema. MIB es el método para describir agentes, especificando los nombres, tipos y el orden de las variables que componen los objetos. Hay dos tipos de MIB: el estándar y la enterprise.

ISC-2003-2-13

11

Los Enterprise MIB son los que son escritos por los vendedores para manejar su propio dispositivo. Los dispositivos pueden tener ambos tipos de MIB siempre y cuándo tengan un enterprise MIB escrito para el dispositivo. Empresas como Cisco systems, Cabletron e IBM son ejemplos de empresas que tienen enterprise MIB para sus dispositivos [13]. Un ejemplo de un MIB podría ser el que usan los enrutadores de Cisco. Estos enrutadores manejan variables como la temperatura dentro del dispositivo, el estado eléctrico del dispositivo, carga del procesador, etc. Existe un MIB-II para Internet lo cual es uno de los muchos estándares que tiene MIB. Este estándar está orientado para manejar dispositivos en redes de tipo TCP/IP. En un principio el director hacía sus peticiones a través de paquetes UDP hacia los agentes. UDP no es el único protocolo en el cual se puede hacer esto, cualquier otro protocolo serviría. A pesar de que UDP no es muy confiable, se utilizó mucho para mandar los mensajes por su habilidad de tener un tamaño muy pequeño de paquete. Esto ayudó a satisfacer el segundo requerimiento del protocolo, bajo consumo de ancho de banda. Normalmente el director hace las peticiones a través del puerto 161 y el agente responde al puerto 162. El puerto 161 y 162 están reservados para el uso de SNMP [14].

4. VERSIONES DE SNMP SNMP versión 1 solo traía 5 comandos que eran [14]:

1. Get_Request – usado para hacer peticiones de una o varias variables del MIB 2. Get_Next_Request – usado para leer el siguiente valor, funciona secuencial mente. 3. Set_Request - usado para actualizar alguna variable del MIB 4. Get_Response – Retorna una respuesta a los tres últimos comandos 5. Trap – usado para reportar eventos significativos de la red. Estos podrían ser falla

en conexión, etc. Los primeros tres son comandos generados por el director cuando hace sus peticiones, recibe respuestas y hace cambios sobre los agentes. Los últimos dos son generados por los agentes. El cuarto comando se utiliza cuando el agente tiene que armar su respuesta a una petición, en cambio el último es para el manejo de excepciones y no se genera cuando hay una petición sino cuando hay una condición especial. SNMP versión 2 mantuvo los mismos 5 comandos de la versión 1, arregló algunos problemas que tenían estos comandos y además adicionó 2 comandos más. Unos de los problemas que se mejoró en la versión 2 fue la eficiencia, antes era un poco lento el funcionamiento del protocolo. Otro problema que se arregló fue el manejo de errores los cuales les dieron una descripción a diferentes tipos de errores, mientras que en la versión 1 simplemente se avisaba que había un error pero no se sabía que tipo de error. También se adicionó la posibilidad de manejar nuevos tipos como Counter64 y BITS (tipos de datos nuevos que maneja SNMP). Counter64 es un entero positivo de 64 bits que tiene como un valor máximo de 264 – 1 (18446744073709551615). Este tiene como función de ser un

ISC-2003-2-13

12

contador dentro de la conexión de SNMP y que apenas llegue al valor máximo el se re inicia y vuelve a comenzar. Como la versión 1 no manejaba ningún tipo de excepciones, la nueva versión se encarga de darle esta nueva funcionalidad a SNMP [14]:

1. inform request 2. get_bulk_request

El comando inform request se usa para la comunicación entre los diferentes directores. De este modo se podía sub dividir grandes redes en pequeñas sub redes y al mismo tiempo haber una comunicación entre estos. El comando get_bulk_request se encargaba de transferir grandes bloques de información del MIB a los directores en un solo comando de transferir. En SNMP versión 3 es muy parecida a la versión 2, con algunas mejoras sobre ciertas funciones de la versión 2, como el de reporte de errores los cuales han mejorado el manejo y la descripción de los errores, le han adicionado mayor seguridad y mayores herramientas administrativas. Han mejorado el manejo de errores y el comando get_bulk_request. Estas mejoras se pudieron ya que con la versión 3 existe una negociación entre los dispositivos y los directores para llegar a un tamaño de paquete óptimo. Con esto se logra tener una menor latencia y menos sobre carga en la red teniendo paquetes más grandes y menos número. Con respecto a los errores, mientras en la versión 1 solo alerta que hay un error en la versión 2 y 3 define un error y el por qué. De igual manera han mejorado el manejo de pólizas (pólizas o reglas relacionado con el manejo de recursos y la configuración de ellas) y manejo de grupos de usuarios, configuración remota por operaciones SNMP, nos permite el uso de algoritmos como DES (modo CMC, Cipher Block Chaning) y MD5 y SHA para aumentar la integridad, autenticación y confidencialidad de los datos, facilidad de monitoreo y configuración remota [10].

5. MENSAJES SNMP Un mensaje es lo que se transfiere entre los dispositivos usando el protocolo SNMP. Esto vendría haciendo la unidad básica de la comunicación entre los dispositivos. Estos son de gran importancia por lo que es la forma que el administrador manda sus peticiones y sus cambios de configuraciones a los dispositivos. De la misma forma es la manera que los dispositivos responden al administrador. Cada mensaje SNMP tiene el siguiente formato [17]:

• Número de versión • Nombre de la comunidad • Uno o más SNMP PDU (peticiones ó respuesta. Sería la parte de los datos del

paquete).

ISC-2003-2-13

13

Cada SNMP PDU con excepción de los traps tienen el siguiente formato:

• id de la Petición – número de secuencia de la petición • Estado de Errores – indica si hay errores en la comunicación con el dispositivo, si

no existe error este devuelve un 0 • Index de Error - indica en que OIDs en el PDU tiene error, si no es 0 • Lista de OIDs y valores – esto es nulo si es un get o un get next

Los PDU de tipo traps tienen el siguiente formato:

• enterprise – identifica el tipo de objeto que causa el trap • dirección del agente – dirección IP del agente que manda el trap • id genérico del trap – el estándar común del traps • id específico del trap – trap propietario o enterprise • fecha – cuando se causó el trap • lista de OIDs y valores - OIDs que puedan ser relevantes mandarlos al director

Con relación a los errores algunos ejemplos de errores que devuelve son:

• 14 que es error del commit de la consulta. • 10 es un error en el valor. • 13 es un error en el cual no hay un recurso disponible.

Viendo un poco cómo se conforma los mensajes SNMP, podemos observar que existe un tipo de autorización o de puerta para el uso de cada dispositivo de red. Existe un tipo de password que vendría a ser el nombre de la comunidad, ya que esto tiene que ser el mismo al que tiene el dispositivo que lo esta recibiendo. Por lo tanto cada dispositivo de red tiene que estar dentro de una comunidad de SNMP. Una comunidad es una variable que identifica a un grupo de dispositivos estar dentro de una misma sección de la red. Es como la gente que vive en un barrio, aunque tengan una dirección diferente, viven en un mismo barrio. Cada director de red puede estar en varias comunidades. De este modo se puede administrar varias comunidades con un mismo director. Una comunidad está definida por un nombre de comunidad que está compuesto de un OctetString con una longitud de 0 – 255 octetos. Y cada mensaje que se mande de tipo, lo cual contiene sus tres partes: Número de versión, nombre de la comunidad y los datos (que serían una secuencia de PDU asociados), pasa por un tipo de verificación con el nombre de la comunidad.

5.1. NIVELES DE SEGURIDAD CON SNMP BÁSICO Autenticación: se maneja de forma simple en texto plano con el nombre de la comunidad que se intercambian en el uso de mensajes SNMP. La autenticación esta basada en la suposición de que el mensaje no es modificado ni interrogado.

ISC-2003-2-13

14

Autorización: Apenas el nombre de la comunidad es validado por el agente o el director, se hace un chequeo de si la dirección del que mandó el mensaje tiene permiso de hacer la petición. Esto era lo único que tenía SNMP versión 2 con respecto a seguridad, lo cual no es muy seguro. Ahora con SNMP versión 3 se tiene implementado el uso de algoritmos como DES y MD5 o SHA. EL DES nos permite tener Confidencialidad y con el MD5 tendremos Integridad de la información que se transmite. SHA viene a jugar un papel importante para la autenticación de los directores. El DES utilizado es con el modo CBC (Chiper Block Chaning)

6. ¿CÓMO FUNCIONA LA COMUNICACIÓN DEL PROTOCOLO? El protocolo SNMP asume que la comunicación es no orientada a conexión, por lo tanto SNMP no garantiza que los paquetes lleguen a su destino, aunque en la realidad la mayoría de ellos llegan y los que no pueden ser retransmitidos. Los protocolos principales sobre los que SNMP se implementa son UDP e IP. SNMP también requiere protocolos de capa de transmisión como Ethernet o Token Ring para implementar el canal de comunicación desde el director al agente. La simplicidad y la comunicación no orientada a conexión permiten que el director y el agente funcionen independientemente. Por lo tanto, el funcionamiento del director no viene a ser interrumpido porque algo le pase al agente. Si el agente falla el director sigue funcionando. Simplemente cuando el agente vuelve a funcionar el manda un trap para indicar el estatus de operación.

6.1. TRANSPORTE SOBRE UDP: En el transporte de los mensajes de SNMP, el agente se mantiene en un estado de espera, escuchando en el puerto 161 para cualquier petición que tenga un director. En este caso los mensajes SNMP vienen a estar encapsulados dentro de los datagramas de UDP, por lo tanto el tamaño del mensaje SNMP está limitado al tamaño máximo de UDP, 65507 octetos. Toda implementación de SNMP tiene que recibir paquetes con un tamaño mínimo de 484 octetos como requisito. Los traps asincrónicos que puede mandar el agente los recibe el director en el puerto 162. A continuación veremos cómo sería una comunicación normal de SNMP [17]:

ISC-2003-2-13

15

Figure 1. Comunicación hacia Agente En este caso el Director hace una petición a un agente y utiliza, por ejemplo, el puerto 1961 para mandar este mensaje. Luego el mensaje es encapsulado dentro de un paquete de UDP y es mandado a través de la red hacia el Agente. El agente siempre tiene el puerto 161 (en donde se encuentra el servicio de SNMP) escuchando para la recepción de cualquier petición que le llega. Apenas llegue el mensaje el agente hace el chequeo de autenticación usando el nombre de la comunidad. Cuando esto es verificado el agente hace la verificación de autorización con el número IP del director, para ver si tiene autorización de hacer la petición que está haciendo. Después de realizadas estas verificaciones, el agente envía la petición al MIB para alistar la respuesta.

Figure 2. Comunicación hacia Director En este último diagrama se muestra lo que vendría a ser la respuesta de la petición. El agente responde la petición en el puerto 161 y la manda encapsulándola en un paquete UDP al director a través de la red. El director recibe la respuesta en el puerto 1961 y la procesa.

6.2. MENSAJES TRAPS ASINCRÓNICOS:

Figure 3. Comunicación a través de Traps

Director

Director

Director

RED

Agente escucha en Puerto 161

Manda petición en puerto 1961 SNMP

Agent protocol Engine

MIB

AGENTE

RED

Agente responde en Puerto 161

Recibe respuesta en puerto 1961 SNMP

Agent protocol Engine

MIB

AGENTE

RED

Agente manda trap en Puerto 161

Recibe trap en puerto 162

SNMP Agent protocol Engine

MIB

AGENTE

ISC-2003-2-13

16

El escenario presentado, es un caso excepción en el cual algún evento especial, como una falla, ha obligado al agente mandar un trap al director. El agente arma el paquete y lo manda usando UDP al director en el puerto 161. El director recibe el trap en el puerto 162 y lo procesa. Este puerto 162 es solo para recibir este tipo de mensajes, por lo tanto siempre esta activo para recibir este tipo de mensajes. [17]

7. VENTAJAS DE SNMP: A continuación daremos ventajas para administradores enfocado en la versión 3 del protocolo:

- Una de las ventajas más grandes es que es simple y no consume mucho ancho de banda. Por lo tanto es fácil de implementar sobre una red grande.

- Da la posibilidad al usuario de administrar remotamente una red de computadores. - Su gran uso en las redes (por lo que es un estándar y aceptado universalmente). La

mayoría de los vendedores de dispositivos de red tienen suporte para SNMP - Un buen nivel de seguridad e integridad de la información - La posibilidad de organizar pólizas de grupos - El comando getBulk esta mejor implementado que en la versión 2:

o Hay menor latencia y menos overhead a través de un número pequeño de paquetes grandes

o Hay negociación de mejor tamaño de paquetes, para llegar a un tamaño óptimo

8. TIPO DE INFORMACIÓN QUE SE PUEDE OBTENER Y SU UTILIDAD: Para esta parte tomamos como referencia los enrutadores de cisco. Para estos se puede obtener información como [3]:

• Obtener el número de intentos exitosos y no exitosos de asignar memoria temporal del enrutador para guardar información. Estos datos alertan si el enrutador está en riesgo de perder paquetes por la falta de memoria temporal para la pila de paquetes. Esto nos puede indicar de que la red esta congestionada y por eso el enrutador no esta pudiendo manejar la gran cantidad de paquetes. O simplemente no hay suficientes recursos disponibles en el enrutador para manejar el tráfico de la red.

• El uso promedio de CPU sobre períodos de tiempo de cinco segundos, un minuto y cinco minutos. Estos datos muestran si el enrutador está sobre cargado, tiene poca utilización o si uso es el adecuado.

• Temperatura interna del enrutador. Estos datos le dicen al administrador como está el ambiente del enrutador. En este caso la temperatura es de gran importancia ya que una temperatura muy alta puede darse por estar en un cuarto con mala ventilación o circulación de aire.

ISC-2003-2-13

17

• El voltaje que sale de varias líneas eléctricas del enrutador. Estos valores permite que el administrador conozca el estado eléctrico del enrutador. Esto puede ser de gran importancia ya que puede avisar que haya fallas eléctricas en el enrutador.

• También se puede obtener información de los números de bytes, paquetes y errores que se han transmitido en cada puerto. Estos datos son importantes para el administrador para sacar estadísticas y sirven para tomar diferentes decisiones sobre la red.

Además de estos datos también puede obtener información de las tarjetas, el tipo de las tarjetas, la información sobre las tarjetas (el tráfico que pasa por cada una, la versión del ROM, etc) y otra gran cantidad de información que puede ser muy útil para el administrador. Otro ejemplo interesante es el poder monitorear Servidores. Aquí se puede hacer uso del módulo de SNMP para los computadores para poder monitorear diferentes cosas del sistema. En este caso se mirará lo que se puede obtener del sistema operativo Windows con su paquete de SNMP [8]:

• Se puede obtener información de donde está la máquina y a quién contactar, lo cual sería importante para uno tener en caso que necesite contactar al encargado de la máquina.

• También se puede obtener información del tiempo que el servidor ha estado prendido y las horas locales de los servidores. Esto tendría uso más que todo para la parte del análisis de información, ya que con esto se podría obtener información acerca de los horarios de los servidores (cuánto lleva en línea, etc.).

• Se puede obtener información de los usuarios que están registrados en este servidor y el número de procesos que esté corriendo y los nombres de los proceso cargados (nombre de los programas). Esto es útil para ver la cantidad de usuarios por servidor y hacer una comparación con otros servidores para ver si hay algunos más recargados que otros, lo cual puede llevar a hacer cambios en la red para mejorar la eficiencia de ella misma.

• Se puede tener información de la memoria RAM, los diferentes discos y unidades (en los discos nos da también el número de serie del disco, el tipo de acceso, escritura o lectura, etc.), las impresoras, los diferentes dispositivos que tiene el sistema, Software Instalado, etc. Lo cual nos permitiría obtener información detallada de la configuración de los equipos (serviría para hacer inventarios y chequeo de software instalado que sea o no permitido dentro de la empresa).

• También nos da información de la última vez que los diferentes dispositivos se les haya hecho un backup. Esto sería importante para los encargados de hacer copias de seguridad de los servidores.

Esto nos brinda la posibilidad de darle información de todo tipo de dispositivos y servidores a los administradores para poder tomar decisiones todo desde un mismo sitio y sin tener que hacer grandes esfuerzos para obtenerla.

ISC-2003-2-13

18

9. ALCANCES DEL PROGRAMA MONET: Tenemos como meta el poder integrar el uso del protocolo de SNMP para poder comunicarnos con diferentes dispositivos de red. Con esto se piensa poder hacer administración de diferentes dispositivos, haciendo cambios en sus configuraciones, de forma remota. Además de esto se tiene planeado poder hacer recolección de información de los mismos dispositivos para tener como un tipo de monitoreo de la red y su funcionamiento. Se tiene la intención de que Monet se pueda integrar con otros proyectos relacionados con las redes, por lo tanto se tiene pensado que la recolección de información de los dispositivos puede dar información que sea útil para otros proyectos relacionados. También se tiene propuesto que la configuración de los dispositivos de redes sea un poco automática el reconocimiento de ella misma, después de haber dado la dirección del dispositivo.

10. HERRAMIENTAS EN EL MERCADO

10.1. OPENVIEW DE HP Características de esta aplicación:

• Descubrimiento automático de la red o Descubrimiento de swiches a nivel 2 y 3 o Mapeo visual de nivel 2 y 3 con relaciones o Vistas dinámicas por protocolos, dispositivos, VLAN´s, subredes

• Análisis de problemas de la red o Análisis de problemas de nivel 2 y 3 o Interfaz por Web mostrando status de los dispositivos de red o Sistema LOGEC para hacer tuning de la red o Recolección de datos o Reportes para planeación de crecimiento o Suporte de Ipv6, OSPF y HSRP

En general esta aplicación se centra sobre las funciones de descubrimiento de la red, Configuración remota y análisis de problemas. [7]

10.2. CISCO VIEW DE CISCO Características de la aplicación:

• Tener una vista gráfica de los diferentes dispositivos de red. • Configuración de estos dispositivos de red • Monitoreo en tiempo real de las estadísticas de las diferentes interfaces, el uso de

recursos y el desempeño de los dispositivos de red.

ISC-2003-2-13

19

Esta aplicación está diseñada expresamente para manejar todo los dispositivos de red. Cisco View también funciona como un timo de módulo y generalmente se encuentra como parte de una aplicación más grande diseñada para administración de redes llamada Cisco Works Server. El Cisco View también puede adicionarse a otras aplicaciones como OpenView para dar mejor soporte a dispositivos de red Cisco. Esta aplicación puede funcionar como uno de tipo cliente – servidor. Donde en el servidor se guarda MIB de los dispositivos y la funcionalidad básica de manejo de dispositivos. [4]

10.3. NETWORKIT 2.0 DE COMPUTER ASSOCIATES Características de la aplicación:

• Análisis de problemas, que trata de prevenir posibles problemas en la red. Esto lo hace con análisis de datos y reconocimiento de patrones.

• Tiene vistas en modo grafico de la topología. Hay varios modos: 2D, 3D, por subred, por objetos, etc.

• Descubrimiento automática de la red • Administración y monitoreo de dispositivos • Suporte para antivirus • Tiene compatibilidad con OpenView (de HP) y NetView (de IBM)

Esta aplicación esta diseñada más que todo para el monitoreo y administración de la red. Además tiene un tipo de prevención de problemas y antivirus lo cual lo vuelve más completo. Adicionalmente tiene soporte hacia otras aplicaciones como OpenView y NetView. [5]

11. PROGRAMAS QUE USAN SNMP

11.1. MRTG: MULTI ROUTER TRAFFIC GRAPHER El MRTG es una herramienta que monitorea la cantidad de carga de tráfico sobre las redes. Esta aplicación genera HTML con imágenes png que dan una representación de la red en el momento. Estas capturas se hacen en intervalos de 5 minutos. MRTG esta hecho para sistemas Unix y Windows. Las ventajas de MRTG son: portabilidad (funciona en casi todos los Unix y Windows), SNMP portable (Usa una implementación portable de SNMP escrito en Perl, lo cual no necesita paquetes externos de SNMP), soporte de SNMP versión 2c, logs constantes, configuración simple, es rápido gracias a que esta codificado parcialmente en C y es gratis. [16]

ISC-2003-2-13

20

11.2. CRICKET Este programa es para monitorear la carga o el tráfico sobre la red como MRTG. Este se basa sobre una base de datos llamada RRDTool y luego muestra los datos en graficas en Web. Esta aplicación funciona en Linux, Solaris, HP-UX y BSD. Este permite tomar datos en intervalos predefinidos por el usuario. Esta aplicación esta hecha con dos módulos que son: colector y el graficador. El colector corre sobre cron como un demonio para hacer las capturas. El graficador es el que se encarga de crear las graficas para mostrarlas en la interfaz grafica basada por Web. Como ya he dicho la interfaz que usa esta aplicación es por Web (la parte del graficador) pero la parte del colector esta conformado por unos archivos de configuración que contiene toda la información que necesita Cricket sobre los diferentes dispositivos y los datos que va capturar. Esta parte no tiene una interfaz grafica que facilite el proceso ya que todo tiene que ser configurado manualmente y en forma de texto. Cricket esta escrito en Perl y esta distribuido bajo la licencia de GNU, pero no se puede obtener código fuente para hacerle ningún tipo de cambios. Esta aplicación ocupa un total de 300KB. [6] [1]

11.3. RMONX RMONX provee información sobre el estatus de la red, detección de eventos, notificación de eventos, monitoreo de tendencias (logs), navegación de MIB y configuración. Esta información permite tener una buena información en el momento de hacer decisiones sobre la red y adicionalmente permite hacer los cambios de configuración de forma remota. RMONX solo corre sobre sistemas Linux. Esta aplicación queda corriendo como un demonio sobre la maquina y su interfaz de uso es a través de la Web, lo cual lo hace fácil de usar. Esta aplicación es comercial. [12]

11.4. GET IF Este es un programa que permite obtener información a través de SNMP y graficarlos. La información puede ser la cantidad de procesos que tiene el dispositivo, el uptime del dispositivo, la cantidad de memoria libre que tiene el dispositivo, el software instalado, etc. Esta información sirve para ver el estado de la red y poder hacer inventario de los dispositivos. También permite navegar a través de los MIB. Su uso es muy simple con su interfaz grafica que ofrece. Esta aplicación esta hecha para Windows en general. Tiene un tamaño de 1.38MB sin contar los MIB que puede usar. Este es un programa gratis pero no se tiene acceso al código fuente. Este programa no genera ningún tipo de logs. [15]

11.5. SNMP MANAGER Este programa, creado por BTT Software, es un simple programa que usa SNMP para monitorear diferentes sistemas en la red. El verifica que los diferentes dispositivos estén en

ISC-2003-2-13

21

línea en intervalos de 10 segundos. Esto sirve mucho para ver el estado básico de un dispositivo en la red y permite ver con facilidad si esta en línea o no. Adicionalmente puede obtener información básica del sistema a través del SNMP. Este programa corre sobre Windows y es una aplicación con licencia lo cual solo permite ser evaluado de forma gratuita. Tiene un tamaño de 132KB. Su modo de uso es a través de una interfaz grafica muy simple de usar. Esta aplicación no genera ningún tipo de logs para el administrador lo cual podría ser un punto negativo ya que no da un historial de la red que está monitoreando. [2]

11.6. SNMP TRAP WATCHER Este programa, creado por BTT Software, simplemente recibe traps creados por todo tipo de dispositivos de red. Este programa corre sobre Windows. Esta es una aplicación libre pero no permite tener acceso a su código fuente. Está en capacidad de exportar logs de los traps que escucha a través del puerto UDP 162. Estos logs son en forma tabulada lo cual es propio del programa. Ocupa un total de 59.5KB descomprimido. Adicionalmente puede dar información básica acerca del dispositivo que está mandando los traps, como el uptime de un dispositivo de red, su dirección, la comunidad, etc. Esto sirve para poder identificar problemas en una red y hacer debugging sobre aplicaciones que usen SNMP. Esta aplicación se maneja a través de una interfaz gráfica que va mostrando en forma de lista los nuevos traps que van entrando. Esta interfaz le da facilidad de uso al programa. [2]

11.7. JFFNMS Este programa es un sistema de monitoreo de redes. Este permite ver rápidamente el estatus de la red. Tiene una consola que muestra los eventos en orden de llegada, muestra de forma gráfica el tráfico y los errores, maneja Traps y funciona en Linux como en Windows 2000. Adicionalmente arma reportes de elementos como tráfico en Bytes, porcentaje de utilización de los dispositivos, paquetes por segundo, Errores por segundo, Rata de error, caídas del servicio, temperatura de los procesadores, Utilización de procesadores, uso de memoria y recursos de discos, numero de procesos y de usuarios por maquinas. Todo esto sirve para dar un estado general de la red y los dispositivos, lo cual ayuda a la toma de decisiones. Estos reportes son presentados en el GUI de tipo Web. Este programa esta distribuido con la licencia de GNU GPL lo cual permite el uso gratuito del software y la posibilidad de hacerle cambios o de usar partes de su código fuente. Tiene un tamaño de 554KB comprimido lo cual lo hace muy cómodo para manejar. Para la instalación de esta aplicación se requiere la instalación de otras aplicaciones como Apache (Servidor http), MySQL (Base de datos), PHP, RRDTOOL y NMAPWin. Esta aplicación tiene la facilidad de que puede ser expandido adicionando le módulos nuevos. Esta aplicación queda corriendo como un demonio que puede ser accedido a través del Web [9]

ISC-2003-2-13

22

11.8. CONCLUSIONES DE APLICACIONES En conclusión puedo decir que las mejores aplicaciones vendrían siendo MRTG, RMONX y JFFNMS. MRTG lo escogería como uno de los mejores ya que es portable a Windows como a Linux, adicionalmente presenta muy bien los datos de la carga de la red y toma un buen historial para uno poder tener como referencia a la hora de tomar decisiones sobre los anchos de banda de la red. RMONX lo escogería por lo completo que es. Tiene una gran gama de aplicativos que utilizan SNMP. El único inconveniente que tiene es que solo corre sobre Linux. JFFNMS esta en un estado entre MRTG y RMONX ya que tiene varias funcionalidades, no tantas como RMONX pero si funciona en Windows como en Linux. Este también me pareció un buen programa que usa SNMP.

12. ANÁLISIS DE MONET

12.1. REQUERIMIENTOS FUNCIONALES DE MONET

1. Hacer consultas de trafico a los dispositivos 2. Creación de archivos de configuración para MRTG 3. Hacer consultas a los dispositivos dependiendo de los MIB que tienen 4. Controlar la ejecución de MRTG

En Monet se va a utilizar MRTG para que se encargue de graficar los datos que obtiene Monet. Lo bueno de Monet es que permite unificar un poco herramientas en el mundo GNU existen por separado. Primero la parte de consultas y configuración con la parte de graficación y recolección de datos. Monet se integraria con MRTG, creando los archivos de configuración que usa MRTG y tambien lo ejecutaria. A continuación tenemos las graficas que podriamos obtener de Monet:

Figure 4. Grafica del tráfico de una tarjeta de Red por hora.

ISC-2003-2-13

23

Figure 5. Grafica del tráfico de una tarjeta de Red por semana.

Figure 6. Grafica del uso de la memoria por hora

Figure 7. Grafica del monitoreo de los procesos en el servidor por hora

Figure 8. Grafica del monitoreo de los procesos en el servidor por semana

Figure 9. Grafica del monitoreo de los usuarios en el servidor por hora

ISC-2003-2-13

24

A continuación tenemos unas imágenes de lo que es la aplicación como tal de Monet:

Figure 10: Parte del Manejador En esta imagen vemos como se ve la parte de la aplicación encargada de manejar las consultas y las configuraciones de los dispositivos. Aquí se puede tener gravadas las pre-configuraciones de los dispositivos con sus respectivas consultas. En la parte baja de la imagen vemos el área donde se imprimen los resultados. En la parte media es donde se tiene los dispositivos que estén configurados con Monet. En la parte de arriba tenemos la parte donde se puede hacer consultas individuales, muchas consultas consecutivas, consultas del árbol completo y hacer modificaciones a los dispositivos

ISC-2003-2-13

25

Figure 11: Parte del Monitor En esta imagen vemos la parte encargada de crear los archivos de configuraciones para el MRTG. Aquí tenemos todas las opciones y unas configuraciones pre-establecidas para tareas comunes.

Figure 12: Menu Principal Aquí vemos el menú principal de donde se configura/borra nuevos dispositivos, se corre/para el MRTG y maneja las pre–configuraciones.

ISC-2003-2-13

26

12.2. ANÁLISIS DE CASOS DE USOS

Figure 13. Diagrama de Casos de Usos En este diagrama lo que se busca es identificar los usuarios del sistemas y los casos de usos en los cuales existe interacción entre los usuarios y el sistema. Para Monet existe un tipo de usuario que es el cliente o administrador de la red. Aquí se ve claramente los requerimientos funcionales de forma más granulada de la aplicación. A continuación tenemos los casos de uso detallados. Table 1. Caso de Uso Registrar Dispositivo IDENTIFICADOR REGISTRAR DISPOSITIVO Nombre Caso de Uso: CU1 Necesario/Deseable: Deseable Prioridad: Baja Iteración: Ciclo 1 Resumen: Registra los dispositivos en el sistema Curso Básico de Evento: 1. El usuario le indica al sistema que

desea adicionar un dispositivo 2. El sistema le pide al usuario la

descripción, la IP y la comunidad del dispositivo.

3. El sistema verifica si ese dispositivo ya ha sido registrado.

4. Ingresa el dispositivo nuevo al sistema.

Caminos de Excepción: • En el punto 3 puede que el usuario este tratando de ingresar un

ISC-2003-2-13

27

dispositivo ya exista. El sistema le avisa y vuelve al punto 1.

Puntos de Extensión: Ninguno Triggers: El usuario le indica al sistema que quiere

ingresar un dispositivo nuevo. Suposiciones: Ninguno Pre-condiciones: Ninguno Post-condiciones: Se ha ingresado un nuevo dispositivo Table 2. Caso de Uso Consultar Dispositivo IDENTIFICADOR CONSULTAR DISPOSITIVO Nombre Caso de Uso: CU2 Necesario/Deseable: Necesario Prioridad: Alta Iteración: Ciclo 1 Resumen: Consulta un dispositivo el OID pedido Curso Básico de Evento: 1. El usuario ingresa la IP y

comunidad del dispositivo y también el OID de la consulta.

2. El sistema hace la consulta al dispositivo.

3. El sistema devuelve el resultado al usuario.

Caminos de Excepción: • En el punto 2 puede que el usuario haya ingresado información errónea o simplemente haya problemas con el dispositivo y no responde. El sistema le avisa al usuario del problema y vuelve al punto 1.

Puntos de Extensión: Ninguno Triggers: El usuario le indica al sistema que quiere

hacer una nueva consulta a un dispositivo. Suposiciones: Ninguno Pre-condiciones: Ninguno Post-condiciones: Se devuelve la respuesta de la consulta. Table 3. Caso de Uso Configurar Dispositivo IDENTIFICADOR CONFIGURAR DISPOSITIVO Nombre Caso de Uso: CU3 Necesario/Deseable: Necesario Prioridad: Alta Iteración: Ciclo 1 Resumen: Efectúa cambios de configuraciones en el

dispositivo.

ISC-2003-2-13

28

Curso Básico de Evento: 1. El usuario ingresa la IP y comunidad del dispositivo y también el OID, valor a cabiar y el tipo de valor.

2. El sistema hace el cambio en el dispositivo.

3. El sistema devuelve el resultado al usuario.

Caminos de Excepción: • En el punto 2 puede que el usuario haya ingresado información errónea o simplemente haya problemas con el dispositivo y no responde. El sistema le avisa al usuario del problema y vuelve al punto 1.

Puntos de Extensión: Ninguno Triggers: El usuario le indica al sistema que quiere

hacer cambios de configuración en un dispositivo nuevo.

Suposiciones: Ninguno Pre-condiciones: Ninguno Post-condiciones: Se ha efectuado un cambio en un

dispositivo Table 4. Caso de Uso Crear Archivo de Configuración IDENTIFICADOR CREAR ARCHIVO DE

CONFIGURACION Nombre Caso de Uso: CU4 Necesario/Deseable: Necesario Prioridad: Alta Iteración: Ciclo 1 Resumen: Crear archivo de configuración para

MRTG Curso Básico de Evento: 1. El usuario ingresa OID´s con sus

opciones necesarios que quiere tener en el archivo de configuración para MRTG.

2. El usuario hace la petición de crear el archivo de configuración.

3. El sistema crea el archivo de configuración.

Caminos de Excepción: Ninguno Puntos de Extensión: Ninguno Triggers: El usuario le indica al sistema que quiere

hacer el archivo de configuración para

ISC-2003-2-13

29

MRTG. Suposiciones: Ninguno Pre-condiciones: Este configurado el directorio donde esta

instalado MRTG y el sitio donde deposita los archivos de graficas de MRTG

Post-condiciones: Se ha creado un archivo de configuración. Table 5. Caso de Uso Ejecutar Monitor IDENTIFICADOR EJECUTAR MONITOR Nombre Caso de Uso: CU5 Necesario/Deseable: Necesario Prioridad: Medio Iteración: Ciclo 1 Resumen: Carga el MRTG para que comience sus

ciclos de monitoreos a los dispositivos. Curso Básico de Evento: 1. El usuario hace la petición de

ejecutar el monitor. 2. El sistema carga el monitor.

Caminos de Excepción: Ninguno Puntos de Extensión: Ninguno Triggers: El usuario le indica al sistema que quiere

ejecutar el monitor MRTG. Suposiciones: Ninguno Pre-condiciones: Este configurado el directorio donde esta

instalado MRTG y el sitio donde deposita los archivos de graficas de MRTG

Post-condiciones: Se ha ejecuta el monitor. Table 6. Caso de Uso Parar Monitor IDENTIFICADOR PARAR MONITOR Nombre Caso de Uso: CU6 Necesario/Deseable: Necesario Prioridad: Medio Iteración: Ciclo 1 Resumen: Descarga el MRTG. Curso Básico de Evento: 1. El usuario hace la petición de parar

el monitor. 2. El sistema para el monitor.

Caminos de Excepción: Ninguno Puntos de Extensión: Ninguno Triggers: El usuario le indica al sistema que quiere

parar el monitor MRTG. Suposiciones: Ninguno Pre-condiciones: Ninguno Post-condiciones: Se descarga el monitor.

ISC-2003-2-13

30

Table 7. Caso de Uso Quitar Dispositivo IDENTIFICADOR QUITAR DISPOSITIVO Nombre Caso de Uso: CU7 Necesario/Deseable: Deseable Prioridad: Baja Iteración: Ciclo 1 Resumen: Quita los dispositivos en el sistema Curso Básico de Evento: 1. El usuario le indica al sistema que

desea retirar un dispositivo del sistema

2. El sistema le pide al usuario la IP del dispositivo.

3. El sistema verifica si ese dispositivo exista.

4. Retira el dispositivo del sistema. Caminos de Excepción: • En el punto 3 puede que el usuario

este tratando de retirar un dispositivo que no existe. El sistema no hace nada y vuelve a la ventana principal.

Puntos de Extensión: Ninguno Triggers: El usuario le indica al sistema que quiere

quitar un dispositivo. Suposiciones: Ninguno Pre-condiciones: Existan dispositivos registrados Post-condiciones: Se ha quitado un dispositivo seleccionado

12.3. DIAGRAMA DE CLASES Ya teniendo los requerimientos detallados de la aplicación, seguimos al diseño de la aplicación. Primero decidí utilizar el patrón fachada para encapsular un poco todos los servicios que se le quieren brindar a la interfaz y separar un poco el modelo de la interfaz grafica. Luego seleccione el patrón command donde trate de encapsular por los diferentes comandos o requerimientos en clases y paquetes. De este modo se logra separa y encapsular por funciones las diferentes partes del programa. Para la parte de la persistencia de los dispositivos, de las configuraciones y de las preconfiguraciones no se necesito una base de datos ya que el programa no exigía una persistencia muy compleja. Por lo tanto se hizo utilización de archivos binarios para esto. Como se ve en el diagrama de clases, esta serialización de los objetos de dispositivos y de las configuraciones esta a cargo de un paquete llamado util que contiene el DataHelper y FileDevice que se encargan de la persistencia de estos objetos.

ISC-2003-2-13

31

Para la parte de la comunicación de SNMP se utilizo unas librerías libres que ya tenia implementada las interfazes para comunicarse con los dispositivos. [11] A continuación tenemos el diagrama de clases de la aplicación.

Figure 14. Diagrama de clases

12.4. DIAGRAMAS DE SECUENCIA Para facilitar un poco el diagrama anterior y la codificación misma de la aplicación es útil crear diagramas de secuencia para ver un poco el flujo del programa. Para esto decidí tomar unos casos de usos importantes y desarrollar su diagrama de flujo. Prácticamente todos

ISC-2003-2-13

32

estos diagramas parten de un punto básico que es la fachada ya que de aquí es que se brindan los servicios al usuario. A continuación tenemos estos diagramas de secuencia:

Figure 15. Diagrama de Secuencia del Caso de uso Consultar Dispositivo

Figure 16. Diagrama de Secuencia del Caso de uso Configurar Dispositivo

ISC-2003-2-13

33

Figure 17. Diagrama de Secuencias del Caso de uso Registrar Dispositivos

Figure 18. Diagrama de Secuencias del Caso de uso de Cargar Dispositivos Los demás casos de usos operan de forma similar a los expuestos anteriormente. Por lo tanto no me pareció importante incluirlos en el diseño.

ISC-2003-2-13

34

13. CONCLUSIONES Y TRABAJO FUTURO Este proyecto buscaba desarrollar una herramienta útil para el campo de la administración de redes utilizando una metodología de desarrollo específica y aprovechando las últimas tecnologías disponibles. Las siguientes son algunas de las conclusiones que se pueden sacar de este trabajo. La herramienta logra cumplir de manera efectiva su propósito de servir de apoyo a la administración de redes. Esto se debe al análisis e investigación que se hicieron antes de comenzar su desarrollo. El proceso de diseño con las herramientas de UML es fundamental para lograr un desarrollo exitoso del proyecto. Además, los diagramas son una herramienta fundamental para las personas que deseen intervenir en el futuro. Es importante hacer un análisis previo de las herramientas y tecnologías que se piensan utilizar en un proyecto para determinar con certeza si en realidad traen beneficios o no. De este modo llegamos a la decisión acertada de usar SNMP para administrar los dispositivos. Es importante escoger una metodología de desarrollo que se ajuste a las características del proyecto. En este caso se escogió como base la metodología XP por considerase apropiada para el tipo de proyecto. Debido a esta buena elección se logró desarrollar la aplicación en el tiempo requerido y se lograron superar todas las dificultades técnicas que surgieron. Si bien la herramienta es completamente funcional, todavía existen varias cosas por hacer en este proyecto, que se describen a continuación. Faltaría adicionarle la posibilidad de que la aplicación interprete los MIB de los dispositivos así facilitando el uso para el usuario y que no se viera en la tarea de interpretar los códigos OID de los dispositivos. Otra cosa que se le podría mejorar sería que la aplicación usara SNMP versión 2 (con seguridad) o 3 y no el 2 (sin seguridad) que está usando. De este modo podría aprovechar los beneficios que traen estas nuevas versiones, en especial adicionarle un poco la parte de seguridad de la comunicación con los dispositivos que brinda la versión 3. Esto no se utilizo en esta versión de la aplicación ya que las librerías utilizadas para la parte del SNMP solo permitían el uso de la versión 1 y 2 sin la parte de seguridad. Es muy importante observar un poco las aplicaciones que ya existen relacionadas al proyecto en el cual uno se encuentre, no solo para saber lo que ya existe sino para ver que se puede reutilizar. Tomemos por ejemplo el MRTG que fue utilizado en este proyecto. Es un programa muy bueno encargado de recolectar datos usando SNMP y de graficarlos en graficas bien claras. Después del análisis se pudo observar de lo bien que hace su función y gracias al licensamiento que tiene se pudo integrar a este proyecto y así ahorrar el tiempo en el desarrollo de un modulo que haga justamente lo que hace MRTG. Hubo otras muy

ISC-2003-2-13

35

buenas aplicaciones que también se analizaron. Estos eran RMONX y JFFNMS los cuales tenían un aspecto más administrativo en comparación con MRTG que es más de monitoreo de datos. En conclusión se pudo observar la gran importancia que tiene SNMP en el área de la administración de dispositivos de red. Gracias a que es un estándar en la mayoría de los dispositivos en mercados que existen esto nos permite tener un protocolo básico para poder llegar a comunicarnos con estos dispositivos de forma centralizada. Esta administración centralizada nos trae el gran beneficio de poder una vista global de la red y poder hacer cambios y toma de decisiones desde un sitio en la red.

ISC-2003-2-13

36

Referencias [1] Andrew Chalmers, “Using open-source and inexpensive tools to cut down management costs”, http://www.serverworldmagazine.com/monthly/2003/04/tools.shtml [2] BTT Software, “BTT Software”, http://www.bttsoftware.co.uk/ [3] Cisco, “Simple Network Management Protocol (SNMP)”, 1994, http://www.cisco.com/warp/public/535/3.html [4] Cisco, “Cisco Works”, http://www.cisco.com/en/US/products/sw/cscowork/ps2406/index.html [5] Computer Associates, “NetworkIT”, http://www.cai.com/products/fdb/networkitpro_fdb_ee.htm [6] “Cricket Home”, http://cricket.sourceforge.net/ [7] HP, “OpenView”, http://www.managementsoftware.hp.com/ [8] “Implementing SNMP on Windows 2000”, http://www.wtcs.org/snmp4tpc/snmp4nt2.htm [9] Javier Szyszlican, “JFFNMS”, http://jffnms.sourceforge.net/ [10] Jeff Case, “Tutorial Abstract: SNMP Update”, May 2001, http://www.nanog.org/mtg-0105/snmp.html [11] Jon Sevy, “Java SNMP Package”, http://edge.mcs.drexel.edu/GICL/people/sevy/snmp/snmp.html [12] Linas Vepstas, “Linux SNMP Network Management tools”, November 1998 http://linas.org/linux/NMS.html [13] Mel Brinkley, “What is SNMP?” UCNS Telecommunications Systems Analyst, Fall Quarter 1995, http://www.uga.edu/~ucns/tti/Computer_Review/Fall95/snmp.html [14] Mr. Vijay Mukhi, Ms. Sonal Kotecha, Mr. Arsalan Zaidi, Mr. Vinesh Kurup, “SNMP” http://www.vijaymukhi.com/vmis/snmp.htm [15] “SNMP4tPC”, http://www.snmp4tpc.com/getif.htm [16] Tobias Oetiker , “MRTG”, http://people.ee.ethz.ch/~oetiker/webtools/mrtg/mrtg.html

ISC-2003-2-13

37

[17] Yoram Cohen, “SNMP - Simple Network Managment Protocol”, http://www2.rad.com/networks/1995/snmp/snmp.htm