SISTEMA DE MONITOREO PARA REDES DE DATOS BASADO EN EL PROTOCOLO· SNMP TRABAJO DE GRADUACION PREPARADO PARA LA FACULTAD DE INGENIERlA PARA OPTAR AL GRADO DE INGENIERO ELECTRONICO POR HERBERT EDGARDO ASCENCIO HURTADO CARLOS ALBERTO BOLAÑOS GUERRERO RAFAEL ADALBERTO COBOS MELENDEZ MARZO-2001 SOYAPANGO-ELSALVADOR-CENTROAMERICA UNIVERSIDAD DON BOSCO FACULTAD DE INGENIERÍA ESCUELA DE INGENIERÍA ELECTRÓNICA RECTOR ING. FEDERICO HUGET DECANO ING. CARLOS BRAN Ing. Franc · co Emilio Morales JURADO ASESOR Alvarenga ---- Üma· Ú Ü~z ~ Ing.V.Íosé Armando Hernández JURADO A Dios, nuestros padres, hermanos, familiares y amigos por todas las muestras de apoyo, comprensión y confianza depositada en nosotros para el logro de ésta meta. Agradecimientos especiales para FEPADE y Americatel El Salvador por toda la colaboración prestada. A todos gracias. Herbert Ascencio INDICE Contenido Página Capítulo I. GENERALIDADES 1.1 Antecedentes del problema ..................................................... · 3 1.2 Importancia y justificación ................. .......... ........ .. ...... .-. . . . . . . . . 5 1.3 Definición del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .. . . . . 6 1.4 Objetivos ....................... ... ........... .................... .... ....... ........... 7 1.4.1 Objetivo general .................... .. ........ ............ .............. 7 1.4.2 Objetivos específicos .................................... ............. 7 1.5 Alcances ... ....... .................... ... ............................ ................... 8 1.6 Limitaciones . . . .. ... . ... . . ..... ....... .. ......... ..... ...... ... . ... ..... .. . .. . . . . . . . . . . 8 l. 7 Metodología de investigación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.7.1 Técnicas utilizadas en la investigación ....... .................. 9 Capítulo II. MARCO TEORICO 2.1 Marco histórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2 Fundamentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2.1 Redes de comunicaciones ............ .... .............. ............ 15 2.2.2 Protocolos ............. ........................................ ............ 17 2.2.3 Modelos de referencia ... . . ......... .... .... ... .. . . . .. . . .. . .. . .. ...... 18 2.2.3.1 Modelo OSI ............... ................................... 18 2.2.3.2 Modelo TCP/IP ............. ............. ................... 21 2.3 Marco conceptual . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . .. . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.3.1 Antecedentes de la gestión de redes ........................... 23 2.3.2 Protocolos de gestión de redes ................................... 24 2.3.2.1 Modelo OSI ...... ......................... ....... ............ 24 2.3.2.2 Modelo TMN ... ............ ... ............ ... .... ...... ... .. 27 2.3.2.3 Modelo Internet (SNMP) ...................... ......... 31 2.3.2.4 RMON .... ........................... : ..................... ..... 32 2.3.2.5 Comparación SNMP/CMIP .............................. 33 2.3.3 Definición de sistema de gestión de redes ............. ...... 34 2.3.4 Normativas para la gestión de redes .. .... .. .. ..... ............ 36 2.4 El protocolo simple para administración de red. (SNMP) .. .... ..... 37 2.4.1 Antecedentes ............................................................ 37 2.4.2 ¿Qué es SNMP? ......................................................... 41 2.4.3 Tecnología SNMP ................ ...... .......... ...... .. .............. 45 2.4.4 Operación del protocolo SNMP ............ ...... ........ .... .... .. 47 2.4.4.1 Funcionamiento del protocolo ........................ 47 2.4.4.2 Estructura del protocolo .. .. .. .. . .. . .. . .. . . .. . .. .. . .. .. . 58 2.5 Base de información sobre la administración (MIS) .. .. . .. .. .. .. .. .. .. 60 2.6 Estructura de la información de administración (SMI) ..... .... ...... 65 Capítulo III. ESTUDIO SOBRE SISTEMAS DE MONITOREO Y CONTROL 3.1 Ope.ración de los sistemas de monitoreo y control .................... 71 3.2 Proceso de adquisición de datos .............. .... .. .... ..... .. .. .... .... .... 75 3.3 Tendencias tecnológicas de las redes de comunicaciones y los sistemas de monitoreo y control .. ...... .. .... .... .. .. .... .... .... ... 76 Capítulo IV. DESARROLLO DEL SISTEMA 4.1 Definición de la capacidad del sistema ..................................... 83 4.1.1 Criterios de diseño ..................................................... 83 4.2 Esquema general de la solución ...... .......... ........ ...... ...... .... .. .... 85 4.3 Definición de la estructura de la base de datos .. .. .. . .. .. .. .. .. .. .. .. .. 88 4.3.1 Routers ..................................................................... 89 4.3.2 Tlpos_target .............................................................. 91 4.3.3 Velocidades ............................................................... 91 4.3.4 Targets ..................................................................... 91 4.3.5 MIS ............. .... ................................................ ......... 92 4.3.6 Target_mib .................................. : ............................ 93 ii 4.3.7 Histórico ................................................................... 93 4.4 Diseño de la base de datos .. .. .. .. . .. .. .. .. .. .. .. . . .. .. .. . . .. . . .. .. .. .. .. .. .. . . 94 Capitulo V. IMPLEMENTACION DEL SISTEMA 5.1 Requerimientos del sistema ................................................... 101 5.1.2 Linux redhat 7.0 ........................................................ 101 5.1.3 Peri .......................................................................... 101 5.1.4 UCD-SNMP ............................................................... 102 5.1.5 PostgreSQL ............................................................... 102 5.1.6 Apache web server .................................................... 102 5.2 Comandos básicos para la operación del sistema ...................... 103 5.2.1 Librerías a utilizar para inicio de programación ............ 103 5.2.2 Sentencias SQL para establecer la conexión ................ 103 5.2.3 Sentencias SQL para interactuar con la base de datos .. 103 5.2.3.1 Conexión para la lectura de datos .................. 103 5.3.1.2 Conexión para la escritura de datos ............... 104 5.3.1.3 Sentencias de lectura de los arreglos de la base de datos ............. .. .. ................... 104 5.3.1.4 Tipos de sentencias SQL para el manejo de datos ...... .... ... . ... .. .. . .. . .. .. .... .. .. .. .. 105 5.2.4 Utilización del módulo UCD-SNMP ............................... 107 5.2.4.1 Snmpget ...................................................... 107 5.2.4.2 Snmpwalk .................................................... 108 5.3 Modelo cliente - servidor ......................................................... 108 5.4 CGI ....................................................................................... 110 5.5 Generación dinámica de HTML ................................................ 111 5.6 Programa principal para la obtención de datos en los dispositivos monitoreados .. . .. . .. . .. ... .. .. .. . . .. .. .. .. .. .. .. .. .. .. .. . 112 5.7 Estructura del sistema ........ .............................. ...................... 114 5.8 Operación del sistema ............................................................ 115 iii 5.8.1 Mantenimientos .......................................................... 116 5.8.1.1 Dispositivos .................................................. 116 5.8.1.2 Interfaces .................................................... 124 5.8.1.3 Mibs ............................................................ 125 5.8.2 Monitoreo .. . .... ...... .... .. ... . ............ ... ...... ... ......... .... ..... 127 · CONCLUSIONES ... .... .... ............ ...... .. ..... ... ..... ........ ..... .... ..................... 133 RECOMENDACIONES ..... ... . ........... ...... .. ... ..... .. . ... . ..... ...... ... .. ... ............ 137 BIBLIOGRAFIA . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 GLOSARIO ........................................................................................... 147 ANEXOS ............................................................................................... 165 iv INDICE DE TABLAS Tabla Página Tabla l. Capas del modelo OSI . . . .. .. . .. .. .. . . . .. .. . ... .. .... . .. . .. .. .. . . . . . . . . . . . .. . . . .. . .. 20 Tabla 2. Recomendación para Gestión SNMP .......................................... 41 Tabla 3. Puertos utilizados para las conexiones SNMP ............................. 43 Tabla 4. Tipos de Error en el campo de error de una PDU Genérica .. .. . .. .. . 50 Tabla 5. Tipos de Trampa Generados por una entidad de protocolo SNMP. 54 Tabla 6. Características de un objeto MIB .. .. .... .. .. .. .. .. .. .. .. . .. .. .. .. . .. . .. .... . .. . 62 Tabla 7. Categoría de las Bases de Información de Administración .. .. . .. .. .. 65 Tabla 8. Tipos de datos utilizados en SNMP Versión 2 .. ..... ....................... 67 Tabla 9. Estructura de la Base de Datos .. .. ......................... ... ....... .......... 89 Tabla 10. Contenido de la tabla Histórico ..... .... .. .......... ........ ........ ... .... .... 95 Tabla 11. Descripción de valores de tabla histórico .. .... .. ..... ....... ... .... .... ... 95 Tabla 12. Ejemplo de mal diseño de tabla histórico .................. : .............. 95 Tabla 13. Ejemplo de asignación de valores en tabla routers . .... .......... ... .. 96 Tabla 14. Ejemplo de tabla histórico con sustitución de símbolos ............. 97 Tabla 15. Ejemplo de asignación de valores en tabla mibs .. ..... .. .............. 97 Tabla 16. Ejemplo de asignación de valores en tabla targets ......... ........ ... 97 Tabla 17. Ejemplo de asignación de valores en tabla Histórico ................. 97 Tabla 18. Ejemplo de lectura de valores en la base de datos .. . .. . .. .. .. . .. .. .. . 98 V INDICE DE FIGURAS Figura Página Figura l. Transmisión Broadcast .. . . . . . .. .. .. .. .. . .. . .. . . . . . . . . • . .. . . . . . .. .. .. . . .. . . .. . .. . .. 15 Figura 2. Red Punto a Punto . . . . . . . . . .. . . .. . . . . . . .. . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Figura 3. Topologías de red ................................................................... 17 Figura 4. Modelo de Capas ...................... .................... .......... ................ 19 Figura S. Flujo de Datos, modelo de capas . ........ ........ .... .... ....... .... ..... ..... 21 Figura 6. Capas del modelo TCP/IP ... ..................................................... 22 Figura 7. (a) Capas del modelo OSI .............................. .......................... 23 (b) Estructura de Protocolos del Modelo TCP/IP ........................ 23 Figura 8. (a) Interacción de Operación .......... ........... .............................. 26 (b) Interacción de Notificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Figura 9. Monitoreo Remoto ................... , ................................. .. ......... .. 33 Figura 10. Sistema de Administración de Red (NMS) ............................... 36 Figura 11. Sistemas Jerárquicos de Administración ............................. ..... 46 Figura 12. Diagrama de flujo . para el proceso de recepción de una PDU -SNMP ..... ... ... .. . . .. . . .......... .... ... ... . .... . .. .... ... . ..... ... 48 Figura 13. Campos de una PDU -SNMP Genérica ..... .. ... ..... .... ... ... . .. . . .... ... 49 Figura 14. Estructura básica del mensaje SNMP Versión 2 .. . . . ..... .. . . .... ..... 58 Figura 15. PDU utilizado en SNMP v2 para los comandos Get, GetNext, Inform, Response, Set y Trap . . . .. . . . . . . . . . .. . . . . . . . . . . . 59 Figura 16. PDU utilizado para ~I comando GetBulk en SNMP v2 . . ........... ... 60 Figura 17. Estructura para las Bases de Información de Administración (MIBs) .. ...... ......... ......... ............. ............... 64 Figura 18. Proceso de Gestión de una Red por medio de SNMP.............. ... 75 Figura 19. Principales elementos administrables con un sistema SNMP . . . .. . .. . . . . . . . . . . . . .. .. .. . . . . . . .. . . . . . . . . . . . . . .. . . . .. . . . .. . 84 Figura 20. Esquema general de la solución ....................... .. .................... 85 vi Figura 21. Estructura de la base de datos . .. .. . .. . . . .. . .. . . . . . . . .. . .. . . . . . . . . .. .. . .. .. .. 89 Figura 22. Comunicación entre un cliente y un servidor ... ....... ................. 109 Figura 23. Estructura de la Interfaz Gráfica ............................................. 114 Figura 24. Pantalla de inicio del Sistema ................................................. 116 Figura 25. Pantalla de Mantenimientos de Parámetros del Sistema ........... 117 Figura 26. Pantalla de Ingreso de Dispositivos ............ ........... .... ..... .... .. .. 118 Figura 27. Pantalla para determinar el índice de las interfaces ................. 119 Figura 28. Pantalla de Información general del dispositivo .. . .. .. . .. .. .. .. .. .. .. . 120 Figura 29. Pantalla de Búsqueda de Dispositivos .................... ... ......... ..... 121 Figura 30. Pantalla de modificación de Dispositivos ............ ...... .... .... ....... 122 Figura 31. Pantalla de modificación de Información del Dispositivos .. .. .. . .. 122 Figura 32. Pantalla de MIB agregados a un Dispositivo .. . .. .. .. .. .. .. .. .. . .. .. .. .. 123 Figura 33. Pantalla de Modificación de interfaces seleccionadas ... .... . ..... .. 124 Figura 34. Pantalla de Modificación de interfaces agregadas ......... ... ........ 125 Figura 35. Tipos de MIB existentes ......................................................... 126 Figura 36. Pantalla de Modificación de MIB .. .. .. .. .. .. .. .. .. . .. .. .. .. . .. .. .. . .. .. .. .. .. 127 Figura 37. Pantalla de listado de dispositivos .. .. .. .. .. . .. .. . .. .. .. .. . .. . .. .. .. .. . .. .. . 128 Figura 38. Pantalla de Información de parámetros del dispositivo .. .. .. .. .. .. . 129 Figura 39. Pantalla de Información de Dispositivos con MIB privados ....... 130 Figura 40. Pantalla de valores de MIB privados ....................................... 130 Figura 41. Grafica de parámetros ........................................................... 131 vii , INTRODUCCION Las redes de telecomunicaciones son un conjunto de elementos discretos, interconectados a través de un medio de transmisión y con una organización de conectividad basada en una topología definida. Las redes de telecomunicaciones transportan la información de los usuarios, estableciendo caminos entre los dos (o más) extremos que comunican. De acuerdo a esta característica, las redes pueden clasificarse en dos grandes grupos: Redes de Conmutación de Circuitos y Redes de Conmutación de Paquetes. Las redes de conmutación de paquetes transportan la información de los usuarios a través de los elementos de red, haciendo uso de la información que posee cada uno de los paquetes, la cual se clasifica en dos tipos, uno de ellos es el encabezado, que consiste en información sobre el direccionamiento, detección de errores, etc. y el otro es la información del usuario, que ha sido previamente fraccionada para adecuarse al tamaño manejado de paquetes en la red. Con la creación de modelos de comunicación para las redes de datos, se ha desarrollado una gran variedad de sistemas de comunicación por parte de los fabricantes de Hardware y Software. El Protocolo de Internet (IP) es uno de los más utilizados en la capa de red de muchos sistemas de comunicación. Los sistemas de administración de redes de datos, son una herramienta necesaria para la relación de los operadores de telecomunicaciones con los dispositivos de· comunicación dentro de la red. Una red administrada permite realizar cambios de manera fácil, supervisar la operación, detectar y controlar fallas en el sistema. En un sistema administrado cada uno de los elementos de red contiene agentes de software y bases de datos con variables que contienen información ix sobre su configuración y estado. Estas variables son transferidas a un elemento específico dentro de la red, que contiene un sistema de administración que recibe e interpreta estas variables al administrador de la red. El protocolo utilizado para la trasferencia de esta información sobre la red IP es el SNMP (Simple Network Management Protocol), que es parte del grupo de #2. protocolos del modelo TCP/IP y es el protocolo de administración más utilizado actualmente por los fabricantes para la administración de equipos de comunicación. El presente documento se encuentra dividido en dos grandes partes, la primera que contiene un estudio teórico sobre los fundamentos de redes de comunicaciones y el protocolo SNMP, para en la segunda desarrollar una guía práctica para el diseño de un sistema prototipo que realiza las funciones básicas del monitoreo de redes y los requerimientos para su implementación. X Capítulo I Generalidades 1.1 ANTECEDENTES DEL PROBLEMA. El tamaño y la complejidad de las redes han ido creciendo aceleradamente debido, en gran parte, a la aparición de las redes públicas de datos como Internet y a la creciente oferta de servicios de comunicaciones de valor agregado soportados sobre redes de conmutación de paquetes. En la operación de la transferencia de información a través de las primeras redes, surgió la necesidad de implementar sistemas de gestión, es decir, sistemas capaces de controlar los recursos que la componen en términos de rendimiento, capacidad, utilización, reconfiguración, diagnósticos y planificación. La gestión de red es un concepto que comprende la administración de los diferentes. recursos que constituyen -una red, tomando forma de seguimiento, coordinación y control de los recursos informáticos y de comunicaciones. Una de las funciones que realiza un sistema de gestión de red es la supervisión constante del funcionamiento adecuado de cada uno de los elementos que componen el sistema de comunicación, constituyendo en forma global el monitoreo efectuado a la red, que constituye el elemento clave en la detección y corrección de errores y fallas dentro de la red. Los sistemas de monitoreo de redes se pueden clasificar de acuerdo al tipo de red al que están orientados: • Sistemas de Monitoreo de equipos de comunicaciones. • Sistemas de Monitoreo de redes de comunicaciones. • Sistemas de Monitoreo de Arquitecturas de computadoras. • Sistemas de Monitoreo de redes de área local (LAN). 3 Las compañías operadoras de Seivicios de Telecomunicaciones y fabricantes de computadoras han desarrollado Sistemas de Monitoreo propios para controlar los seivicios que brindan sus redes y recursos de comunicaciones ( dispositivos y protocolos) propios de su arquitectura de comunicaciones, entre los cuales existen: • Netview de IBM. • Cisco Works de Cisco Systems. • UNMA (Unified Network Management Architecture) de ATT. • ENMA (Enterprisewide Management Architecture) de DEC. Dado el crecimiento de redes de área local instaladas, existen también diversos Sistemas de Monitoreo desarrollados para controlarlas: • LAN Manager. • Vines. • Netware. • Whats up La mayor parte del desarrollo de normas para el Monitoreo de redes se basan en los dos modelos siguientes: • Gestión OSI para las redes basadas en protocolos OSI. • Gestión SNMP para las redes basadas en el modelo TCP/IP. Alguni?s corporaciones se han decidido por las soluciones particulares para la gestión y monitoreo, ya sea, desarrollando sistemas propios o utilizando los sistemas de fabricantes específicos. 4 1.2 IMPORTANCIA Y JUSTIFICACIÓN Los sistemas de monitoreo de redes de comunicaciones han evolucionado con el desarrollo tecnológico en esta última década, como resultado de los beneficios que ofrecen: • Supervisión continua de la operación de los elementos una red. • Disminución en el tiempo de respuesta en la detección de problemas de operación, permitiendo un nivel elevado de disponibilidad, que implica calidad en el servicio que la red presta. • Información visual de la ubicación de una falla dentro de la red administrada, que permite al operador identificarla inmediatamente para realizar las correcciones necesarias. • Medición de tráfico generado en elementos o grupos de elementos, que proporciona un parámetro de calidad de la operación actual de la red, permitiendo al proveedor de servicio la planeación de su crecimiento y posibles cambios en su topología. • Medición de los recursos físicos (memoria, unidad de procesamiento o puertos de comunicación) y lógicos (Sistema operativo) utilizados en el sistema, en los elementos de red y en los enlaces de comunicación para planificar la actualización en un elemento específico. • Realización de tareas de monitoreo en tiempos programados que permitan un . punto de equilibrio en la utilización de recursos y la veracidad de la información de supervisión. Los fabricantes de equipos de comunicaciones desarrollan, además, herramientas para la administración de los sistemas de red, lo cual implica lo siguiente: • Altos costos de adquisición del sistema de administración. 5 • Costos adicionales por la contratación de servicios profesionales, especializados en el área de administración de redes, para su implementación y capacitación del personal que opera la red. Esta segunda implicación, es causa de la carencia de los conocimientos fundamentales en el área de administración de redes, en las empresas de telecomunicaciones de nuestro país, lo cual justifica la investigación de técnicas eficientes, que permitan desarrollar aplicaciones para el monitoreo de redes y la introducción de los avances tecnológicos relacionados a esta área en El Salvador. En el país se ha generado un alto crecimiento en la demanda de servicios de comunicación de datos y acceso a Internet, obligando a las empresas a ser más competitivas en la calidad de los servicios que brindan, para lo cual es sumamente indispensable un sistema que permita conocer _el estado actual de los diferentes elementos que forman parte de la red, en forma continua. 1.3 DEFINICIÓN DEL PROBLEMA El funcionamiento de las redes de conmutación de paquetes está sujeto a los siguientes problemas: • Los protocolos de conmutación de paquetes como IP han sido creados para que la información (en paquetes) fluya dentro de la red por caminos disponibles y cercanos a su destino, sin tomar en cuenta enlaces fuera de ·servicio, por lo que no es inmediata la detección de problemas en un enlace de comunicación sin una herramienta que verifique su funcionamiento. • Los sistemas de administración y monitoreo de redes tienen elevados costos y requieren, para su implementación, de personal especializado que generalmente proviene del extranjero. 6 • Una red de comunicaciones requiere un elemento que supervise la operación del funcionamiento de la misma. • En El Salvador no se ha realizado una investigación sobre el funcionamiento del protocolo SNMP y los conceptos fundamentales de su operación, para el desarrollo de sistemas de aplicación específicos. · 1.4 OBJETIVOS 1.4.1 OBJETIVO GENERAL: • Desarrollar un sistema que permita establecer procedimientos de monitoreo sobre elementos específicos ubicados en una red de comunicación de datos, por medio del protocolo SNMP. 1.4.2 OBJETIVOS ESPECÍFICOS: • Investigar las principales características que poseen los sistemas de comunicación de datos para determinar las estrategias de monitoreo sobre su operación. • Conocer las principales normas de administración de redes para el desarrollo de . un sistema que cumpla con las características necesarias para efectuar una supervisión por medio del protocolo SNMP. • Determinar los requerimientos y funciones de cada elemento de una red administrada. • Desarrollar un sistema de supervisión, basado en un sistema operativo, capaz de funcionar en una red, como gestor de las variables involucradas en ella. 7 1.5 ALCANCES Con el desarrollo del presente proyecto se logrará: • Proporcionar una guía práctica para desarrollar un sistema de monitoreo para la administración de redes. • Brindar conocimientos generales para la comprensión del protocolo SNMP y conceptos relacionados. • Crear un sistema de monitoreo de redes basado en estándares internacionales de administración. • Analizar por medio del sistema creado, la información de administración mediante una interfaz de operador, que permita una fácil y rápida comprensión de los resultados obtenidos. • Determinar los procedimientos de actualización del sistema para el monitoreo de nuevos dispositivos que sean administrables por medio del protocolo SNMP. 1.6 LIMITACIONES • Los procedimientos de actualización del sistema dependen directamente de la capacidad de integración en sistemas de administración de equipos específicos de comunicaciones creados por ciertos fabricantes. • Los procedimientos de escritura sobre los elementos administrados estarán limitados por el acceso que los diferentes fabricantes permiten de sus equipos. • La cuantificación del número máximo de elementos que forman parte de una red administrada, por un solo sistema de monitoreo, depende de diversos elementos específicos de una red. • El desarrollo del Sistema de Monitoreo para Redes de Datos basado en el Protocolo SNMP será una aplicación de tipo general, que para su operación 8 será configurado con una marca específica ampliamente utilizada en las empresas locales. 1.7 METODOLOGÍA DE INVESTIGACIÓN La investigación a realizar es directa como también de tipo documental. En una primera fase se pretende recopilar información bibliográfica y documentación digital, centrando esta investigación en lo que son los protocolos de gestión de administración de redes, así como lo relacionado con las redes de comunicaciones. Como segunda fase se llevará a cabo una investigación acerca de aplicaciones en sistemas de monitoreo de redes utilizando el protocolo de gestión SNMP. 1.7.1 TECNICAS UTILIZADAS EN LA INVESTIGACION. • Correo electrónico. Ha permitido la comunicación con personas que en alguna medida están involucradas en el desarrollo de sistemas de administración de redes, profesionales y otro tipo de personas que tienen conocimiento en aplicaciones similares a la que se está implementando, así como de aquellos foros de discusión en los cuales se tratan temas afines al sistema propuesto. • Investigación bibliográfica. Se ha realizado una investigación bibliográfica sobre los diferentes componentes necesarios para la implementación Sistema de Monitoreo para Redes de Datos, Basado en el Protocolo SNMP. El material utilizado incluye libros, revistas, documentación y otro tipo de literatura con información de gran ayuda para el desarrollo del trabajo. 9 • Entrevistas con profesionales. Llevadas a cabos con profesionales en el área de Internet y de tecnología de información encargadas o responsables del departamento operaciones de empresas privadas, debido a que estas personas están en contacto con los distintos equipos y tienen relación directa con los problemas que se observan en el mantenimiento de una red de comunicaciones. • Información disponible en www. Como se sabe Internet es una fuente que permite tener acceso a la más variada información sobre un tema en particular, razón por la cual se ha convertido en la principal técnica de investigación para el presente trabajo, esto porque permite conocer los diferentes aspectos relativos a como llevar a cabo la implementación de cualquier sistema o desarrollo de alguna aplicación en particular, así como también documentación sobre diferentes proyectos y aplicaciones referentes a lo que son los sistemas de gestión y monitoreo. El WWW se ha convertido en la principal fuente para obtener información para llevar a cabo este trabajo, ya que en El Salvador se cuenta con muy poca documentación relativa a este tipo de aplicación. 10 Capítulo II Marco ·Teórico 2.1 MARCO HISTÓRICO Desde el desarrollo de los dispositivos semiconductores y la integración en alta escala de dispositivos, las comunicaciones han evolucionado aceleradamente, tanto el campo de la comunicación de voz, como de la comunicación de equipos electrónicos, hasta lograr la integración de las comunicación en las actuales redes de conmutación de paquetes con la capacidad de operar múltiples servicios. En un principio la comunicación de datos se realizó en forma experimental y regional en organismos militares y de investigación en Estados Unidos y Rusia. En 1973, la DARPA inició un programa de investigación de tecnologías de comunicación entre redes de diferentes características. El proyecto se basó en la transmisión de paquetes de información y tenía por objetivo la interconexión entre redes. De este proyecto surgieron dos redes: ARPANET (para investigación) y MILNET (de uso exclusivamente militar). Para comunicar redes se desarrollaron básicamente dos protocolos: El Protocolo de Internet (IP) y el Protocolo de Control de Transmisión (TCP) que posteriormente se integraron para formar el conjunto de protocolos TCP/IP. En 1980, se incluyó en el UNIX 4.2 de Berkeley, el conjunto TCP/IP y fue el protocolo militar estándar en 1983. Con el nacimiento en 1983 de Internet, este grupo de protocolos ·fue extensamente popularizado para formar una interred que es la principal fuente de información en la actualidad. En 1985, la ARPANET fue ampliamente utilizada y llegó a presentar congestión en los servicios de comunicación, en respuesta a este hecho, la Fundación Nacional de Ciencia, inició la fase 1 del desarrollo de la red NSFNET. 13 La NSFNET se formó por múltiples redes regionales y redes punto a punto como la "NASA SCIENCE NET'', conectadas a través de una estructura constituida sobre la NSFNET. En 1986, la NSFNET se extendió, como estructura jerárquica, conectando redes regiones y redes de centros de investigación el cual se encontraba conectado a un núcleo principal formado por el enlace entre seis centros de ''Supercomputadoras'~ Los enlaces originales tenían un ancho de banda de 56kbps, el cual fue incrementado en ·1988 a enlaces estándar Tl (1.544Mbps). Este fue el resultado de los altos requerimientos de los servicios de comunicación demandados por la NSF. La red ARPANET dejó de funcionar oficialmente en 1990 y en 1991 el tráfico de datos fue incrementado considerablemente, generando la necesidad de un incremento de los enlaces del núcleo de la NSFNET a enlaces T3 ( 45Mbps). En la actualidad el núcleo del Internet se encuentra formado por un conjunto de empresas que se denominan Proveedores de Servicios de Internet (ISP, Internet Service Providers) que poseen puntos de conexión, denominados Puntos de Presencia (POS, Points Of Presence) en muchas regiones alrededor del planeta. El término "Proveedores de Servicios de Internet" se utiliza actualmente para cualquier empresa que proporcione conectividad entre redes, sin embargo es común que se pueda distinguir entre proveedores de mayor capacidad (NSP, National Service Providers) y puntos de presencia que permiten el acceso (NAP, Network Access Point) a empresas de menor capacidad. 14 Dada la cobertura global de las empresas dedicadas a la interconexión de redes, el tráfico sé incrementado en forma proporcional, por lo que se han desarrollado nuevas tecnologías para . la transmisión sobre medios como fibra óptica con WDM y DWDM, Packet Over SONET (Syncronous Optical Network), con estándares de velocidad basados en una Jerarquía SDH (Jerarquía Digital Síncrona) desde 155Mbps hasta el desarrollo de interfaces hasta de 10Gbps. 2.2 FUNDAMENTOS 2.2.1 REDES DE COMUNICACIONES Una red de comunicaciones consiste en un conjunto de elementos interconectados entre sí por medio de enlaces que permiten la interacción entre cada uno de ellos para soportar el transporte de información de un sitio a otro. Cuando la información transferida en la red posee formato digital y pertenece a dispositivos informáticos se denomina una red de comunicación de datos. Las redes de comunicación de datos pueden clasificarse, en forma general, de acuerdo a dos criterios: por tecnología de transmisión y por escala de cobertura. Las redes de comunicación de datos, de acuerdo a la tecnología de transmisión que utilizan pueden clasificarse en: • Redes de Medios Compartidos (Broadcast): Un solo canal de comunicación es compartido por todos los dispositivos o elementos de red. Un paquete de datos enviado por uno de ellos es recibido por todos los rPd"::mtPc: rlonrlP c:P Pnr11Pntr;:::i inrlt 1irlo 15 Información Agura 1. Transmisión Broadcast restantes, donde se encuentra incluido el destinatario del paquete. • Redes Punto a Punto: Existen conexiones entre pares individuales de elementos de red. Los paquetes que se envían de un elemento A a un elemento B, pueden circular a través de elementos C y D, donde se utiliza el enrutamiento (routing) para dirigirlos. RED Figura 2. Red Punto a Punto Generalmente las redes de medios compartidos se emplean en redes de área local, mientras que las redes de Punto a punto en redes de área extensa. Por la escala de cobertura, las redes pueden clasificarse como: • Redes de Área Local (LAN): Posee distancias entre elementos de red menores a 1km y al~as velocidades de transmisión. • Redes de Área Extensa (WAN): realizan el enrutamiento de los paquetes para dirigir la información entre dos elementos de red y pueden extenderse hasta 1,000km. TOPOLOGÍA DE RED La topología o arquitectura de un sistema de comunicación de datos, identifica la forma en que varias estaciones o elementos de la red se encuentran interconectados. La figura 3 muestra la disposición de la interconexión en cada una de ellas. 16 a Elemento de Red :'!'?1x,q!• e Elemento de Red (d) Rgura 3. Topologías de red. (a) Punto a Punto; (b) Estrella; (e) Bus o medio compartido; (d) Anillo; (e) Malla Completa. 2.2.2 PROTOCOLOS De la misma forma que los protocolos están presentes en todo proceso para el establecimiento- de comunicación humana, en los dispositivos electrónicos es esencial, desde los de más bajo nivel (por ejemplo, la transmisión de bits en un medio ñsico) hasta aquellos de más alto nivel ( como la ejecución de aplicaciones cliente-servidor en una red informática). Tomando al modelo OSI (Open Systems Interconection) como referencia podemos afirmar que para cada capa o nivel que él define existen uno o más 17 protocolos interactuando. Los protocolos se ejecutan entre pares de dispositivos lógicos o físicos iguales. Por lo tanto, los protocolos establecen una descripción formal de los formatos en que deberán presentar los mensajes para poder ser intercambiados por equipos de comunicaciones y además definen las reglas que se deben seguir para lograr el flujo de la información. 2.2.3 MODELOS DE REFERENCIA. 2.2.3.1 MODELO OSI. Una de las necesidades más crítica de un sistema de comunicaciones es el establecimiento de estándares, sin ellos sólo podrían comunicarse entre sí, equipos del mismo fabricante y de igual tecnología. La conexión entre equipos electrónicos ha sido estandarizando paulatinamente siendo las redes telefónicas las pioneras en este campo, por ejemplo la histórica CCITT definió los estándares de telefonía: PSTN, PSDN e ISDN. Otros organismos internacionales que generan normas relativas a las telecomunicaciones son: ITU-TSS (antes CCITT), ANSI, IEEE e ISO. La ISO (International Organization for Standarization) ha generado una gran variedad de estándares, siendo uno de ellos la norma IS0-7494 que define el modelo OSI, proporciona · una herramienta teórica para comprender mejor el funcionamiento de las redes de comunicación de datos. El modelo OSI no garantiza la comunicación entre equipos pero establece las bases para una mejor estructuración de los protocolos de comunicación. Tampoco existe ningún sistema de comunicaciones que los aplique estrictamente, siendo la familia de protocolos TCP/IP la que más se acerca. 18 El modelo OSI consta de 7 capas o niveles. Las características generales de las capas son las siguientes: • Cada una de las capas desempeña funciones bien definidas. • Los servicios proporcionados por cada nivel son utilizados por el nivel superior. • Existe una comunicación virtual entre las mismas capas durante una conexión, de manera horizontal. • Existe una comunicación vertical entre una capa de nivel N y la capa de nivel N + 1. a) Comunicación horizontal entre capas iguales. lnformació Información b) Comunicación vertical entre capas adyacentes. Figura 4. Modelo de Capas. En la tabla 1 se detallan las funciones y aplicaciones de cada unas de las capas del modelo OSI. Nivel Nombre FUNCION Dispositivos y protocolos 1 Físico Establece la transmisión del flujo de bits a través Cables, tarjetas y hubs. del medio. RS-232, X.21, V.35. 2 Enlace Divide el flujo de bits en unidades con formato Bridges, Switches (tramas) intercambiándolas mediante el empleo de HDLC, PPP y LLC. protocolos de línea. 19 3 Red Establece las comunicaciones y determina el Routers. camino que tomarán los datos en la red. Además proporciona el direccionamiento lógico. IP, IPX, AppleTalk. 4 Transporte Garantiza la entrega confiable de segmentos al Gateways. receptor por medio de mensajes de UDP, TCP, SPX. reconocimiento. Además establece el control del flujo. 5 Sesión Administra la comunicación entre las aplicaciones y Gateways. permite a un mismo usuario, realizar y mantener diferentes conexiones a la vez (sesiones). 6 Presentación Conversión entre distintas representaciones de Gateways. datos y entre terminales y organizaciones de Compresión, encriptado, sistemas de archivos con características diferentes. vnoo. 7 Aplicación Este nivel proporciona servicios estandarizados X.400 para poder realizar funciones especificas en la red. Las personas que utilizan las aplicaciones hacen una petición de un servicio (por ejemplo un envío de un archivo). Tabla l. Capas del modelo OSL La comunicación en el modelo OSI siempre se realiza entre dos sistemas. Cuando la información se genera en el nivel 7 del emisor, desciende por el resto de los niveles hasta llegar al nivel 1, que es el correspondiente al medio de transmisión (por ejemplo el cable de red) y llega hasta el nivel 1 del otro sistema, donde va ascendiendo hasta alcanzar el nivel 7. En este proceso, cada uno de los niveles divide la información y agrega a los datos información de control relativa a su nivel, de forma que los datos originales van siendo recubiertos por capas o datos de control, formando en cada una unidades de datos de protocolo (PDU). De forma análoga, al ser recibido" dicho paquete en el otro sistema, según va ascendiendo del nivel 1 al 7, va descartando en cada nivel los datos añadidos por el nivel equivalente del otro sistema, hasta quedar únicamente los datos transmitidos. 20 Información de Control Transmisor 1 datos Receptor y 1 Aplicación 1 e? 1 datos Aplicación 1 es I e? 1 1 Presentación datos Presentación Sesión 1 es es I e1 I datos Sesión 1 Transporte e4 es es!C?I datos Transporte 1 Red 1 e3 e4 es es I e? 1 datos Red 1 Enlace 1e21 e3 e4 es es I e? 1 datos Enlace 1 Física 1 e1 1e21 e3 e4 es es I e7 I datos Física • Figura 5. Flujo de Datos, modelo de capas (CN información de control del nivel N). De esta forma, la información de control que se adiciona en los paquetes, permite que, como ejemplo, el nivel 5 de un sistema local establezca una conexión virtual con el nivel 5 del sistema remoto, de tal forma que la -información debe _ recorrer los niveles 4 al 1 en el sistema local y del 1 al 4 del sistema remoto. A las normas de comunicación entre niveles iguales es a lo que se denomina protocolo. Este mecanismo asegura la modularidad del conjunto, ya que cada nivel es independiente de las funciones del resto, lo que garantiza que para modificar las funciones de un determinado nivel no sea necesario reescribir todo el conjunto. En las familias de protocolos más utilizadas en redes de computadoras (TCP/IP, IPX/SPX, etc.), se suele encontrar con funciones de diferentes niveles en un solo nivel, debido a que la mayoría de ellos fueron desarrollados antes que el modelo OSI. 2.2.3.2 MODELO TCP/IP. Las funciones propias de una red de comunicaciones pueden ser divididas en las siete capas propuestas por ISO para su modelo de sistemas abiertos (OSI). 21 Sin embargo la implementación real de una arquitectura puede diferir de este modelo. El Modelo TCP/IP propone cuatro capas, donde las funciones de las capas de Sesión y Presentación son responsabilidad de la capa de Aplicación y las capas de Enlace de Datos y Física son vistas como la capa de Interface a la Red. Por tal motivo para TCP/IP sólo existen las capas Interface de Red, la de Red, la de Transporte y la de Aplicación. Como puede verse TCP/IP presupone independencia del medio ñsico de comunicación, sin embargo existen estándares bien definidos a los nivel de Enlace de Datos y Físico que proveen mecanismos de acceso a los diferentes medios y que en el modelo TCP/IP deben considerarse la capa de Interface de Red; siendo los más usuales el proyecto IEEE 802, Ethernet, Token Ring y FDDI. Aplicación ·:., Transporte .. . . Red ' Interface de Red Figura 6. Capas del modelo TCP/IP. Para entender el funcionamiento de los protocolos TCP/IP debe tenerse en cuenta la arquitectura que ellos proponen para comunicar redes. Tal arquitectura ve como iguales a todas las redes a conectarse, sin tomar en cuenta el tamaño de ellas, ya sean LAN o WAN. Define que todas las redes que intercambiarán información deben estar conectadas a un mismo dispositivo de comunicación o equipo de procesamiento, a tales dispositivos se les denomina ''Puertas de Enlace (Gateways)'~ que generalmente son dispositivos como ''Routers" o ''Bridges'~ 22 En la figura 7 ·se establece una relación entre el conjunto de protocolos TCP /IP y el modelo OSI. Aplicación Presentación Telnet TFP SNMP SMTP DNS HTTP TFTP Sesión Transporte TCP (TCP/UDP) Red IP (ICMP) Enlace IEEE 802.2 AAL de Datos IEEE 802.3 IEEE 802.5 LAPB ATM Física Ethernet Token Ring I FDDI Línea Sincrona SONET ( a ) ( b) Figura 7. (a) Capas del modelo OS/; (b) Estructura de Protocolos del Modelo TCP/IP. La figura 7 (b) esquematiza lo que se denomina "Estructura de Protocolos TCP/IP", donde Ethernet, Token Ring, FDDI, Línea síncrona (Redes de Área Ancha) y SONET, son tecnologías de interconexión que definen estándares de acuerdo al medio de transmisión utilizado por cada uno de ellos (Cobre, Fibra Óptica, Radio). Las normas IEEE 802.2 definen el formato de las tramas que establecen el enlace en la comunicación. AAL es un protocolo de adaptación que se utiliza para la interconexión de redes sobre una plataforma ATM (Modo de Transferencia Asíncrona). 2.3 MARCO CONCEPTUAL 2.3.1 ANTECEDENTES DE LA GESTIÓN DE REDES El organismo que administra y regula la red Internet encargó en 1987, a un grupo técnico ( que se encarga de encontrar soluciones a los problemas técnicos 23 que plantea el funcionamiento de la red), una solución de gestión integrada para dicha red. Este grupo técnico propuso una solución que sé dividió en dos fases: • En la primera fase, utilizar un único protocolo capaz de ser entendido por todos los dispositivos de la red Internet, como solución provisional a corto plazo. • Posteriormente cuando se desarrollaran las normas OSI, utilizar los protocolos de gestión OSI soportados sobre la plataforma de comunicaciones de Internet. Esta solución se conoce como CMOT (CMIP sobre TCP/IP). 2.3.2 PROTOCOLOS DE GESTION DE REDES Las cuatro principales arquitecturas de gestión de red que actualmente existen son: • Modelo OSI • Modelo TMN • Modelo Internet (SNMP) • RMON 2.3.2.1 MODELO OSI ISO ha definido una arquitectura de gestión OSI cuya función es permitir supervisar, controlar y mantener una red de datos. El modelo de Gestión de red OSI está dividido en cinco categorías de servicios de gestión denominadas Áreas Funcionales Específicas de Gestión (Specific Management Functiona/ Areas, SMFA). Estas categorías son las siguientes: 24 • Gestión de configuración La gestión de configuración comprende una serie de facilidades mediante las cuales se realizan las siguientes funciones: □ Activación y desactivación de elementos. □ Definición o cambio de parámetros de configuración. o Recolección de información de estado. □ Denominación de los elementos de la red. • Gestión de fallos Detección, diagnóstico y corrección de los fallos de la red y de las condiciones de error en sus elementos. Incluye los siguientes procedimientos: o Notifjcación de fallos □ Sondeo periódico en busca de mensajes de error □ Establecimiento de alarmas • Gestión de prestaciones Se define como la evaluación del comportamiento de los elementos de la red. Para hacer posible este análisis es preciso mantener un histórico con datos estadísticos y de configuración. • Gestión de contabilidad Determinación de los costos asociados a la utilización de los recursos de la red y la asignación de los correspondientes cargos para los usuarios. • Gestión de seguridad Comprende el conjunto de facilidades mediante las cuales el administrador de la red modifica la funcionalidad que proporciona seguridad que restringe el acceso no autorizado. Incluye aspectos como la gestión de claves, firewalls e históricos de seguridad. 25 El proceso de supervisión y control de un objeto 'Gestionable'' se realiza mediante una serie de interacciones. Estas interacciones pueden ser de dos tipos: • De operación: el gestor solicita información al objeto gestionable o requiere realizar una acción sobre él. • De notificación: el objeto gestionable envía información al gestor como consecuencia un evento ocurrido en el dispositivo. Gestor del Sistema Sistema de Objetos (a) Solicitud de Información Gestor del Sistema Notificación de Eventos Sistema de Objetos (b) Notificación de Eventos Figura 8. (a) Interacción de Operación; (b) Interacción de Notificación. Un objeto gestionable se caracteriza además por un conjunto de atributos que són las propiedades, o características del objeto, y un comportamiento en respuesta a las operaciones solicitadas. Otros componentes de la arquitectura de gestión OSI son: • Estructura de la Información de Gestión (Structure of Management Information, SMI). Define la estructura lógica de la información de gestión OSI. Establece las reglas para nombrar, codificar e identificar a los objetos gestionables y a sus atributos. Define un conjunto de subclases y tipos de 26 atributos que son en principio aplicables a todos los tipos de clases de objetos gestionables. • Base de Información de Gestión ( Management Information Base, MIB). Representa la información que se está utilizando, modificando o transfiriendo en la arquitectura de los protocolos de gestión OSI. La MIB conoce todos los objetos gestionables y sus atributos. No es necesario que este centralizada físicamente en un lugar concreto, puede estar distribuida a través del sistema y en cada uno de sus niveles. • CMIS ( Common Management Information Services). Consiste en un conjunto de reglas que identifican las funciones de una interfaz OSI entre aplicaciones, utilizado por cada aplicación para intercambiar información. CMIS define la estructura de la información que es necesaria para describir el entorno. 2.3.2.2 MODELO TMN El término TMN (Telecommunications Management Network) fue introducido por la ITU-T, y está definido en la recomendación M.3010. Aunque en un principio no hubo mucha colaboración entre los grupos de gestión de red de la ISO y el CCITT (antecesor de la ITU-T), posteriormente fueron incorporados los siguientes conceptos del modelo OSI al estándar TMN: • Se adoptó el modelo gestor-agente del modelo OSI. _ • Se siguió el paradigma de la orientación a objetos de la arquitectura OSI. • Se trabajó conjuntamente en el desarrollo del concepto de dominios de gestión. 27 Una diferencia entre ambos modelos consiste en la introducción, en el modelo TMN, de una red separada de aquella que se gestiona, con el fin de transportar la información de gestión (Fuera de Banda). A diferencia del modelo OSI, en el cual se definen cinco áreas funcionales, el estándar TMN no entra en consideraciones sobre las aplicaciones de la información gestionada. Por el contrario, el modelo TMN define las siguientes funcionalidades: • El intercambio de información entre la red gestionada y la red TMN. • El intercambio de información entre redes TMN. • La conversión de formatos de información para un intercambio consistente de información. • La transferencia de información entre puntos de una TMN. • El análisis de la información de gestión y la capacidad de actuar en función de ella. • La manipulación y presentación de la información de gestión en un formato útil para el usuario u operador de la red. • El control del acceso a la información de gestión por los usuarios autorizados. Arquitectura TMN El modelo TMN define su arquitectura en tres grandes grupos: a) Arquitectura funcional, que describe la distribución de la funcionalidad dentro de la TMN, con el objeto de definir los bloques funcionales a partir de los cuales se construye la TMN. b) Arquitectura física, que describe las interfaces y el modo en que los bloques funcionales se implementan en equipos ñsicos. 28 e) Arquitectura de la información, que sigue los principios de los modelos OSI de gestión (CMIS y CMIP). En general la arquitectura del modelo TMN trabaja, basado en bloques funcionales que ejecutan los procedimientos de supervisión y control sobre la red gestionada. En la arquitectura funcional se definen cinco tipos de bloques funcionales. Estos bloques capacitan a la TMN para realizar sus tareas de gestión: • Función de operación de sistemas {OSF). Los OSF procesan la información relativa a la gestión de la red con el objeto de monitorear y controlar las funciones de gestión. Es posible definir múltiples OSF dentro de una única TMN. • Función de estación de trabajo {WSF). Este bloque funcional proporciona los mecanismos para que un usuario pueda interactuar con la información gestionada por la TMN. • Función de elemento de red {NEF). Es el bloque que actúa como agente, susceptible de ser monitoreado y controlado. Estos bloques proporcionan las funciones de intercambio de datos entre los elementos de la red y el sistema de gestión. • Adaptadores Q {QAF). Este tipo de bloque funcional se utiliza para conectar a la TMN aquellas entidades que no soportan los puntos de referencia estandarizados por TMN. • Función de mediación {MF). La función de mediación se encarga de garantizar que la información intercambiada entre los bloques del tipo OSF o NEF cumple los requisitos demandados por cada uno de ellos. Puede realizar 29 funciones de almacenamiento, adaptación, filtrado y condensación de la información. Estándar TMN El estándar TMN define una serie de capas o niveles de gestión mediante las cuales se pretende abordar la gran complejidad de la gestión de redes de telecomunicación. Cada uno de estos niveles agrupa un conjunto de funciones de gestión. El estándar LLA define cuáles son esos niveles y las relaciones entre ellos. Se definen los siguientes niveles: • Nivel de Elementos de Red. Incluye- las funciones que proporcionan información en formato TMN del equipamiento de red así como las funciones de adaptación para proporcionar interfaces TMN a elementos de red no-TMN. • Nivel de Gestión de Elementos. Incluye la gestión remota e individual de cualquier elemento de red que se precise para el establecimiento de conexiones entre dos puntos finales para proporcionar un servicio. Este nivel proporcionará funciones de gestión para monitorear y controlar elementos de gestión individuales en la capa de elemento de red. • Nivel de Gestión de Red. Incluye el control, superv1s1on, coordinación y configuración de grupos de e_lementos de red constituyendo redes y subredes para la realización de una conexión. • Nivel de Gestión de Servicios. Incluye las funciones que proporcionan un manejo eficiente de las conexiones entre los puntos finales de la red, asegurando un óptimo aprovisionamiento y configuración de los servicios prestados a los usuarios. 30 • Nivel de Gestión de Negocio. Incluye la completa gestión de la explotación de la red, incluyendo contabilidad, gestión y administración, basándose en las entradas procedentes de los niveles de Gestión de Servicios y de Gestión de Red. 2.2.3.3 MODELO DE INTERNET (SNMP) En 1988, el IAB (Internet Activities Board, Comité de Actividades Inter- Red) determinó la estrategia de gestión para el modelo TCP/IP (Transfer Control Protocol/Internet Protocol). Esto significó el nacimiento de dos esfuerzos paralelos: la solución a corto plazo, SNMP, y la solución eventual a largo plazo, CMOT (CMIP sobre TCP/IP). CMOT implantaría los estándares del modelo de gestión OSI en el entorno Internet (TCP/IP). CMOT tuvo que afrontar los problemas derivados de la demora en la aparición de especificaciones y la ausencia de implementaciones prácticas. Como consecuencia de ello, la iniciativa CMOT fue paralizada en 1992. Actualmente, la gestión SNMP es un directo competidor de la Gestión OSI y se siguen definiendo normas para la gestión SNMP. La última implementación del protocolo SNMP es la norma SNMP versión 3, que actualmente esta en la fase de pruebas y desarrollo. El protocolo SNMP procede del protocolo SGMP (Simple Gateway Management Protocol), que es un Protocolo Sencillo para · Gestión de Equipos Informáticos que efectúan enrutamiento de datagramas IP en Internet. El protocolo SNMP fue desarrollado por los mismos autores que el protocolo SGMP. Estas personas tienen una visión práctica de las redes y desarrollaron el protocolo en solamente unos meses. 31 SNMP se ha convertido, debido al enorme éxito que ha tenido desde su publicación, en el estándar más popular de gestión de redes. Prácticamente todo el equipamiento de redes puede ser gestionado por SNMP. Algunas de las funciones que proporciona SNMP son: • Supervisión del rendimiento de la red y su estado. • Control de los parámetros de operación. • Obtención de informes de fallos. • Análisis de fallos. Debido a que SNMP es el protocolo gestión central de esta investigación será estudiado con detalle en secciones posteriores. 2.3.2.4 RMON La especificación RMON (Remate MONítor, monitoreo remoto) es una base de información de gestión (MIS) desarrollada por el organismo IETF (Internet Engineering Task Force) para proporcionar capacidades de monitoreo y análisis de protocolos en redes de área local (segmentos de red). Esta información proporciona a los gestores una mayor capacidad para planificar y ejecutar una política preventiva de mantenimiento de la red. Las implementaciones de RMON consisten en_ soluciones cliente/servidor. El cliente es la aplicación que se ejecuta en la estación de trabajo de gestión, presentando la información de gestión al usuario. El servidor es el agente que se encarga de analizar el tráfico de red y generar la información estadística. La comunicación entre aplicación y agente se realiza mediante el protocolo SNMP. 32 Í Agente RMON Estación de Gestión Agente RMON - Estadísticas - Supervisión del Sistema Agente RMON Figura 9. Monitoreo Remoto RMON es una herramienta muy útil para el gestor de red pues le permite conocer el estado de un segmento de red sin necesidad de desplazarse físicamente hasta el mismo y realizar medidas con analizadores de redes y protocolos. Las iniciativas se dirigen actualmente hacia la obtención de una mayor y más precisa información. En concreto, se trabaja en la línea de analizar los protocolos de nivel superior, monitoreando aplicaciones concretas y comunicaciones extremo a extremo (niveles de red y superiores). Estas facilidades se incorporarán en versiones sucesivas de la especificación (RMON II). 2.3.2.5 COMPARACION SNMP /CMIP. A continuación se hace una comparación entre los protocolos SNMP y CMIP: • SNMP está basado en técnicas de sondeo, mientras que CMIP utiliza una técnica basada en eventos. Esto permite a CMIP ser más eficiente que SNMP en el control 9e grandes redes. • CMIP es un protocolo orientado a conexión mientras que SNMP es un protocolo sin conexión. Esto significa que la carga de proceso de SNMP es reducida, pero cuando se envía un mensaje nunca se puede asegurar que el mensaje llega a su destino. La seguridad de los datos no es prioritaria para SNMP. 33 • CMIP permite la implementación de comandos condicionales sofisticados, mientras que SNMP necesita el nombre de cada objeto. • CMIP permite, mediante una única petición, la recolección de gran cantidad de datos de los objetos gestionables, enviando información de retorno en múltiples respuestas. Esto no está permitido en SNMP. • CMIP está especialmente preparado para gestionar grandes redes distribuidas; mientras que SNMP está recomendado para la gestión inter-red. • CMIP realiza una distinción clara entre los objetos y sus atributos. En SNMP no está permitido esto, lo cual hace imposible la reutilización de atributos y definiciones. • SNMP es, por el contrario de CMIP, un Modelo de Gestión práctico y de rápida implementación y con la instalación de Sistemas de Administración de Red es posible crear funciones que permitan al operador de red hacer más sencilla la tarea sobre la red. Es por esta razón que este protocolo es el seleccionado como estándar universal entre los fabricantes de equipos de telecomunicaciones para su instalación en redes administradas. 2.3.3 DEFINICIÓN DE SISTEMA DE GESTIÓN DE REDES Se entiende por "Gestión de Redes y servicios de telecomunicaciones" ál conjunto de actividades destinadas a garantizar los servicios que prestan las redes. Actualmente los Sistemas de Comunicaciones prestan servicios a los usuarios utilizando Redes Privadas y Redes públicas. La interconexión entre las mismas proporciona mejores posibilidades en la provisión de servicios pero complica el control de las redes. El término /'gestión/; utilizado en muchos y diversos entornos del comportamiento humano, está relacionado con la planificación, el seguimiento, evaluación de costos, control de recursos y actividades. 34 Aplicando este término al entorno de redes, la gestión de red comprende la administración de los diferentes recursos que constituyen una red. La gestión de red toma la forma de seguimiento, coordinación y control de recursos informáticos y de comunicaciones. En la actualidad, y debido a la competencia de servicios, las organizaciones y empresas que no disponen de una buena gestión de sus redes y servicios de comunicaciones son cautivas de la tecnología y, en vez de emplear los recursos informáticos para hacer negocios, sus recursos informáticos pueden estar impidiendo el progreso de su negocio. Entre los problemas que se presentan en la interconexión de redes están: • Dispositivos diferentes: la interconexión de redes permitió la inserción de diferentes tipos de dispositivos fabricados por diferentes empresas lo que dificulta la integración de un sistema de gestión. • Administraciones diferentes: la interconexión entre redes de distinto propósito y distinto tamaño, se administran y gestionan de distinta forma. • Tecnologías de interconexión diferentes: existen redes interconectadas con diferentes topologías, utilizando diferentes tecnologías de transmisión y protocolos. Ante esta problemática tecnológica surgió la necesidad de implementar una metodología para la gestión de redes capaz de gestionar la configuración de sus componentes, la seguridad, las fallas y el desempeño. Distintos proveedores intentaron resolver algunos de estos problemas en forma puntual y aislada. Unificando las funcionalidades de estos esfuerzos surge el concepto "Network 35 Management System" (NMS) o Sistema de Gestión de Redes, que fue definido como: El elemento capaz de realizar el conjunto de actividades que controlan o vigilan el uso de los recursos y proporcionar la posibilidad de supervisar el estado, medir el rendimiento, reconocer actividades anormales en la red y notificar al operador para recuperar el servicio. Sistema de Administración de Red (NMS) SNMP Elemento 1 Elemento 2 Elemento 3 Elemento 4 Elementos de la Red Administrada Figura 1 O. Sistema de Administración de Red (NMS} El principal objetivo de la gestión de red es garantizar un nivel de servicio en los recursos gestionados con el mínimo costo. 2.3.4 NORMATIVAS PARA LA GESTION DE REDES El Comité Asesor de Internet (IAB) ha elaborado o adoptado varias normas para la administración de la red. En su mayoría, éstas se han diseñado específicamente para ajustarse a los requerimientos del TCP/IP, aunque, cuando es posible, cumplen con la arquitectura OSI. Un grupo de trabajo en Internet, responsable de las normas para la administración de la red, adoptó un enfoque de dos pasos para cubrir las necesidades actuales y futuras. El primer paso comprende el uso del Protocolo Simple para Administración de la Red (SNMP), el cual fue diseñado y aplicado por el grupo de trabajo. SNMP 36 se utiliza actualmente en muchas redes Internet, y está integrado dentro de muchos de los productos comerciales que están disponibles. Conforme se ha mejorado la tecnología, SNMP ha evolucionado y se ha vuelto más completo. El segundo paso comprende las normas OSI para administración de la red, llamados Servicios Comunes de Información sobre la Administración (Common Management Information Services, CMIS), y al Protocolo Común de Información sobre la Administración (Common Management Information Protocol, CMIP), los cuales se utilizarán en las futuras aplicaciones de TCP/IP. IAB ha publicado "Common Management Information Setvices and Protocol over TCP/IP (CMOT) como una norma para TCP/IP y para la administración OSI. Tanto SNMP como CMOT utilizan el concepto de los administradores de red que intercambian información con los procesos que se encuentran dentro de los dispositivos de la red, como las estaciones de trabajo, bridges, · routers, hubs, multiplexores, etc. La estación de administración primaria se comunica con los diferentes procesos de administración, construyendo la información sobre el estado de la red. La arquitectura tanto de SNMP como de CMOT es tal, que la información recopilada se almacena en un formato que permite a otros protocolos leerla. 2.4 PROTOCOLO SIMPLE DE ADMINISTRACIÓN DE REDES (SNMP) 2.4.1 ANTECEDENTES. SNMP realmente no fue el primer protocolo de administración definido para uso en Internet. En 1987, el SGMP fue definido por RFC (Request For Comment) para administrar la red en constante expansión de routers en Internet. Fue un 37 diseño provisional para pruebas hasta que se desarrollara un protocolo más elaborado. Un RFC es un documento que circula por Internet con especificaciones de un "estándar'' o parte de uno. Desde una introducción general, pedagógica y divertida sobre TCP/IP, hasta las particularidades del SNMP sobre redes IPX. Los RFC's contienen las verdaderas especificaciones de funcionamiento de Internet. En 1989 se comenzó a desarrollar el protocolo SNMP, teniendo la experiencia proporcionada por la corta vida de SGMP y de la necesidad de administrar otros dispositivos además de routers. Actualmente, la RFC 1157, escrita en 1990, es la actualización más reciente de SNMP versión l. Relacionado a los estándares SNMP están asociados los estándares /'Management lnfo1mation Base I y Ir; los cuales definen los contenidos del agente. Posteriormente aparecieron dos nuevos protocolos: por un lado, la segunda versión del SNMP, que incorpora muchas de las funciones del original (que sigue en uso) e incluye nuevas características que mejoran sus deficiencias. Por otro lado, el CMIP, que estaba mejor organizado y contenía muchas más funciones que las dos versiones del SNMP. Existen muchos protocolos disponibles. Los dos principales son SNMP y CMIP. Generalmente, SNMP trabaja bajo el modelo TCP/IP y CMIP trabaja bajo el modelo OSI. Típicamente los Sistemas de Administración de Red proveen funcionalidad a ciertas clases de dispositivos. Si se observa el modelo de referencia OSI se notará que la mayoría de los sistemas de administración de red (NMSs) operan hasta la capa 3 y algunas veces hasta la 4. Si se sigue este modelo, entonces la administración debería abarcar por lo menos los siguientes dispositivos: • Capa Física: Módems, DSU/CSU, multiplexores, HUBs, Repetidores o algún otro dispositivo que provea acceso ñsico a un medio de transmisión. 38 • Capa de Enlace de datos: Bridges, Switches, o algún otro dispositivo que defina la señalización de datos en un medio físico. • Capa de Red: Routers, Gateways, Switches /ayer 3, o algún otro dispositivo que tome decisiones acerca de dónde los datos irán basados en algún esquema de direccionamiento de red. • Capa 4. Transporte. (opcional) Incluye TCP y UDP, IPX/NCP, SPX o algún otro protocolo que provea conexión orientada a servicios de conexiones entre los nodos finales. SNMP implementado bajo TCP/IP o aún IPX/SPX, provee administración para muchos de estos dispositivos en forma general sin un software adicional. Nótese que las primeras tres capas especifican dispositivos de hardware, mientras que la capa 4 es expresada puramente en software. La información de la capa 4 puede proveer información útil para la administración de una red, como por ejemplo determinar si un servidor UNIX que está corriendo sobre TCP/IP, tiene conexión TCP con otros servidores y en qué puerto o cuantos broadcast UDP ha generado el servidor. Para el desarrollo de la administración de redes en Inter-redes basadas en TCP/IP, el IAB decidió seguir una estrategia en la cual a corto plazo se designó el SNMP para administrar los nodos, y se proponía para largo plazo la estructura de administración de redes OSI. Se escribieron entonces dos documentos para definir la administración de la información: RFC 1065 que norma la Estructura de la Información . de Administración, SMI; y RFC 1066, que norma la Base de Información de Administración, MIB. Ambos documentos fueron diseñados para ser compatibles con la estructura SNMP y la administración de redes OSI. Algunas de las especificaciones en el diseño de SNMP fueron: 39 a} Administración de red integrada: capacidad de administrar redes incorporando componentes que vinieran de una variedad de fabricantes con una simple aplicación. b} Interoperabilidad: capacidad de implementar un dispositivo de un proveedor, administrado por el sistema de un proveedor diferente. e} Estándares: definen métodos comunes de comunicación y estructuras de datos de manera que redes diferentes puedan ser integradas con una única administración de red. Posteriormente se obseivó que los requerimientos de SNMP y los de administración de redes basadas en el modelo OSI diferían más de lo esperado en un principio, por lo que los requerimientos de compatibilidad entre el SMI y el MIS y ambas estructuras fueron suspendidas. La IAB ha designado al SNMP, a la SMI y a la Internet MIB inicial como "Protocolos Estándar", con status de "Recomendado" (RFC). Por medio de esta acción, la IAB recomienda que todas las implementaciones de IP y TCP sean administradas por red, y que las implementaciones que son administrables por red se espera que los adopten e implementen. Así pues, la actual estructura para administración de redes basadas en TCP /IP consiste en: • Estructura e identificación de la Información de Administración para redes basadas en TCP/IP, que describe cómo se definen los objetos administrados contenidos en el MIB tal y como se especifican en la RFC 1155. 40 • Protocolo de Administración de Redes Simples, que define el protocolo usado para administrar estos objetos, según se expone en la RFC 1157. Recomendación Normalización RFC1065 Define la estructura de Información (SMI) RFC1066 Define el formato de las Bases de Información (MIB) RFC1155 Especifica el contenido de los MIBs RFC1157 Definición de SNMP Versión 1 Tabla 2. Recomendación para Gestión SNMP. 2.4.2 lQUE ES SNMP? El Protocolo Simple para Administración de la red (SNMP) no es sólo un protocolo, sino tres protocolos que juntos forman una familia; todos diseñados para trabajar en procedimientos de administración. Los protocolos que conforman la familia SNMP y sus papeles se muestran a continuación: • Base de Información de la administración (MIB): Una base de datos, generada por el agente de un elemento administrado, que contiene información del estado de los objetos que compone el elemento en estudio. • Estructura e identificación de la información sobre la administración (SMI): Una especificación que define las entradas en una MIB. • Protocolo simple para administración de la red (SNMP): El conjunto de normas que permiten la comunicación entre los dispositivos administrados y los servidores de administración. Los dispositivos que tienen integradas las capacidades para SNMP corren un módulo de software agente para administración, cargado como parte de un ciclo de arranque o incluído en la memoria fija (firmware) del dispositivo. A los dispositivos que poseen agentes SNMP se les denomina dispositivos administrados. 41 Los dispositivos administrados por SNMP se comunican con el software servidor SNMP que está localizado en un elemento de la red. El dispositivo se comunica con el servidor , al igual que el modelo de Gestión OSI, de dos formas: por sondeo o por interrupción. En el sondeo de un dispositivo (físico o lógico), el servidor de administración consulta al elemento administrado sobre su condición o sobre sus estadísticas actuales. El sondeo en ocasiones se hace en intervalos regulares, teniendo al servidor conectado a todos los dispositivos administrados de la red. Una desventaja del sondeo es que la información no siempre se encuentra actualizada y por otra parte, el tráfico de la red se incrementa con el número de dispositivos administrados y la frecuencia del sondeo. Un sistema SNMP basado en la interrupción hace que el dispositivo administrado envíe mensajes al servidor cuando algunas condiciones lo requieran. De esta forma, el servidor conoce inmediatamente cualquier problema (a menos que el dispositivo falle, en cuyo caso la notificación debe hacerse desde otro dispositivo que haya tratado de comunicarse con el dispositivo que falló). Los sistemas de administración basados en la interrupción tienen, al igual que los basados en sondeo, sus propias desventajas. En primer lugar entre los problemas está la necesidad de ensamblar un mensaje para el servidor, lo que puede requerir de una gran cantidad de ciclos del CPU, todos los cuales se toman de la rutina normal del dispositivo. Si' el mensaje que va a enviarse es extenso, como sucede cuando contiene una gran cantidad de estadísticas, la red puede padecer de una notable degradación mientras el mensaje se ensambla y transmite. Por otra parte, en un sistema de administración basado en interrupción, si existe una falla mayor en cualquier parte de la red, como cuando falla el suministro de energía eléctrica, cada dispositivo administrado por SNMP tratará de 42 enviar al mismo tiempo, mensajes controlados por interrupción hacia el servidor, para reportar el problema. Esto puede congestionar la red y producir una información errónea en el servidor. Frecuentemente se utiliza una combinación de sondeo y de interrupción para sobreponerse a todos estos problemas de los sistemas de administración. La combinación se llama sondeo dirigido por trampa (trap), e implica que el servidor haga un sondeo de las estadísticas a intervalos regulares o cada vez que lo ordene el administrador del sistema. Además, cada dispositivo administrado por SNMP puede generar un mensaje de interrupción cuando se presenten ciertas condiciones, pero estos mensajes tienden a estar más rigurosamente definidos que en el simple sistema controlado por interrupción. Después de recibir un mensaje de interrupción con sondeo dirigido por trampa, el servidor puede seguir sondeando al dispositivo para mayores detalles, en caso de ser necesario. Por lo general, SNMP se utiliza como una aplicación cliente/servidor asincrónica, lo que significa que tanto el dispositivo administrado como el software servidor SNMP pueden generar un mensaje para el otro y esperar una respuesta, en caso de que haya que esperar una. Ambos lo empaquetan y manejan el software para red ( como el IP) como lo haría cualquier otro paquete. SNMP utiliza UDP como un protocolo de transporte de mensajes. El puerto 161 de UDP se utiliza para todos los mensajes, excepto para las trampas, que llegan al puerto 162 de UDP. Los agentes reciben sus mensajes del administrador a través del puerto UDP 161 del agente. Puerto UDP Mensajes 161 Solicitud de información/confiquración 162 Mensaies asíncronos (Traps) Tabla 3. Puertos utilizados para las conexiones SNMP. 43 SNMP versión 2 añade algunas nuevas posibilidades a la versión anterior de SNMP, de las cuales, la más útil para los servidores es la operación get-bulk. Esta permite que se envíen un gran número de entradas MIS en un solo mensaje, en vez de requerir múltiples consultas get-next como lo hace SNMP versión l. Además, SNMP v2 tiene mayor seguridad que SNMP vl, evitando que los intrusos observen el estado o la condición de los dispositivos administrados. Tanto la encriptación como la autentificación están soportadas por SNMP v2. SNMP v2 es un protocolo más complejo y no se usa tan ampliamente como SNMP vl. EL SNMP reúne todas las operaciones en el paradigma obtener-almacenar (fetch store paradigm). Conceptualmente, el SNMP contiene sólo dos comandos que permiten a un administrador buscar y obtener un valor desde un elemento de datos o almacenar un valor en un elemento de datos. Todas las otras operaciones se definen como consecuencia de estas dos operaciones. La interacción entre un NMS y el dispositivo administrado se puede llevar a cabo a través de cuatro diferentes tipos de comandos: a) Lectura: para monitorear los dispositivos administrados, los Sistemas de Administración leen las variables contenidas dentro de los dispositivos. b) Escritura: para controlar los dispositivos administrados, los Sistemas de Administración escriben variables que son almacenadas dentro de los dispositivos administrados. e) Operaciones transversales: Los Sistemas de Administración utilizan esta operación para determinar cuales variables son soportadas por un dispositivo administrado y la secuencia para obtener estas variables de las tablas de información, por ejemplo las tablas de ruteo IP, en los dispositivos administrados. 44 ' . d) Trampas: los dispositivos administrados utilizan trampas (traps) para reportar asincrónicamente ciertos eventos a los Sistemas de Administración. La mayor ventaja de usar el paradigma obtener-almacenar es la estabilidad, simplicidad, flexibilidad. El SNMP es especialmente estable ya que sus definiciones se mantienen fijas aun, cuando nuevos elementos de datos se añaden al MIS y se definen nuevas operaciones como efectos del almacenamiento de esos elementos. A pesar de su extenso uso, SNMP tiene algunas desventajas. La más importante es que ese apoya en UDP. Puesto que UDP no tiene conexiones, no existe contabilidad inherente al enviar los mensajes entre el servidor y el agente. Otro problema es que SNMP proporciona un solo protocolo para mensajes, por lo que no pueden realizarse los mensajes de filtrado. Esto incrementa la carga del software receptor. Finalmente, SNMP casi siempre utiliza el sondeo en cierto grado, lo que ocupa una considerable cantidad de ancho de banda. 2.4.3 TECNOLOGIA SNMP Sorprendentemente, SNMP v2 no proporciona gestión de red. En lugar de eso SNMP v2 proporciona un marco de trabajo en el que se pueden construir aplicaciones de gestión de red. Estas aplicaciones, como la gestión de fallos, monitoreo del rendimiento, contabilización de tiempo, etc. están fuera del ámbito del estándar. Lo que proporciona SNMP v2 es la infraestructura de la gestión de la red. La esencia de SNMP v2 es un protocolo que se utiliza para intercambiar información de gestión. Cada elemento en un sistema de gestión de red mantiene una base de datos local de la información relevante de gestión de red, conocida como base de información de gestión (MIS). El estándar SNMP v2 define la 45 estructura de esta información y los tipos de datos permitidos; esta definición se conoce como estructura de información de gestión (SMI). El estándar también proporciona varias MIB que son generalmente útiles para la gestión de red. Además, los vendedores y los grupos de usuarios pueden definir nuevas bases de datos sobre información de administración (MIBs). SNMP v2 dará apoyo a una estrategia de gestión de red altamente centralizada o distribuida. En este último caso, algunos sistemas operan con ambas funciones, el de gestor y el de agente. En su papel de agente, un sistema aceptará órdenes de un sistema de gestión superior. Algunas · de estas órdenes están relacionadas con la MIB local en el agente. Otras órdenes requieren que el agente actúe como delegado para dispositivos remotos. En este caso, el agente delegado asume el papel de gestor para acceder a la información en un agente remoto, y después asume el papel de agente para pasar esa información a un gestor superior. : SNMP Red A Sistema Gestión Jerarquía mayor : SNMP i SNMP : ; ••••••••• •••••• j ••• ••••• •• •••• ••• ••••• •••• ••••••• • : •••• ••••••••••••• Red B Figura 11. Sistemas Jerárquicos de Administración. 46 2.4.4 OPERACIÓN DEL PROTOCOLO SNMP. 2.4.4.1 FUNCIONAMIENTO DEL PROTOCOLO. El funcionamiento del protocolo se puede entender a partir de dos instancias: los elementos de procedimiento y la estructura de una PDU1 • Elementos de procedimiento. A continuación se describen las acciones que realiza una entidad de protocolo en una implementación SNMP. Se definirá la dirección de transporte como una dirección IP seguida de un número de puerto UDP, asumiendo que se está utilizando el servicio de transporte UDP. a) Cuando una entidad de protocolo envía un mensaje, realiza las siguientes acciones: - Construye la PDU apropiada como un objeto definido con el lenguaje ASN.1 - Pasa la PDU, junto con un nombre de comunidad y las direcciones de transporte de fuente y destino, a un servicio de autenticación. Este servicio generará en respuesta otro objeto en ASN.1 - La entidad construye ahora un mensaje en ASN.1 usando el objeto que le ha devuelto el servicio de autenticación y el nombre de la comunidad. - Este nuevo objeto se envía a la entidad destino usando un servicio de transporte. b) Cuando una entidad de protocolo recibe un mensaje, realiza las siguientes acciones (esquematizado en la figura 12): 1 PDU es la unidad de datos de protocolo y constituye el formato de los mensajes enviados en la red para transferir información. 47 Verificación de comunidad y Direcciones IP Reconocimiento de PDU Envia Notificación de Error Procesamiento de PDU Inicio Fin de la rutina Agura 12. Diagrama de flujo para el proceso de recepción de una PDU - SNMP. 48 - Hace un pequeño análisis para ver si el datagrama recibido se corresponde con un mensaje en ASN.1. Si no lo reconoce, el datagrama es descartado y la entidad no realiza más acciones. - Observa el número de versión. Si no concuerda descarta el datagrama y no realiza más acciones. - Pasa los datos de usuario, el nombre de comunidad y las direcciones de transporte de fuente y destino al servicio de autenticación. Si es correcto, este devuelve un objeto ASN.1 Si no lo es, envía una indicación de fallo. Entonces la entidad de protocolo puede generar una trampa (trap), descarta el datagrama y no realiza más acciones. _ - La entidad intenta reconocer la PDU. Si no la reconoce, descarta el datagrama. Si la reconoce, según el nombre de comunidad adopta un perfil y procesa la PDU. Si la PDU exige respuesta, la entidad iniciará la respuesta ahora. Estructura de una PDU. Una PDU Genérica contiene los datos mostrados en la figura 13. PDU Type Request ID Error Error lndex Object1 Object2 Object N Status Value 1 Value 2 Value N ¡.······················-······ Variables -- ► Figura 13. Campos de una PDU -SNMP Genérica. - PDU type.: Número entero que indica el orden de emisión de los datagramas. Este parámetro sirve también para identificar datagramas duplicados en los servicios de datagramas poco fiables. - Request ID: Identificación de Requisición, asocia las demandas de SNMP con las peticiones. 49 - Error Status: Estado de Error, indica la presencia de errores y el tipo de errores. Solamente una operación de respuesta es posible en éste campo. Otras operaciones colocan éste campo en cero. Puede tomar los valores mostrados en la tabla 4. Valor de Error Tipo de Error Descripción (O) NoError No existe Error (1) TooBig Exedido el tamaño máximo (2) NoSuchName Nombre desconocido (3) BadValue Valor erróneo (4) ReadOnly Valor de Solo lectura (5) GenErr Error General Tabla 4. Tipos de Error en el campo de error de una PDU Genérica. - Error Index: Indice de Error. asocia un error con un objeto de instancia en particular. Solamente una operación de respuesta puede colocar éste campo. Otras operaciones colocan éste campo en cero. - VarBindlist {variables): Lista de nombre de variables con su valor asociado. Algunas PDU quedan definidas sólo con los nombres, pero aún así deben llevar valores asociados. Se recomienda para estos casos la definición de un valor nulo (NULL). Para la construcción de un datagrama de PDU, el protocolo SNMP se auxilia de cinco comandos básicos, que permiten extraer o colocar la información en los agentes administrados. Los comandos son: a) GetRequest-PDU y GetNextRequest-PDU (Mensaje de Solicitud y Mensaje de próxima solicitud, en los casos que se realizan múltiples requisiones) 50 b) SetRequest-PDU (Mensaje de solicitud de configuración de parámetros en el elemento administrado). c) GetResponse-PDU (Mensaje de solicitud de respuesta). A continuación se describe más detalladamente el significado de cada uno de los tipos de PDU. a) GetRequest-PDU y Get NextRequest-PDU. Son PDUs que solicitan a la entidad destino los valores de ciertas variables. En el caso de GetRequest-PDU estas variables son las que se encuentran en la lista VarBindlist; en el de GetNextRequest-PDU son aquellas cuyos nombres son sucesores lexicográficos de los nombres de las variables de la lista. Como se puede observar, GetNextRequest-PDU es útil para completar tablas de información sobre un MIS específico. Siempre tienen a cero los campos ErrorStatus y Errorlndex. Son generadas por una entidad de protocolo sólo cuando lo requiere su entidad de aplicación SNMP. Estas PDUs siempre esperan como respuesta una GetResponse-PDU. b) SetRequest-PDU. Ordena a la entidad destino poner a cada objeto reflejado en la lista VarBindlist el valor que tiene asignado en dicha lista. Es idéntica a GetRequest­ PDU, excepto por el identificador de PDU. Es generada por una entid~d de protocolo sól0 cuando lo requiere su entidad de aplicación SNMP. Espera siempre como respuesta una GetResponse-PDU. 51 e) GetResponse-PDU. Es una PDU generada por la entidad de protocolo sólo como respuesta a GetRequest-PDU, GetNextRequest-PDU o SetRequest-PDU. Contiene o bien la información requerida por la entidad destino o bien una indicación de error. Cuando una entidad de protocolo recibe uno de los comandos anteriores, sigue las siguientes reglas: - Si algún nombre de la lista ( o el sucesor lexicográfico de un nombre en el caso de Get NextRequest-PDU ) no coincide con el nombre de algún objeto en la lista del MIB al que se pueda realizar el tipo de operación requerido C'Set" o "Get''), la entidad envía al remitente del mensaje una Get Response-PDU idéntica a la recibida, pero con el campo ErrorStatus puesto a 2 (noSuchName), y con el campo Errorlndex indicando el nombre de objeto en la lista recibida que ha originado el error. - De la misma manera actúa si algún objeto de la lista recibida es un tipo agregado (como se define en el SMI), si la PDU recibida era una GetRequest-PDU. Si se ha recibido una SetRequest-PDU y el valor de alguna variable de la lista no es del tipo correcto o está fuera de rango, la entidad envía al remitente una GetResponse-PDU idéntica a la recibida, salvo en que el campo ErrorStatus tendrá el valor 3 (badValue) y el campo Errorlndex señalará el objeto de la lista que ha generado el error. 52 - Si el tamaño de la PDU recibida excede una determinada limitación, la entidad enviará al remitente una GetResponse-PDU idéntica a la recibida, pero con el campo ErrorStatus puesto a 1 (tooBig). - Si el valor de algún objeto de la lista no puede ser obtenido (o · alterado, según sea el caso) por una razón no contemplada en las reglas anteriores, la entidad envía al remitente una GetResponse-PDU idéntica a la recibida, pero con el campo ErrorStatus puesto a 5 (genErr) y el campo Errorlndex indicando el objeto de la lista que ha originado el error. Si no se llega a aplicar alguna de estas reglas, la entidad enviará al remitente una GetResponse- PDU de las siguientes características: - Si es una respuesta a una GetResponse-PDU, tendrá la lista VarBindlist · recibida, pero asignado a cada nombre de objeto el valor correspondiente. - Si es una respuesta a una GetNextResponse-PDU, tendrá una lista VarBindlist con todos los sucesores lexicográficos de los objetos de la lista recibida, que estén en la lista del MIB relevante y que sean susceptibles de ser objeto de la operación "Get", junto con cada nombre, aparecerá su correspondiente valor. - Si es una respuesta a una SetResponse-PDU, será idéntica a esta, pero antes la entidad asignará a cada variable mencionada en la lista VarBindlist su correspon~iente valor. Esta asignación se considera simultánea para todas las variables de la lista. En cualquiera de estos casos, el valor del campo ErrorStatus es O (noError), igual que el de Errolndex. El valor del campo RequestID es el mismo que el de la PDU recibida. 53 d) Trap-PDU. Es una PDU que indica una excepción o trampa. Es generada por una entidad de protocolo sólo a petición de una entidad de aplicación SNMP. Cuando una entidad de protocolo recibe una Trap-PDU, presenta sus contenidos a su entidad de aplicación SNMP. Los datos que incluye una Trap-PDU son los siguientes: - enterprise: Determina el tipo de objeto que ha generado la trampa. - agent-addr: Dirección del objeto que ha generado la trampa. - generic-trap: Número entero que indica el tipo de trampa. Puede tomar los valores mostrados en la tabla S. - specific-trap: entero con un código específico. - Time-stamp: tiempo desde la última indicación de la · entidad de red y la generación de la trampa. - Variable-bindings: lista tipo VarBindlist con información de posible interés. Valor de Error o 1 2 linkDown Conexión erdida 3 linkU Conexión establecida 4 authenticationFailure Fallo en la autenticación 5 6 Tabla 5. Tipos de Trampa Generados por una entidad de protocolo SNMP. A continuación se describen las trampas genéricas mostradas en la tabla S. 54 Trampa de arranque frío (COLDSTART) la entidad de protocolo remitente se está reinicializando de forma que la configuración del agente o la implementación de la entidad de protocolo puede ser alterada. Por ejemplo, un trap podría ser mandado por un router que recién ha sido configurado y requiere reiniciarse para que los cambios tengan efecto. Trampa de arranque caliente (WARMSTART) La entidad de protocolo remitente se está reinicializando de forma que ni la configuración del agente ni la implementación de la entidad de protocolo se altera. Trampa de conexión perdida {LINKDOWN) La entidad de protocolo remitente reconoce un fallo en uno de los enlaces de comunicación representados en la configuración del agente. Esta Trap-PDU contiene como primer elemento de la lista variable-bindings el nombre y valor de la interfaz afectada. Por ejemplo, una interfase en un router que se ha dañado o un archivo en un servidor con un NIC2 fallo. Trampa de conexión establecida {LINKUP) La entidad de protocolo remitente reconoce que uno de los enlaces de comunicación de la configuración del agente se ha establecido. El primer elemento de la lista variable-bindings es el nombre y el valor de la interfaz afectada. Trampa de fallo de autenticación {AUTHENTICATIONFAILURE) La entidad de protocolo remitente recibe un mensaje de protocolo que le indica que no ha sido autenticado. 55 Trampa de pérdida de vecino egp (EGPNEIGHBORLOSS) Un vecino EGP con el que la entidad de protocolo remitente estaba emparejado ha sido seleccionado y ya no tiene dicha relación. El primer elemento de la lista variable-bindings es el nombre y el valor de la dirección del vecino afectado. Trampa específica (ENTERPRISESPECIFIC) La entidad remitente reconoce que ha ocurrido algún evento específico. El campo specifictrap identifica qué trampa en particular se ha generado. El protocolo SNMP por sí sólo es un protocolo de consulta y respuesta. El NMS puede enviar múltiples consultas sin recibir ninguna respuesta, ya que no es un protocolo orientado a la conexión. Sin embargo la operación del protocolo SNMP se puede definir a partir de seis comandos básicos: • Get: permite al administrador (NMS) recibir un objeto de instancia de parte de un elemento administrado. • GetNext: permite al administrador recibir el próximo objeto de instancia de una tabla o de una lista contenida en un elemento administrado. • GetBulk: es un comando nuevo para la versión 2 de SNMP. La Operación GetBulk fue agregada para hacer más fácil la operación de adquirir grandes cantidades de información sin necesidad de realizar la operación GetNext. La operación GetBulk fue creada para eliminar virtualmente la necesidad de utilizar la operación GetNext. 2 NIC, Iniciales de Network Interface card (Tarjeta de Interface de Red). 56 • Set: permite al administrador NMS colocar un valor en el objeto de instancia con la ayuda de un agente. • Trap: usado por el agente en forma asincrónica para informar al NMS de algunos eventos ocurridos en el elemento administrado. • Inform: comando nuevo en SNMP v2. El comando de información fue creado para permitir al NMS enviar información de un trap a otro NMS. SEGURIDAD EN SNMP El protocolo SNMP v2 incluye dos protocolos de seguridad: uno para la autenticación y el otro para la privacidad. Estos dos protocolos son llamados: Dígest Authentícatíon Protoco/ y el Symmetríc Prívacy Protocol El Digest Authentication Protocol verifica que el mensaje recibido es el mismo que fue enviado. La integridad de los datos es protegida usando un mensaje parecido de 128 bits, el cual es calculado de acuerdo al algoritmo MDS (Message Digest 5). El mensaje es calculado al enviar lo y encapsularlo de acuerdo al SNMPv2. El receptor verifica el mensaje parecido ( digest). Un valor conocido solamente por el emisor y el receptor, es utilizado como prefijo del mensaje. Después de que el digest es usado para verificar la integridad del mensaje, el valor secreto es usado para verificar el mensaje de origen. Para garantizar la _privacidad del mensaje, se utiliza el Symetric Privacy Protocol (El protocolo de simetría de privacidad), el cual utiliza una llave de encriptación secreta que es conocida solamente por el emisor y el receptor. Después de que el mensaje es autenticado, éste protocolo utiliza el algorítmo Data Encryption Standard (DES), estándar de encriptación de datos, para efectuar la 57 privacidad. El protocolo DES está documentado por la ANSI (American National Standards Institute) y la NISf (National Institute of Standards and Technology). 2.4.4.2 ESTRUCTURA DEL PROTOCOLO. Los mensajes SNMPv2 constan de un encabezado y una PDU. La estructura básica se muestra en la figura 14. Encabezado PDU Figura 14. Estructura básica del mensaje SNMP Versión 2. • Encabezado del mensaje: el encabezado del mensaje en SNMPv2 consta de dos campos: Número de versión y Nombre de la comunidad. a) Número de versión: especifica la versión de SNMP que se está utilizando en el mensaje. b) Nombre de la comunidad: define un ambiente de acceso para un grupo de NMSs. Se dice que los NMSs dentro de una comunidad existen dentro del mismo dominio administrativo. Los nombres de comunidad sirven como una forma vaga de autenticación ya que los dispositivos que no saben el nombre adecuado de la comunidad son eliminados de las operaciones en SNMP. • PDU: SNMPv2 especifica dos formatos de PDU, dependiendo de la operación del protocolo SNMP, una es la PDU que hace referencia a los comandos Get, GetNext, Inform, Response, Set y Trap; y la otra PDU es la que hace referencia al comando GetBulk. 58 a) PDU para Get, GetNext, Inform, Response, Set y Trap. PDU Type Request ID Error Error lndex Object1 Object2 Object N Status Value 1 Value 2 Value N Variables ----► Agura 15. PDU utilizado en SNMP v2 para los comandos Get, GetNext, Inform, Response, Set y Trap. - Tipo de PDU: identifica el tipo de PDU transmitido (Get, GetNext, Inform, Response, Trap). - Solicitud de ID: asocia las solicitudes de SNMP con respuestas. - Status de error: indica uno de muchos errores y tipos de error. Solamente la operación respuesta activa este campo. Las demás operaciones fijan el valor de este campo en cero. - Indice de error: asocia un error con una instancia de objeto particular. Solamente la operación respuesta activa este campo. Las demás operaciones fijan el valor de este campo en cero. - Enlace de variables: sirven como el campo de datos del PDU en SNMPv2. Cada enlace de variable asocia una instancia de objeto particular con su valor actual (a excepción de las solicitudes Get y GetNext, para las que se ignora el valor). b) PDU para GetBulk. La PDU enviada en la operación GetBulk está formada por los siguientes campos: 59 Tipo de ID de sin Máximo Objeto 1 Objeto 2 Objeto N PDU solicitud repetidores re peticione Valor 1 Valor 2 Valor N Variables Figura 16. PDU utilizado para el comando GetBulk en SNMP v2. - Tipo de PDU: Identifica la PDU como una operación GetBulk. - Solicitud de ID: Asocia las solicitudes de SNMP con respuestas. - Sin repetidores: Especifica el número de instancias del objeto en el campo de enlaces que se deben acceder no más de una vez desde el comienzo de la solicitud. Este campo se utiliza cuando algunas de las instancias son objetos escalares con una sola variable. Máximo de repeticiones: Define la cantidad máxima de veces que se deben acceder otras variables, que no sean las especificadas en el campo sin repeticiones. - Variables: Sirve como el campo de datos de PDU en SNMPv2. Cada enlace de variables asocia una instancia de objeto particular con su valor actual ( a excepción de las solicitudes Get, GetNext, para las cuales se ignora el valor). 2.5 BASE DE INFORMACION PARA LA ADMINISTRACION (MIB). Es un método de descripción de objetos administrados especificando los nombres, tipos y el orden de los campos que hacen el objeto. Hay un solo árbol MIB definido por ISO. Sin embargo, parte de este árbol tiene secciones para propietarios específicos. Usualmente cada propietario tiene su propio MIB que contiene sus propios nombres de variables (por ejemplo, IBM, HP, etc). Los MIB's 60 de empresas son hechas por propietarios de sus objetos particulares. Hay muchas MIB's de empresas, por ejemplo: CISCO Systems, Cabletron, IBM, RAD, etc. Existen dos tipos de MIB, llamados MIB-1 y MIB-2. Las estructuras son · diferentes, MIB-1 se utilizó a principios de 1988 y tiene 114 entradas en la tabla, las cuales están divididas en grupos. Para que un dispositivo administrado pueda ser compatible con MIB-1, debe manejar grupos que son aplicables a ésta. Por ejemplo, una impresora admfnistrada no tiene que aplicar todas las entradas que traten con el Protocolo para Gateway Exterior (Exterior Gateway Protocol, EGP), el cual generalmente lo aplican solamente los routers y los dispositivos similares. MIB-2 es una ampliación a MIB-1 hecha en 1990, está formada por 171 entradas que están divididas en diez grupos. Las adiciones amplían algunas de las entradas de los grupos b