CAPÍTULO 1. INTRODUCCIÓN 7

Tamaño: px
Comenzar la demostración a partir de la página:

Download "CAPÍTULO 1. INTRODUCCIÓN 7"

Transcripción

1 ÍNDICE CAPÍTULO 1. INTRODUCCIÓN 7 CAPÍTULO 2. GESTIÓN DEL PROYECTO Descripción del proyecto Objetivos del proyecto Alcance del proyecto Planificación temporal Riesgos y planes de contingencia Método de trabajo Gestión real del proyecto 14 CAPÍTULO 3. DESCRIPCION DEL PROTOCOLO SNMP Introducción Evolución histórica del protocolo SNMP Arquitectura de un sistema de gestión de red Entidad gestora Dispositivos a gestionar Protocolo de gestión Modelo de información Estructura de la información de administración MIB Operaciones de SNMP La seguridad en SNMP Conclusiones 31 CAPÍTULO 4. DESARROLLO TEÓRICO Introducción (finalidad del proyecto) Captura de requerimientos hardware Captura de requerimientos software El Sistema Operativo Los agentes Análisis de herramientas de monitorización de datos Servidor http Análisis de herramientas para la comunicación de redes IP y GSM Conclusiones 38 CAPÍTULO 5. DESARROLLO PRÁCTICO Instalación, configuración y pruebas de los agentes Linux Debian (Net-SNMP) Otros agentes SNMP para Linux Windows 2000, Windows 2003 Server Instalación y configuración de MRTG Instalación y configuración del servidor HTTP, Apache Instalación y configuración de Gnokii Conclusiones 69 CAPÍTULO 6. CONCLUSIONES 71 1

2 CAPÍTULO 7. BIBLIOGRAFÍA 73 ÍNDICE DE FIGURAS Figura 1. Diagrama EDT Figura 2. Diagrama de Gantt inicial Figura 3. Tareas y diagrama de Gantt real Figura 4. Ubicación del protocolo SNMP en el modelo OSI Figura 5. Componentes principales de una arquitectura de gestión de red Figura 6. Árbol de objetos MIB Figura 7. Implementación parcial del módulo system Figura 8. Formato de las PDUs en SNMPv2 Figura 9. Operaciones SNMP Figura 10. Instalación del paquete snmp a través del comando apt-get Figura 11. Definición de los nombres de comunidad y grupos asignados Figura 12. Relación entre modelos de seguridad y grupos Figura 13. Definición de vistas y tipo de acceso Figura 14. Proceso snmp escuchando en el puerto 161 a través del protocolo UDP Figura 15. Salida del comando snmpget Figura 16. Salida del comando snmpget con múltiples variables Figura 17. Salida del comando snmpgetnext Figura 18. Salida del comando snmpwalk Figura 19. Utilización del comando snmpset Figura 20. Salida del comando snmpstatus Figura 21. Salida del comando snmptranslate Figura 22. Salida del comando snmpnetstat Figura 23. Panel de instalación del agente SNMP en Windows Figura 24. Estado del servicio SNMP Figura 25. Panel de propiedades del servicio SNMP Figura 26. Detalles de las opciones del menú Servicio Figura 27. Panel de configuración de Seguridad del servicio SNMP Figura 28. Instalación de los módulos necesarios para MRTG Figura 29. Opciones globales para el archivo mrtgcpu.cfg Figura 30. Implementación parcial del archivo de configuración mrtg.cfg Figura 31. Implementación parcial del archivo mrtgdiscos.cfg Figura 32. Implementación del script snmp_hdfree Figura 33. Implementación parcial del archivo mrtgfreemem.cfg Figura 34. Implementación del script snmp_windowsmemfree Figura 35. Implementación parcial del archivo mrtgnumprocses.cfg Figura 36. Implementación parcial del archivo mrtgonoff.cfg Figura 37. Implementación del script para comprobar el estado, on/off, de un dispositivo Figura 38. Utilización del comando cfgmaker Figura 39. Implementación parcial del archivo mrtgredservers.cfg creado mediante el comando cfgmaker Figura 40. Implementación parcial del archivo mrtgroutercisco.cfg creado mediante el comando cfgmaker Figura 41. Implementación del script galarma Figura 42. Implementación del script galarmaok Figura 43. Compilación de los archivos de configuración 2

3 Figura 44. Tareas a realizar de manera periódica Figura 45. Utilización del comando indexmaker Figura 46. Menú principal de acceso a las gráficas Figura 47. Vista global de las gráficas Figura 48. Vista detallada de las gráficas Figura 49. Instalación del módulo apache2 Figura 50. Configuración de apache2, permisos de acceso por IP Figura 51. Utilización del comando htpasswd2 Figura 52. Configuración de apache2, autorizaciones Figura 53. Menú de acceso a las gráficas Figura 54. Conexión del cable de datos al teléfono móvil Figura 55. Instalación del modulo gnokii Figura 56. Configuración de gnokii, modelo de móvil y conexión Figura 57. Configuración de gnokii, tiempo de espera Figura 58. Comprobación de la instalación de gnokii mediante el comando gnokii monitor Figura 59. Enviar sms a través de gnokii Figura 60. Script galarma Figura 61. Script galarmaok Figura 62. Recepción de una alerta 3

4 CAPÍTULO 1. INTRODUCCIÓN Aquí comienza el desarrollo de este Proyecto Fin de Carrera (de aquí en adelante PFC), titulado Implantación de un sistema de gestión de dispositivos de red, basado en el protocolo SNMP, el cual se encuentra enmarcado dentro del amplio mundo de las redes informáticas. El centro de formación Cebanc-Cdea, situado en San Sebastián, cuenta con su propia red informática formada por una gran cantidad de dispositivos informáticos diferentes. A los administradores informáticos de esta empresa, les resultaba algo incómodo y tedioso el hecho de tener que comprobar el funcionamiento de estos dispositivos además de sentir una cierta frustración cuando uno o varios de ellos fallaban sin conocer el motivo. De esta manera les surgió la idea de implantar en su red un sistema de gestión o control, de tal forma que fuera el propio sistema el que les avisara de los fallos en la red y evitarse así el tener que realizar ellos mismos periódicamente controles. Mi gran pasión por las redes informáticas y el hecho de realizar prácticas en esta empresa durante el verano del año 2002, provocaron el comienzo del desarrollo de este proyecto. Para mí, consistía un gran reto y una ampliación en mis conocimientos informáticos, ya que desconocía casi por completo el mundo de las gestiones de las redes informáticas. El presente documento tratará de explicar todos los pasos que se han llevado a cabo en la realización de este proyecto. Inicialmente se desarrollará el Documento de Objetivos del Proyecto (DOP), que reúne los objetivos a completar, los cuales obviamente han sido solicitados por la empresa Cebanc-Cdea, así como una serie de puntos sobre la gestión del propio proyecto. Posteriormente se pasa al aspecto más laborioso e importante de todo este documento donde se realiza el estudio y aprendizaje del protocolo de gestión de red utilizado, que servirá de base para el posterior desarrollo práctico. Para concluir se comentarán una serie de conclusiones personales obtenidas tras la finalización del proyecto. Por último, me gustaría comentar, que este documento no pretende ser un manual global para implantar un sistema de gestión en una red informática, ya que existen múltiples maneras de gestionar una red, las cuales varían en función de los requerimientos y necesidades de las propias redes. No se intenta que el sistema de gestión que se desarrollará a continuación, sea mejor o peor que otros, sino que sea el óptimo para la red en la que se va a implantar. 4

5 CAPÍTULO 2. GESTIÓN DEL PROYECTO En este capítulo se abordará todo lo relativo a la gestión de este PFC. Se explicará de una forma resumida en qué consiste el proyecto y cuáles son los objetivos que se pretenden conseguir. Seguidamente se desarrollará el alcance, la planificación temporal, una lista de riesgos junto con su plan de contingencia así como la metodología a seguir para la buena realización de este PFC. Finalmente se realizará un apartado sobre la gestión real del proyecto, en el que se incluirán todas aquellas modificaciones surgidas durante el desarrollo del PFC y que servirá para realizar un balance entre la gestión planificada al comienzo y la real. 2.1 Descripción del proyecto Hoy en día una red está formada por una gran cantidad de elementos complejos, tanto de tipo hardware como software y que interactúan; desde enlaces, routers, servidores y otros dispositivos que componen la parte física de la red, hasta los diferentes protocolos que coordinan y controlan estos dispositivos. Cuando una organización reúne cientos o miles de estos componentes para formar una red, es normal que algunos no funcionen bien ocasionalmente, que los elementos de la red se desconfiguren, que los recursos de la red sean sobreexplotados, o que los componentes de la red sencillamente se rompan. El administrador de red, cuyo trabajo es mantener la red con un funcionamiento óptimo, debe ser capaz de responder ante estos percances o incluso si se puede, evitarlos. Este PFC consistirá en realizar la implantación de herramientas hardware y software que facilitarán el control de la red al administrador. Como es obvio pensar, se necesitará una red lo suficientemente amplia como para poder llevar a cabo el proyecto; para ello, este proyecto se desarrollará en el centro de formación Cebanc-Cdea, el cual cuenta con una red de aproximadamente 300 máquinas y unos 15 servidores, además de diferentes dispositivos para su conexión. La aplicación final será capaz de monitorizar la información de los diferentes componentes de la red por medio de gráficas que facilitarán la comprensión del funcionamiento de la red al administrador. 2.2 Objetivos del proyecto A continuación se detallarán los objetivos que se pretenden conseguir con la realización de este proyecto: 1. Aprendizaje del protocolo SNMP, Simple Network Management Protocol, para su uso posterior. SNMP es un protocolo de gestión de red, que nos va a permitir obtener datos concretos de los dispositivos que participan en la red (como por ejemplo, la tasa de CPU que se está utilizando en un servidor o el consumo de tráfico en las entradas/salidas de una interfaz de red). Se analizará su funcionamiento y la evolución desde su aparición. 5

6 2. Implantación de un sistema de control de red, que contará con las siguientes funcionalidades: Capacidad para monitorizar los resultados obtenidos por medio del protocolo SNMP. Este sistema presentará los resultados deseados por medio de unas gráficas. Almacenamiento de datos históricos para poder comparar la información obtenida en tiempo real con la información ya almacenada y así poder realizar un mejor análisis de los datos obtenidos. Y por último, disponibilidad para el envío de una alerta, a través de correo , a un teléfono móvil. Este enviará un mensaje (vía SMS), con el contenido del texto del , a otro teléfono móvil que estará en posesión del administrador. La alerta sólo se enviará en caso de anomalías críticas en la red (por ejemplo, en el bloqueo de un servidor). También aparecen como objetivos indirectos un estudio básico de la red instalada en la empresa y del diferente software a utilizar para la realización de la aplicación. 2.3 Alcance del proyecto En este punto se tratarán las tareas que implican este proyecto, y que las podemos dividir en tres grandes grupos: En el primero quedan englobadas todas aquellas que se basan en la recopilación de información (mediante la búsqueda por diferentes fuentes y a través de reuniones con el cliente). El segundo sirve de nexo entre el primero y el tercero. Aquí queda encuadrada la tarea de análisis de la información obtenida en las tareas anteriores, y que servirá para la realización de las tareas posteriores. Y en el tercero se encuentran todas las que implican el desarrollo del sistema (implantación y pruebas). Cada una de las tareas puede subdividirse en otras más pequeñas como se muestra en el siguiente diagrama EDT: 6

7 PFC Gestión Entregables de cada fase Búsqueda documentació n Consulta en libros Captura de requisitos Consultas con el cliente Análisis de requisitos Desarrollo Implantación Memoria final Consulta en Internet Estudio de la red Pruebas Consulta en manuales Consulta en otras fuentes (fig. 1, diagrama EDT) 2.4 Planificación temporal Este apartado servirá para realizar una estimación del tiempo que se empleará en la realización del proyecto y sus diferentes tareas. Inicialmente se prevé que la mayor parte del tiempo se dedique en la parte media y final del proyecto (en el análisis de la información e implantación de la aplicación). El tiempo dedicado a la recopilación de la información dependerá de la calidad de esta. Esto es importante, ya que sin un buen material de partida es altamente probable que surjan problemas en las fases posteriores y que pueden llevar a reanalizar muchos conceptos que implicarán un aumento del tiempo en la realización del PFC. Hay que tener en cuenta que durante el primer cuatrimestre me encontraré cursando asignaturas, de las que deberé examinarme a finales de enero y primeros de febrero. A partir de febrero, si no ocurre nada imprevisto, el tiempo que podré dedicar al proyecto será completo. De esta forma la planificación temporal del proyecto en un principio queda dividida de la siguiente manera: Hasta finales del mes de diciembre se realizarán las tareas de búsqueda de información y captura de requerimientos Tras la realización de los exámenes, a mediados de febrero, se continuará con el análisis, la implantación y las pruebas Se espera finalizar el proyecto a primeros de mayo para realizar su posterior presentación en la convocatoria de junio. Para ver una representación gráfica de la planificación expuesta se presenta a continuación su correspondiente diagrama de Gantt: 7

8 2.5 Riesgos y planes de contingencia Al igual que en cualquier otro proyecto, este también cuenta con una serie de riesgos que de no detectarse a tiempo podrían afectar a su desarrollo. Se analizarán y se presentarán soluciones para poder evitarlos: Mala documentación. Es un riesgo importante a tener en cuenta ya que la información obtenida durante las primeras fases va a servir de base para el posterior desarrollo del proyecto. Una mala documentación podría llevar a su fracaso. También hay que tener en cuenta la alta probabilidad que existe de que mucha de la documentación necesaria se encuentre en inglés, idioma en el que el alumno no tiene un nivel muy alto. o Solución: contrastar, con diferentes documentos, la información obtenida. Referente al idioma, el alumno espera no tener excesivos problemas, pero si se da el caso habrá que realizar uso de herramientas traductoras (traductores de páginas Web o sencillamente un diccionario). Falta de recursos humanos. Al ser este un PFC que se va a desarrollar en una empresa y por lo tanto va a contar con usuarios reales, el buen desarrollo del proyecto va a depender también del nivel de colaboración de los clientes, sobre todo en la fase de captura de requerimientos donde se pueden dar malentendidos de lo que se quiera realizar. o Solución: mantener una comunicación regular, mediante reuniones personales o vía , con las dos partes implicadas en este proyecto (el tutor del mismo, D. José Antonio Lozano Alonso y el cliente, la empresa Cebanc-Cdea). Inicialmente no se cree que vaya a faltar colaboración por parte del cliente. Si esto no fuese así, los tiempos planificados para realizar las diferentes tareas del proyecto se podrían alargar, con lo cual habría que realizar una replanificación temporal del PFC. Falta de experiencia: es otro gran riesgo ya que es el primer proyecto, con una envergadura aceptable, al que el alumno se enfrenta solo. Esto puede provocar el retraso en el desarrollo del PFC o haciendo que los objetivos planteados en un principio deban ser menos ambiciosos. o Solución: durante las primeras fases, documentarse lo máximo posible y a través de diferentes medios (libros, Internet o personas con conocimientos sobre el tema). Pérdida de la información: aunque hoy en día los problemas de seguridad y fiabilidad en los sistemas a nivel usuario no son excesivamente preocupantes, hay que tenerlos en cuenta. La pérdida parcial de la información podría provocar retrasos en las tareas, y la pérdida total el fracaso seguro. o Solución: tener una política de backups (copias de seguridad). El alumno realizará copias de la información en dispositivos como CD-RW (CD s regrabables) o en DVD-RW si fuese necesario (tienen mayor capacidad que los CD s). Las copias se realizarán cuando el alumno lo estime oportuno (probablemente cada vez que se realice un importante avance en el desarrollo del proyecto). 8

9 Estos son los mayores problemas que se pueden detectar al comienzo de la realización de este PFC. Seguramente, durante su transcurso aparecerán muchos más. Todos ellos se recogerán en el apartado Gestión real del proyecto. 2.6 Método de trabajo Para el buen desarrollo de este proyecto se intentará mantener un ritmo adecuado en la realización del mismo. Tal y como se ha adelantado en el punto de la planificación temporal, el alumno se encuentra cursando asignaturas del último año de carrera. Hasta febrero se le dará mayor prioridad a las asignaturas, pero sin dejar de lado el desarrollo del PFC. A partir de la finalización de los exámenes del primer cuatrimestre, y contando con que el alumno tendrá mas tiempo libre, se llevarán a cabo las tareas que a priori se cree que serán más laboriosas. Al final de cada una de las fases en las que se divide el proyecto, se pretende generar un informe con lo que se ha realizado en dicha fase y que se entregará tanto al director del proyecto como al cliente. De esta manera se pretende conseguir un mayor control y seguimiento del proyecto de las tres partes implicadas (alumno, cliente y director). También será importante mantener una buena comunicación. Puesto que el cliente ha ofrecido sus instalaciones al alumno para realizar el proyecto, la comunicación alumno-cliente será prácticamente diaria. Con respecto al profesor, además de mantenerle informado del desarrollo del proyecto por medio de los informes de cada fase, si alguna de las dos partes cree conveniente realizar alguna reunión se comunicarán vía para llevarla a cabo. 2.7 Gestión real del proyecto Este último apartado de este capítulo, al contrario que los demás, se realiza una vez finalizado el proyecto, y se utiliza para realizar un balance de la gestión propuesta inicialmente para el desarrollo del mismo. Comparando el diagrama de Gantt presentado al inicio de este proyecto, con el real, lo primero que destaca es el tiempo empleado. En un principio se había estimado la finalización hacia el mes de mayo, cumpliéndose ésta realmente en el mes de octubre. Se explicarán los motivos de este aumento de tiempo: 1. Debido a que los conocimientos del alumno sobre sistemas de gestión de red eran muy escasos, se tuvo que hacer una replanificación temporal de la fase de captación de requerimientos, ampliando el tiempo de esta, para poder asimilar mejor los conceptos que iban surgiendo, y de esta manera evitar acarrear problemas en las fases posteriores. 2. También se apuntó anteriormente, que durante los meses de enero y febrero el alumno se encontraría realizando exámenes. Debido a una imprevista nevada, algunos de estos exámenes se suspendieron hasta fechas posteriores, lo cual también incidió en la duración de la fase de captación de requerimientos. 9

10 3. Aunque se preveía que durante el segundo cuatrimestre el alumno no tuviera asignaturas que cursar, debió de realizar un examen en el mes de junio, lo que provocó una parada temporal en el desarrollo del proyecto. 4. Por último y provocado por una incompatibilidad en el calendario con el tutor del proyecto, la corrección del presente documento también se vió demorada durante un par de semanas en el mes de agosto. Continuando con el análisis del diagrama de Gantt real, se observa que algunas tareas se han eliminado, las correspondientes a las entregas de los informes de cada fase. Esto se debió a que, el tutor del proyecto no está dedicado a la materia sobre la que se basa el proyecto (redes informáticas) y por lo tanto poco podía ayudar en la parte técnica. En cuanto al responsable del proyecto en la empresa Cebanc-Cdea, al no contar éste con suficiente tiempo como para revisar estos informes, el alumno le fue informando, prácticamente a diario y de una manera coloquial, de los avances que se iban realizando y de las dudas que iban surgiendo. Para finalizar, también se observa que muchas de las fases se han solapado. No era algo previsto al inicio de este proyecto, debido a que el alumno en aquel momento desconocía cuál iba a ser el desarrollo del mismo. A medida que se iba avanzando, y como se observará en los capítulos posteriores, era necesario el realizar las tareas de esta manera. 10

11 CAPÍTULO 3. DESCRIPCIÓN DEL PROTOCOLO SNMP La realización de este proyecto se basa en el uso del protocolo SNMP (Simple Network Management Protocol). Por ello, en este capítulo se tratará de explicar su funcionamiento, sus componentes, su arquitectura, así como su evolución en sus diferentes versiones desde su nacimiento en la década de los Introducción A finales de los años 70 las redes de ordenadores experimentaron un espectacular crecimiento y comenzaron a conectarse entre sí. Pasaron de ser pequeñas redes a convertirse en grandes infraestructuras globales, lo que conllevó también al crecimiento en número de los componentes hardware y software. Debido a esto, cada vez se hacía más difícil el control y la gestión de dichos componentes por lo que tuvo que ser necesario el desarrollo de un sistema para poder mantener la gestión en la red. Antes de que surgiera la necesidad de gestionar las redes, ya habían aparecido una serie de problemas a la hora de interconectarlas; estos mismos problemas se dieron también en el momento en el que se comenzaron a gestionar y como veremos la política que se utilizó para solucionarlos fue similar: Dispositivos diferentes: la interconexión de redes permite conectar diferentes dispositivos de distintas marcas comerciales que soportan el protocolo de transmisión de datos TCP/IP(Transmisión Control Protocol/Internet Protocol). A la hora de administrar una red esto se presenta como un problema. El uso de una tecnología de interconexión abierta fue la que dio solución a este problema, por lo que para administrar estas redes se hizo necesario también utilizar una tecnología de administración de redes abierta. Administraciones diferentes: hay que tener en cuenta que como se permite la interconexión de redes de diferente propósito, éstas también se encontrarán administradas y gestionadas de diferente forma. 3.2 Evolución histórica del protocolo SNMP Tal y como se ha comentado en puntos anteriores, el gran aumento de las redes y sus componentes hizo necesario la creación de un sistema de comunicación que pudiera administrarlas y gestionarlas. Este sistema de comunicación se implementó en forma de protocolo tal y como se explica a continuación. A mediados de los años 80 aparecen los primeros protocolos de gestión, SGMP (Simple Gateway Monitoring Protocol). Este protocolo definía una plataforma que servía para monitorizar el rendimiento de los dispositivos que unían las redes que se encontraban aisladas. Fue diseñado por un grupo de investigadores universitarios de redes, usuarios y gestores, que gracias a su experiencia y a la imperiosa necesidad que había por crear un sistema de administración de redes, pudieron diseñar e implementar el protocolo SNMP en unos pocos meses. En un principio el protocolo SNMP fue creado como una solución temporal hasta que llegaran protocolos de gestión de red con mejores diseños y más completos. Su primera versión, SNMPv1 (propuesto 11

12 originalmente en el Request For Comment, RFC, 1157) [1], contaba con un manejo muy simple que se basaba en el intercambio de información de red a través de mensajes o PDU s (Protocol Data Unit). Era un protocolo que se podía extender fácilmente por toda la red. Pero no todo era perfecto, ya que no estaba pensado para poder gestionar las numerosas e innovadoras redes que cada día iban apareciendo. Además contaba con importantes deficiencias en materia de seguridad. Paralelamente a la creación de SNMP, surgió otro protocolo de gestión, CMIP (Common Managment Information Protocol) del modelo ISO/OSI (Open System Interconnection), encargado del desarrollo de estándares en materias de comunicaciones de datos. CMIP, se encontraba mucho mejor organizado, contaba con muchas más funciones y subsanaba muchas de las deficiencias de SNMP. El precio de todo esto es que se convirtió en un sistema tan grande y complejo, que consumía muchos recursos en la red y tan solo las mejores equipadas podían soportarlo. De esta manera SNMP encontró una mejor aceptación entre los usuarios y se convirtió en la opción más factible para la gestión de redes. Tras quedarse SNMP al frente de los protocolos de gestión de red, se hacía necesario subsanar todas aquellas carencias que habían surgido en su primera versión. Por este motivo, a principios de los años 90 se empieza a trabajar en una nueva versión del protocolo, SNMPv2 (RFCs ) [1]. Las mayores innovaciones sobre las que se trabajaron en esta versión son: Mecanismos de seguridad, los cuales no existían en la primera versión. Se basaron en tres grandes conceptos dentro del mundo de la seguridad: privacidad de los datos, autenticación de los usuarios y control en el acceso. Estructuras de datos, que permitían un mejor manejo de éstos. Se abría la posibilidad de gestionar un número de datos y objetos mayor, de tal manera que el problema de gestionar grandes redes se iba solucionando. Desafortunadamente muchas de estas innovaciones no se llegaron a implementar y se quedaron en pura teoría, como fue el caso de las referentes a la seguridad, provocando que esta versión sirviera como parche o extensión de la versión anterior. Con la evolución del mundo de Internet estas versiones dejaban al descubierto las grandes deficiencias que surgían en torno a la seguridad. Por esta razón a finales de los 90, los grupos de expertos se reunieron para crear un nuevo conjunto de RFC s ( , ) [1], conocidos como SNMPv3, que se orientaban a solucionar estas deficiencias. Las principales ventajas que aparecieron en esta versión sobre sus predecesoras fueron las siguientes: Se implantan definitivamente los mecanismos de seguridad (privacidad, autenticación y autorización). El uso de LOO (Lenguajes Orientados a Objetos) como Java o C++ que ayudaron en la construcción de elementos propios del protocolo (objetos al fin y al cabo) y que sirvieron también para dar una mayor consistencia al protocolo lo cual equivalía a una mayor seguridad de éste. [1] Consultar referencia en la Bibliografía [ [ 12

13 Hoy en día, SNMP está considerado como el gran estándar dentro de los protocolos de gestión de red, algo que no ha pasado inadvertido para los fabricantes de dispositivos de red que diseñan la gran mayoría de sus productos para soportar este protocolo. 3.3 Arquitectura de un sistema de gestión de red Dentro de la arquitectura de red del modelo OSI, el protocolo SNMP se sitúa en el tope del nivel de transporte, como se observa en la figura 4, por encima de la capa de protocolos de transporte como por ejemplo UDP (User Datagram Protocol). Aplicación SNMP Transporte IP Acceso a red Físico (fig. 4, ubicación del protocolo SNMP en el modelo OSI) En la propia arquitectura de gestión de red, existen tres componentes básicos que se pasarán a analizar seguidamente: La entidad gestora Los dispositivos a gestionar El protocolo de gestión de red Entidad gestora La entidad gestora es una aplicación que se ejecuta en una máquina que se encuentra en el centro de operaciones de red. Es desde esta máquina donde se va a controlar la gestión de la red: recolección, procesamiento y visualización de la información a gestionar. Desde aquí el administrador de red tendrá la capacidad de interactuar con los dispositivos que quiera controlar Dispositivos a gestionar Los dispositivos a gestionar, son todos aquellos dispositivos que tienen algún tipo de capacidad de trabajo en red; puede ser un servidor, un router, un módem, una impresora, un hub, switches, etc. Cada dispositivo contará con diferentes objetos a gestionar (managed objects), que son el hardware de los dispositivos que se gestionan (por ejemplo, en un servidor su tarjeta de red) y sus parámetros de configuración (bytes emitidos y recibidos en un router, por ejemplo). En estos objetos se encuentra la información que el administrador de red puede controlar desde la entidad gestora. Esta información se almacena en una base 13

14 de datos de información de gestión (MIB; Manager Information Base), que se analizará más adelante. Por último, en cada dispositivo existe un agente de gestión de red (de aquí en adelante agente), que es el proceso encargado de comunicarse con la entidad gestora proporcionando la información que ésta solicite. En la siguiente figura, se puede visualizar la arquitectura descrita. Entidad Gestora Agente SNMP MIB MIB SNMP Dispositivo a gestionar SNMP SNMP Dispositivo a gestionar Agente MIB Dispositivo a gestionar MIB Agente Agente Dispositivo a gestionar MIB (fig. 5, componentes principales de una arquitectura de gestión de red) Protocolo de gestión Un buen sistema de gestión, será aquel que sea capaz de reconocer la gran diversidad de dispositivos a administrar que pueden aparecer en una red, ofreciendo un entorno de administración adecuado. Teniendo en cuenta esto, una de las características más importantes que se ha de cumplir a la hora de implantar un sistema de gestión en una red es que el impacto, en términos de rendimiento, que se produzca en los dispositivos gestionados sea mínimo. Para poder llevar a cabo la comunicación entre los agentes de cada dispositivo y la entidad gestora va a ser necesario tener un protocolo, en este caso un protocolo de gestión (SNMP, CMIP, etc). A través del protocolo, la entidad gestora podrá realizar consultas sobre el estado de los dispositivos o indicar a los agentes de cada dispositivo las acciones que deben de llevar a cabo. De la misma manera, los agentes podrán utilizar el protocolo para informar a la entidad de cualquier anomalía que pudiera suceder en un dispositivo (por ejemplo la caída de un servidor). Dentro del protocolo de gestión, va a ser importante la elección de un servicio de transporte adecuado, ya que el rendimiento del protocolo va a depender directamente de este servicio. Tal y como se ha comentado en el apartado anterior, la implantación de un sistema de control de red debe causar el menor impacto 14

15 posible en la propia red, característica que deberá de cumplir el servicio de transporte. Hay que tener en cuenta que en el momento en el que se den fallos en la red, la administración de ésta ha de seguir funcionando (será en ese instante cuando más se necesite tener la red controlada y administrada), por lo que el servicio de transporte seleccionado deberá de ser fiable para que no se provoque una pérdida de la información. Los servicios de transporte los podemos clasificar en dos categorías: orientados y no orientados a conexión. Los orientados a conexión (por ejemplo TCP), son mas fiables, permiten la retransmisión de la información pero hacen un mayor uso de los recursos de la red; por ejemplo: si en un momento dado la red se encuentra congestionada y es difícil establecer una conexión, con un servicio de transporte orientado a conexión necesitaríamos tres pasos para establecer dicha conexión, mientras que con un servicio no orientado a conexión solo nos haría falta un paso. Si la red está perdiendo paquetes, será más sencillo establecer la conexión de ésta última forma. Por todo esto, lo que se recomienda en los protocolos de gestión es el uso de un servicio de transporte no orientado a conexión. De hecho, para SNMP en el RFC 1906, se establece que UDP es el servicio de transporte más adecuado (lo cual no implica que no se pueda utilizar TCP). 3.5 Modelo de información En este apartado se va a tratar la estructuración de la información en un entorno de gestión de red, así como la forma de comunicación de los datos Estructura de la información de administración La estructura de la información de administración (Structure of Management Information, SMI) define las reglas para definir la información de administración; es el lenguaje que se utiliza para definir la información de gestión que reside en una entidad de red (en nuestro caso, los dispositivos a gestionar). Con este lenguaje nos aseguramos que la sintaxis y semántica de los datos de gestión de red se encuentren bien definidos y no sean ambiguos. En el apartado se ha comentado que cada dispositivo a gestionar cuenta con una serie de objetos que contienen información sobre el dispositivo, y que dicha información se almacena en una base de datos denominada MIB. SMI, se encarga de definir el esquema de esa base de datos. SMI está basado en el lenguaje de definición de objetos Abstract Syntax Notation One (ASN.1), pero ya cuenta con los suficientes tipos de datos específicos como para que se le considere un lenguaje de definición de datos. Además también proporciona construcciones de lenguaje de alto nivel, entre las que destacan estas dos: OBJECT-TYPE: esta construcción se utiliza para especificar el tipo de datos, el estado y la semántica del objeto gestionado. 15

16 MODULE-IDENTITY: esta otra construcción nos permite poder agrupar objetos relacionados dentro de lo que se denomina un módulo de información MIB SNMP tiene definido una estructura estándar para los datos que gestiona, la base de información de gestión (Management Information Base; MIB). En esta estructura se definen los datos (objetos con valores) que contiene un dispositivo gestionado, al igual que las operaciones que permite. Esos valores van a poder ser consultados o modificados por una entidad de gestión enviando mensajes, a través del protocolo SNMP, al agente que se está ejecutando en el dispositivo a gestionar. Los objetos se especifican utilizando la construcción, comentada en el punto anterior, OBJECT- TYPE y se reúnen en módulos (módulos MIB) utilizando el constructor MODULE- IDENTITY. Se puede ver parte de la implementación de uno de estos módulos en la figura 7. Debido a la gran diversidad de dispositivos de red y fabricantes que residen en el mercado informático, la IETF (Internet Engineering Task Force) tuvo que buscar una manera estándar de identificar a todos los dispositivos y de acceder a la información de gestión que contienen. Para ello, la IETF adoptó un entorno estandarizado de identificación que había sido propuesto por la ISO, de tal manera que se iba a poder identificar cualquier objeto de cualquier dispositivo, independientemente del fabricante. La MIB mantiene una estructura de árbol, de tal manera que para acceder a un dato en concreto desde la raíz, sólo va a existir un único camino. En la parte superior del árbol se encuentra ISO y ITU-T (Internacional Telecommunication Union), las dos principales organizaciones de estandarización. Tal y como se observa en la figura 6, cada nodo del árbol contiene un nombre y un número, de tal forma que cada nodo va a ser identificable mediante una secuencia de nombres o de números. En nuestro caso, para acceder a los módulos MIB estándar podremos hacerlo de las siguientes dos maneras: mediante su nombre:.iso.org.dod.internet.management ó a través de su representación numérica (también llamada OID, Object IDentifier)

17 ITU-T (0) ISO (1) Joint ISO/ITU-T (2) Standard (0) Cuerpos miembros de ISO (1) Organizaciones identificadas por ISO (3) US DoD (6) Internet (1) managment (2) MIB-2 (1) MIB-1 (2) system (1) interface (2) address translation (3) ip (4) icmp (5) tcp (6) udp (7) egp (8) snmp (11) (fig. 6, árbol de objetos MIB) Las hojas del árbol MIB, son los objetos que contienen las variables que a su vez contienen información sobre el dispositivo. La versión estándar actual de la MIB, es la MIB-II ( ) especificada en el RFC Aquí se encuentran algunos de los módulos de información que más nos van a interesar para la gestión del dispositivo: system( ): incluye información sobre el fabricante y el tiempo sobre el último reinicio del sistema de gestión interface( ): información sobre los interfaces de red address translation( ): contiene la dirección de red y sus traducciones a direcciones físicas ip( ): proporciona las tablas de rutas y estadísticas sobre los datagramas IP recibidos icmp( ): contiene información sobre los mensajes icmp recibidos tcp( ): muestra información sobre las conexiones TCP, retransmisiones, etc. udp( ): cuenta el número de datagramas UDP, enviados, recibidos, etc. egp( ): proporciona información acerca de los mensajes egp, recibidos, enviados, etc. A modo de nota informativa, comentar que en el RFC 3000 [1] se encuentran enumerados todos los módulos MIB estandarizados. [1] Consultar referencia en la Bibliografía 17

18 En la figura 7, se muestra parte de la implementación de la MIB-II. En concreto, las definiciones de tres objetos del grupo o módulo system: sysdescr, sysobjectid y sysuptime. RFC1213-MIB DEFINITIONS ::= BEGIN IMPORTS mgmt, NetworkAddress, IpAddress, Counter, Gauge, TimeTicks FROM RFC1155-SMI OBJECT-TYPE FROM RFC-1212; -- This MIB module uses the extended OBJECT-TYPE macro as -- defined in [14]; -- MIB-II (same prefix as MIB-I) mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } -- textual conventions DisplayString ::= OCTET STRING -- This data type is used to model textual information taken -- from the NVT ASCII character set. By convention, objects -- with this syntax are declared as having SIZE (0..255) PhysAddress ::= OCTET STRING -- This data type is used to model media addresses. For many -- types of media, this will be in a binary representation. -- For example, an ethernet address would be represented as -- a string of 6 octets. -- groups in MIB-II system OBJECT IDENTIFIER ::= { mib-2 1 } interfaces OBJECT IDENTIFIER ::= { mib-2 2 } at OBJECT IDENTIFIER ::= { mib-2 3 } ip OBJECT IDENTIFIER ::= { mib-2 4 } icmp OBJECT IDENTIFIER ::= { mib-2 5 } 18

19 tcp OBJECT IDENTIFIER ::= { mib-2 6 } udp OBJECT IDENTIFIER ::= { mib-2 7 } egp OBJECT IDENTIFIER ::= { mib-2 8 } -- historical (some say hysterical) -- cmot OBJECT IDENTIFIER ::= { mib-2 9 } transmission OBJECT IDENTIFIER ::= { mib-2 10 } snmp OBJECT IDENTIFIER ::= { mib-2 11 } -- the System group -- Implementation of the System group is mandatory for all -- systems. If an agent is not configured to have a value -- for any of these variables, a string of length 0 is -- returned. sysdescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "A textual description of the entity. This value should include the full name and version identification of the system's hardware type, software operating-system, and networking software. It is mandatory that this only contain printable ASCII characters." ::= { system 1 } sysobjectid OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "The vendor's authoritative identification of the network management subsystem contained in the entity. This value is allocated within the SMI enterprises subtree ( ) and provides an easy and unambiguous means for determining `what kind of box' is being managed. For example, if vendor `Flintstones, Inc.' was assigned the subtree , it could assign the identifier to its `Fred 19

20 Router'." ::= { system 2 } sysuptime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The time (in hundredths of a second) since the network management portion of the system was last re-initialized." ::= { system 3 } (fig. 7, implementación parcial del módulo system) Por cada uno de los objetos, vemos que muestra: su nombre o definición (OBJECT-TYPE) la estructura de datos de ese objeto, el tipo de dato que va a devolver ese objeto (SYNTAX) el tipo de privilegio o acceso al objeto, lectura, escritura, creación. (ACCESS) su estado, que indica si esa definición es actual o antigua y una descripción de lo que se obtiene de él (DESCRIPTION) Además de la MIB estándar (MIB-II), otra MIB que también nos va a interesar es la HOST-RESOURCES-MIB (MIB de recursos del host con OID ), de la cual podremos obtener información de recursos de servidores tales como la capacidad de disco duro, el número de usuarios del sistema, el uso de la memoria RAM, el número de procesos, software instalado, etc (la descripción de esta MIB se encuentra definida en el RFC 2790) [1]. Por último, comentar que muchas empresas y fabricantes informáticos se dedican también a crear sus propias MIBs (MIBs propietarias) para sus productos, de tal manera que el usuario final pueda obtener una mejor información y realizar una gestión adecuada de dicho producto Operaciones de SNMP La forma más común de utilizar el protocolo SNMP es de la manera petición respuesta, en el que la entidad gestora envía una petición a un agente (que se encuentra en un dispositivo a gestionar), la recibe, la trata y envía una respuesta a esa petición. Las peticiones se suelen utilizar para obtener (get) o modificar (set) valores de objetos MIB del dispositivo a gestionar. Otra manera de utilizar el protocolo SNMP, es mediante mensajes trampa o traps. Aquí, la entidad gestora no envía ninguna petición, sino que es el propio agente del dispositivo que se está gestionando el que envía un mensaje a la entidad gestora. Estos traps se utilizan cuando se dan situaciones excepcionales, por [1] Consultar referencia en la Bibliografía 20

21 ejemplo: el agente instalado en un servidor podría enviar un trap cuando el espacio libre de su disco duro alcance un determinado nivel. Aunque se detallará más adelante, el sistema operativo Windows 2003 Server no soporta la última versión del protocolo (SNMPv3), por lo que la versión utilizada en este PFC será la 2 (SNMPv2), la cual tiene definidos siete tipos de mensajes o PDUs que se engloban en cinco grupos (el formato se puede observar en la figura 8): operaciones tipo get, que son enviadas desde la entidad gestora a un agente para obtener el valor de los objetos MIB del dispositivo a gestionar. Existen tres diferentes: o GetRequest: utilizada para obtener el valor de uno o varios objetos MIB o GetNextRequest: utilizada para obtener el valor del siguiente objeto MIB en una tabla (de esta manera evitamos tener que hacer múltiples GetRequest) o GetBulkRequest: utilizada cuando se va a acceder a una tabla que contiene una gran cantidad de objetos MIB tipo set, enviadas desde la entidad gestora al agente del dispositivo gestionado para modificar el valor de uno o varios objetos MIB: o SetRequest tipo inform, se envían desde la entidad gestora al agente de otra entidad gestora para notificar la información MIB que es remota a la entidad receptora (no se va a utilizar): o InformRequest tipo response, se envían como respuesta a los mensajes expuestos anteriormente, desde el agente a la entidad gestora: o Response mensajes trampa o traps, estos mensajes se envían desde el agente del dispositivo gestionado a la entidad gestora, para informar a esta de un evento excepcional sucedido en el dispositivo gestionado. El apelativo de trampa, se debe a que el agente envía el mensaje sin que la entidad gestora lo solicite. 21

22 Obtener/establecer cabecera Variables a obtener/establecer Tipo PDU (0-3) id petición Estatus de error (0-5) Índice de error Nombre Valor Nombre Valor Tipo PDU (4) Empresa Dirección agente Tipo trampa (0-7) Código específico Marca de tiempo Nombre Valor Cabecera de trampa Información de trampa PDU SNMP (fig. 8, formato de las PDUs en SNMPv2) Como ya se ha comentado, UDP es el principal protocolo de transporte para el envío de mensajes SNMP siendo el puerto 162 el usado para los mensajes trampa (la entidad gestora se queda a la escucha del puerto esperando recibir algún mensaje) y el 161 para el resto de mensajes como se muestra en la siguiente figura. (fig. 9, operaciones SNMP) Debido a que UDP ofrece un servicio de transporte no orientado a conexión, esto es, no fiable, no se va a poder obtener una garantía de que las peticiones, o sus respectivas respuestas, lleguen a su correspondiente destino. Por ello, la entidad gestora utiliza el campo ID Petición de las PDU para numerar las peticiones realizadas a un agente; éste, tomará la ID Petición de la petición recibida y la indicará en la PDU de respuesta. De esta manera la entidad gestora puede detectar las peticiones o respuestas perdidas. En el caso particular, de que la entidad gestora no recibiera la correspondiente respuesta a la petición enviada, el estándar SNMP actualmente no indica si se debe de seguir algún tipo de política (como por ejemplo, la retransmisión de la petición). 22

23 3.5.3 La seguridad en SNMP En el apartado anterior hemos comprobado que los mensajes SNMP no se utilizan sólo para obtener información de los dispositivos gestionados, sino que también se puede modificar información de estos (con el mensaje SetRequest). Esto es algo peligroso, ya que un usuario no autorizado podría captar estos mensajes y modificarlos a su gusto originando graves problemas en la red. Ya se ha comentado que la seguridad en las dos primeras versiones del protocolo SNMP era algo escasa. Se basa en el concepto de comunidad (community). Hay dos tipos de comunidades que indican los permisos de acceso y que pueden ser: Read-only o sólo lectura, utilizada cuando solo se quiere obtener información de los dispositivos gestionados Read-write o lectura-escritura, además de obtener información, se realizan cambios en la información del dispositivo Cada una de estas, tiene una clave de acceso llamada nombre de comunidad (community name) y que se ha de indicar cuando se utilizan los mensajes SNMP. Por defecto son: public para la comunidad read-only private para la read-write Obviamente, para aumentar la seguridad de nuestro sistema lo primero que se debería de realizar es el cambio de estos nombres de comunidad. Ya que en este PFC se utiliza SNMPv2, en capítulos posteriores se explicará como realizar este paso. Es en la versión 3 de SNMP cuando se introducen verdaderos mecanismos de seguridad. Esta seguridad se basa en los conceptos de autenticación y cifrado. Aparece también el concepto de usuario, que se identifica por un nombre de usuario y una clave de acceso. Para el cifrado o encriptación de la información, SNMPv3 utiliza el sistema de clave compartida DES (Data Encryption Standard), y para la autenticación también se suelen utilizar funciones de dispersión (lo más común es utilizar algoritmos como MD5 o SHA). Todos estos mecanismos hacen de SNMPv3 la versión más segura del protocolo ofreciendo una gran confianza a sus usuarios aunque dependiendo de las necesidades de estos y de la gestión que se vaya a realizar de la red, se podrán seguir utilizando cualquiera de las otras dos versiones anteriores. 3.6 Conclusiones El protocolo de gestión SNMP cuenta con un diseño simple lo que le hace tener también una implementación sencilla capaz de integrarse en grandes redes necesitando pocos recursos. La utilización de las MIB como base de datos de los dispositivos a gestionar, permite a los usuarios un acceso sencillo a la información que deseen conocer. 23

24 La popularidad la alcanzó al ser, prácticamente, el único protocolo de gestión que existió al principio, lo cual hizo que los fabricantes informáticos diseñaran sus productos para soportar SNMP. Siendo un protocolo tan popular, no se podía permitir las desventajas con las que contaba, las referentes a la seguridad, que cada vez se iban haciendo más latentes a medida que surgían redes más potentes. Por ello, los grupos de expertos se reunieron para introducir los mecanismos de seguridad, ofreciendo de esta manera un gran protocolo de gestión a los usuarios más exigentes. 24

25 CAPÍTULO 4. DESARROLLO TEÓRICO En este capítulo se abordará de una manera global (sin entrar en detalles) el propio desarrollo del proyecto: se comentará de forma breve su finalidad, para pasar posteriormente a la captura y análisis de requerimientos necesarios para poder llevarlo a cabo: A nivel hardware, se enunciarán los dispositivos necesarios y sus características más relevantes. A nivel software, se realizará un pequeño análisis de los programas y paquetes informáticos utilizados. También se comentarán las decisiones más relevantes tomadas durante la realización de este proyecto, que en general se han establecido en función de la arquitectura de la red informática sobre la que se ha implantado el sistema de gestión. 4.1 Introducción (finalidad del proyecto) Este proyecto tiene como finalidad la implantación de un sistema de control o gestión de una red informática que pueda facilitar el control de ésta a su administrador. Como características más relevantes de este sistema, se presentan la capacidad de monitorizar mediante gráficas, diferentes parámetros de los dispositivos que se encuentran en la red así como un almacenamiento histórico de los datos para su posterior análisis. En caso de producirse un evento importante en alguno de los dispositivos gestionados, el sistema también será capaz de generar una alerta que pueda enviarse mediante correo electrónico o vía SMS (Short Message Service, Servicio de Mensajes Cortos), pudiendo así el administrador realizar un control más cómodo de la red informática. 4.2 Captura de requerimientos hardware Aunque pueda resultar una obviedad, lo primero que necesitaremos para llevar a cabo el proyecto es una red informática lo suficientemente amplia. Es por ello que este sistema se va a implantar en el centro de formación Cebanc-Cdea, el cual cuenta con una red de aproximadamente 300 máquinas y unos 15 servidores, además de múltiples dispositivos (routers, switches, hubs, etc.) para su interconexión. En segundo lugar, y haciendo referencia al capítulo anterior, se utilizará como base un protocolo de gestión (SNMP) para el control de la red. Centrándonos ya en la arquitectura del protocolo SNMP, lo primero será disponer de una máquina o un servidor que haga la función de entidad gestora. Para ello se cuenta con un servidor HP ProLiant ML 110, que presenta las siguientes características, las cuales se consideran suficientes como para llevar a cabo un buen control de la red: Procesador Intel Pentium 4 a 2.80 GHz 512 MB de memoria SDRAM DDR PC 3200 A 400 MHz Disco duro con capacidad para 40 GB (ATA/ rpm) 25

26 Tarjeta de red Broadcom 5705 PCI Gigabit 10/100/1000 integrada con WOL (Wake on LAN). Desde esta interfaz habrá que tener conexión con los dispositivos a gestionar. Conexión a un SAI (Sistema de Alimentación Ininterrumpida), para evitar problemas en caso de cortes en el sistema eléctrico. Hay que recordar, que del buen funcionamiento de esta máquina dependerá la buena gestión de la red, sobre todo en los momentos más críticos (cuando haya congestiones, cortes de luz, etc.). Por ello, es importante contar con una máquina lo más fiable posible y así poder obtener al final una mayor probabilidad de éxito en el control de la red. Una vez que tenemos la máquina que trabajará como entidad gestora, el siguiente punto a tratar es la elección de los dispositivos de red a gestionar y sus parámetros. Tras consultarlo con el cliente de este proyecto, el administrador de sistemas de la empresa, se decide gestionar 11 de los servidores y 1 de los routers. Por motivos de seguridad para la empresa, no se detallarán en profundidad las características de estos dispositivos aunque sí se puede comentar que entre los servidores algunos ofrecen servicios típicos como: servicio de correo interno/externo servicio web acceso a la base de datos del centro servicio de descarga de ficheros gestión de dominios bajo Windows 2003 (DCs, Domain Controler) cursos interactivos on-line Los parámetros que se desean gestionar y monitorizar posteriormente son los siguientes: en cada uno de los servidores: o tráfico entrante/saliente en las tarjetas de red o espacio libre en los HD (Hard Disk, disco duro) o tasa de CPU utilizada o memoria RAM disponible o numero de sesiones abiertas o numero de procesos en ejecución o estado (encendido/apagado) en el router: o tráfico entrante/saliente en sus diferentes bocas Ya se comentó en el capítulo anterior que a través de las MIB podemos monitorizar prácticamente todo aquello que se nos ocurra. Algunos parámetros interesantes que también se podrían haber gestionado pero que el cliente no consideró necesarios en estos momentos son: estado de los servicios/procesos (si se encuentran en ejecución o no), memoria utilizada por cada proceso, estado de los puertos, etc. 26

27 De los 11 servidores, 10 de ellos trabajan bajo el Sistema Operativo Windows 2003 Server y el restante, bajo Windows Esto será importante, a la hora de tener que instalar y configurar el agente de cada uno de los servidores. Por último, para posibilitar a nuestro sistema la capacidad de envío de SMS, será necesario contar con un dispositivo móvil que permita el envío de este tipo de mensajes, así como su correspondiente cable de conexión de datos, para que la entidad gestora pueda comunicarse con él. La elección de estas herramientas se deja para un punto posterior, ya que se tomará una decisión en función del software a utilizar. Todo lo explicado hasta ahora es referente al hardware necesario, a continuación se detallará el software. Antes de nada, resaltar que como finalidad indirecta del proyecto, también se quiere desarrollar e implantar el sistema con herramientas gratuitas y de libre distribución y esto se debe básicamente a dos motivos: primero, porque para su realización no se cuenta con ningún tipo de presupuesto económico y segundo porque se quiere demostrar que muchas de las herramientas de libre distribución son tan válidas y funcionales como las desarrolladas por las empresas privadas. 4.3 Captura de requerimientos software El Sistema Operativo A nivel software, la primera decisión a tomar es la elección de la plataforma bajo la que se desarrolla el control de la red. Principalmente existen dos grandes sistemas en el mercado, Windows y Linux. Además de tener en cuenta lo comentado en el punto anterior, también se toma en consideración las consultas realizadas con el cliente, quien me animó y me aconsejó a realizarlo bajo GNU/Linux, sistema que a nivel de servidores ofrece un mejor rendimiento y una mayor fiabilidad que Windows. Además, el tener los servidores a gestionar con Windows como sistema base, no nos presenta ningún tipo de problema. Una vez decantados por el S.O. Linux, la siguiente decisión es la elección de la distribución a utilizar. Actualmente, existen múltiples distribuciones de este S.O., tales como Red Hat, Suse, Mandrake, Debian, etc. Todas ellas tienen en común el núcleo Linux, junto con sus bibliotecas y herramientas del proyecto GNU (proyecto para el desarrollo de herramientas totalmente libres), y difieren en el conjunto de aplicaciones que reúnen cada una. Es conocido, que la instalación de paquetes y programas bajo Linux no suele ser algo trivial y cómodo. Esto se presenta como un problema, ya que se prevé que durante este proyecto se tenga que instalar y configurar diferente software. Se decide utilizar Debian (versión del núcleo ), debido a que subsana los problemas comentados en el párrafo anterior. Gracias a su comando apt-get, se pueden instalar y actualizar de manera sencilla los paquetes y servicios que deseemos. Además se realiza una instalación por red, que nos permite decidir desde un principio los paquetes a instalar. Con una instalación desde CD tendremos una gran cantidad de paquetes instalados que no se van a utilizar, lo cual podría generar una sobrecarga en nuestra máquina de forma innecesaria. Otra ventaja con la que cuenta la distribución por red, es que en el 27

28 momento de la instalación contamos con las últimas versiones de todos los paquetes, y que a través del comando apt-get update se podrán ir actualizando cómodamente Los agentes Hasta el momento tenemos, por un lado el servidor o máquina que trabaja como entidad gestora y que funciona bajo Linux, utilizando la distribución Debian; por el otro los dispositivos a gestionar (11 servidores Windows y 1 router), y el protocolo SNMP para realizar la gestión entre la entidad y los dispositivos. Siguiendo la arquitectura del protocolo de gestión comentada en el capítulo 3, el siguiente paso es poner en funcionamiento a los agentes de cada dispositivo, que son los procesos encargados de comunicarse con la entidad gestora. Para llevar a cabo las primeras pruebas, además de realizar la instalación de los agentes en cada uno de los servidores a gestionar, también se instala el agente en la propia entidad gestora (de esta manera se detalla también la instalación y configuración de un agente en Linux). En este último caso nuestro servidor además de trabajar como entidad gestora, adquiere también la funcionalidad de dispositivo gestionable. Para el caso del router (y el ejemplo serviría para otros dispositivos como switches o hubs), el fabricante (Cisco) le dio soporte para el protocolo SNMP, por lo que ya cuenta con el agente. Tan solo hay que consultar su manual, para poder configurarlo. Es interesante también, acceder a las páginas web de los fabricantes para poder comprobar si existen nuevas actualizaciones para el firmware de nuestros productos. En la mayoría de las distribuciones Linux, se incluye un agente SNMP que es uno de los más desarrollados en la actualidad. Se trata de la librería NET- SNMP, antes denominada ucd-snmp. Más adelante se explicará su instalación, su configuración y las herramientas con las que cuenta. Uno de los principales problemas durante la realización de este proyecto, surgió en el momento en el que se debía de analizar el agente con el que trabaja la plataforma Windows. Tras recopilar la información necesaria sobre los dispositivos a gestionar, y más concretamente sobre los agentes de Windows, se comprobó que estos ya partían con una desventaja importante: actualmente no soportan SNMPv3. Esto presenta un problema a nivel de seguridad, ya que los mensajes SNMP no pueden viajar cifrados ni se puede realizar una seguridad a nivel de usuario (tal y como se explicó en el capítulo anterior). Tras consultar este problema con el cliente del proyecto, no se vio tampoco como un gran inconveniente, ya que toda la información SNMP va a viajar sólo a través de la Intranet (ó red interna) de la empresa y además ya se había decidido que los mensajes se iban a utilizar únicamente para obtener información. Es decir, se presentaron los riesgos al cliente, éste los evaluó y consideró que la seguridad que ofrece SNMPv2 era suficiente para la red de la empresa. 28

29 En compensación, el agente de Windows ofrece otro tipo de opciones en materias de seguridad para suplir de alguna manera esa carencia, que se verán más adelante. Una vez que tenemos instalados y configurados los agentes en los diferentes servidores a gestionar, ya podemos realizar el control de éstos desde la entidad gestora. Ahora bien, queremos tener los datos representados de una manera amigable, vistosa y clara, utilizando por ejemplo la representación a través de gráficas. Para ello haremos uso de una herramienta de monitorización de datos, que será capaz de generar las gráficas en páginas HTML (HyperText Mark-Up Language), y que posteriormente podrán ser visibles desde otras máquinas, haciendo uso también de un servidor HTTP (HyperText Transfer Protocol) Análisis de herramientas de monitorización de datos Aunque inicialmente se preveía que el decidir el software a utilizar para monitorizar los datos fuese uno de los pasos más laboriosos, por existir multitud de software en el mercado y tener que realizar múltiples pruebas con cada una de las aplicaciones que nos pudieran interesar, resultó mucho más sencillo de lo que parecía. Como se ha dicho, actualmente en el mercado, existen muchas herramientas de monitorización de dispositivos, pero descartando todas aquellas que no son de libre distribución y que no trabajan en el mundo Linux, básicamente nos podemos quedar con dos ya que son las más valoradas y usadas en el ámbito de la gestión de redes: MRTG (Multi Router Traffic Grapher) y Nagios. Se comenzó analizando Nagios, y rápidamente se descartó ya que aunque permite la captura de paquetes SNMP, no es un sistema de monitorización y gestión basado en SNMP sino que se basa en unos pequeños módulos software que realizan chequeos de la red. Con lo cual, la elección fue sencilla: MRTG. Esta herramienta cuenta con todas las características necesarias para solventar los requerimientos de este proyecto: genera páginas HTML con los gráficos, es capaz también de generar alarmas (de esta manera no hace falta usar los mensajes trampa o traps, evitando tener el puerto 162 abierto), y es un sistema basado en SNMP (sus desarrolladores lo crearon para poder trabajar, básicamente, con SNMP, aunque permite otros métodos de obtención de datos, como se verá más adelante) Servidor HTTP Una vez que tenemos las páginas web con los gráficos de los dispositivos funcionando, se va a montar en nuestra máquina un servidor de páginas web, para que se pueda acceder a las gráficas desde otras máquinas. Para este proyecto se va a emplear el servidor HTTPD de Apache por diferentes motivos: disponibilidad del programa, facilidad de instalación, necesita muy pocos recursos y podemos obtenerlo de manera gratuita. 29

30 Actualmente se cuenta con dos versiones de este software, Apache 1.x y Apache 2.x. La versión 1.x aún se encuentra activa y en desarrollo, lo cual implica que no se hará obsoleta en pocos años. La versión 2.x, cuenta con una serie de funcionalidades nuevas que la hacen más eficiente en sistemas no Unix. Muchos de sus módulos han sido simplificados, al igual que el archivo de configuración principal. Instalando esta versión, nos evitamos también el tener que realizar una migración de la versión 1.x a la 2.x en un futuro. Por todos los motivos explicados anteriormente, se decide instalar Apache Análisis de herramientas para la comunicación de redes IP y GSM Por último, nos hará falta un software o librería capaz de comunicar redes IP (Internet Protocol) con redes GSM (Global System for Mobile communications, Sistema Global para las Comunicaciones Móviles), de tal manera que podamos enviar alarmas (a través de mensajes SMS) sobre los eventos excepcionales ocurridos en los dispositivos, al teléfono móvil del administrador de la red. En la distribución Debian, dos son las principales librerías que nos ofrecen este tipo de servicio: alamin y gnokii. Alamin es un proyecto español basado en el proyecto Gnokii. Su utilización más habitual, es la de pasarela para el envío de alarmas desde una red de ordenadores a un dispositivo móvil, informando de la gestión de la red. Otro uso muy común que se le da actualmente es, como aplicación para mostrar los SMS que los teleespectadores envían a los programas de televisión. Actualmente se encuentra en desarrollo, en espera de añadir nuevas funcionalidades, siendo un programa muy completo. Cuenta con la desventaja de que el número de dispositivos móviles que se ha testeado con este programa, aún no es muy amplio. Gnokii es un programa de similares características, pero lleva más tiempo en desarrollo lo que lo hace más fiable además de contar con una configuración muy sencilla. Cuenta con un abanico de soporte de teléfonos móviles más amplio. Estas características hacen que seleccionemos Gnokii como software para la realización de este último punto. 4.4 Conclusiones En este capítulo se ha tratado de recopilar de una manera global los requerimientos y las decisiones de este proyecto. Como se ha comprobado, la gran mayoría de estos requerimientos se han seleccionado en función de la propia topología de la red y de las necesidades del cliente. De aquí se puede deducir, que la manera de implantar un sistema de gestión de red no es única, lo que conlleva a que actualmente no exista un estándar para poder llevar a cabo esta tarea. Hay que tratar de realizar un buen estudio de la red y tener claras las capacidades con las que se quiere dotar al sistema de gestión, para que el funcionamiento del sistema sea lo más óptimo posible en nuestra red. 30

31 Una vez recopilados todos los requerimientos necesarios, en el siguiente capítulo se explicarán con más detalle cada uno de ellos. Se hará siguiendo el mismo orden en el que se ha realizado el proyecto. 31

32 CAPÍTULO 5. DESARROLLO PRÁCTICO Este es el capítulo más práctico de todo el proyecto. Aquí se detallará paso a paso la configuración de todo el software que ha aparecido en capítulos anteriores. Como ya se ha explicado anteriormente, no se puede tratar como un manual global o estándar, sino de un manual para la red con la que se está trabajando en este proyecto. Aún así, también puede servir de punto de partida para implantar sistemas de gestión en otro tipo de redes. Por motivos de seguridad para la red de Cebanc-Cdea, algunos de los archivos de configuración que se van detallar, no aparecen exactamente de la manera en la que se han implementado (como por ejemplo, los nombres de comunidades, grupos o direcciones IP). El desarrollo de este capítulo se realizará en el siguiente orden: inicialmente se tratará la instalación y configuración de los agentes tanto en Linux como en Windows; posteriormente pasaremos a la instalación y configuración de la herramienta de monitorización (MRTG) y del servidor web (Apache). El capítulo concluye detallando el uso del software para comunicar redes IP y GSM (Gnokii). 5.1 Instalación, configuración y pruebas de los agentes Como ya se ha comentado, cada dispositivo gestionado contará con un agente para poder comunicarse con la entidad gestora. En la propia entidad gestora también se instalará el agente, de tal manera que se puedan hacer pruebas en el propio servidor (utilizaremos nuestro servidor, como entidad gestora y dispositivo a gestionar). Además la configuración de este agente, será diferente a la del resto de dispositivos a gestionar, ya que este contará con un agente Linux, mientras que el resto utilizarán uno para Windows. En el caso de los servidores (o máquinas terminales), los agentes y el servicio SNMP, no vienen instalados por defecto en el S.O. A continuación explicaremos los dos casos que se han utilizado en este proyecto Linux Debian (Net-SNMP) La librería Net-SNMP es una de las más conocidas y utilizadas en plataformas Linux. De hecho las distribuciones más importantes de este S.O. siempre la añaden entre sus aplicaciones. La versión utilizada, para la distribución en Debian, ha sido la Esta librería cuenta con diferentes paquetes de los cuales nos interesan dos: snmp ( ) Net-SNMP Apps: en este paquete se encuentran las aplicaciones NET-SNMP, que son una colección de comandos para los clientes, para poder publicar las peticiones SNMP a los agentes snmpd ( ) Net-SNMP Agents: es el agente Net-SNMP. Es un servicio (en Linux también conocido como demonio) que se queda a la escucha de peticiones SNMP desde los clientes y proporciona respuestas. 32

33 Para realizar su instalación desde la línea de comandos, lo primero que se deberá hacer es acceder como superusuario a través del comando su, y luego ayudarnos del comando apt-get para la instalación del paquete, como se muestra en la figura 10. su Password: sojos:/home/rmartin# apt-get install snmp (fig 10, instalación del paquete snmp a través del comando apt-get) Una vez instalado el agente y sus aplicaciones, tan sólo habrá que configurarlo según las necesidades del equipo en el que va a estar instalado. La propia librería incluye suficiente documentación para describir los diferentes archivos de configuración. El fichero que más nos va a interesar es el snmpd.conf, que en nuestro caso se encuentra en /etc/snmp/ Las primeras definiciones en el archivo de configuración se refieren al modo de acceder al agente desde cualquier servidor. Su funcionamiento es un poco complejo, debido a que este agente da soporte para las 3 versiones del protocolo y si recordamos, la seguridad en las dos primeras versiones se basa en comunidades, mientras que en la última se realiza a través de usuarios. Ya se explicó en el capítulo anterior que la versión del protocolo que se utilizará en este proyecto es la SNMPv2, por lo tanto realizaremos la configuración del agente basándonos en las comunidades. Lo primero que se ha de definir son los nombres de comunidad en función de dónde se haga la petición y del grupo de seguridad. Se verá más claro con un ejemplo como el de la figura 11. # Mapear el nombre de comunidad en un nombre de seguridad # (dependiendo de donde provenga la petición) # sec.name source community com2sec readonly default public com2sec readwrite private (fig. 11, definición de los nombres de comunidad y grupos asignados) En este caso, se está indicando que para acceder desde cualquier servidor a este se hará dentro del grupo readonly y con el nombre de comunidad public. El propio servidor ( ) puede acceder a sí mismo a través del grupo readwrite y con el nombre de comunidad private. Ya se comentó, que los nombres de comunidad eran por defecto los que aparecen aquí. Es en este momento cuando se deben de cambiar los nombres por otros, para aumentar la seguridad de acceso al sistema. A continuación se debe definir una relación entre modelos de seguridad y grupos, como se muestra en la figura 12. Todos los accesos como comunidad public desde cualquier lugar se incluyen en el grupo MyROGroup, mientras que los accesos como comunidad private desde el propio servidor se añaden al grupo MyRWGroup. 33

34 # Asignacion de grupos (mapear los nombres de seguridad en grupos) group MyRWGroup v1 readwrite group MyRWGroup v2c readwrite group MyRWGroup usm readwrite group MyROGroup v1 readonly group MyROGroup v2c readonly group MyROGroup usm readonly (fig. 12, relación entre modelos de seguridad y grupos) Para que quede más claro; hasta ahora tenemos dos grupos de acceso: MyROGroup y MyRWGroup y que están ligados a los grupos de seguridad readonly y readwrite, respectivamente. En readonly se encuentran todos los accesos que se hagan desde cualquier lugar y utilizando el nombre de comunidad public. Mientras que en readwrite sólo se encuentra el propio servidor que podrá acceder a sí mismo utilizando la comunidad private. A continuación, se definen las vistas (figura 13). Con esto se indica a qué zonas de la MIB tiene acceso cada grupo. # Vistas (accesos permitidos a la MIB) # incl/excl subtree mask view all included.1 80 view system included.iso.org.dod.internet.mgmt.mib-2.system # Especificar los permisos de los grupos # group context sec.model sec.level prefix read write notif access MyROGroup "" any noauth exact all none none access MyRWGroup "" any noauth exact all all none # Datos informativos de contacto syslocation Servidor Linux en dptoinformatica syscontact Raul Martin (fig. 13, definición de vistas y tipo de acceso) Con esta configuración se garantiza el acceso de escritura al grupo MyRWGroup a cualquier zona de la MIB, mientras que sólo se permite leer dentro de la vista system al grupo MyROGroup que es de sólo lectura. Con esto ya tenemos nuestro agente de Linux configurado. A continuación hay que lanzar el proceso snmpd y comprobar que se encuentra escuchando en el puerto 161, como se ve en la figura 14. sojos:/home/rmartin# cd /etc/init.d sojos:/etc/init.d# snmpd start sojos:/etc/init.d# netstat -anp -u Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name udp : :* 1 167/inetd udp : :* 1 178/snmpd (fig. 14, proceso snmp escuchando en el puerto 161 a través del protocolo UDP) 34

35 Es importante tener en cuenta que cada vez que modifiquemos algo en este archivo de configuración, para que los cambios tengan efecto, se deberá de reiniciar el servicio. En Debian se puede realizar fácilmente con el comando restart. Una vez que tenemos el agente configurado, y el proceso snmpd en ejecución, podemos comenzar a utilizar las herramientas de gestión incluidas en el paquete snmp. Con estas herramientas podremos utilizar todas esas funciones que se comentaron en el capítulo 3 (GetRequest, GetNextRequest, etc). Las herramientas (o comandos) con las que contamos son las siguientes: snmpget: se utiliza para obtener datos de un dispositivo dado su nombre y un OID (figura 15). sojos:/# snmpget -c 2nmp -v2c localhost system.sysuptime.0 SNMPv2-MIB::sysUpTime.0 = Timeticks: ( ) 22 days, 20:53:36.94 (fig. 15, salida del comando snmpget) En esta orden se indica, el nombre de la comunidad de acceso public, la versión a utilizar, la 2 (2c), el nombre del dispositivo que queremos gestionar (localhost o su IP ) y el OID, system.sysuptime.0 También podemos realizar múltiples consultas en una única orden (figura 16). sojos:/# snmpget -c 2nmp -v2c localhost sysuptime.0 sysname.0 SNMPv2-MIB::sysUpTime.0 = Timeticks: ( ) 22 days, 20:54:09.78 SNMPv2-MIB::sysName.0 = STRING: sojos (fig. 16, salida del comando snmpget con múltiples variables) snmpgetnext: este comando es similar al anterior, salvo que en vez de devolver el valor del OID que nosotros le indiquemos, nos devolverá el siguiente. Se suele utilizar para poder recorrer de forma manual el árbol MIB, indicando siempre el último OID solicitado (figura 17). sojos:/# snmpgetnext -c 2nmp -v2c localhost sysuptime.0 SNMPv2-MIB::sysContact.0=STRING:Raul (fig. 17, salida del comando snmpgetnext) snmpwalk: con este comando se realizan getnexts de manera automática. Es más cómodo para recorrer los valores del árbol MIB. En la figura 18 se muestra cómo recorrer sólo el módulo system. sojos:/# snmpwalk -c 2nmp -v2c localhost system SNMPv2-MIB::sysDescr.0 = STRING: Linux sojos #1 Fri Sep 3 06:24:46 UTC 2004 i686 SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10 SNMPv2-MIB::sysUpTime.0 = Timeticks: ( ) 22 days, 20:55:23.07 SNMPv2-MIB::sysContact.0 = STRING: Raul Martin SNMPv2-MIB::sysName.0 = STRING: sojos SNMPv2-MIB::sysLocation.0 = STRING: Servidor Linux en dptoinformatica 35

36 SNMPv2-MIB::sysORLastChange.0 = Timeticks: (12) 0:00:00.12 SNMPv2-MIB::sysORID.1 = OID: IF-MIB::ifMIB SNMPv2-MIB::sysORID.2 = OID: SNMPv2-MIB::snmpMIB SNMPv2-MIB::sysORID.3 = OID: TCP-MIB::tcpMIB SNMPv2-MIB::sysORID.4 = OID: IP-MIB::ip SNMPv2-MIB::sysORID.5 = OID: UDP-MIB::udpMIB SNMPv2-MIB::sysORID.6 = OID: SNMP-VIEW-BASED-ACM- MIB::vacmBasicGroup SNMPv2-MIB::sysORID.7 = OID: SNMP-FRAMEWORK- MIB::snmpFrameworkMIBCompliance SNMPv2-MIB::sysORID.8 = OID: SNMP-MPD-MIB::snmpMPDCompliance SNMPv2-MIB::sysORID.9 = OID: SNMP-USER-BASED-SM- MIB::usmMIBCompliance... (fig. 18, salida del comando snmpwalk) snmpset: este comando se utiliza para modificar información del dispositivo a gestionar (figura 19). sojos:/# snmpget -v2c -c public localhost systcontact.0 SNMPv2-MIB::sysContact.0 = STRING: Raul Martin sojos:/# snmpset -v2c -c public localhost systcontact.0 s "Administrador" SNMPv2-MIB::sysContact.0 = STRING: Administrador sojos:/# snmpget -v2c -c public localhost systcontact.0 SNMPv2-MIB::sysContact.0 = STRING: Administrador (fig. 19, utilización del comando snmpset) Vemos en la línea de comandos que antes de indicar el valor nuevo de la variable hay indicada una s ; esto es para indicar el tipo del valor de la variable (en este caso string). Para conocer el resto de tipos de variables podemos ejecutar el siguiente comando snmpset h tail -4 snmpstatus: permite acceder al estado del agente (podemos comprobar si éste se encuentra activo, figura 20) sojos:/# snmpstatus -v2c -c 2nmp localhost [ ]=>[Linux sojos #1 Fri Sep 3 06:24:46 UTC 2004 i686] Up: 22 days, 21:10:28.03 Interfaces: 0, Recv/Trans packets: / IP: / (fig. 20, salida del comando snmpstatus) snmptranslate: con esta orden podemos pasar un OID a la variable que representa. Muy útil a la hora de explorar el árbol MIB (figura 21). sojos:/# snmptranslate SNMPv2-MIB::sysUpTime.0 (fig. 21, salida del comando snmptranslate) snmpnetstat: comando similiar al netstat de Linux, pero utilizando el agente SNMP para obtener la información (nos muestra una lista de los puertos abiertos en una máquina, figura 22). 36

37 sojos:/# snmpnetstat -v2c -c 2nmp localhost Active Internet (tcp) Connections Proto Local Address Foreign Address (state) tcp sojos.cebancdea.edu.ssh ESTABLISHED Active Internet (udp) Connections Proto Local Address udp *.discard udp *.sunrpc udp *.snmp udp *.947 udp *.950 udp * udp * (fig. 22, salida del comando snmpnetstat) Además de estos comandos, la librería Net-SNMP presenta algunos más que son menos conocidos y menos utilizados ( snmpdelta o snmptest ). Aquí se ha presentado la forma más sencilla y común de utilizarlos, pero cada comando presenta muchas opciones que se pueden consultar a través del parámetro --help (Ej: snmpget help ). De todos los presentados aquí, para este proyecto los que más van a interesar son básicamente dos: snmpget y snmpwalk. El comando snmpset, suele ser también muy utilizado, pero tras consultarlo con el cliente y sus necesidades, no se consideró necesario usarlo. Además, teniendo en cuenta que vamos a utilizar la versión SNMPv2 con una seguridad sólo basada en comunidades, es interesante tener desactivado ese comando. En el archivo de configuración del agente (/etc/snmp/snmpd.conf), tenemos indicado que todas las consultas SNMP que se hagan desde cualquier máquina que no sea la propia (localhost o ), sean solo de tipo lectura (sólo se podrán obtener datos, nunca modificarlos). Como ya se ha comentado, la instalación de este agente en este proyecto, tan solo se ha utilizado para realizar las primeras pruebas sobre la propia máquina, y también para poder aprender como configurar un agente en Linux Otros agentes SNMP para Linux Aunque el agente Net-SNMP es posiblemente el más utilizado y el que en más distribuciones aparece, no es el único dentro del mundo Linux. También existen otros como: SNMP++, programado en lenguaje C++ pero que sólo soporta las dos primeras versiones del protocolo SNMP, y cuya licencia de distribución no es libre. Agent++, basado en el anterior y de similares características salvo que soporta todas las versiones de SNMP. Opennms, es una librería en Java desarrollada por el proyecto Open Network Managment (Gestión Abierta de Redes). Se caracteriza por incluir varios agentes, desde el propio agente que se encarga de comunicarse con la entidad gestora, hasta agentes para poder procesar alarmas. 37

38 Una vez vistos los agentes para Linux, en el próximo apartado se comentará la configuración de los agentes de los dispositivos a gestionar (11 servidores con plataforma Windows: 1 con Windows 2000, 10 con Windows 2003) Windows 2000, Windows 2003 Server El agente que ofrece Windows es el mismo para las versiones 2000, 2003 Server y XP, por lo que su configuración es similar. El servicio SNMP en Windows, actualmente soporta, pero no incluye software de administración. El software de administración es el que debe de instalarse en la entidad gestora, para que se encargue de la administración. Aquí obtenemos otro motivo más, para haber utilizado en nuestra entidad gestora la plataforma Linux. Para instalar el protocolo SNMP y su agente en Windows: Iniciar el Asistente para componentes de Windows al que se accede a través del menú Panel de Control -> Agregar o quitar programas -> Agregar o quitar componentes de Windows. Marcamos la opción Herramientas de administración y supervisión y vemos los detalles como muestra la figura 23. (fig 23, panel de instalación del agente SNMP en Windows) Marcamos la opción que incluye el agente. Tras la instalación el servicio SNMP se iniciará automáticamente. Lo podremos comprobar en la lista de 38

39 servicios a la que se accede desde el menú Herramientas Administrativas (figura 24). (fig. 24, estado del servicio SNMP) Accedemos a la configuración del servicio seleccionándolo y desde el menú Acción haciendo clic en Propiedades; se muestra en la siguiente figura. (fig. 25, panel de propiedades del servicio SNMP) En la ficha Agente, indicamos un nombre de contacto para el servidor y su ubicación. Las opciones del menú Servicio se detallan en la figura 26. Teniendo en cuenta estas opciones, en nuestros servidores marcamos las opciones Aplicaciones y De un extremo a otro (ver figura 25). 39

40 (fig. 26, detalles de las opciones del menú Servicio) 40

41 (fig. 27, panel de configuración de Seguridad del servicio SNMP) En la ficha Seguridad, que se muestra en la figura 27, se indican los nombres de comunidad y qué derechos tiene cada una de las comunidades que indiquemos. Como ya se ha comentado varias veces, en nuestro caso sólo se va a obtener información de estos dispositivos, por lo que los derechos de la comunidad serán de sólo lectura. Además también, podemos señalar desde qué máquinas se pueden aceptar paquetes SNMP. Aquí indicaremos la dirección IP (o el nombre) de nuestra entidad gestora. De esta forma nos aseguramos que sólo se va a poder gestionar el dispositivo desde nuestra entidad gestora. Marcamos también la opción Enviar captura de autenticación, que servirá para comprobar si los paquetes SNMP se reciben desde direcciones IP válidas. Si esto no fuera así, porque la dirección IP (o nombre de la máquina) o el nombre de la comunidad no son correctos, se enviaría desde el agente un mensaje de error hacia la entidad gestora. En el resto de fichas, para las necesidades de este proyecto, no se hará prácticamente ninguna modificación: 41

42 o o o o o Capturas: se refiere a los traps (alarmas de eventos excepcionales) comentados en el capítulo anterior. Más adelante se explicará como se realizan estas alarmas sin tener que utilizar estos mensajes trampa. Dependencias: muestra los servicios que dependen del servicio SNMP; útil cuando se va a detener o reiniciar el proceso. General: muestra información sobre el servicio (nombre, descripción, estado, etc) Iniciar sesión: esto es útil si se tienen diferentes cuentas de acceso en la máquina gestionada, para habilitar o deshabilitar el servicio a cada una de las cuentas Recuperación: muestra una serie de opciones a realizar en caso de que el servicio no funcione (indicamos que se vuelva a reiniciar el servicio) Otro problema que surgió durante el desarrollo del proyecto, fue la disponibilidad de determinados datos en estos servidores. Con esta instalación, sólo se tiene acceso a los datos que ofrece la MIB estándar (MIB-II). Datos como el número de procesos o sesiones no se pueden obtener de esta MIB, por lo que fue necesario el uso y la instalación de dos MIBs nuevas: HOST-RESOURCES-MIB con OID y que como su propio nombre indica es una MIB especialmente dedicada a recursos de servidores. SNMP4W2K-WINDOWS-2000-PERFORMANCE con OID destinada a gestionar parámetros de máquinas con un S.O. Windows. Generalmente las MIBs suelen ser librerías dinámicas (.dll) o archivos de texto (.txt,.mib) que se encuentran en la carpeta C:\Windows\System32. En los sistemas Linux la gran mayoría son archivos con extensión.txt y se encuentran por defecto en la ruta /usr/share/snmp/mibs. Una vez configurados los agentes de los servidores Windows, lo siguiente es realizar pruebas para comprobar que tenemos conexión vía SNMP. Las pruebas se realizan utilizando desde la entidad gestora los comandos indicados para Linux, indicando en este caso el nombre de la comunidad que hayamos definido en los agentes de Windows (por motivos de seguridad no se menciona en este documento), e indicando también la dirección IP del servidor que queramos gestionar. Con todo esto, ya podemos administrar nuestros dispositivos. Surge un nuevo problema, y es que la solicitud y obtención de datos a través de la línea de comandos de Linux, no resulta muy atractiva y tampoco nos ofrece excesiva información. Es decir, por ejemplo, si solicitamos el espacio libre del disco duro de un servidor, este nos devolverá un número del tipo , lo cual no nos dice nada. Llega el momento de monitorizar los datos, y para ello lo haremos mediante gráficas, y más concretamente con el paquete de libre distribución MRTG. Su configuración e instalación, se detallan a continuación. 42

43 5.2 Instalación y configuración de MRTG Es una de las herramientas de monitorización de dispositivos más importantes para plataformas Linux. Se encuentra programado por Tobias Oetiker y Dave Rand en Perl y C. En el caso más general se utiliza tan sólo para monitorizar el tráfico en diferentes dispositivos, pero profundizando en su configuración, podemos representar todo aquello que el protocolo SNMP y las MIB nos ofrezcan (ó incluso datos que nos ofrezca otro programa externo). Los gráficos que genera, además de ofrecer una vista diaria, representan también la información de la última semana, último mes y último año. Esto es posible, gracias a que MRTG contiene un archivo donde recopila los datos obtenidos del dispositivo de red durante un tiempo máximo de 2 años. Al ser un software tan demandado y utilizado, muchas distribuciones Linux cuentan con esta librería, como es el caso de Debian. Como siempre para instalar los diferentes paquetes utilizaremos el comando apt-get y siendo superusuario (comando su ). Los paquetes necesarios son: mrtg ( ): contiene el propio programa mrtgutils (0.5): son las utilidades necesarias para que MRTG pueda generar las estadísticas mrtg-contrib ( ): archivos necesarios, por ser MRTG un programa libre, pero que depende de otros programas que no lo son sojos:/# apt-get install mrtg mrtgutils mrtg-contrib (fig. 28, instalación de los módulos necesarios para MRTG) MRTG suele basar su configuración en el archivo /etc/mrtg.cfg. Por normal general, en este archivo se guarda toda la configuración de todos los dispositivos. En nuestro caso, al tener un número importante de dispositivos a gestionar y sobre todo una gran cantidad de parámetros de cada uno, se decidió realizar un archivo de configuración por cada tipo de parámetro a administrar. De esta forma, en nuestra entidad gestora, en el directorio /etc/ nos encontramos los siguientes archivos de configuración: mrtgcpu.cfg: archivo de configuración referente a la tasa de CPU utilizada por cada servidor gestionado mrtgdiscos.cfg: aquí se configura el espacio libre en los discos duros de cada servidor gestionado mrtgfreemem.cfg: archivo de configuración sobre la memoria RAM disponible en cada servidor gestionado mrtgnumprocses.cfg: archivo de configuración referente al número de procesos en ejecución y el número de sesiones abiertas en cada servidor gestionado mrtgonoff.cfg: en este archivo se configura el estado de los servidores (encendido ó apagado) 43

44 mrtgredservers.cfg: desde aquí queda configurado el tráfico entrante/saliente de cada una de las interfaces de red de cada servidor (ya que hay servidores con más de una interfaz de red) mrtgroutercisco.cfg: configuración del tráfico de red entrante/saliente del router Cisco A continuación se detallarán cada uno de estos archivos. Para no hacer un documento muy pesado, no se presentará todo el archivo (ya que en determinados casos es muy repetitivo), sino lo más importante de cada uno. mrtgcpu.cfg ### Ultima actualizacion: 11/08/05 ### mrtgcpu.cfg - Archivo de configuracion para representar el porcentaje de uso de cpu en los servidores, tanto por usuario como por el sistema ### Global Config Options # for Debian WorkDir: /var/www/mrtg ### Global Defaults MaxBytes[_]: 100 Unscaled[_]: ymwd ShortLegend[_]: % YLengend[_]: Uso de CPU Legend1[_]: Usuario CPU % (Load) Legend2[_]: Sistema CPU % (Load) LegendI[_]: Usuario LegendO[_]: Sistema ThreshMaxO[_]: 99 ThreshProgO[_]: /home/rmartin/mrtg/alarmas/galarma ThreshProgOKO[_]: /home/rmartin/mrtg/alarmas/galarmaok Options[_]: growrigth,nopercent,unknaszero,gauge,noinfo WriteExpires: Yes Language: spanish EnableIPv6: no Interval: 5 Refresh: 300 ThreshDir: /home/rmartin/mrtg/alarmas/threshdir (fig. 29, opciones globales para el archive mrtgcpu.cfg) Las primeras líneas de cada uno de los archivos de configuración se utilizan para indicar la última modificación del archivo y una breve descripción de lo que contiene. La primera palabra clave que aparece es WorkDir. Aquí se especifica donde se crearán los archivos log (archivos de registro) y las páginas web. Las siguientes opciones, son opciones globales para todos los dispositivos que aparezcan a continuación. En MaxBytes, indicamos el valor máximo que los dos parámetros supervisados (ya que por cada gráfico podemos representar dos parámetros) pueden alcanzar. En este caso hemos indicado un valor de 100, ya que estamos gestionando la tasa de uso de CPU, que nos devolverá unos valores que oscilarán entre 0 y

45 Cada gráfico se escala verticalmente para hacer que los datos actuales sean visibles incluso cuando son muy inferiores a MaxBytes. Esto se puede suprimir utilizando la opción Unscaled. Se indican con una letra que gráfico no se quiere escalar (d=dia, w=semana, m=mes, y=año). Las siguientes 6 opciones, se refieren a las leyendas que aparecerán posteriormente en el documento HTML que contiene las gráficas. A continuación aparecen opciones más interesantes (el resto, son básicamente para configurar los gráficos). ThreshMaxO, este es el valor máximo aceptable para el parámetro Output o de salida (el segundo). En este caso cuando el parámetro Output supere el valor 99, se ejecutará el programa indicado en ThreshProgO. Cuando el parámetro Output, sea inferior a 99 se ejecutará el programa especificado en ThreshProgOKO. Para realizar lo mismo, pero con el primer parámetro (Input o de entrada), se utilizan ThreshMaxI, ThreshProgI y ThreshProgOKI. En Options, se indican otro tipo de opciones para los gráficos: growright, para conseguir que el gráfico se desplace de derecha a izquierda (el valor más actual a la derecha del gráfico, y los históricos a su izquierda); nopercent, no imprime los porcentajes en las gráficas. En este caso no tiene mucho sentido volver a indicar los porcentajes, ya que los datos que estamos representando son porcentajes. En el caso, por ejemplo, del espacio libre en el disco duro, sí nos puede interesar además del valor en sí, cuál es el porcentaje libre con respecto al total; unknaszero, en caso de que se obtuviera un valor desconocido se registraría como un 0 en vez de repetir el último valor, que es la opción por defecto; gauge, trata los valores obtenidos como medidas del estado actual y no como incrementos; noinfo, suprime la información sobre el tiempo en funcionamiento y nombre del dispositivo en la página web generada. Languaje, muestra las páginas web en el idioma que indiquemos (es=español). EnableIPv6, MRTG soporta la versión 6 del protocolo IP. Nuestra red, actualmente utiliza la versión 4, por lo que desactivamos esta opción. Interval, aquí se indica cada cuanto se testean o gestionan los datos, No se puede poner un valor inferior a 5 minutos (en parte es lógico, si estuviéramos testeando datos, por ejemplo cada minuto, podríamos saturar la red). Más adelante, comprobaremos que esto se puede especificar de otra forma. Refresh, número de segundos que tardará la página web en actualizarse (minímo 300 segundos). Threshdir, definiendo esta opción que apunta a un directorio escribible, MRTG solo alertará cuando se sobrepase algún límite del umbral. Por ejemplo, en este caso, si en un momento dado la CPU se satura y se obtiene un porcentaje de uso de 100, saltará la alarma, si en el próximo testeo (a los 5 minutos), sigue teniendo un uso de 100, no volverá a saltar. Esto es para evitar que se envíen gran cantidad de alarmas. Cuando el uso de CPU baje del umbral indicado (99), se enviará otra alarma (la especificada en ThreshProgOKO), indicando que el problema ya se encuentra resuelto. 45

46 A continuación se presentan las opciones dedicadas a cada servidor (figura 30). Como las opciones son similares, sólo se muestran las de los dos primeros servidores. ######################################################### # Tasa de CPU por usuario y sistema en el servidor NTSQL2 ######################################################### Target[ntsql2-cpu]: Title[ntsql2-cpu]: NTSQL2 - CPU LOAD PageTop[ntsql2-cpu]: <H1>NTSQL2 - CPU (Usuario y Sistema) Load %</H1> ########################################################## # Tasa de CPU por usuario y sistema en el servidor NTMail2 ########################################################## Target[ntmail2-cpu]: Title[ntmail2-cpu]: NTMail2 - CPU LOAD PageTop[ntmail2-cpu]: <H1>NTMAIL2 - CPU (Usuario y Sistema) Load %</H1> (fig. 30, implementación parcial del archivo de configuración mrtgcpu.cfg) En Target, se decide lo que debe monitorizar MRTG. En este caso, son dos OIDs en los que se encuentran el valor de uso de CPU por el usuario y por el sistema. El primero representa el valor de entrada (input) y el segundo el de salida (output). También hay que especificar el nombre de comunidad y la dirección IP del dispositivo. Entre corchetes se indica un nombre de etiqueta. Para este proyecto hemos decidido utilizar el nombre del servidor seguido del parámetro a gestionar. Title sirve para especificar el título de la página HTML generado para el gráfico, y PageTop para la cabecera de título. El resto de archivos tiene una configuración similar; a partir de ahora tan sólo se detallarán aquellas opciones nuevas que surjan y todo aquello que sea reseñable. mrtgdiscos.cfg ### Ultima actualizacion: 28/07/05 ### mrtgdiscos.cfg - Archivo de configuración para representar la capacidad de los discos duros ThreshMinO[_]: 10% ThreshProgO[_]: /home/rmartin/mrtg/alarmas/galarma ThreshProgOKO[_]: /home/rmartin/mrtg/alarmas/galarmaok ################################################################# # Espacio total y espacio libre del HD Datos del servidor NTMail2 ################################################################# Target[ntmail2-discoe]: `/home/rmartin/mrtg/snmpscripts/snmp_hdfree nombrecomunidad 4` MaxBytes[ntmail2-discoe]: ################################################################### 46

47 # Espacio total y espacio libre del HD Sistema del servidor NTMail2 ################################################################### Target[ntmail2-discoc]: `/home/rmartin/mrtg/snmpscripts/snmp_hdfree nombrecomunidad 2` MaxBytes[ntmail2-discoc]: (fig. 31, implementación parcial del archivo mrtgdiscos.cfg) Esto es parte del archivo de configuración, en el que se monitorizan por cada gráfica el espacio total de cada disco duro de cada servidor y el espacio libre. En este caso se utiliza la opción ThreshMinO, la alarma saltará cuando el valor obtenido sea menor que el indicado en esta opción. Vemos que el valor es un porcentaje, de esta forma conseguimos que las alarmas salten cuando quede menos del 10% de espacio libre. Para obtener los datos, en esta ocasión se utiliza un script. A la hora de utilizar scripts en Target hay que tener en cuenta que debe devolver cuatro valores: 1: el estado actual del parámetro de entrada (en este caso el espacio total) 2: el estado actual del parámetro de salida (el espacio libre) 3: el tiempo de funcionamiento del dispositivo 4: el nombre del dispositivo En la figura 32 se muestra el código del script (snmp_hdfree) al que se le pasa como parámetros la dirección IP del dispositivo, el nombre de comunidad y un índice. # Script para obtener el espacio libre del HD # Parametros de entrada: $1 direccion ip del dispositivo # $2 nombre de la comunidad de lectura del dispositivo # $3 indice del disco duro en el OID de la MIB #Obtener el espacio total HDTotal=`snmpget -v2c -c $2 $1 hrstoragesize.$3 gawk '{print $4}'` #Obtener el espacio usado HDUsado=`snmpget -v2c -c $2 $1 hrstorageused.$3 gawk '{print $4}'` #Obtener las unidades en las que se miden los datos anteriores Unidad=`snmpget -v2c -c $2 $1 hrstorageallocationunits.$3 gawk '{print $4}'` #Obtener el espacio total, ya multiplicado por las unidades espaciototal=$(((hdtotal)*unidad)) #Obtener el espacio libre espaciolibre=$(((hdtotal-hdusado)*unidad)) echo $espaciolibre echo $espaciototal #Obtener el tiempo de funcionamiento Tiempo=`snmpget -v2c -c $2 $1 sysuptime.0 gawk '{print $5, $6, $7}'` echo $Tiempo #Obtener el nombre de la máquina Nombre=`snmpget -v2c -c $2 $1 sysname.0 gawk '{print $4}'` echo $Nombre (fig. 32, implementación del script snmp_hdfree) mrtgfreemem.cfg ### Ultima actualizacion: 29/07/05 47

48 ### mrtgfreemem.cfg - Archivo de configuracion para representar la memoria libre de los servidores ThreshMinO[_]: 5% ThreshProgO[_]: /home/rmartin/mrtg/alarmas/galarma ThreshProgOKO[_]: /home/rmartin/mrtg/alarmas/galarmaok ########################## # Memoria libre en NTMail2 ########################## Target[ntmail2-freemem]: `/home/rmartin/mrtg/snmpscripts/snmp_winmemfree nombrecomunidad 6` Title[ntmail2-freemem]: NTMail2 - Memoria libre ########################## # Memoria libre en NTWeb ########################## Target[ntweb-freemem]: `/home/rmartin/mrtg/snmpscripts/snmp_winmemfree nombrecomunidad 6` Title[ntweb-freemem]: NTWeb - Memoria libre (fig. 33, implementación parcial del archive mrtgfreemem.cfg) En este caso se trata de monitorizar la memoria RAM disponible en cada ordenador. Como hay que representar dos parámetros, monitorizamos también la memoria total. Y de esta forma se generan las alarmas cuando la memoria libre se encuentre por debajo del 5% del total. Al igual que en el caso anterior, aquí también se obtienen los datos a través del siguiente script, representado en la figura 34. # snmp_winmemfree: script para obtener la memoria libre de un servidor windows # Parametros de entrada: $1 direccion ip del dispositivo # $2 nombre de la comunidad de lectura del dispositivo # $3 indice de la memoria RAM disponbile en el OID de la MIB total=`snmpget -v2c -c $2 $ gawk '{print $4}'` libre=`snmpget -v2c -c $2 $ $3 gawk '{print $4}'` echo $total echo $libre #Obtener el tiempo de funcionamiento Tiempo=`snmpget -v2c -c $2 $1 sysuptime.0 gawk '{print $5, $6, $7}'` echo $Tiempo #Obtener el nombre de la máquina Nombre=`snmpget -v2c -c $2 $1 sysname.0 gawk '{print $4}'` echo $Nombre (fig 34, implementación del script snmp_winmemfree) mrtgnumprocses.cfg ### Ultima actualizacion: 28/07/05 ### mrtgnumprocses.cfg - Archivo de configuracion para representar el numero de procesos y sesiones abiertas de los servidores 48

49 ###################################################################### ####################################### # Numero de procesos del sistema (hrsystemprocesses.0) # Numero de sesiones abiertas en el servidor NTMail2 (serverserversessions.0 - Cargado de la MIB perfmib.mib) # -Windows+SNMP+SNMP4tPC ###################################################################### ####################################### Target[ntmail2-procses]: MaxBytes[ntmail2-procses]: 100 (fig. 35, implementación parcial del archivo mrtgnumprocses.cfg) En este archivo (figura 35) se configuran los números de procesos en ejecución y sesiones abiertas en cada servidor. Obtenemos los datos a través de los OIDs, proporcionados por la MIB SNMP4W2K-WINDOWS-2000-PERFORMANCE implementada en el archivo perfmib.mib. En este caso, no se consideró necesario la gestión de alarmas, y el control de sus datos se realizará analizando las gráficas que genere. mrtgonoff.cfg ### Ultima actualizacion: 28/07/05 ### mrtgonoff.cfg - Archivo de configuración para representar el estado de los servidores: 1 encendido, 0 apagado ############################# # Estado del servidor NTMail2 ############################# Target[ntmail2-onoff]: `/home/rmartin/mrtg/snmpscripts/snmp_onoff nombrecomunidad` MaxBytes[ntmail2-onoff]: 1 (fig. 36, implementación parcial del archivo mrtgonoff.cfg) Aquí se monitoriza el estado de los servidores, si se encuentran encendidos o apagados. Como se puede ver la alarma se genera cuando se obtiene un valor menor que 1. Para conocer el estado del servidor, se ha creado un script que puede devolver dos valores: 1, si el servidor se encuentra encendido, 0 si se encuentra apagado. Por lo tanto en estas gráficas sólo se generarán dos valores 0 ó 1. En la figura 37 se muestra el script para la obtención de los valores. # Script que comprueba si un dispositivo se encuentra encendido o apagado # Parametros de entrada: $1 direccion ip del dispositivo # $2 nombre de la comunidad de lectura del dispositivo # Salida: 1 si esta encendido # 0 e.o.c # variable que nos indicara si el dispositivo se encuentra encendido (1) o # apagado (0) estado=0 # recoger lo que que devuelve la consulta snmpget 49

50 resultado=`snmpget -v2c -c $2 $1 system.sysuptime.0 gawk '{print $2}'` # si devuelve algo es porque el dispositivo se encuentra encendido if test $resultado then #si llego aqui es porque el dispositivo esta encendido estado=1 fi # Obtener dos veces el mismo parametro para que el MRTG pinte el mismo parametro de entrada y salida echo $estado echo $estado #Obtener el tiempo de funcionamiento Tiempo=`snmpget -v2c -c $2 $1 sysuptime.0 gawk '{print $5, $6, $7}'` echo $Tiempo #Obtener el nombre de la máquina Nombre=`snmpget -v2c -c $2 $1 sysname.0 gawk '{print $4}'` echo $Nombre (fig. 37, implementación del script para comprobar el estado, on/off, de un dispositivo) mrtgredservers.cfg mrtgroutercisco.cfg En estos dos archivos, se encuentra la configuración referente al tráfico de entrada/salida de cada una de las interfaces de los servidores y del router Cisco. Mientras que el resto de archivos se ha tenido que editar manualmente, para obtener el archivo de configuración de tráfico de red, MRTG presenta el siguiente comando: cfgmaker. En la figura 38, se muestra su utilización. sojos:/etc# cfgmaker >> mrtgroutercisco.cfg (fig. 38, utilización del comando cfgmaker) Vemos que hay que indicar el nombre de comunidad y el nombre o dirección IP del dispositivo a gestionar, y todo lo que genere se redirecciona a los archivos de configuración. ### Ultima actualizacion: 27/07/05 ### mrtgredservers.cfg - Archivo de configuración para representar el tráfico entrante/saliente en las interfaces de los servidores ##################################################################### # System: NTMAIL2 # Description: Hardware: x86 Family 6 Model 11 Stepping 1 AT/AT COMPATIBLE - Software: Windows Version 5.2 (Build 3790 Uniprocessor Free) # Contact: Carlos Sanchez # Location: Dpto. Informatico ###################################################################### ### Interface >> Descr: 'HP-NC3163-Fast-Ethernet-NIC' Name: '' Ip: ' ' Eth: ' f-b8' ### Target[ _65539]: 50

51 SetEnv[ _65539]: MRTG_INT_IP=" " MRTG_INT_DESCR="HP-NC3163-Fast-Ethernet-NIC" MaxBytes[ _65539]: Title[ _65539]: Análisis de Tráfico -- NTMAIL2 PageTop[ _65539]: <H1>Análisis de Tráfico -- NTMAIL2</H1> <TABLE> <TR><TD>System:</TD> <TD>NTMAIL2 in Dpto. Informatico</TD></TR> <TR><TD>Maintainer:</TD> <TD>Carlos Sanchez</TD></TR> <TR><TD>Description:</TD><TD>HP-NC3163-Fast-Ethernet-NIC </TD></TR> <TR><TD>ifType:</TD> <TD>ethernetCsmacd (6)</TD></TR> <TR><TD>ifName:</TD> <TD></TD></TR> <TR><TD>Max Speed:</TD> <TD>12.5 MBytes/s</TD></TR> <TR><TD>Ip:</TD> <TD> (ntmail2.cebancdea.edu)</td></tr> </TABLE> (fig. 39, implementación parcial del archivo mrtgredservers.cfg creado mediante el comando cfgmaker) Esta es una parte de lo generado en el archivo mrtgredservers.cfg tras utilizar el comando cfgmaker. A continuación se incluye una parte del archivo mrtgroutercisco.cfg ### Ultima actualizacion: 26/07/05 # Created by /usr/bin/cfgmaker ###################################################################### # System: C1600_CDEA # Description: Cisco Internetwork Operating System Software # IOS (tm) 1600 Software (C1600-Y-M), Version 12.0(12), RELEASE SOFTWARE (fc1) # Copyright (c) by cisco Systems, Inc. # Compiled Mon 10-Jul-00 19:59 by htseng # Contact: # Location: ###################################################################### ### Interface 1 >> Descr: 'Ethernet0' Name: 'Et0' Ip: ' ' Eth: '00-02-b9-1d-7e-50' ### Target[ _1]: SetEnv[ _1]: MRTG_INT_IP=" " MRTG_INT_DESCR="Ethernet0" MaxBytes[ _1]: Title[ _1]: Traffic Analysis for 1 -- C1600_CDEA PageTop[ _1]: <H1>Traffic Analysis for 1 -- C1600_CDEA</H1> <TABLE> <TR><TD>System:</TD> <TD>C1600_CDEA in </TD></TR> <TR><TD>Maintainer:</TD> <TD></TD></TR> <TR><TD>Description:</TD><TD>Ethernet0 JAC044368PU </TD></TR> <TR><TD>ifType:</TD> <TD>ethernetCsmacd (6)</TD></TR> <TR><TD>ifName:</TD> <TD>Et0</TD></TR> <TR><TD>Max Speed:</TD> <TD> kbytes/s</td></tr> <TR><TD>Ip:</TD> <TD> ()</TD></TR> </TABLE> ### Interface 2 >> Descr: 'Serial0' Name: 'Se0' Ip: '' Eth: '' ### 51

52 Target[ _2]: SetEnv[ _2]: MRTG_INT_IP="" MRTG_INT_DESCR="Serial0" MaxBytes[ _2]: Title[ _2]: Traffic Analysis for 2 -- C1600_CDEA PageTop[ _2]: <H1>Traffic Analysis for 2 -- C1600_CDEA</H1> <TABLE> <TR><TD>System:</TD> <TD>C1600_CDEA in </TD></TR> <TR><TD>Maintainer:</TD> <TD></TD></TR> <TR><TD>Description:</TD><TD>Serial0 </TD></TR> <TR><TD>ifType:</TD> <TD>frame-relay (32)</TD></TR> <TR><TD>ifName:</TD> <TD>Se0</TD></TR> <TR><TD>Max Speed:</TD> <TD>193.0 kbytes/s</td></tr> </TABLE> (fig. 40, implementación parcial del archivo mrtgroutercisco.cfg creado mediante el comando cfgmaker) En este extracto se ha incluido la configuración de dos de las bocas del router Cisco (Interface1 e Interface2). En todos los archivos de configuración, se tiene indicado que las variables ThreshProgI y ThresProgOKI (y análogamente ThreshProgO y ThreshProgOKO), ejecuten los programas externos galarma y galarmaok respectivamente. galarma se ejecutará cuando se produzca la alarma y galarmaok cuando el valor del parámetro vuelva a ser correcto. Estos dos scripts, básicamente lo que hacen es recoger los datos del MRTG (dispositivo-parametro, valor del umbral y el valor del parámetro actual), y los envía mediante el comando mail a las direcciones de correo que indiquemos (por ejemplo, a todo el departamento informático). En la figura 41 se muestra su código. # Script que recoge los datos del MRTG, y crea la alarma que se envia por correo en un archivo # (que tiene por nombre lo que contenga $1) # Parámetros de entrada: # $1: contiene el nombre del dispositivo gestionado y el parámetro que ha hecho generar la alarma # $2: contiene el valor del umbral del dispositivo y del parámetro indicados anteriormente # $3: contiene el valor actual del parametro del dispositivo gestionado, por el cual ha generado la alarma # # redireccionamos lo que genera la alarma del mrtg a un archivo (de nombre, lo que contenga $1) echo "problema en:" $1 "umbral sobrepasado:" $2 "dato actual:" $3 > /home/raul/mrtg/alarmas/$1 # enviamos el archivo a una direccion de correo electrónico mail -s "Alarma desde MRTG" < /home/raul/mrtg/alarmas/$1 (fig. 41, implementación del script galarma) El siguiente es el código del archivo galarmaok que funciona de manera similar al anterior: # Script que recoge los datos del MRTG, y crea la alarma de "problema solucionado" que se envia por correo en un archivo 52

53 # (que tiene por nombre lo que contenga $1) # Parámetros de entrada: # $1: contiene el nombre del dispositivo gestionado y el parámetro para el que se ha solucionado la alarma # $2: contiene el valor del umbral del dispositivo y del parámetro indicados anteriormente # $3: contiene el valor actual del parametro del dispositivo gestionado # # redireccionamos lo que genera la alarma del mrtg a un archivo echo "problema solucionado en:" $1 "umbral:" $2 "dato actual:" $3 > /home/raul/mrtg/alarmas/$1 # enviamos el archivo a una direccion de correo electrónico mail -s "Alarma CORREGIDA desde MRTG" < /home/raul/mrtg/alarmas (fig. 42, implementación del script galarmaok) Hasta aquí, se ha conseguido que las alarmas que se generen se envíen por correo electrónico. Otra de las capacidades con las que se quiere dotar al sistema de gestión, es la de que se puedan enviar también mediante SMS a un teléfono móvil. Esto se explicará en el último punto de este capítulo. Una vez que tenemos todos los archivos configurados, lo siguiente es compilarlos con el comando mrtg (fig. 5.34). De esta forma, en caso de que hubiese algún error en alguno de los archivos, nos lo mostraría. Si los archivos están correctamente, la primera vez que se haga esto, aparecerán unos cuantos mensajes Warning. Ejecutaremos el mismo comando hasta que no aparezcan. sojos:/etc# mrtg mrtgnumprocses.cfg sojos:/etc# mrtg mrtgroutercisco.cfg sojos:/etc# mrtg mrtgcpu.cfg... (fig. 43, compilación de los archivos de configuración) Y de esta misma manera, realizaríamos la compilación del resto de archivos de configuración. Ahora podemos comprobar que se nos han generado las páginas web, en el directorio indicado en los archivos de configuración (WorkDir: /var/www/mrtg). Se habrán generado archivos html con el nombre que hayamos utilizado en las etiquetas dentro de los archivos de configuración (Ej: ntsql2-cpu.html, ntmail2-cpu.html, ntsql2- disco.html, etc.) A partir de ahora el mrtg se ejecutará en cada archivo el tiempo que hayamos indicado en cada variable Interval. Podemos comprobarlo, viendo que se ha añadido en el archivo mrtg dentro de /etc/cron.d. Aquí encontraremos todas aquellas tareas que se ejecuten periódicamente (figura 44). sojos:/etc/cron.d# more mrtg 0-55/5 * * * * mrtg /etc/mrtg.cfg >> /var/log/mrtg/mrtg.log 0-55/5 * * * * mrtg /etc/mrtgdiscos.cfg >> /var/log/mrtg/mrtgdiscos.log 53

54 0-55/5 * * * * mrtg /etc/mrtgnumprocses.cfg >> /var/log/mrtg/mrtgnumprocses.log 0-55/5 * * * * mrtg /etc/mrtgredservers.cfg >> /var/log/mrtg/mrtgredservers.log 0-55/5 * * * * mrtg /etc/mrtgroutercisco.cfg >> /var/log/mrtg/mrtgroutercisco.log 0-55/5 * * * * mrtg /etc/mrtgfreemem.cfg >> /var/log/mrtg/mrtgfreemem.log 0-55/5 * * * * mrtg /etc/mrtgcpu.cfg >> /var/log/mrtg/mrtgcpu.log 0-55/5 * * * * mrtg /etc/mrtgonoff.cfg >> /var/log/mrtg/mrtgonoff.log (fig. 44, tareas a realizar de manera periódica) Como se puede observar, cada comando mrtg genera una salida que se redirecciona a unos ficheros de registro (.log). En caso de que sucediera algún problema a la hora de invocar el comando mrtg podremos revisar estos archivos, para detectar más fácilmente los errores. En este proyecto el número de páginas html que se generan es bastante amplio, una por cada dispositivo/parámetro. Mediante el comando indexmaker podemos agrupar todas estas páginas, en una sola. En este caso se han recogido en función del tipo de parámetro, es decir, se mostrará una página web con todos los tráficos de red, otra con los espacios libres de los discos de los servidores, etc. El comando se utiliza como se indica en la figura 45. sojos:/etc# indexmaker mrtgcpu.cfg > /var/www/mrtg/cpu.html (fig. 45, utilización del comando indexmaker) De esta manera, conseguimos agrupar todas las gráficas que se generan a partir de mrtgcpu.cfg en el archivo cpu.html. El resto de páginas creadas, se listan a continuación: discos.html freemem.html numprocses.html onoff.html redservsers.html routercisco.html A su vez, se ha creado otra página web índice (en /var/www/mrtg/index.html) para poder acceder a esas 7 páginas web (figura 46). 54

55 (fig. 46, Menú principal de acceso a las gráficas) Desde este menú podremos acceder de forma cómoda a las gráficas generadas. Pinchando en uno de los enlaces obtendríamos las gráficas, similares a las que se muestran en la figura 47. Pulsando con el ratón sobre cada una de estas gráficas, obtendríamos más detalles, como el histórico semanal, mensual y anual, además de los valores de los datos actuales, medios y máximos de cada gráfica (figura 48). Con todo esto, ya tendríamos funcionando nuestras gráficas monitorizando los dispositivos y parámetros que se han indicado. En este momento, sólo tenemos acceso a las gráficas desde la propia entidad gestora. Se quiere que se puedan acceder también desde otras máquinas, por ejemplo, desde todos los ordenadores del departamento de informática. Esto se detalla en el siguiente punto. 55

56 (fig. 47, vista global de las gráficas) Numero de procesos y sesiones en NTSQL2 Gráfico diario (5 minutos : Promedio) Máx Procesos 48 Promedio Procesos 45 Actual Procesos 45 Máx Sesiones 25 Promedio Sesiones 9 Actual Sesiones 23 Gráfico semanal (30 minutos : Promedio) Máx Procesos 47 Promedio Procesos 47 Actual Procesos 45 56

57 Máx Sesiones 26 Promedio Sesiones 7 Actual Sesiones 22 Gráfico mensual (2 horas : Promedio) Máx Procesos 48 Promedio Procesos 47 Actual Procesos 45 Máx Sesiones 24 Promedio Sesiones 5 Actual Sesiones 11 Gráfico anual (1 día : Promedio) Máx Procesos 48 Promedio Procesos 45 Actual Procesos 46 Máx Sesiones 9 Promedio Sesiones 4 Actual Sesiones 8 VERDE ### AZUL ### Numero de procesos Numero de sesiones abiertas (fig. 48, vista detallada de las gráficas) 5.3 Instalación y configuración del servidor HTTP, Apache Para ello, utilizamos el comando apt-get, ya que esta librería se encuentra disponible en la distribución de Debian. apt-get install apache2 (fig. 5.49, instalación del módulo apache2) Una vez instalado el servidor web, se procede a realizar su configuración. Como se ha dicho, para esta versión de Apache, el archivo httpd.conf se ha simplificado bastante. Muchas de las opciones que incluía este archivo, en la nueva versión han pasado a /etc/apache2/sites-available/default. En este archivo introduciremos varias reglas de seguridad: acceso a las gráficas restringidas por IP (indicaremos qué máquinas tienen acceso a las gráficas, mediante su dirección IP) acceso restringido por usuario y password (también se deberán de indicar para el acceso un nombre de usuario y un password) Para restringir el acceso por IP, introducimos las siguientes líneas en el archivo de configuración, como se muestra en la siguiente figura. 57

58 <Directory /var/www/> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from allow from allow from # This directive allows us to have apache2's default start # page # in /apache2-default/, but still have / go to the right # place RedirectMatch ^/$ /mrtg/ </Directory> (fig. 50, configuración de apache2, permisos de acceso por IP) Con la directiva allow from seguida de una dirección IP, damos permiso de acceso a la máquina con esa IP. A continuación, crearemos un usuario y una contraseña para poder acceder a las gráficas, utilizando el comando htpasswd2 (figura 51). sojos:/etc/init.d# htpasswd2 c /etc/apache2/usuarios adminet New password Re-type new password Adding password for user adminet (fig. 51, utilización del comando htpasswd2) Hay que indicar en el comando, el archivo en el que se guardará el usuario, y su nombre de acceso. Luego se solicitará el password para ese usuario. También añadiremos las siguientes líneas en el archivo de configuración default (figura52). <Directory /var/www/> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from allow from allow from AuthType Basic AuthName adminet AuthUserFile /etc/apache2/usuarios Require valid-user # This directive allows us to have apache2's default start # page # in /apache2-default/, but still have / go to the right # place RedirectMatch ^/$ /mrtg/ </Directory> (fig. 52, configuración de apache2, autorizaciones) Se añade, el tipo de autorización, el usuario y el archivo donde se encuentra ese nombre de usuario (podemos tener también más de un usuario con acceso). 58

59 De esta forma, cada vez que se quiera acceder a las gráficas desde alguna de las máquinas que hemos señalado en el archivo de configuración, se solicitará también un nombre de usuario y un password (figura 53). (fig. 53, menú de acceso a las gráficas) En este archivo de configuración aparece también otra directiva, DocumentRoot, en la que se debe indicar la raiz de las páginas web a mostrar. Para este proyecto, recordar que se hizo un índice y que se encuentra en /var/www/mrtg. DocumentRoot /var/www/mrtg Con esto, finalizamos la configuración del servidor Apache2. Contiene muchas más opciones, pero para este proyecto nos sirve con las restricciones añadidas. 5.4 Instalación y configuración de Gnokii Llegamos al último paso de este proyecto. Nuestro sistema hasta ahora es capaz de monitorizar los dispositivos y parámetros que ya se han indicado, y de enviar alertas a través del correo electrónico cuando se suceden determinados eventos excepcionales. Se solicitó que el sistema de gestión fuera capaz de enviar estas alertas por medio de un SMS a un teléfono móvil. Veremos como realizar este paso, de una manera muy sencilla. Para ello, necesitaremos un teléfono móvil conectado a nuestra entidad gestora, y un software que sea capaz de comunicarlos: Gnokii. 59

II. Gestión de Red en Internet

II. Gestión de Red en Internet 1. Introducción a la gestión de red en Internet. 2. Marco de la gestión de red en Internet. 3. Estructura de la información de gestión. 3.1. Estructura de la MIB. 3.2. Sintaxis de objetos. 3.3. Acceso

Más detalles

MIB: Descripción Base de Información para Gestión Management Information Base MIB OSI SNMP MIB MIB CMIP SNMP ASN.1

MIB: Descripción Base de Información para Gestión Management Information Base MIB OSI SNMP MIB MIB CMIP SNMP ASN.1 MIB: Descripción La Base de Información para Gestión (Management Information Base o MIB) es un tipo de base de datos que contiene información jerárquica, estructurada en forma de árbol, de todos los dispositivos

Más detalles

SNMP: Conceptos. Carlos Vicente Servicios de Red Universidad de Oregón

SNMP: Conceptos. Carlos Vicente Servicios de Red Universidad de Oregón SNMP: Conceptos Carlos Vicente Servicios de Red Universidad de Oregón Necesidad de una arquitectura En una red heterogénea, es necesario definir (y estandarizar) una serie de elementos para su fácil gestión:

Más detalles

Modelo de gestión de Internet

Modelo de gestión de Internet Modelo de gestión de Internet 1 Premisa de diseño Si la gestión de red es esencial entonces debe implantarse en todos los recursos de la red. Consecuencia: - El impacto al añadir la gestión a un nodo debe

Más detalles

Implementación de Software de Administración de Redes basado en Java

Implementación de Software de Administración de Redes basado en Java Implementación de Software de Administración de Redes basado en Java GestionRedesCisco2.0 Jorge Rabanal García, Electronic Engineer Student Francisco Alonso Villalobos, Electronic Engineer Escuela de Ingeniería

Más detalles

TEMA 29 LOS PROTOCOLOS DE GESTIÓN. TCP/IP Y SNMP. OSI Y CMIS/CMIP. RMON.

TEMA 29 LOS PROTOCOLOS DE GESTIÓN. TCP/IP Y SNMP. OSI Y CMIS/CMIP. RMON. TEMA 29 LOS PROTOCOLOS DE GESTIÓN. TCP/IP Y SNMP. OSI Y CMIS/CMIP. RMON. Introducción... 1 TCP/IP Y SNMP... 2 Administración...3 Seguridad...3 Ventajas de SNMP...3 Desventajas de SNMP...3 Las versiones

Más detalles

SNMP. (Simple Network Management Protocol)

SNMP. (Simple Network Management Protocol) SNMP (Simple Network Management Protocol) SNMP es un protocolo de la capa de aplicación del modelo de protocolos TCP/IP diseñado para el intercambio de información de administración de los dispositivos

Más detalles

INSTITUTO POLITÉCNICO NACIONAL

INSTITUTO POLITÉCNICO NACIONAL INSTITUTO POLITÉCNICO NACIONAL ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y ELÉCTRICA UNIDAD ADOLFO LÓPEZ MATEOS - ZACATENCO ACADEMIA DE COMPUTACIÓN LABORATORIO DE DESARROLLO DE REDES SEMINARIO DE REDES PRACTICA

Más detalles

Mediciones pasivas. Performance de redes Instituto de Ingeniería Eléctrica, Universidad de la República 2005.

Mediciones pasivas. Performance de redes Instituto de Ingeniería Eléctrica, Universidad de la República 2005. Mediciones pasivas en elementos de red Agenda: Simple Network Managment Protocol (SNMP) Multi-Router Traffic Grapher (MRTG) Cisco NetFlow SNMP Protocolo de capa de aplicación. Permite intercambio de información

Más detalles

SNMP Simple Network Management Protocol

SNMP Simple Network Management Protocol Simple Network Management Protocol Protocolo de gestión remota de dispositivos Managed Node Agent Mnged Object Management Protocol Managed Node Agent Mnged Object NMS Managed Node Agent Mnged Object Managed

Más detalles

INDICE. GetBulkRequest... 14 InformRequest... 14

INDICE. GetBulkRequest... 14 InformRequest... 14 SNMP PROTOCOL 1 INDICE (SNMP)SIMPLE NETWORK MANAGEMENT PROTOCOL... 3 Componentes Básicos de SNMP:... 3 Comandos Básicos SNMP:... 4 Management Information Base (MIB)... 5 Tablas MIB SNMP... 6 Operaciones

Más detalles

III Encuentro Científico Internacional de Invierno

III Encuentro Científico Internacional de Invierno III Encuentro Científico Internacional de Invierno Implementación de un Sistema de Gestión de QoS mediante SNMP sobre Software Libre Ing. Ronald Paucar C. rpaucar@utp.edu.pe Lima, 31 de Julio del 2004

Más detalles

ADMINISTRACIÓN DE REDES. Ing. Camilo Zapata czapata@udea.edu.co Universidad de Antioquia

ADMINISTRACIÓN DE REDES. Ing. Camilo Zapata czapata@udea.edu.co Universidad de Antioquia ADMINISTRACIÓN DE REDES. Ing. Camilo Zapata czapata@udea.edu.co Universidad de Antioquia SNMP Es un protocolo del nivel de Capa de Aplicación. Proporciona un formato de mensajes para el intercambio de

Más detalles

TCP/IP. IRI 2 do cuatrimestre 2015

TCP/IP. IRI 2 do cuatrimestre 2015 TCP/IP IRI 2 do cuatrimestre 2015 Redes y Protocolos Una red es un conjunto de computadoras o dispositivos que pueden comunicarse a través de un medio de transmisión en una red. Los pedidos y datos de

Más detalles

Anexo A. SNMP: Simple Network Management Protocol. BBDD: Base de Datos. MIB: Management Information Base.

Anexo A. SNMP: Simple Network Management Protocol. BBDD: Base de Datos. MIB: Management Information Base. Anexo A Acrónimos SNMP: Simple Network Management Protocol. BBDD: Base de Datos. MIB: Management Information Base. CORBA: Common Object Request Broker Arquitecture. NETCONF: Network Configuration Protocol.

Más detalles

UNIVERSIDAD LUTERANA SALVADOREÑA FACULTAD DE CIENCIAS DEL HOMBRE Y LA NATURALEZA

UNIVERSIDAD LUTERANA SALVADOREÑA FACULTAD DE CIENCIAS DEL HOMBRE Y LA NATURALEZA UNIVERSIDAD LUTERANA SALVADOREÑA FACULTAD DE CIENCIAS DEL HOMBRE Y LA NATURALEZA CARRERA: LIC. CIENCIAS DE LA COMPUTACIÓN CÁTEDRA: REDES I CATEDRÁTICO: ING. MANUEL FLORES VILLATORO PROYECTO: MONITOREO

Más detalles

UNIVERSIDAD LUTERANA SALVADOREÑA FACULTAD DE CIENCIAS DEL HOMBRE Y LA NATURALEZA. Cátedra: Ciencias del hombre y la naturaleza Redes I

UNIVERSIDAD LUTERANA SALVADOREÑA FACULTAD DE CIENCIAS DEL HOMBRE Y LA NATURALEZA. Cátedra: Ciencias del hombre y la naturaleza Redes I UNIVERSIDAD LUTERANA SALVADOREÑA FACULTAD DE CIENCIAS DEL HOMBRE Y LA NATURALEZA LICENCIATURA EN CIENCIAS DE LA COMPUTACION Cátedra: Ciencias del hombre y la naturaleza Redes I Trabajo de Investigación:

Más detalles

SNMP. Dr. Víctor J. Sosa Sosa. Protocolo SNMPv1

SNMP. Dr. Víctor J. Sosa Sosa. Protocolo SNMPv1 SNMP Dr. Víctor J. Sosa Sosa Antecedentes En la primera etapa de ARPANET se comprendió que cuando había problemas con la red, la única forma de identificar el problema era ejecutando comandos muy simples

Más detalles

Monitoreo de redes Agentes SNMP

Monitoreo de redes Agentes SNMP Monitoreo de redes Agentes SNMP Ing. Diego Córdoba www.linuxinstitute.com.ar Pagina 1 de 7 Las variables SNMP Las variables almacenadas en la MIB se identifican y definen según una serie de reglas llamadas

Más detalles

CAPITULO III. TECNOLOGÍA SNMP

CAPITULO III. TECNOLOGÍA SNMP CAPITULO III. TECNOLOGÍA SNMP En este capitulo haremos una presentación sobre la estructura básica del protocolo de monitoreo SNMP. El objetivo de este protocolo es poder realizar un monitoreo del estado

Más detalles

CAPITULO IV PRUEBAS Y RESULTADOS DE LA HERRAMIENTA DE GESTIÓN DE REDES VIRTUALES.

CAPITULO IV PRUEBAS Y RESULTADOS DE LA HERRAMIENTA DE GESTIÓN DE REDES VIRTUALES. CAPITULO IV PRUEBAS Y RESULTADOS DE LA HERRAMIENTA DE GESTIÓN DE REDES VIRTUALES. INTRODUCCIÓN En el campo de las tecnologías de información la tendencia más importante en este momento la constituyen los

Más detalles

SNMP GRUPO 5: MARTÍN DOS SANTOS MORAES JONATHAN MAIA ARIEL RAMIREZ LUIS JURADO TAPIA

SNMP GRUPO 5: MARTÍN DOS SANTOS MORAES JONATHAN MAIA ARIEL RAMIREZ LUIS JURADO TAPIA SNMP GRUPO 5: MARTÍN DOS SANTOS MORAES JONATHAN MAIA ARIEL RAMIREZ LUIS JURADO TAPIA INTRODUCCIÓN SNMP IETF(Internet Engenering Task Force) Sus fines INTRODUCCIÓN SNMP Fue Desarrolado por el IETF (Internet

Más detalles

INSTALACIÓN Y CONFIGURACIÓN DE UN AGENTE DE GESTIÓN SNMPV3

INSTALACIÓN Y CONFIGURACIÓN DE UN AGENTE DE GESTIÓN SNMPV3 INSTALACIÓN Y CONFIGURACIÓN DE UN AGENTE DE GESTIÓN SNMPV3 JUDIT DE LA CALZADA CUESTA RUBÉN FRÍAS SIMÓN LAURA DE LA PARRA JIMÉNEZ Resumen En este documento se va a abordar el problema de la gestión de

Más detalles

SNMP funciona bajo TCP/IP, lo cual significa que desde un sistema central se puede gestionar cualquier ordenador de la LAN, WAN o internet.

SNMP funciona bajo TCP/IP, lo cual significa que desde un sistema central se puede gestionar cualquier ordenador de la LAN, WAN o internet. Monitorización gráfica del tráfico de red y otros parámetros del sistema Joaquín Garzón Alcalde En este artículo se explica como monitorizar de forma gráfica determinados parámetros del sistema como el

Más detalles

Proyecto Free-Love Scanner

Proyecto Free-Love Scanner Proyecto Free-Love Scanner Documentación Por Richie (luckyr13) 08 2 Cualquier duda o comentario asi como si quieres utilizar parcial o totalmente el código favor de comentarlo a: richie.isc@hotmail.com

Más detalles

Redes de Ordenadores Curso 2001-2002 4º Ingenieria Superior Informática Campus Ourense- Universidad de Vigo

Redes de Ordenadores Curso 2001-2002 4º Ingenieria Superior Informática Campus Ourense- Universidad de Vigo TEMA 9 GESTIÓN DE RED Dos orientaciones: Análisis básico de las actividades de una gestión de red Análisis básico de las herramientas de gestión de red y SNMP. 9.1. Actividades de una gestión de red. Un

Más detalles

En 1993 se unifican estas dos aproximaciones --> SNMPv2.

En 1993 se unifican estas dos aproximaciones --> SNMPv2. GESTIÓN INTERNET 2.6 SNMPv2 2.6.1 Antecedentes Las limitaciones de SNMP llevan a la definición en 1992 de dos nuevos protocolos: S-SNMP (SNMP seguro) que añade seguridad al protocolo SNMP y SMP (Simple

Más detalles

Práctica 1 Configuración de un agente de gestión

Práctica 1 Configuración de un agente de gestión it 1) Objetivos o Conocer los parámetros de configuración de un agente: comunidad, vistas, acceso y valores de objetos de MIBs del sistema. o Familiarizarse con las operaciones soportadas por SNMPv1: snmpget,

Más detalles

Este documento es producto de trabajo realizado por Network Startup Resource Center (NSRC at http://www.nsrc.org). Este documento puede ser

Este documento es producto de trabajo realizado por Network Startup Resource Center (NSRC at http://www.nsrc.org). Este documento puede ser Este documento es producto de trabajo realizado por Network Startup Resource Center (NSRC at http://www.nsrc.org). Este documento puede ser libremente copiado o re-utilizado con la condicion de que toda

Más detalles

Tema 1: Introducción a la gestión y planificación de redes

Tema 1: Introducción a la gestión y planificación de redes Tema 1: Introducción a la gestión y planificación de redes 1. Introducción general 2. Objetivos de la gestión de redes 3. Objetivos de la planificación de redes 4. Sistemas de gestión de red Gestión de

Más detalles

Simple Network Management Protocol

Simple Network Management Protocol Simple Network Management Protocol Departamento de Sistemas Telemáticos y Computación (GSyC) http://gsyc.urjc.es Diciembre de 2013 GSyC - 2013 Simple Network Management Protocol 1 c 2013 GSyC Algunos derechos

Más detalles

Ejercicio de aprendizaje con MIB-Browser.

Ejercicio de aprendizaje con MIB-Browser. Ejercicio de aprendizaje con MIB-Browser. 1.- Objetivo El alumno analizará y explorará el significado y utilidad de los diferentes objetos de la MIB-II, consultando los valores a un agente SNMP con ayuda

Más detalles

Gestión. Area de Ingeniería Telemática http://www.tlm.unavarra.es. Grado en Ingeniería en Tecnologías de Telecomunicación, 4º

Gestión. Area de Ingeniería Telemática http://www.tlm.unavarra.es. Grado en Ingeniería en Tecnologías de Telecomunicación, 4º Gestión y Planificación de Redes y Servicios Gestión Area de Ingeniería Telemática http://www.tlm.unavarra.es Grado en Ingeniería en Tecnologías de Telecomunicación, 4º Ejemplo En línea de comandos con

Más detalles

Gestión de red en Linux con SNMP

Gestión de red en Linux con SNMP Gestión de red en Linux con SNMP Documento extraído de los artículos: - Gestión SNMP con Linux por Javier Fernández-Sanguino Peña - Administración y mantenimiento de redes con Linux por David Guerrero

Más detalles

Router Teldat. Agente SNMP

Router Teldat. Agente SNMP Router Teldat Agente SNMP Doc. DM512 Rev. 8.40 Septiembre, 2000 ÍNDICE Capítulo 1 Introducción al protocolo SNMP... 1 1. Introducción...2 2. Tipos de paquetes SNMP...3 3. Autenticación...4 Capítulo 2 Configuración

Más detalles

Soporte de MIB para DistributedDirector

Soporte de MIB para DistributedDirector Descargue este capítulo Descargue el libro completo Guía de configuración de la administración del Cisco IOS Network, versión 122SR (PDF - 8 MB) Feedback Contenidos Descripción general de características

Más detalles

Figura 1: Ciclo de la Administración del desempeño

Figura 1: Ciclo de la Administración del desempeño 1 INTRODUCCIÓN El servicio de acceso a Internet de la Escuela Politécnica Nacional, no cubre las expectativas de los usuarios finales debido a que los tiempos de respuesta, la disponibilidad y la seguridad

Más detalles

Capas del Modelo ISO/OSI

Capas del Modelo ISO/OSI Modelo ISO/OSI Fue desarrollado en 1984 por la Organización Internacional de Estándares (ISO), una federación global de organizaciones que representa aproximadamente a 130 países. El núcleo de este estándar

Más detalles

Gestión de Redes TCP/IP basada en RMON. Dra. Ing. Caridad Anías Calderón Cujae cacha@tesla.cujae.edu.cu

Gestión de Redes TCP/IP basada en RMON. Dra. Ing. Caridad Anías Calderón Cujae cacha@tesla.cujae.edu.cu Gestión de Redes TCP/IP basada en RMON Dra. Ing. Caridad Anías Calderón Cujae cacha@tesla.cujae.edu.cu Aspectos a tratar Introducción Características de RMON Ventajas del empleo de RMON Versiones de RMON

Más detalles

GLOSARIO DE TÉRMINOS CUALIFICACIÓN PROFESIONAL: OPERACIÓN DE REDES DEPARTAMENTALES. Código: IFC299_2 NIVEL: 2

GLOSARIO DE TÉRMINOS CUALIFICACIÓN PROFESIONAL: OPERACIÓN DE REDES DEPARTAMENTALES. Código: IFC299_2 NIVEL: 2 MINISTERIO DE EDUCACIÓN, CULTURA Y DEPORTE SECRETARÍA DE ESTADO DE EDUCACIÓN, FORMACIÓN PROFESIONAL Y UNIVERSIDADES DIRECCIÓN GENERAL DE FORMACIÓN PROFESIONAL INSTITUTO NACIONAL DE LAS CUALIFICACIONES

Más detalles

Un poco más acerca de SNMP

Un poco más acerca de SNMP Un poco más acerca de SNMP Management Information Base (MIB): Todo recurso de red gestionable debe ser representado a través de un objeto El conjunto de todas las variables conocidas por un agente es la

Más detalles

INTEROPERABILIDAD ENTRE LOS MARCOS DE GESTION SNMP Y CORBA (GATEWAY)

INTEROPERABILIDAD ENTRE LOS MARCOS DE GESTION SNMP Y CORBA (GATEWAY) UNIVERSIDAD CENTROCCIDENTAL LISANDRO ALVARADO DECANATO DE CIENCIA Y TECNOLOGIA MAESTRIA CIENCIA DE LA COMPUTACION MENCION REDES DE COMPUTADORAS INTEROPERABILIDAD ENTRE LOS MARCOS DE GESTION SNMP Y CORBA

Más detalles

LA ARQUITECTURA TCP/IP

LA ARQUITECTURA TCP/IP LA ARQUITECTURA TCP/IP Hemos visto ya como el Modelo de Referencia de Interconexión de Sistemas Abiertos, OSI-RM (Open System Interconection- Reference Model) proporcionó a los fabricantes un conjunto

Más detalles

En este capítulo se proporciona una visión general de las redes de computadores. Así, se presenta una descripción general de las comunicaciones de

En este capítulo se proporciona una visión general de las redes de computadores. Así, se presenta una descripción general de las comunicaciones de En este capítulo se proporciona una visión general de las redes de computadores. Así, se presenta una descripción general de las comunicaciones de datos y la tipología de redes que se emplean. Además este

Más detalles

SNMP: Simple Network Management Protocol

SNMP: Simple Network Management Protocol SNMP: Simple Network Management Protocol Patricio E. Valle Vidal pvalle@elo.utfsm.cl Profesor: Tomás Arredondo V. 20 de Agosto 2007 : Redes de Computadores I (ELO-322) CONTENIDOS Problema Introducción

Más detalles

PRÁCTICA 3A Administración con SNMP

PRÁCTICA 3A Administración con SNMP PRÁCTICA 3A Administración con SNMP 1.- Objetivo de aprendizaje El alumno analizará y explorará el significado y utilidad de los diferentes objetos de la MIB-II, consultando los valores a un agente SNMP

Más detalles

GESTIÓN DE REDES PARTE II

GESTIÓN DE REDES PARTE II PARTE II Arquitectura de Gestión de Internet 2.1 Introducción El desarrollo de SNMP ha estado ligado al de TCP/IP. TCP/IP nace con la ARPANET desarrollada por el DoD. Sus estándares están publicados en

Más detalles

UNIVERSIDADE DA CORUÑA FACULTADE DE INFORMÁTICA LABORATORIO DE GESTIÓN DE REDES: HERRAMIENTA NET-SNMP (PARTE II)

UNIVERSIDADE DA CORUÑA FACULTADE DE INFORMÁTICA LABORATORIO DE GESTIÓN DE REDES: HERRAMIENTA NET-SNMP (PARTE II) UNIVERSIDADE DA CORUÑA FACULTADE DE INFORMÁTICA LABORATORIO DE GESTIÓN DE REDES: HERRAMIENTA NET-SNMP (PARTE II) 1. PRÁCTICA 4: EL AGENTE Net-SNMP 1.1. Objetivos - Conocer los parámetros de configuración

Más detalles

SISTEMA SNMP DE SUPERVISION REMOTA

SISTEMA SNMP DE SUPERVISION REMOTA SISTEMA SNMP DE SUPERVISION REMOTA SISTEMA AVANZADO DE SUPERVISIÓN REMOTA INTRODUCCION VIMESA ha diseñado e implementado un sistema de gestión remota SNMP mediante conexión GPRS o LAN para centros emisores

Más detalles

Configuración del acceso a Internet en una red

Configuración del acceso a Internet en una red Configuración del acceso a Internet en una red Contenido Descripción general 1 Opciones para conectar una red a Internet 2 Configuración del acceso a Internet utilizando un router 12 Configuración del

Más detalles

Un poco más acerca de SNMP SNMP SMI. SNMP SMI: Ejemplo. Tipos de datos. Tiposde datosde un objeto OBJECT-TYPE MODULE-IDENTITY:

Un poco más acerca de SNMP SNMP SMI. SNMP SMI: Ejemplo. Tipos de datos. Tiposde datosde un objeto OBJECT-TYPE MODULE-IDENTITY: Un poco más acerca de SNMP Information Base (MIB): Todo recurso de red gestionable debe ser representado a través de un objeto El conjunto de todas las variables conocidas por un agente es la MIB de este

Más detalles

UNIVERSIDAD CENTROCCIDENTAL "LISANDRO ALVARADO" DECANATO DE CIENCIAS Y TECNOLOGIA MAESTRIA EN CIENCIAS DE LA COMPUTACION MENCION REDES DE COMPUTADORAS

UNIVERSIDAD CENTROCCIDENTAL LISANDRO ALVARADO DECANATO DE CIENCIAS Y TECNOLOGIA MAESTRIA EN CIENCIAS DE LA COMPUTACION MENCION REDES DE COMPUTADORAS UNIVERSIDAD CENTROCCIDENTAL "LISANDRO ALVARADO" DECANATO DE CIENCIAS Y TECNOLOGIA MAESTRIA EN CIENCIAS DE LA COMPUTACION MENCION REDES DE COMPUTADORAS MODELO DE GESTION WBEM PARA ADMINISTRACION DE REDES

Más detalles

PRÁCTICA Nº. 1: Familiarización con el gestor de red MIB Browser.

PRÁCTICA Nº. 1: Familiarización con el gestor de red MIB Browser. PRÁCTICAS DE GESTIÓN DE RED. PRÁCTICA Nº. 1: Familiarización con el gestor de red MIB Browser. 1. Descubrimiento automático de la red. Se trata de descubrir las máquinas que forman parte del dominio de

Más detalles

Monitorización de sistemas y servicios

Monitorización de sistemas y servicios Monitorización de sistemas y servicios Contenidos Contenidos... 1 Resumen ejecutivo... 2 Arquitectura de la plataforma de monitorización... 2 Monitorización y alarmas... 3 Monitorización... 3 Servicios

Más detalles

Arquitectura de Redes y Comunicaciones

Arquitectura de Redes y Comunicaciones MODELO DE REFERENCIA OSI El modelo de referencia de interconexión de sistemas abiertos es una representación abstracta en capas, creada como guía para el diseño del protocolo de red. El modelo OSI divide

Más detalles

Redes de Computadoras Introducción Arquitectura de Redes

Redes de Computadoras Introducción Arquitectura de Redes Universisdad de Los Andes Facultad de Ingeniería Escuela de Sistemas Redes de Computadoras Introducción Arquitectura de Redes Mérida - Venezuela Prof. Gilberto Díaz Otra clasificación de las redes Según

Más detalles

CI Politécnico Estella

CI Politécnico Estella PROGRAMACIÓN DEL /ASIGNATURA DEPARTAMENTO: Informática GRUPO/CURSO: 1º AS / 2.014-2.015 / ASIGNATURA: ISOP (IMPLANTACIÓN DE SISTEMAS OPERATIVOS) PROFESOR: Mikel Villanueva Erdozain 1. SÍNTESIS DE LA PROGRAMACIÓN

Más detalles

Router Teldat. Agente SNMP

Router Teldat. Agente SNMP Router Teldat Agente SNMP Doc. DM712 Rev. 10.00 Marzo, 2003 ÍNDICE Capítulo 1 Introducción al protocolo SNMP...1 1. Introducción... 2 2. Tipos de paquetes SNMP... 3 3. Autenticación... 4 Capítulo 2 Configuración

Más detalles

Protocolos y Modelo OSI

Protocolos y Modelo OSI Protocolos y Modelo OSI. Mg. Gabriel H. Tolosa. tolosoft@unlu.edu.ar So as I look at transitioning to the communication platforms of the future, I see that the beauty of Internet protocols is you get the

Más detalles

SERVIDOR PROXY CACHÉ. Servicios que ofrece:

SERVIDOR PROXY CACHÉ. Servicios que ofrece: SERVIDOR PROXY CACHÉ Servicios que ofrece: 1. Filtrado de contenidos web. 2. Proxy caché. 3. Cortafuegos. 4. Antivirus 5. Servidor DHCP. 6. Balanceo de carga. 7. Servidor Web para Intranets. 8. Administración

Más detalles

Juan de Dios Murillo Morera e-mail: jmurillo@una.ac.cr Santiago Caamaño Polini e-mail: scaamano@costarricense.cr INTRODUCCIÓN

Juan de Dios Murillo Morera e-mail: jmurillo@una.ac.cr Santiago Caamaño Polini e-mail: scaamano@costarricense.cr INTRODUCCIÓN UNICIENCIA 24 pp. 83-89 2010 IMPLEMENTACIÓN DE UN SERVIDOR FTP UTILIZANDO EL MODELO CLIENTE/SERVIDOR MEDIANTE EL USO DE SOCKETS EN LENGUAJE C UNIX CON EL FIN DE MEJORAR LOS TIEMPOS DE RESPUESTA EN LA RED

Más detalles

Tema 3: Modelos de gestión de red 1. SNMP. 2. OSI. SNMP

Tema 3: Modelos de gestión de red 1. SNMP. 2. OSI. SNMP Tema 3: Modelos de gestión de red 1. SNMP. 2. OSI. SNMP Historia Desde el origen de TCP/IP(1969) se utiliza para gestión herramientas basadas en el protocolo ICMP (Internet-Control Message Protocol). La

Más detalles

SNMP. Area de Ingeniería Telemática http://www.tlm.unavarra.es. Grado en Ingeniería en Tecnologías de Telecomunicación, 4º

SNMP. Area de Ingeniería Telemática http://www.tlm.unavarra.es. Grado en Ingeniería en Tecnologías de Telecomunicación, 4º Gestión y Planificación de Redes y Servicios SNMP Area de Ingeniería Telemática http://www.tlm.unavarra.es Grado en Ingeniería en Tecnologías de Telecomunicación, 4º SNMP Simple Network Management Protocol

Más detalles

Dispositivos de Red Hub Switch

Dispositivos de Red Hub Switch Dispositivos de Red Tarjeta de red Para lograr el enlace entre las computadoras y los medios de transmisión (cables de red o medios físicos para redes alámbricas e infrarrojos o radiofrecuencias para redes

Más detalles

MODELO OSI. Historia. Modelo de referencia OSI

MODELO OSI. Historia. Modelo de referencia OSI MODELO OSI El modelo de interconexión de sistemas abiertos (ISO/IEC 7498-1), también llamado OSI (en inglés open system interconnection) es el modelo de red descriptivo creado por la Organización Internacional

Más detalles

CUALIFICACIÓN OPERACIÓN DE REDES DEPARTAMENTALES PROFESIONAL. Nivel 2. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN OPERACIÓN DE REDES DEPARTAMENTALES PROFESIONAL. Nivel 2. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 16 CUALIFICACIÓN OPERACIÓN DE REDES DEPARTAMENTALES PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 2 Código IFC299_2 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Multi Traffic Routing Grapher (MRTG)

Multi Traffic Routing Grapher (MRTG) UNIVERSIDAD CENTROCCIDENTAL LISANDRO ALVARADO DECANATO DE CIENCIAS Y TECNOLOGÍA COORDINACIÓN DE POST-GRADO Maestría en Ciencias de la Computación- Mención Redes de Computadoras Multi Traffic Routing Grapher

Más detalles

Uso de SNMP para encontrar un número de puerto a partir de una dirección MAC en un switch Catalyst

Uso de SNMP para encontrar un número de puerto a partir de una dirección MAC en un switch Catalyst Uso de SNMP para encontrar un número de puerto a partir de una dirección MAC en un switch Catalyst Contenido Introducción prerrequisitos Requisitos Componentes Utilizados Convenciones Antecedente Detalles

Más detalles

Gestión de Redes IP. Presentación realizada por: Ing. Pablo Borrelli. Gestión de Redes IP 1

Gestión de Redes IP. Presentación realizada por: Ing. Pablo Borrelli. Gestión de Redes IP 1 Gestión de Redes IP Lugar: Sala de I.T.I. (Instituto Tecnológico de Informática) Presentación realizada por: Ing. Pablo Borrelli Gestión de Redes IP 1 Presentación e introducción. Gestión de la Red de

Más detalles

UNIVERSIDAD LUTERANA SALVADOREÑA FACULTAD DE CIENCIAS DEL HOMBRE Y LA NATURALEZA LICENCIATURA EN CIENCIAS DE LA COMPUTACIÓN ASIGNATURA: REDES I TEMA:

UNIVERSIDAD LUTERANA SALVADOREÑA FACULTAD DE CIENCIAS DEL HOMBRE Y LA NATURALEZA LICENCIATURA EN CIENCIAS DE LA COMPUTACIÓN ASIGNATURA: REDES I TEMA: UNIVERSIDAD LUTERANA SALVADOREÑA FACULTAD DE CIENCIAS DEL HOMBRE Y LA NATURALEZA LICENCIATURA EN CIENCIAS DE LA COMPUTACIÓN ASIGNATURA: REDES I TEMA: SISTEMA DE MONITOREO DE EQUIPOS CON SNMP CATEDRÁTICO:

Más detalles

SNMP. Area de Ingeniería Telemática http://www.tlm.unavarra.es. Grado en Ingeniería en Tecnologías de Telecomunicación, 4º

SNMP. Area de Ingeniería Telemática http://www.tlm.unavarra.es. Grado en Ingeniería en Tecnologías de Telecomunicación, 4º Gestión y Planificación de Redes y Servicios SNMP Area de Ingeniería Telemática http://www.tlm.unavarra.es Grado en Ingeniería en Tecnologías de Telecomunicación, 4º SNMP Simple Network Management Protocol

Más detalles

El Modelo de Referencia OSI

El Modelo de Referencia OSI El Modelo de Referencia OSI Tabla de Contenidos 2. El Modelo de Referencia OSI... 2 2.1 Nivel físico...4 2.2 Nivel de enlace... 4 2.3 Nivel de red... 5 2.4 Nivel de transporte...5 2.5 Nivel de sesión...

Más detalles

8 Conjunto de protocolos TCP/IP y direccionamiento IP

8 Conjunto de protocolos TCP/IP y direccionamiento IP 8 Conjunto de protocolos TCP/IP y direccionamiento IP 8.1 Introducción a TCP/IP 8.1.1 Historia de TCP/IP El Departamento de Defensa de EE.UU. (DoD) creó el modelo de referencia TCP/IP porque necesitaba

Más detalles

Resumen para examen. Tema: Gestion de Red. Versión 2.1

Resumen para examen. Tema: Gestion de Red. Versión 2.1 Resumen para examen. Tema: Gestion de Red. Versión 2.1 Creado por Mario Zaizar mariozaizar@hotmail.com www.lazaizarweb.tk Por que hacer este documento?...decidi escribir esto porque aprenderé mucho con

Más detalles

Monitoreo de redes. Ing. Diego Córdoba www.linuxinstitute.com.ar Pagina 1 de 6

Monitoreo de redes. Ing. Diego Córdoba www.linuxinstitute.com.ar Pagina 1 de 6 Monitoreo de redes Ing. Diego Córdoba www.linuxinstitute.com.ar Pagina 1 de 6 Manejo de traps Hasta ahora hemos visto una arquitectura de polling, en la que instalamos una consola central de monitoreo

Más detalles

Router, Enrutador o Encaminador

Router, Enrutador o Encaminador Router, Enrutador o Encaminador Un router es un tipo especial de computador. Cuenta con los mismos componentes básicos que un PC estándar de escritorio. Tiene una CPU, memoria, bus de sistema y distintas

Más detalles

Gestión de Redes Introducción a SNMP

Gestión de Redes Introducción a SNMP Gestión de Redes Introducción a SNMP These materials are licensed under the Creative Commons Attribution-Noncommercial 3.0 Unported license (http://creativecommons.org/licenses/by-nc/3.0/) Contenido Que

Más detalles

Unidad 3: El sistema operativo. Trabajo con conexión.

Unidad 3: El sistema operativo. Trabajo con conexión. Unidad 3: El sistema operativo. Trabajo con conexión. 1.- Red de ordenadores Vamos a describir que es una red informática o red de ordenadores. Una red informática es un sistema de interconexión entre

Más detalles

Perito Judicial en Redes y Telecomunicaciones

Perito Judicial en Redes y Telecomunicaciones Perito Judicial en Redes y Telecomunicaciones TITULACIÓN DE FORMACIÓN CONTINUA BONIFICADA EXPEDIDA POR EL INSTITUTO EUROPEO DE ESTUDIOS EMPRESARIALES Perito Judicial en Redes y Telecomunicaciones Duración:

Más detalles

Capítulo 3. Software para el Monitoreo de Redes

Capítulo 3. Software para el Monitoreo de Redes Capítulo 3 Software para el Monitoreo de Redes No basta saber, se debe también aplicar. No es suficiente querer, se debe también hacer. Johann Wolfgang Goethe Software para el Monitoreo de Redes El estilo

Más detalles

Seguridad en redes: TCP/IP, filtrado de tráfico y firewalls. Alberto Castro Rojas

Seguridad en redes: TCP/IP, filtrado de tráfico y firewalls. Alberto Castro Rojas Seguridad en redes: TCP/IP, filtrado de tráfico y firewalls EL64E Alberto Castro Rojas 1 Agenda Las redes locales y su conexión a distancias Dirección MAC y dirección IP Equipos de interconexión Los protocolos

Más detalles

Modelo TCP/IP. Página 1. Modelo TCP/IP

Modelo TCP/IP. Página 1. Modelo TCP/IP Modelo TCP/IP Página 1 Índice: Página 1.-Introducción 3 2.-Arquitectura TCP/IP 3 3.-Protocolo IP 8 4.-Direccionamiento IP 9 5.-Otros Protocolos de la capa de Red. 12 6.-Ejercicios 13 7.-Protocolos de resolución

Más detalles

GUÍAS FÁCILES DE LAS TIC

GUÍAS FÁCILES DE LAS TIC GUÍAS FÁCILES DE LAS TIC del COLEGIO OFICIAL DE INGENIEROS DE TELECOMUNICACIÓN Trabajo Premiado 2006 Autor: Router IP D. José María Jurado García-Posada 17 de Mayo 2006 DIA DE INTERNET Guía fácil Router

Más detalles

1.Introducción. 2.Direcciones ip

1.Introducción. 2.Direcciones ip 1.Introducción El papel de la capa IP es averiguar cómo encaminar paquetes o datagramas a su destino final, lo que consigue mediante el protocolo IP. Para hacerlo posible, cada interfaz en la red necesita

Más detalles

Router Teldat. Agente SNMP

Router Teldat. Agente SNMP Router Teldat Agente SNMP Doc. DM712 Rev. 10.70 Junio, 2007 ÍNDICE Capítulo 1 Introducción al protocolo SNMP...1 1. Introducción... 2 2. Tipos de paquetes SNMP... 3 3. Autenticación... 4 Capítulo 2 Configuración

Más detalles

Cuaderno Técnico: MONITORIZACIÓN DE SERVICIOS Y SISTEMAS

Cuaderno Técnico: MONITORIZACIÓN DE SERVICIOS Y SISTEMAS Asociación Informáticos de Instituciones Sanitarias de Castilla y León Cuaderno Técnico: MONITORIZACIÓN DE SERVICIOS Y SISTEMAS Mariano Raboso Mateos Doctor Ingeniero de Telecomunicación Autores: Mariano

Más detalles

ÍNDICE DE CONTENIDOS

ÍNDICE DE CONTENIDOS ÍNDICE DE CONTENIDOS 1. Conceptos generales sobre redes... 1. 2. Elementos básicos de una red. Hardware y Software... 3. 3. Configuración de una LAN. Protocolo TCP IP... 5. 4. Recursos compartidos en una

Más detalles

UNIVERSIDAD LUTERANA SALVADOREÑA FACULTAD DE CIENCIAS DEL HOMBRE Y LA NATURALEZA LICENCIATURA EN CIENCIAS DE LA COMPUTACIÓN ASIGNATURA: REDES I TEMA:

UNIVERSIDAD LUTERANA SALVADOREÑA FACULTAD DE CIENCIAS DEL HOMBRE Y LA NATURALEZA LICENCIATURA EN CIENCIAS DE LA COMPUTACIÓN ASIGNATURA: REDES I TEMA: UNIVERSIDAD LUTERANA SALVADOREÑA FACULTAD DE CIENCIAS DEL HOMBRE Y LA NATURALEZA LICENCIATURA EN CIENCIAS DE LA COMPUTACIÓN ASIGNATURA: REDES I TEMA: SISTEMA DE MONITOREO DE EQUIPOS CON SNMP CATEDRÁTICO:

Más detalles

Emerson Network Energy Center, ENEC Enterprise, es una aplicación para la gestión remota de. Multiplataforma. Navegación intuitiva.

Emerson Network Energy Center, ENEC Enterprise, es una aplicación para la gestión remota de. Multiplataforma. Navegación intuitiva. Emerson Network Energy Center, ENEC Enterprise, es una aplicación para la gestión remota de sistemas de energía, baterías, corriente alterna, grupos electrógenos, SAIs, sistemas de refrigeración, sistemas

Más detalles

IS23 Mantenimiento de Instalaciones Informáticas Práctica 7. Análisis de redes

IS23 Mantenimiento de Instalaciones Informáticas Práctica 7. Análisis de redes IS23 Mantenimiento de Instalaciones Informáticas Práctica 7. Análisis de redes 1 Objetivos Ingeniería Técnica Informática de Sistemas Curso 2003/2004 En la presente sesión se pretende familiarizar al alumno

Más detalles

Ficha Técnica. effidetect

Ficha Técnica. effidetect Ficha Técnica effidetect Página 1 de 9 Introducción El Sistema Pointer es un producto de Predisoft (www.predisoft.com) cuyo propósito es la detección (en línea) del fraude que sufren las instituciones

Más detalles

Participantes. Representantes de la academia de sistemas y computación de los Institutos Tecnológicos. Academia de sistemas y computación.

Participantes. Representantes de la academia de sistemas y computación de los Institutos Tecnológicos. Academia de sistemas y computación. 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Clave e la asignatura: Horas teoría-horas práctica-créditos: Redes de Computadoras Ingeniería en Sistemas Computacionales SMC 0429 3-2-8 2.-

Más detalles

CONTENIDO RESUMEN... V PRESENTACIÓN...VI CAPÍTULO 1... 1 MONITOREO Y ADMINISTRACIÓN DE REDES... 1

CONTENIDO RESUMEN... V PRESENTACIÓN...VI CAPÍTULO 1... 1 MONITOREO Y ADMINISTRACIÓN DE REDES... 1 i CONTENIDO RESUMEN... V PRESENTACIÓN...VI CAPÍTULO 1... 1 MONITOREO Y ADMINISTRACIÓN DE REDES... 1 1.1 INTRODUCCIÓN A LA ADMINISTRACIÓN Y MONITOREO DE REDES... 1 1.1.1 DEFINICIÓN Y OBJETIVOS DE LA ADMINISTRACIÓN

Más detalles

Unidad Didáctica Redes 4º ESO

Unidad Didáctica Redes 4º ESO Unidad Didáctica Redes 4º ESO Qué es una red? Una red es la unión de dos o más ordenadores de manera que sean capaces de compartir recursos, ficheros, directorios, discos, programas, impresoras... Para

Más detalles

Unidad II. EVOLUCIÓN DEL PROTOCOLO DE GESTIÓN INTERNET. Documento base para los temas:

Unidad II. EVOLUCIÓN DEL PROTOCOLO DE GESTIÓN INTERNET. Documento base para los temas: Unidad II. EVOLUCIÓN DEL PROTOCOLO DE GESTIÓN INTERNET Documento base para los temas: 1. Modelos de gestión de internet. 2. Protocolo SNMP v1 3. Protocolo SNMP v2. Información de gestión (RFC 1901) 4.

Más detalles

Monitoreo de red. Inventario de hardware y software. Monitoreo actividad del usuario. Soporte a usuarios. Protección contra fuga de datos.

Monitoreo de red. Inventario de hardware y software. Monitoreo actividad del usuario. Soporte a usuarios. Protección contra fuga de datos. nvision Es una solución modular que permite gestionar la red, llevar el control y cumplimiento de licencias inventario de hardware y software de equipos Windows, monitorear la actividad que realizan diariamente

Más detalles

REDES DE COMPUTADORES Laboratorio

REDES DE COMPUTADORES Laboratorio 1nsloo.cl REDES DE COMPUTADORES Laboratorio Práctica 1: Emulación de redes con NetGUI. 1. OBJETIVOS. El objetivo de esta práctica es aprender a utilizar la herramienta de emulación de redes Netkit / NetGUI,

Más detalles

Redes de Datos- Arquitecturas de protocolos. Ph.D. Jhon Jairo Padilla Aguilar UPB Bucaramanga

Redes de Datos- Arquitecturas de protocolos. Ph.D. Jhon Jairo Padilla Aguilar UPB Bucaramanga - Arquitecturas de protocolos Ph.D. UPB Bucaramanga Protocolo de Comunicaciones Hola Hola Qué hora tiene? Las 10 am gracias De nada Establecimiento conexión Transferencia De Información Solicitud cx Confirmación

Más detalles

Monitorización del Sistema

Monitorización del Sistema Monitorización del Sistema Tabla de Contenidos 9. Monitorización del Sistema... 2 Monitorización de la actividad de Red... 2 Planificación de progresos... 2 Protección contra virus... 3 Soporte de Impresoras...

Más detalles

DESARROLLO WEB EN ENTORNO SERVIDOR

DESARROLLO WEB EN ENTORNO SERVIDOR DESARROLLO WEB EN ENTORNO SERVIDOR CAPÍTULO 7: Programación de servicios Web Marcos López Sanz Juan Manuel Vara Mesa Jenifer Verde Marín Diana Marcela Sánchez Fúquene Jesús Javier Jiménez Hernández Valeria

Más detalles