Casa abierta al tiempo

UNIVERSIDAD AUTONOMA METROPOLITANA

UNIDAD : IZTAPALAPA

DIVISION : CIENCIAS BASICAS E INGENIERIA

CARRERA : LICENCIATURA EN COMPUTACION

MATERIA : PROYECTO DE INVESTIGACION I Y I1

TITULO : DESARROLLO DE UN MONITOR PARA REDES TCP/IP

FECHA : 23 DE OCTUBRE DE 1998

ALUMNOS :

EDGAR GUTIERREZ SANCHEZ 92321618

RUBEN LEON RODRIGUEZ 92320846

MIGUEL TREJO KURI 92323550

ASESOR : ING. VICTOR MANUEL RAMOS RAMOS

UNIVERSIDAD AUTONOMA METROPOLITANA unidad lztapalapa

Proyecto de Investigación I y Proyecto de Investigación II

Asesor: Ing. Victor Manuel Ramos Ramos

Alumnos: Edgar Gutiérrez Sánchez

(92321618)

Rubén León Rodriguez (92320846)

Miguel Trejo Kuri (92323550)

1 . Modelos propuestos para la solución del problema de comunicación entre equipos .............................. 1 . 1 . Modelo OS1 de SO ............................................................................................................................. 1.2. Modelo TCP/IP ..................................................................................................................................

2 . Protocolos relacionados con el modelo TCP/IP ....................................................................................... 2 . 1 . Concepto de protocolo ....................................................................................................................... 2.2. Protocolos orientados a conexión ...................................................................................................... 2.3. Protocolos no orientados a conexión ................................................................................................. 2.4. Clasificación de las redes TCP/IP de acuerdo a su dimensión ..........................................................

2.5.1. Diferencias fundandamentales .................................................................................................. 2.5.2. Formato del paquete .................................................................................................................

2.6. I . File Transfer Protocol (FTP) .................................................................................................... 2.6.2. Telnet ....................................................................................................................................... 2.6.3. Simple Network Management Protocol (SNMP) .................................................................... 2.6.4. Simple Mail Transfer Protocol (SMTP) .................................................................................. 2.6.5. Internet Control Message Protocol (ICMP) ............................................................................. 2.6.6. Common Management Information Protocol (CMIP) .............................................................

3 . Simple Network Management Protocol (SNMP) ..................................................................................... 3.1. Conceptos ...........................................................................................................................................

3 . I . I . Estación de administración ........................................................................................................ 3.1.2. Protocolo de administración ...................................................................................................... 3 . I . 3. Objetos administrados ...............................................................................................................

3.1.3. I . Management Information Base (MIB) .......................................................................... 3.1.3.2. Agentes ..........................................................................................................................

3.2. ASN . 1 (Abstract Syntax Notation One) ............................................................................................. 3.2. 1 . Representación de ASN . 1 .......................................................................................................... 3.2.2. Tipos de datos ............................................................................................................................

3.2.2. 1 . Tipos Simples ................................................................................................................ 3.2.2.2. Tipos Construidos ......................................................................................................... 3.2.2.3. Tipos Etiquetados .......................................................................................................... 3.2.2.4. Subtipos .........................................................................................................................

3.3. Operadores SNMP y el Servicio de Transporte ................................................................................. 3.3.1 . SNMP GET ................................................................................................................................. 3.3.2. SNMP GETNEXT ..................................................................................................................... 3.3.3. SNMP GETBULK ..................................................................................................................... 3.3.4. SNMP SET ............................................................................................. ...................................

3.3.6. RESPONSES ....................................................................................................

4 . Diagrama de clases de REMonitor ............................................................................................................

2.5. Comparación entre TCP (Transmission Control Protocol) y UDP (User Datagram Protocol) .........

2.6. Protocolos de capas superiores ...........................................................................................................

3.3.5. SNMP INFORMREQUEST ......................................................................................................

3.4. Estructura del PDU (Protocol Data Unit) ........................................................................................... .........................

Anexo A . Operación de REMonitor ..............................................................................................................

Anexo B . Articulo Congreso Electro '97 ......................................................................................................

Conclusiones .............................................................. ...................................................................................

Bibliografía ...................................................................................

*

.................................................................

1 1 3 7 7 7 8 8 8 9 9

11 11 11 11 12 12 13 16 16 16 16 17 18 19 20 20 21 21 21 22 22 22 23 24 24 25 26 26 26 30

46

49

54

55

OBJETIVOS PERSEGUIDOS

0 Desarrollar un sistema de administración para redes que utilizan la familia de protocolos

0 I~nplementarlo en un lenguaje de programación orientado a objetos (POO), con capacidad de ser

0 Utilizar como protocolo de administración, el SNMP ( S'imple Network Management Protocol ),

TCP/lP.

portable en distintas plataformas.

además de RMON ( REMOTE MONITORING NETWORK ).

INTRODUCCION

El presente documento forma parte del trabajo realizado para el desarrollo de un sistema de monitoreo para redes TCP/IP, al cual se le ha dado 131 nombre de REMonitor. Dentro del documento se hace mención a los conceptos más importantes en lo que se refiere a redes de comunicación y administración de redes. Con ello se da un panorama de lo que es la administración de redes y las funciones que desempeña un sistema de monitoreo para llevar a cabo dicha tarea.

Se integra de 4 capítulos, a saber:

El capítulo I trata sobre los 2 principales modelos de comunicación que se tienen: El modelo OS1 de ISO, y el modelo TCP/IP. Se describen las principales características de ambos modelos.

En el capítulo I 1 se adentra hacia lo que es el concepto de protocolo, sus tipos, y protocolos de capas Superiores, describiendo el funcionamiento de ellos.

El capítulo I l l esta dedicado a explicar el funcionamiento de el protocolo SNMP, sus operadores y la estructura del PDU, así como los conceptos principales en la administración de una red.

El capítulo IV contiene los diagramas de las principales clases implementadas en el sistema REMonitor, al mismo tiempo que da una explicación del funcionamiento de ellas.

Se han agregado además, 2 anexos que complementan la documentación de REMonitor: En el anexo A se ejempliiica la forma de operación de REMonitor, detallando con figuras la interfaz que el usuario verá al momento de operarlo. Finalmente, en el anexo B (artículo enviado al congreso Electro '97), describe en forma concisa como se relacionan las distintas clases de REMonitor, su funcionalidad, las estructuras y objetos que sle forman al estar operando el sistema.

1. MODELOS PROPUESTOS PARA LA SOLUCIóN DEL PROBLEMA DE COMUNICACIóN ENTRE EQUIPOS.

1 .l. Modelo OS1 de ISO.

Este modelo propuesto por la Organización Internacional de Normas (IS0 por sus siglas en ingles), se le conoce como Modelo de Referencia OSI (Open System Interconection), ya que precisamente se refiere a la conexión de sistemas heterogéneos.

Este modelo propone dividir el conjunto de funciones relacionadas con los servicios de comunicación en capas o niveles funcionales de acuerdo con los siguientes criterios:

1 , Homogeniedad de las funciones contenidas en cada nivel. 2. Definición de niveles entre los que las interacciones se limiten al mínimo. 3. Mantenimiento del nimero de niveles o estratos funcionales en un intervalo razonable,

Se dice que es u n modelo para sistemas abiertos, pues pone especial atención en el intercambio de información entre sistemas y no en el fhcionamiento interno de cada sistema en particular. De esta manera el modelo de referencia OS1 constituye el marco de trabajo para el desarrollo de protocolos normalizados para la comunicación entre dos capas cooperantes ubicadas en equipos distintos.

Este modelo OS1 tienen siete capas o niveles. Los principios aplicados para el establecimiento de siete niveles fueron los siguientes:

l. Un nivel se creará en situaciones en donde se necesita un nivel diferente de abstracción. 2. Cada nivel deberá efectuar una función bien definida. 3. La función que realizará cada nivel deberá seleccionarse con la intención de definir protocolos

4. Los límites de los niveles deberá seleccionarse tomando en cuenta la minimización del flujo de

5 . El nimero de capas deberá ser lo suficientemente grande para que funciones diferentes no tengan que ponerse juntas en el mismo nivel y por otra parte también deberá ser lo suficientemente pequefío para que su arquitectura no llegue a ser difícil de manejar.

normalizados internacionalmente.

información a travCs de las interfaces.

El modelo OS1 describe una arquitectura estratificada de red dividida en siete niveles:

1 . Nivel de control de interconexión física (o Nivel Físico), 2. Nivel de control de enlace de datos (o Nivel de Enlace de datos). 3. Nivel de control de red. 4. Nivel de transporte. 5. Nivel de sesión. 6. Nivel de servicios de presentación. 7. Nivel de aplicación.

LOS niveles inferiores comprenden las funciones que aseguran la transferencia de información entre dos terminales dentro de la red de comunicaciones. Los tres ]niveles recomiendan procedimientos para solucionar los requerimientos de conexión entre un ETD y un ETCD, para efectos de realizar la transmisión de información. Los niveles uno a cuatro de OS1 conforman el subsistema de transporte. El nivel cuatro releva a las sesiones de cualquier detalla referente a la forma en la cual se realiza la trasferencia de datos.

Los niveles de sesión, presentación y aplicación constituyen los niveles superiores del modelo. A diferencia de los cuatro niveles inferiores, los cuales están fundamentalmente implicados en proporcionar una comunicación confiable de extremo a extremo, los niveles superiores ofrecen una serie de servicios orientados al usuario. Los niveles superiores comprenden las funciones que soportan las aplicaciones ofrecidas al usuario y están relacionadas con la interpretación de la información.

1. Niveljisico. Este nivel permite la flexibilidad de uso de varios medios físicos para la interconexión con

procedimientos de control diferentes, tales como la recomendación V.24 de CCITT para redes telefónicas y la recomendación X.21 para redes de datos. Es el nivel más bajo en la estructura de OS1 y en se definen las características mecánicas, eléctricas, funcionales y de procedimiento necesarios para la transmisión de bits entre las entidades en el nivel de enlace de datos.

2. Nivel de enlace de dak)x Mientras que el nivel físico provee solamente un flujo de bits, la tarea del enlace es volver confiable

la transmisión. Este nivel gestiona una o más conexiones lógicas entre dos entidades de la red. Para completar esta tarea realiza finciones de secuenciación de datos, control de flujo y permite además, la detección y corrección de errores. Así con un protocolo de nivel 2 completo, el nivel superior puede suponer una transmisión virtualmente libre de errores.

3. Nivel de conrrol de red. este nivel asegura a las capas superiores la independencia sobre las tecnologías para la transmisión

de datos. En el se efectilan las operaciones que garantizan el funcionamiento de la propia red. AI mismo tiempo es responsable del establecimiento y manejo de la conexión entre dos entidades de transporte, pasando posiblemente a través de nodos intermedios o de tránsito cuyas capacidades debe negociar.

El nivel red realiza operaciones de enrutamiento, de control de congestión, así como de tnulticanalización. La información entre dos entidades de aplicación, cruza los tres niveles inferiores en cada uno de los nodos sobre la ruta de comunicación.

4. Nivel de transporte. En este nivel se asegura la transferencia confiable y transparente de datos entre puntos extremos.

Aquí se lleva a cabo el control de los nodos de tránsito. Pera ir de uno a otro es necesario llevar en memoria dos direcciones: la del destino final y la del destino inmediato. Sólo en el último segmento de la red ambas coincidirán. En cada puesto intermedio es necesario seleccionar la dirección correcta (sabiendo qué ruta es la más conveniente para llegar al destino final). La decisión depende de diversos factores, tales como la existencia, la ocupación, el costo, etc.

Una o más conexiones de transporte pueden ubicarse dentro de la misma conexión de red. Cada una se identifica por u n "identificador de punto final de transporte".

La complejidad de las funciones de la capa de transporte, que son responsable de la calidad del servicio ofrecido entre puntos extremos, depende de la calidad del servicio de la red disponible. Si la conexión ofrecida por la capa de red es fiable y económica, las funciones necesarias en la capa de transporte quedarán proporcionalmente reducidas.

5. Nivel de sesidn. El objetivo del nivel de sesión es organizar y sincronizar el dialogo, así como controlar la

transferencia de datos entre entidades del nivel presentación. Para ello ofrece servicios de gestión de conexión de sesión, apoyándose a su vez en las prestaciones del nivel transporte.

Los servicios del nivel sesión se clasifican en dos categorías: 1. Servicios de administración de sesiones, se unen temporalmente dos entidades de presentación. 2. Servicios de dialogo de sesión. Que controlan la transferencia de datos, delimitan y sincronizan

operaciones con los datos entre entidades de nivel presentación.

6. Nivel de servicio.s de presentación. En este nivel se maneja la sintaxis o representación de la información. Sus funciones incluyen el

formate0 de datos, la codificación, la traducción entre con.juntos de caracteres y códigos, así como la selección de los mecanismos de despliegue de la informaci8ón en pantalla.

Siendo algunos protocolos que se encuentran en esta capa los protocolos de terminal virtual, protocolos de archivo virtual y los protocolos de transferencia de trabajos y manipulación.

7. Nivel de uplicctrcich. Todos los demás niveles existen para brindar soporte a éste que es el encargado de proporcionar al

usuario el acceso al entorno OSI, brindándole servicios de información distribuida. El propósito de la capa de aplicación es servir entre los usuarios que se comunican por medio de OSI.

Una aplicación se compone de procesos cooperantes que se comunican mediante el uso de protocolos definidos en esta capa. Estos procesos de aplicación son la fuente y el destino último de los datos intercambiados.

Por illtimo se debe observar que el modelo OS1 describe las funciones que cada nivel debe ejecutar, pero no la forma en que serán llevadas a cabo dichas funciones, es decir, los detalles de implantación no se contemplan en el modelo.

1.2. Modelo TCP/IP

Otro modelo para redes de computadoras es el modelo TCP/IP implementado por el Depto de Defensa de los Estados Unidos aunque antes se denominaba ARPANET.

Una medida importante entorno a TCP/IP fue la decisión de implantarlos basados en el sistema operativo UNIX. De igual importancia fue la decisión de liberar el código y designar a la Universidad de California en Berkeley como su distribuidor.

El departamento de la Defensa de los Estados Unidos (DOD por sus siglas en inglés) optó por desarrollar protocolos y arquitecturas en lugar de adoptar los; estándares por tres razones:

Los protocolos del modelo TCP/IP se especificaron y tuvieron una difusión, anterior a la estandarización de OSI. Debido a las necesidades inmediatas del proyecto ARPANET, era inútil esperar la aparición de normas reconocidas internacionalmente.

0 Los requerimientos específicos de comunicaciones en el modelo TCP/IP, tienen un mayor impacto en el diseño de protocolos y en la arquitectura. Esta característica ofrece facilidades para la implantación que no se encuentran en otros modelos. Existen diferencias filosóficas con respecto a la naturaleza apropiada de una arquitectura de comunicación y sus protocolos.

1. El concepto dejerarquía contra el de nivel. 2. La importancia que cada modelo concede a la interconexión de redes. 3. La utilidad de servicios no orientados a conexión. 4. El enfoque para funciones de administración.

El modelo TCP/IP reconoce que el trabajo de la comunicación es muy complejo y diverso para que se realice por una sola unidad. En consecuencia, éste se divide en módulos o entidades cooperantes que soportan en col1-junto un servicio distribuido.

El modelo OS1 se basa en los mismos razonamientos, pero además, reconoce que existen de la misma jerarquía con características en común que se puleden agrupar en un solo nivel o capa. La objeción, algunas veces aumentada por los diseñadores del modelo TCP/IP, es que el modelo OS1 es prescriptivo más 110 descriptivo.

Es posible definir más de un protocolo de la misma jerarquía y la funcionalidad de ellos puede no ser igual o siquiera seme-jante. Algo que es común acerca de un grupo de protocolos es que pueden compartir el mismo conjunto de protocolos de jerarquía in-ferior. En lo que concierne a las relaciones entre niveles, que se presentan en OSI, pueden mencionarse que:

0 La entidad del nivel (N) puede intercambiar datos usando los servicios de la entidad del nivel (N- I ) . Otra forma de decir es que la entidad del nivel (N- I ) debe estar implicada en cada transferencia de datos de la entidad del nivel (N).

0 La entidad del nivel (N-1) da servicio intercambiando unidades de datos que contienen información de control de nivel (N-1) y datos de la entidad (N).

Por su lado, en el modelo TCP/IP, se permiten las siguientes operaciones: 0 Una entidad puede usar directamente los servicios de otra jerarquía más baja, aun sin ser

adyacentes. 0 Pueden utilizarse caracteres de escape para colocar caracteres de control dentro de una cadena

de datos. Esta situación no se describe completamente en OS1 dentro del concepto de unidad de datos de protocolo.

0 Pueden separarse las conexiones de control y datos; los datos y la información de control no comparten la unidad de datos. Con esto se ofreceln diferentes servicios para cada tipo de conexión.

0 Se pueden mane.jar la información desde una jerarquía inferior para realizar un control en las jerarquías superiores. Se permite la cooperación de midtiples entidades de la misma jerarquía.

Una diferencia histórica entre el modelo TCP/IP y OS1 es la importancia que el primero concede a la interconexión. Esta ocurre cuando dos sistemas de comunicación no están unidos a la misma red. Así, los datos transferidos deben atravesar al menos dos redes que además, pueden ser de distinto tipo.

En el modelo TCP/IP tienen igual importancia los servicios sin conexión y los servicios orientados a conexión, mientras que el modelo OS1 está expresado solamente en términos de estos últimos. El uso principal del servicio sin conexión en TCP/IP es en la interconexión entre redes, ya que no es seguro suponer que todas las redes intermedias son confiables, como para construir una ruta dedicada por donde pueda transferirse una secuencia de datos.

Una diferencia final entre el modelo TCP/IP y OS1 es la forma en la cual son tratadas las funciones de administraci6n (es decir, la designación, el control de acceso y la contabilidad de los recursos de la red). En el modelo OS1 estas se clasifican por nivel y se localizan como tareas de administración en cada 11110. El modelo TCP/IP no excluye este enfoque, pero 'va más lejos. Desde el punto de vista de

4

TCP/IP, muchas de estas funciones pueden ofrecerse a través de un protocolo de tipo “sesión”. Este enfoque refleja el hecho de que esos protocolos usan servicios de transporte.

El modelo TCPAP puede describirse por la interacción de tres agentes: procesos, anfitriones y redes. Los procesos son las entidades flmdamentales de la comunicación y se ejecutan en los anfitriones (estaciones) que pueden soportar varios procesos simultheos. La comunicación entre procesos se lleva a cabo a través de redes a las que se conectan los anfitriones. Los tres conceptos constituyen un principio ftlndamental del modelo: la transferencia de información a un proceso se realiza primero, llevándola al anfitrión donde reside el proceso fuente, el anfitrión la entrega a la red que la hace llegar hasta el anfitrión final donde es ofrecidad al proceso destino. La red se ocupará del enrutamiento de datos entre los anfitriones, mientras estos acuerden como dirigir los datos a sus procesos.

El modelo organiza a sus protocolos en cuatro “niveles”. Siendo estos los siguientes:

0 Nivel acceso a red. Nivel internet.

0 Nivel anPitrión-anfitriótl. 0 Nivel proceso/aplicación.

Nivel ucceso u IVY/.

Este nivel comprende protocolos que gestionan el uso de los servidores en red y residen en un anfitrión o su equivalente lógico. Una función de todos es el enrutamiento de datos entre los anfitriones que pertenecen a la misma red.

Otros servicios que ofrecen son el de control de flujo y errores entre anfitriones; así como varias características de calidad de servicio como prioridad y seg,uridad. Una entidad a nivel red se invoca regularmente por la entidad de nivel internet o de nivel anfitrión-anfitrión, pero también puede invocarse desde una entidad a nivel proceso/aplicación.

Nivel Internet. El nivel internet soporta los procedimientos que permiten el tránsito de datos a través de múltiples

redes. Así, éste debe proporcionar una función de enrutamie:nto. Los protocolos se implantan entre los anfitriones y los puentes (Gatewuys).

Nivel anJtricin-anfitritin. Este nivel contienen los protocolos con capacidad para enviar datos entre dos procesos en diferentes

anfitriones. Puede ofrecer una conexión lógica entre entidades de alto nivel. Otros posibles servicios incluyen control de errores, flujo y la capacidad de manejar señales de control no asociadas con una conexión lógica de datos.

Son necesarios cuatro tipos de protocolos generales en este nivel, teniendo cada uno de ellos diferentes requerimientos de servicio:

o Un protocolo de datos orientado a conexión. Caracterizado por la necesidad de una entrega confiable de datos. Muchas aplicaciones de procesamilento de datos pueden usar este servico.

0 Un protocolo para datagramas. Que sólo ofrece servicos básicos y puede ser apropiado para algim tráfico, particularmente aplicaciones que no se orientan a conexión.

0 Un protocolo de voz. Que caracteriza por la necesidad de manejar un flujo constante de datos con una variación mínima de retardo.

0 Un protocolo de datos en tiempo real. Tiene características del protocolo orientado a datos y del protocolo de voz.

Nivel proceso/u~~licacidl7. Comprende protocolos para compartir recursos y garantizar acceso remoto. En la siguiente figura se presenta el modelo de la arquitectura TCP/IP y varios de sus protocolos

más importantes.

Protocolos Gateway IP e ICMP PROXY

ARP, RARP

IEEE 802 Ethernet DOCMP LAPB/M/X SDLC Aloha TDMA, etc.

IEEE802 Ethernet EIA-232 X.21 BIS V.24 ISDN, etc.

1 I

La manera en que se apilan las capas del modelo puede variar dependiendo de las necesidades de los usuarios de la red y de las decisiones hechas por los diseñadores. Nótese que estas normas encajan en los tres niveles superiores de la arquitectura. Los protocolos que descansan sobre TCP son ejemplos de nivel aplicación. Por su parte, los'protocolos de los dos niveles pueden implantarse con una amplia selección de normas y protocolos. Los sistemas pueden tener interfaz con una gran variedad de redes. De u n modo general TCPiIP confiará en los estándares naionales e internacionales a este nivel.

Son muchos los que piensan que la serie TCPiIP es un enfoque más viable por un cierto número de razones. Primero porque ha demostrado que funciona, segundo porque hay un gran número de productos en el mercado basados en éI, tercero porque e s fácil el acceso a su documentación y finalmente porque está asociado con UNIX.

Frente a los partidarios de TCP/IP se encuentran los clonvencidos de OSI, que insisten en sus bondades. En todo caso, no se discute la operatividad de ésite, por lo menos en los niveles inferiores, donde la misma serie TCPiIP puede confiar el acceso a red, en protocolos como X.25 (redes públicas de conmutación de paquetes) o 4.391 (Red Digital de Servicios Integrados) estructurados con el enfoque de OSI. También es cierto que el modelo de 7 c.apas vino a marcar una dirección en la compresión del problema de las arquitecturas de red. Recordando que OS1 no describe como deben hacerse las cosas en cada nivel, sino que cosas deben hacerse. Es decir, clasifica las tareas del sistema. OS1 no es una implantación, debe enterderse como un lenguaje informal de descripción de redes de telecomllnicaciones. Se habla de un lenguaje porque el modelo designa la terminologia con que se aborda el diseiio. En contraste TCPiIP es una implantación. De ahí que se diga que mientras uno es prescriptivo el otro es descriptivo. Ambos modelos tienen puntos en común y diferencias importantes. No es que ciertas cosas que hace el modelo TCPiIP no puede ser hechas en el modelo OSI, más

bien, el argumento es que el primero propone que los protocolos sean modulares y jerárquicos, lo que daría ventajas para lograr un desempeíio más eficiente.

6

""."-. -- I .~" "-

2. PROTOCOLOS RELACIONADOS CON EL MODELO TCP/IP.

2.1. Concepto de protocolo.

Los protocolos son los estándares para las comunicaciones, es decir, son las reglas para la comunicación. Contienen los detalles referentes a los formatos de los mensajes, describen cómo responde una computadora cuando llega un mensaje y esipecifican de qué manera una computadora maneja un error u otras condiciones anormales. Un aspecto importante es que permite reflexionar sobre la comunicación por computadora de manera independiente de cualquier hardware de red de cualquier marca. En cierto sentido, los protocolos son para las comunicaciones lo que los algoritmos para la computación. Un algoritomo permite especificar o entender un cómputo aunque no se conozca los detalles de u n -juego de instruciones de CPU. De manera similar, un protocolo de comunicaciones permite especificar o entender la comunicación de manera similar y sin depender de un conocimiento detallado de una marca en particular de hardware de red.

2.2. Protocolos orientados a conexión (con acuse de recibo).

Las tres fases para establecer una transferencia de datos em un protocolo orientado a conexión son:

0 Reconocimiento Transferencia Liberación

Reconocimiento: Es necesario un reconocimiento mutuo entre las partes que establecerán la conexión y el sistema

que proporciona el servicio de comunicación ( la red ); esto se realiza antes de que se de la transferencia de datos. Durante el establecimiento de la conexión las tres entidades guardan información de sus contrapartes, tal como su dirección y las características QOS ( Quality Of Service ). Esta información permanece durante toda la etapa de transmisión, estableciendose así una relación entre las entidades.

Tvansjierencia: Las unidades de datos del protocolo ( PDU, Protocol Data Unit ) que se enviaran, no necesitan mas

que una abreviación del identificador de la entidad a donde se enviarán, con ello se accesa a las tablas de ruteo para ver la dirección completa y las características QOS.

El servicio orientado a conexión también proporciona ( salvo pocas excepciones ), un reconocimiento de las unidades de datos transferidas; es decir, la entidad receptora envía un mensaje al emisor notificando que se ha recibido sin error la unidad de dato, o por el contrario, si durante la transmisión se recibe una PDU con error, el protocolo permite la retransmición de la PDU. Además de estos servicios, la mayoría de los protocolos orientados a conexión aseguran que los datos lleguen en el orden correcto al destino final.

2.3. Protocolos no orientados a conexión (sin acuse de recibo).

En estos protocolos no existe la etapa de reconocimiento, por lo que tampoco es necesaria la etapa de liberación. Los PDUs son tratados como entidades separadas e independientes. No hay una relación que se mantenga durante la transferencia de los datos

En contraste con los servicios orientados a conexión, no se proporciona ningun reconocimiento de los PDUs, además de que las redes no orientadas a conexión no se hacen cargo del control de flujo, cada PDU debe llevar la dirección completa del receptor. Dado que no hay una relación preestablecida entre las entidades transmisoras, los PDUs pueden tomar difrentes rutas de encaminamiento, con lo cual se tiene mayor probabilidad de que lleguen en desorden a su destino.

2.4. Clasificación de las redes TCP/IP de acuerdo a su dimensión.

La familia de protocolos TCP/IP se ha implementado en redes de diversos tamaños, los cuales se clasifican principalmente en:

0 Redes de Area Amplia ( Wide Area Networks o WANs 0 Redes de Area Local ( Local Area Networks o LANs )

Las diferencias que las distinguen son:

0 La conexión entre los dispositivos de las LANs son generalmente de unos pocos cientos de metros a varios miles de metros., mientras que una WAN puede ser mucho más grande que la extensión de una LAN.

0 La transmitisión en una LAN generalmente consiste de datos, y algunas veces de voz y video. 0 La capacidad de transmisión en una LAN es por lo general más grande que la de una WAN. 0 El canal de transmisi6n de la LAN es por lo general propio de la compañía. 0 La tasa de error en una LAN es considerablemente mejor que el de una WAN,

2.5. Comparación entre TCP (Transmission Control Protocol) y UDP (User Datagram Protocol).

El Protocolo de Control de Transmisión (TCP por sus siglas en inglés) define un servicio clave proporcionado para una red de redes llamado entrega de flujo confiable. El TCP proporciona una conexión tipo full duplex entre dos máquinas, lo que les permite intercambiar grandes volúmenes de datos de manera eficaz.

Dado que utiliza u n protocolo de ventana deslizante, el TCP puede hacer eficiente el uso de la red. Como se hacen pocas suposiciones sobre el sistema de entrega adyacente, el TCP es lo suficientemente flexible como para operar sobre una gran variedad de sistemas de entrega. Ya que proporciona u n control de flujo, el TCP permite que el sistema cuente con una amplia variedad de velocidades para la comunicación.

El UDP es u n protocolo sencillo en el sentido de que no aumenta de manera significativa la semántica del IP. Sólo proporciona a los programas de aplicación la capacidad para comunicarse, mediante el uso del servicio de entrega de paquetes, sin conexión y no confiable. Por lo tanto, 10s mensajes UDP se pueden perder, duplicar, retrasar o entregar en desorden; el programa de aplicación que utiliza el UDP debe resolver estos problemas. Muchos programas que emplean el UDP no funcionan correctamente en una red de redes debido a que no manejan estas condiciones.

En el esquema de estratificación por capas de protocolo, el UDP reside en la capa de transporte arriba de la capa del Protocolo Internet y bajo la capa de aplicación. Conceptualmente, la capa de transporte es independiente a la capa Internet, pero en la práctica interactúan estrechamente.

2.5.1. Diferencias fundamentales.

Siendo las principales diferencias entre estos dos protocodos: 0 la Confinhilidud que cada uno proporciona (TPC es confiable mientras que el UDP no

0 el Tipo de conexicin de estos (UDP es sin conexión y el TCP proporciona una conexión full proporciona este servicio) y

duplex).

2.5.2. Formato del paquete.

Formato de los mensajes UDP.

Cada mensaje UDP se conoce como datagrama de usuario. Conceptualmente, un datagrama de usuario consiste de dos partes: un encabezado y un área de datos UDP. Como se muestra en la siguiente figura, el encabezado se divide en cuatro campos de 16 bits, que especifican el puerto desde el que se envió el mensaje, el puerto para el que se destina el mensaje, la longitud del mensaje y una suma de verificación UDP.

O 16 31

PUERTO UDP DE ORIGEN

LONGITUD DEL MENSAJE UDP SUMA DE VERlFlCAClON UDP

DATOS

...

Los campos PUERTO DE ORIGEN y PUERTO DE DESTINO contienen los números de puerto del protocolo UDP utilizados para el multiplexado de datagramas entre los procesos que los esperan recibir. El PUERTO DE ORIGEN es opcional. Cuando se utliza, especifica la parte a la que se deben enviar las respuestas, de lo contrario, puede tener valor de cero.

El campo de LONGITUD contiene u n conteo de los octetos en el datagrama UDP, incluyendo el encabezado y los datos del usuario UDP. Por lo tanto, el vallor mínimo para el campo LONGITUD es de ocho, que es la longitud del encabezado.

La suma de verifiacicón UDP es opcional y no es necesari'o utilizarla; un valor de cero en el campo SUMA DE VERlFlCAClON significa que la suma no se computó. Los diseñadores decidieron hacer opcional la suma de verificación a fin de permitir que las implantaciones operen con poco trabajo computacional cuando utilicen UDP en una red de área local altamente confiable. Sin embargo, se debe recordar que el IP no computa una suma de verificación de la porción de datos de un datagrama IP. Así que, la suma de verificación UDP proporciona la única manera de garantizar que 10s datos lleguen intactos, por lo que se debe utilizar.

Formato del segmento TCP.

La unidad de transferencia entre el software TCP de do,s máquinas se conoce como segmento. Los segmentos se intercambian para establecer conexiones, transferir datos, enviar acuses de recibo, anunciar los tamaííos de ventanas y para cerrar conexiones. Debido a que el TCP utiliza acuses de recibo incorporados, un acuse que viaja de la máquina A a la máquina B puede viajar en el mismo segmento en el que viajan los datos de la máquina A a la máquina B, aun cuando el acuse de recibo se refiera a los datos enviados de B hacia A. En la siguiente figura se muestra el segmento TCP

O 4 10 16 24 31 PUERTOFUENTE I PUERTO DESTINO 1

1 NUMERO DE ACUSE DE RECIBO

SUMA DE VERlFlCAClON I PUNTERO DE URGENCIA

OPCIONES (SI LAS HAY) RELLENO

DATOS

... 1 Cada segmento se divide en dos partes: el encabazado y datos. El encabezado, conocido como

encabezado TCP, transporta la identificación y la información de control. Los campos PUERTO FUENTE y PUERTO DESTINO contienen los números de puerto TCP que identifican a los programas de aplicación en los extremos de la conexión. El campo NUMERO DE SECUENCIA identifica la posición de los datos del segmento en el flujo de datos del transmisor. El campo NUMERO DE ACUSE DE RECIBO identifica el número de octetos que la fuente espera recibir después. Observe que el número de secuencia se refiere al flujo que va en la misma dirección que el segmento, mientras que el número de acuse de recibo se refiere al flujo que va en la dirección opuesta al segmento.

El campo HLEN contiene un número entero que especifica la longitud del encabezado del segmento, medida en multiplos de 32 bits. Es necesario porque el campo OPCIONES varia en su longitud, dependiendo en qué opciones se haya incluido. Así , el tamaño del encabazado TCP varia dependiendo de las opciones seleccionadas. El campo de 6 bits marcado como RESERVADO, está reservado para usarse en el futuro.

Algunos segmentos sólo llevan u n acuse de recibo y otros solamente llevan datos. Otros llevan solicitudes para establecer o cerrar una conexión. El s o f l a r e TCP utiliza el campo de 6 bits etiquetado como CODE BITS, para determinarse el propósito y contenido del segmento. Los seis bits indican cómo interpretar otros campos en el encabezado, de acuerdo con la siguiente tabla:

El software TCP informa sobre cuántos datos está dispuesto a aceptar cada vez que envía un segmento, al especificar su tamaño de memoria en el campo VENTANA. El campo contiene un nilmero entero sin signo de 16 bits en el orden de octetos estándar de red. Los anuncios de ventana proporcionan otro e-jemplo de acuse de recibo de carga, tlransporte y descarga ya que acompañan a todos los segmentos, tanto a los que llevan datos, como a ICIS que sólo llevan un acuse de recibo.

2.6. Protocolos de capas superiores.

2.6.1. File Transfer Protocol.

El protocolo FTP (File í‘Yun,sfer Protocol) se utiliza para la trasferencia de archivos teniendo otras

0 Acceso interactivo. Aunque el FTP está disefiado p,ara usarse mediante programas, la mayor parte de las implementaciones proporcionan una interfaz interactiva que permite a las personas interactuar fácilmente con los servidores remotos.

0 Especificación de formato (representación). El FTP permite al cliente especificar el tipo de formato de datos almacenados.

0 Control de autoidentificación. El FTP requiere que lcls clientes se autoricen a sí mismos con el envío de un nombre de conexión y una clave dle acceso al servidor antes de pedir la transferencia de archivos.

facilidades tales como:

2.6.2. Telnet.

El conjunto de protocolos TCP/IP incluye un protocolo de terminal remota sencilla, llamado TELNET el cual permite al usuario de una localidad establecer una conexión TCP con un servidor de acceso a otro. TELNET transfiere después las pulsaciones de teclado directamente desde el teclado del usuario a la computadora remota como si hubiese sido hechos en un teclado unido a la máquina remota. TELNET también transporta la salida de la máquina remota de regreso a la pantalla del usuario.

2.6.3. Simple Network Management Protocol.

El protocolo de administración de redes TCP/IP estándar es el SNMP, el cual define un protocolo de administración de bajo nivel que proporciona dos operaciones básicas: obtener un valor de una variable o almacenar un valor dentro de una variable. En el S’NMP, todas las operaciones de dan como consecuencia de los valores que se almacenen en las variables. El SNMP define el formato de los mensajes que viajan entre la computadora del administrador y una entidad supervisada. Un estándar asociado al SNMP define el conjunto de variables que una entidad administrada

mantiene. El estándar se conoce como Management Infomation Base, o MIB. Las variables se

describen utilizando ASN.1, L I ~ lenguaje formal que proporciona una forma codificada concisa así como una notación precisa que es posible para los usuarios para nombres y objetos.

2.6.4. Simple Mail Transfer Protocol.

El protocolo de transferencia estándar se conoce como SMTP (Simple Mail Transfer Protocol), este protocolo se enfoca específicamente en cómo transfiere el sistema de entrega de correo subyacente los mensajes a través de u n enlace de una máquina a otra. No especifica de qué manera acepta el sistema de correo los mensajes de un correo de un usuario o cómo presenta al usuario la interfaz de usuario el correo entrante. El SMTP tampoco especifica en qué forma se almacena el correo o con qué frecuencia el sistema de correo trata de enviar mensajes.

2.6.5 Internet Control Message Protocol (ICMP)

ICMP es u n protocolo para el control y envio de mensajes de errores para IP. Se puede accesar mediante sockets. Ocasionalmente un gateway o host destino se tratará de comunicar con un host fuente, por ejemplo, para reportar un error en el procesamiento de los datagramas. Para tal fin se creó este protocolo.

ICMP usa el soporte básico de IP como si fuera un protoc,olo de nivel más alto, sin embargo, ICMP es en realidad parte integral de IP, y debe ser implementado por todos los módulos 1P.

Los mensages ICMP son enviados por diversas situaciones: Por ejemplo, cuando un datagrama no alcanza su destino: cuando el gateway no puede continuar recibiendo más datagramas; y cuando el gateway puede dirigir el host para el envió de tráfico en una ruta más corta.

Los mensajes ICMP generalmente reportan errores en el procesamiento de datagramas. Estos mensajes son enviados usando el encabezado básico de IP. E l primer octeto de la porción de datos de el datagrama es u n campo de tipo ICMP, el valor de este campo determina el formato de los datos restantes.

1 .- SOLlCITUD DE RESPUESTA: Este tipo se usa para probar y verificar que el destino se puede alcanzar y esta respondiendo. La utilidad de PING trabaja sobre este tipo de mensaje.

2.- DESTINO INACCESIBLE: Este tipo de mensaje es generado cuando un datagrama IP no puede ser liberado por un nodo. Este tipo esta más delimitado por otros codigos como sigue:

O Red inaccesible 1 Host inaccesible 2 Protocolo inaccesible 3 Puerto inaccesible 4 Fragmentación necesaria y DF en set. 5 Falla en ruta fuente 6 Red destino desconocida 7 Host destino desconocido

8 Fuente aislada 9 La cotnunicación con la red destino esta prohibida 1 O La comunicación con el host destino es desconocida. 1 I Red inaccesible para el tipo de servicio 12 Red inaccesible para el tipo de servicio

3.- FUENTE APAGADA. Este tipo se genera cuando los buffers estan agotados en un gateway intermedio o host final. 4.- REDIRECCION. Este tipo se genera por un cambio de ruta. 5.- TIEMPO EXCEDIDO PARA EL DATAGRAMA. Se genera cuando el campo de tiempo de vida del datagrama ha excedido su limite. 6.- TIMESTAMP REQUEST AND REPLY. Se genera cuando se solicita un timestamp. 7.- MASCARA DE DIRECCIONES SOLICITADA. Este tipo es enviado para obtener una máscara de direcciones de una subred.

2.6.6 Common Management Information Protocol (CMIP)

Una vez que SNMP surgió como el primer protocolo de administración para redes, en los años siguientes se desarrollaron otros 2 protocolos diferentes que surgirian en los años 80's. El primero fué el SNMPv2, el cual incorporaba muchas de las características del original SNMP. El segundo fué el Common Management Information Protocol (CMIP), el cual fué mejor organizado y contiene muchas más características que SNMPvl o SNMPv2.

Cuando CMIP fué desarrollado, se suponía que sería el protocolo que reemplazaría a SNMP. Creado por el gobierno p grandes corporaciones, muchos pensaron que sería una realidad dado su casi ilimitado presupuesto de desarrollo. Desafortunadamente, problemas con su implementación han retardado su expansión.

El diseíío básico de CMlP es similar a SNMP, el mecanismo para administrar una red se hace empleando PDU's al igual que en SNMP. CMlP sin embargo, contiene 11 tipos de PDU's (comparado con 5 de SNMP). En CMIP las variables sort estructuras de datos complejas, y muy sofisticadas, con muchos atributos, que incluyen:

1) Atributos de variable: Representan las características de la variable (su tipo de dato, si es de

2) Funcionamiento de la variable: Que acciones pueden hacerse con la variable. 3) Notificaciones: La variable genera un reporte de evento cada vez que un evento especificado

escritura, por ejemplo).

ocurre (por e-jemplo, una terminal apagada podría causar una notificación de tal evento).

La más grande característica de CMIP es que sus variables no sólo retransmiten para y desde la terminal (como en SNMP), si no además, pueden también usarse para ejecutar tareas que podrían ser imposibles bajo SNMP. Por ejemplo: Si una terminal en una red no puede alcanzar su servidor de archivos u n número predeterminado de veces, entonces CMIP puede notificar al personal apropiado de tal evento. Con SNMP sin embargo, un usuario tendría que seguir la pista de cuántas veces intentó sin éxito alcanzar el servidor que una terminal tiene establecida. CMIP resulta así un sistema administrador de redes más eficiente, con menos trabajo por parte del usuario para mantener actualizado el estado de su red.

Otra ventaja de CMIP es soluciona varios de los fallos de SNMP. Por ejemplo, tiene incluidos dispositivos de gestión de la seguridad que soportan autorizaciones, control de acceso, contraseñas, entre otras cosas. Como resultado de la seguridad que dIe por sí proporciona CMIP no necesita de posteriores actualizaciones. Otra ventaja de CMIP es que haya sido creado no solo por gobiernos sino que también por grandes empresas, en los que puede tener en el futuro un mercado fiel.

A continuación haremos una descripción de los protocolos SNMP y CMIP, estableciendo puntos comunes y diferenciadores entre ambos:

o Tanto SNMP como CMIP son protocolos que pertenecen al nivel de aplicación,último de las capas OSI. Ambos se benefician, por tanto, de los servicios ]proporcionados por los protocolos de más bajo nivel.

o SNMP se apoya en los protocolos TCP/IP, del nivel de transporte, enlace y red, respectivamente, y del UDP(Users Datagram Protocol), del nivel de transporte. CMIP, sin embargo, descansa sobre el protocolo TP4 de OSI, en el nivel de transporte. Pero existe la posibilidad de que utilice TCP/IP, en cuyo caso el protocolo se llama CMOT( CMIP over TCPDP). Por lo demás, son similares. El protocolo de más ba-jo nivel TCP/IP es el más utilizado en este tipo de aplicaciones. Su exito reside, en gran parte, en su madurez y probada eficacia tecnológica para la conexión de múltiples redes.

0 SNMP f i e aprobado por el IAB(1nternet Activities Board), que es también el responsable de dar las especificaciones de TCP/IP. Desde el principio SNMP se creo con la idea de un protocolo para el seguimiento del funcionamiento de redes, detección y análisis de fallos y configuración de las dispositivos de red. El CMIP, por su parte, fue aprobado por la ISO(Internaciona1 Organization for Standardization).

0 CMIP y SNMP utilizan métodos diferentes para enviar menajes a través de la red. SNMP es un protocolo no orientado a la conexión, que envía mensajes en paquetes secuenciales. CMIP, por el contrario, está orientado a la conexión. Utiliza conexiones en circuito virtual para enviar los mensajes.

0 La ventaja principal de SNMP está en su sencillez. Se puede decir que su lema es el trabajo realizado con u n minimo coste de desarrollo. CMIP, sin embargo, es un protocolo más complejo y de más difícil implementación.

0 SNMP y CMIP se definen utilizando la Notación Sintáctica Abstracta 1 (ASN. I) , que es una forma de representación de la información tal que puede ser interpretada fácilmente por una persona, a diferencia de la codificación digital de los datos. La diferencia entre ambos reside en la utilización distinta de ASN.1 por los dos protocolos. SNMP pone restricciones en la codificación de temas complejos como las listas.

0 Un gran inconveniente de CMIP es que requiere más potencia de procesamiento que SNMP. Un agente típico de CMIP necesita unos 400Kb de memoria, mientras que uno SNMP, normalmente, unos 1 OKb.

CMIP es un sistema de gestión de red muy bien diseñado que mejora muchas de las deficiencias del SNMP. Si todo lo dicho hace a CMIP tan bueno, uno se puede hacer la pregunta de por qué no se usa apenas. La respuesta es que CMIP significa también desventajas: CMIP requiere 10 veces más recursos de red que SNMP. En otras palabras, muy pocas redes de la actualidad son capaces de soportar una implementación completa de CMIP sin grandes modificaciones en la red (muchísima más memoria y nuevos protocolos de agente). Por eso mucha gente piensa que CMIP está destinado al fracaso. La <mica solución es disminuir el tamaño de CMIP cambiando sus especificaciones. Así han aparecido varios protocolos que funcionan con la base de CMIP con menos recursos, pero todavía no ha llegado el momento de prescindir del tan extendido SNMP. Otro problema de CMIP es su

14

dificultad de programación: existe tal cantidad de variables que solo programadores muy habilidosos son capaces de sacarles todo su potencial.

3. Simple Network Management Protocol (SNMP).

3.1. Conceptos.

Antes que la Znlernet Activities Board (IAB, Organismo internacional encargado de fijar estándares para la interconexión y comunicación en una red) postulara los estándares para la administración de una red, un grupo de cuatro ingenieros realizaron un protocolo llamado el Simple Gatewq Monitoring Protocol (SGMP), dicho protocolo fue el pilar sobre el cual se creó el SNMP.

Un sistema de administración de una red consta de tres componentes :

0 Varios nodos administrados, cada uno conteniendo um agente ; 0 AI menos una estación administradora de la red (NMS, NetworkManagement Station) ; y 0 Un protocolo de administración de red el cuál es usado por la estación y los agentes para

intercambiar información.

La interconexión y comunicación entre distintas computadoras, gateways, etc. para implementar una red, puede llegar a ser de gran dificultad si no hay un acuerdo para el manejo de alarmas, indicadores de funcionamiento, estadísticas de tráfico, registros, estadísticas de conteo, y otros elementos necesarios en una red.

El reconocimiento de este problema trajo como respuesta que la IAB estableciera estándares para redes basadas en TCP/IP, fijando dos protocolos para administración de redes ; estos protocolos son conocidos como el Simple Network Management Protocol (SNMP), y el Common Management Inj’ormation Services and Protocol Over (CMOT). El más usado hoy en día es el SNMP.

Los siguientes temas analizan las componentes de una red, tomando como protocolo de administración a el SNMP.

3.1.1. Estación de administración.

Una estación de administración de red es un sistema en el cuál están corriendo :

El protocolo de administración de red ;y Las aplicaciones que administran la red.

Si vemos el protocolo como el mecanismo que provee la administración, las aplicaciones determinan las políticas de ésta administración. A las estaciones que administran una red de grandes dimensiones se les conoce como una Network Operations Center (NOC). No existe una relación fija entre los nodos administrados y las NOCS’s. Puede ser que muchos elementos de una red se asignen a una sola estación NOC, o contrariamente, muchas NOC’s administren a un mismo elemento.

Se debe enfatizar que, dado que hay muchos máis nodos administrados que estaciones administradoras en una red, es mejor tener un pequeño porcentaje de dispositivos controlados con una buena funcionalidad, que tener la gran mayoría.

3.1.2. Protocolo de administración.

Dependiendo el paradigma usado para la administración de una red, hay varias formas en las cuales un protocolo puede administrar a una red. Por ejemplo, en un paradigma de ejecución remota, el protocolo de administración es usado para intercambiar ‘“fragmentos de programa” los cuales son ejecutados en el nodo administrador.

16

En el Internet-standard Network Management Fmmework ( Framework usado para la administración de redes en la familia de protocolos Internet), se usa el paradigma de “Depuración Remota”, cada nodo administrado es visto como un contenedor de varias variables. Para leer el valor de estas variables, el nodo administrado es monitoreado. Para cambiar el valor de estas variables, entonces el nodo es controlado, es decir, se le envía un comando imperativo.

Además de las operaciones de lectura y escritura, hay otras dos operaciones que son necesarias :

o Una operación de recorrido, la cual permita a la estación administradora determinar que

o Una operación de captura, la cual permita al nodo administrado reportar un evento no ordinario variables soporta el nodo administrado ; y

a la estación administradora.

Tanto SNMP como el Internet-standard Network Management Framework son derivados del SGMP. El SNMP es u n protocolo de solicitudhespuesta asíncrono, esto significa que una entidad SNMP no necesita esperar una respuesta después de enviar un mensaje, puede enviar otro mensaje o realizar otras actividades.

3.1.3. Objetos administrados.

Un objeto administrado es el término usado para identificar cualquier recurso administrado en una internet, como puede ser L I ~ router, una conexión TCP, una tabla de direcciones IP, etc. ; cada objeto tiene un identificador que se deriva de la concatenación de los números asociados con cada nodo en el árbol de jerarquías (fig. 3.1 ). Por ejemplo, la MIB Internet es identificada por 1.3.6.1.2. l .

RAlZ

CCITT (O) /‘ \ //O\\, ISO-CCITT (2)

STND (O) REG-AUTH (1) MEM (;!) IE-org (3)

MIB (1)

Fig. 3.1 La jerarquía de registro Internet.

Un objeto administrado tiene asociado a 61 una sintaxis y semántica que son completamente abstractas. La estructura de la información de administración (SMI, Structure of Management Information), describe estas reglas; define el esquema d'e identificación y la estructura para los objetos administrados en la internet.

Cada objeto administrado se describe mediante una macro ASN.l definida en la SMI, ésta es llamada la macro OBJECT-TYPE. SMI describe los nombres usados para identificar los objetos administrados (que son los recursos de la red). Estos nombres son IDENTIFICADORES DE OBJETO ASN. 1 y usan la convención de nombramiento descrita en la figura 3.1.

Si vemos la colección de ob-jetos administrados residiendo en un contenedor virtual, como una base de datos, la SMI define el esquema para esa base de datos. Dicha base de datos es analizada posteriormente.

3.1.3.1. Management Information Base

La Internet-standard Management Information Base (MIAY, describe los objetos que se espera sean implementados por los nodos administrados que utilizan la familia de protocolos Internet. La estructura de administración de redes Internet esta organizada por grupos de objetos.

La primera Internet-standard MIB, conocida como MIEI-I, fue diseñada para incluir el mínimo nimero de objetos que se pensó serían de ayuda para la administración de una internet. A continuación se muestran los grupos de la MIB-I :

22 3

33 26 17 4 6

1 ¡4

Enlaces de red Traducci6n de direcs. IP

El protocolo IP El protocolo ICMP El protocolo TCP El protocolo UDP El protocolo EGP

Posteriormente se tuvieron grandes planes para la crealzión de la MIB-11. Desafortunadamente, debido a las muchas tareas que competían por realizarse, pocas se terminaron y el esfuerzo inicial se fue disipando. Después de que la IAB revisó su estrategia para la administración de redes, el grupo de trabajo SNMP se responsabilizó de la Internet-standard MIB y comenzó a trabajar en la MIB-11. El trabajo echo para la creación de la MIB-I1 se terminó a fines de 1989.

El énfasis primordial de la MIB-I1 fue crear nuevos objetos, manteniendo la compatibilidad con SMI y la MIB-I. A continuación se muestra la MIB-I1 terminada.

La MIB-I1 usa el mismo esquema de nombramiento que la MIB-I. Dado que la MIB-I1 es un superconjunto de la MIB-I, los objetos contenidos en ambas MIB's tienen el mismo nombre.

En una organización no es necesario implementar todos los grupos de objetos MIB. Claro que si esta usándose gateways exteriores, el grupo EGP debe ser olbligatorio ; o bien, si se implementa UDP en la capa de transporte, el grupo TCP no es necesario.

3.1.3.2. Agentes.

El SNMP define una comunidad como la interacción entre un agente SNMP y uno o más administradores SNMP. Las semánticas de una comunidad son complejas, pero, pero la sintaxis es simple. Una comunidad SNMP es escrita como una cadena de octetos sin interpretación. La cadena de octetos es llamada el nombre de la comunidad. Cada octeto puede tomar el valor de O a 255, aunque los octetos en la mayoría de los nombres de las comunidades usan caracteres ASCII.

Cuando un mensa-je SNMP es intercambiado, contiene dos, partes :

0 Un nombre de una comunidad, con cualquier información adicional requerida para validar que

0 Datos, los cuales contienen una operación SNMP y los operandos asociados a ella. la entidad SNMP emisora es un miembro de la comunidad identificada ; y

En la figura 3.2 se muestra un ejemplo de como trabajan las operaciones SNMP. Para simplificar sólo se mustra una estación administrada, pero queda por entendido que pueden existir n estaciones administradas por una misma estación administradora. En el dibujo, un centro de control de red (Una computadora host, gateway, o cualquier otra máquina), se c'omunica con un gateway IP que contiene un agente IP. El agente ejecuta las operaciones SNMP y accesa la MIB residente en el gateway. Después, el agente IP usa los mensajes SNMP para comunicarse con el centro de control de la red. Estos mensajes soportan operaciones tales como obtención de información, cambio en la información, emisión de mensajes no solicitados en eventos de alarma, etc..

Gateway IP

SNMP Centro de control

de la red Agente

SNMP

Fig. 3.2 Operaciones SNMP entre un agente y un centro de control de red.

Los datos sobre los cuales operan estos mensajes son defiinidos por la MIB, la cual se ilustra en la figura 3.2. En un ambiente típico, el control de la red c'ontiene la MIB para todos sus recursos administrados (objetos). Sin embargo no es necesario que cada agente almacene la MIB por completo, cada agente almacena la porción de la MIB que es relevante para su propia operación. La porción de la MIB contenida en u n agente suele llamarse una vista.

3.2. ASN.l (Abstract Syntax Notation One)

3.2.1. Representación de ASN.l

ASN.1 define una notación abstracta que permite describir los datos sin importar como están implementados. Esto permite que cada plataforma de hardware utilice la técnica más apropiada para implementar las reglas. ASN.1 utiliza tipos para describir los datos y BER (Basic Encoding Rules) describe como se representan esos tipos. DER (Distinguished Encoding Rules) es un subconjunto de BER que proporciona una codificación única a cada valor de ASN.l. Cabe mencionar que ASN.l es utilizada para dos propósitos diferentes:

0 Definir los formatos de los PDUs intercambiados por el protocolo de administración; y, 0 Como el medio para definir los objetos que son administrados.

Usar ASN.1 es como utilizar una notación de transferencia. Una vez que las estructuras de datos pueden ser descritas de una forma independiente de la arquitectura de la computadora debe haber una manera de transmitir esas estructuras sin ambigüedad a través de la red. Este es el trabajo de la notación de sintaxis de transferencia. Uno puede tener varias notaciones de sintaxis de transferencia para una sola sintaxis abstracta.

La estructura de administración de redes de internet utiliza sólo un subconjunto de ASN.l ya que los principios generales de ASN. 1 nos pueden generar dificultades innecesarias. En ASN.l son definidos tres tipos de objetos:

0 types, los cuales definen nuevas estructuras de datos; 0 values, que son instancias de un type; y,

mucros, que usadas para cambiar la gramática del lenguaje ASN. 1

Cada uno de estos objetos es llamado utilizando una palabra ASN.l; también ASN.l utiliza una convención alfabética para indicar el tipo de objeto al que esa palabra se refiere:

o para u n type, la palabra comienza con una mayúscula (P.e. Gauge); 0 para u n vmlzlc (una instancia o variable de un tipo), la palabra comienza con una minúscula (P.e.

0 para una 177~~1-o, la palabra es escrita con mayúsculas (1p.e. OBJECT-TYPE). internet); y,

Las palabras reservadas del lenguaje ASN. 1 se escriben con mayúsculas. Un tipo ASN. 1 es definido usando una sintaxis como se muestra:

NameOffype ::= TYPE

De igual forma, u n valor (más propiamente dicho una instancia de un tipo de datos) es definida como sigue:

nameOfValue NameOfType ::= VALUE

Esto es, la primera variable se llama (nameofvalue), después se declara el tipo (NameOfType), y después se le asigna u n valor.

20

"" .. .. . . . . ""

3.2.2. Tipos de datos

La estructura de administración utiliza cuatro tipos de @pes ASN.l:

3.2.2.1. Tipos Simples

a) INTEGER: Es un tipo de datos que toma como valor un número entlero. Nótese que como ASN.1 describe un

objeto conceptual, no existe limitación en cuanto al número de bits que se utilicen para representar el número requerido). Además, para definir un tipo de datos entero, es conveniente asociar nombres simbólicos para los valores que pueden tomar las instancias de este tipo de datos, P.e.,

status ::= INTEGER {up( l), down(2), testing1(3)}

myStatus Status ::= up -- or 1

De acuerdo con ASN.1, cualquier cantidad numérica1 puede ser asignada a mystatus. Por convención, si se enumeran valores simbólicos para un tipo de datos entero, sólo esos valores son válidos para instancias de ese tipo de datos.

b) OCTECTSTMNG:

puede tomar valores entre O y 255. ES u n tipo de datos que tiene cero o más octetos como valor; cada byte en una cadena de octetos

c) OBJECT IDENTIFIER: U n identificador de ob-jeto, es un tipo de datos que denota a un objeto llamado de una manera

correcta. Los identificadores de objeto nos permiten reconocer los objetos, de acuerdo con la semántica asociada con el objeto. Un identificador de objeto es una secuencia de valores enteros no negativos que recorren el árbol de administración de internet que se muestra en la figura. Cuando se describe un identificador de objeto hay varios formatos que se pueden utilizar. El formato textual más conciso, es nombrar todos los valores enteros que se 'encuentran cuando se recorre el árbol, comenzando por la raíz y descendiendo por las ramas. Los valores enteros son separados por un punto. Así 1.0.8571.5.1 identifica al objeto que esta comenzando por la raíz, después en el nodo con el número 1, después en la nodo O, y así sucesivamente.

d) NULL:

actualmente no se usa. También la estructura de administración admite la existencia de este tipo de datos, aunque

3.2.2.2. Tipos Construidos

Los tipos construidos (C'o~structed Types) ASN.l utilizados en la administración son los siguientes:

a) SEQUENCE:

tipos ASN.1 simples. Es similar a una estructura en la mayoría de los lenguajes. Es un tipo de datos que contiene una lista ordenada de celro 6 más elementos, los cuales son otros

b) SEQUENCE OF TYPE:

Es u n tipo de datos que contiene una lista ordenada de cero ó más elementos del mismo tipo ASN.1. Esto similar a los arreglos dinámicos en la mayoría de los lenguajes: el número de elementos no se conoce hasta que se crea el arreglo, pero cada elemento tienle sintaxis idéntica.

3.2.2.3. Tipos Etiquetados

Además de utilizar tipos construidos, ASN.l proporciona métodos para definir nuevos tipos de datos etiquetando un tipo previamente definido. ASN.1 define cuatro tipos de etiquetas: universal tugs, upplicution-wide tugs, context-specific tags y private-use tags. Todas las etiquetas consisten de una clase y nitmero no negativo, de esta forma se pueden definir muchas etiquetas application-wide en u n módulo, cada una con diferente número.

Desde u n punto de vista conceptual, etiquetar un tipo de dato consiste en poner el tipo de dato existente y la etiqueta dentro de u n tipo de dato nuevo.

3.2.2.4. Subtipos

Además de etiquetar u n tipo de dato para duplicar la semiintica de un objeto, también es útil refinar la semántica. Por qjemplo, anteriormente vimos que cada octeto de una cadena de octetos lleva un valor de O a 255. Podría ser iltil crear u n nuevo tipo de datos para cadenas de otra indole.

Una extensión iltil definida para ASN.1 son los subtipos, los cuales permiten a los programadores de ASN.1 hacer los refinamientos de la semántica. Las rleglas para crear subtipos son extensas y complicadas, pero para la administración sólo ocuparemos dos, como se muestra en los ejemplos:

IpAddress::= -- in network-byte order

IMPLICIT OCTET STRING (SIZE (4)) [APPLICATION O]

Counter::= [APLICATION 11

IMPLICIT INTEGER (0..4292967295)

En el primer e-jemplo. se define un tipo de dato IpAddress que contiene una cadena de octetos. Tampoco se tienen restricciones para el valor de cada octeto, la longitud de la cadena es exactamente 4. En el segundo ejemplo se define un tipo de dato de valores enteros; las instancias de este tipo de dato pueden tomar valores no negativos entre O y 232.

3.3. Operadores SNMP y el Servicio de Transporte

Los requerimientos de transporte que SNMP necesita sor1 pocos. Las funciones de administración de redes por lo general se llevan a cabo por “bombardeo”. ]El requerimiento básico es un servicio de transporte no orientado a conexión; esto permite a la estación de administración determinar el nivel apropiado de retransmisión para solucionar redes congestionadas.

SNMP define también una comunidad (community), que es una relación entre un agente SNMP y uno ó más administradores SNMP. El nombre de la comunidad es una cadena de octetos y cada octeto puede contener valores entre O y 255, esto es sólo los caracteres imprimibles del código ASCII. Cuando son intercambiados paquetes, estos contienen dos partes:

22

.. . ””. l..l . .. . .-

0 Un nombre de una comunidad, junto con alguna información adicional necesaria para validar

0 Datos, que contienen una operación SNMP y los operandos asociados. que la entidad transmisora SNMP es un miembro de l,a comunidad identificada; y,

Una vez que la entidad transmisora ha sido validada colmo miembro de una comunidad, el nodo administrado debe determinar que nivel de acceso es permitido. A un conjunto de objetos visibles a una comunidad particular se le llama vista o alcance (view). Para cada objeto en la vista, la comunidad define u n modo de acceso que puede ser: read-mly ó read-write.

En la siguiente tabla se muestran los operadores permitidos por SNMP V l y V2:

3.3.1 SNMP GET

El comando SNMP GET inicia un query de administración de redes a una agente remoto y con esto una respuesta es transmitida por el agente. El comando SNMP GET trata de traer los objetos de la información de administración.

La solicitud Get puede generar un nilmero de errores que son regresados por el agente. Estos errores incluyen noS~~chNatne, tooBig, y genErr. A continuación sle muestran los errores más comunes que llegan desde el agente:

0 Aggregate error; este error llega cuando la estación administradora ha tratado por error de traer u n objeto renglón. El error regresado es “noSuchName” con un índice de error que indica la variable.

0 Variable erro^: este error es una indicación de un intento de traer una variable que no se puede

0 Set error: este error indica que el PDU de respuesta excedería a las limitaciones del agente. El

0 Binding error: Este error es regresado cuando una variable no concuerda exactamente. El error

traer. El error regresado es “genErr”.

error regresado es “tooBig”.

regresado es “noSuchName”.

3.3.2. SNMP GETNEXT

El comando SNMP GETNEXT trata de traer los subárboles especificados de la MIB. La implementación del comando SNMP GETNEXT puede variar de agente en agente o de administrador en administrador.

El comando GETNEXT puede generar un gran número de errores que son regresados por el agente. Estos errores son casi los mismos que se generan por el comando GET, sólo con algunas pequeñas diferencias:

0 Size error: este error indica que el PDU de respuesta excedería las limitaciones del agente. El

0 Binding ermr: este error es regrasado cuando un nombre de variable no concuerda. El error

0 Lexicogruphicul error: esta condición llega cuando el sucesor a la variable solicitada en el

error regresado es “tooBig”.

regresado es “noSuchName”.

campo asociado no puede ser traida. El error regresado es “genErr”.

3.3.3. SNMP GETBULK

La estación administradora puede usar el operador GETNEXT repetidamente, usando los resultados de la operación anterior como operandos de la siguiente operación. El GETBULK tiene un RFC completo dedicado a su implementación (RFC 1 187).

El GETBULK regresa los mismos errores que GETNEXT. La solicitud GETBULK opera escencialmente e-jecutando multiples compandos GETNEXT. El PDU de GETBULK es similar a cualquier otro PDU, escepto que la sintaxis de dos campos cambia. El campo Error Status se reemplaza por Non-Repeaters, y Error Index se cambia por Max-Repetitions. Los valores de estos campos indican el proceso que se va a llevar acabo. El campo Non-Repeaters define cuantas de las variables solicitadas no son procesadas varias veces. Este campo es usado cuando algunas variables son objetos escalares, es decir, objetos que tienen una instancia.

Las variables solicitadas son regresadas en un PDU, de acuerdo a la forma en que esas variables son solicitadas. El nilmero total de variables puede ser calculado como sigue:

=MIN-OF + (MAX-REPS * MAX-NUM) donde : MIN-OF = el valor más chico de el campo Non-Repeaters y un número de variable asociada MAX-REPS = el campo Max-Repetitions de la solicitud MAX-NUM = el nimero mínimo de variables asocicadas y cero

3.3.4. SNMP SET

El comando SNMP SET manda una solicitud de administración a un agente remoto para cambiar el valor de una variable SNMP. El comando SNMP SET, cuando se usa en una renglón de la tabla que contiene variable milltiples tendrá varias variables, una para cada objeto, todas con el mismo identificador de ob.jeto.

En SNMP, en el nivel de protocolo, una estación administradora usa una operación SET que contiene u n conjunto arbitrario de variables asociadas. En el caso donde un agente detecte que una o más de esas variables asociadas se refieren a una instacial de objeto que no esta disponible en el agente, puede de acuerdo con las reglas de SNMP, compo~rtarse de acuerdo a uno de los siguientes paradigmas:

1. Puede rechazar la operación SNMP SET refiriendose como instancias de objetos no existentes y regresando una respuesta con el campo de error-status puesto en “noSuchName” y el campo de error-index referenciado a la primera instancia equivocada.

2. Puede aceptar la operación SNMP SET como solicitud para la creación de nuevas instacias de objetos correspondientes a cada una de las instacias de objetos nombradas en las variables asociadas. El valor de cada nuevo objeto creado es especificado por la componente “value” de las variables asociadas. En este caso, si la solicitud especifica un valor para un nuevo objeto incorrecto, ya sea por el valor o por la sintaxis, entonces rechaza la operación SNMP SET y responde con el campo de error-status en “badvalue” y el campo de error-index referenciado a la primera variable equivocada.

3. Puede aceptar la operación SNMP SET y crear nuevas instacias de objetos corno se describe en el punto 2, pero además, crear instancias de objetos extras para completar un renglón en una tabla lógica. de la cual las instancias especificadas pueden ser parte.

La implementación del operador SET es una de las más difíciles dentro del agente. Puede regresar varios errores al NMS; dichos errores son similares a los de los demás comandos de SNMP:

Variable Bindings error: este error se presenta cuandlo el campo de las variables asociadas no está disponible para las operaciones de SET. El error regresado es “noSuchName” con el campo error-index indicando la variable. Variable Field error: este error es una indicación de que el campo de las variables asociadas no llena los requerimientos TLV. El error regresado es “badValue”. Size error: este error indica que el PDU de respuesta excedería las limitantes del agente. El error regresado es “tooBig” con el campo error-index en O. General Set error: Este error es regresado cuando una variable no puede se alterada por alguna razón. El error regresado es “genErr”.

3.3.5. SNMP INFORMREQUEST

El InformRequest es utilizado para las comunicaciones entre administradores. Esta característica puede ser utilizada para administración distribuida así como para proporcionar administración redundante. Esta funcón fué introducida para la versión 2 pero muchos fabricantes están reforzando la versión 1 con una función similar.

3.3.6. RESPUESTAS

Es un punto que tiene que quedar bien claro; existe una respuesta SNMP a cada comando SNMP. Podríamos pensar que algunos comandos, como el SET, no tienen una respuesta. Muchas aplicaciones de administración mandan u n GET después de un SET para asegurarse de que la variable ha sido cambiada correctamente.

3.4. Estructura del PDU (Protocol Data Unit)

El UDP es el transporte de elección para SNMP, también puede ser utilizado con cualquier transporte que soporte los requeriminetos. Se pueden encontrar muchos agentes que pegan el transporte en el agente SNMP. Esto se ve muy frecuentem’ente en ambientes PC. Muchas veces los agentes SNMP de PC traba-jan a través de los controladores de sockets

En la siguiente figura se muestra como el SNMP esti colocado sobre la pila UDP/IP en la implementación normal.

SNMP Protocol Data

SNMP Header

Network (I P)

I I 26

No importa de que lado venga el PDU SNMP, ya sea del lado de administración o del lado del agente, la transferencia se lleva a cabo de la misma forma. Esto es, el dato es metido en un paquete SNMP. Después de que el dato es colocado en el buffer es codificado de la forma ASN.l. El UDP suelta entoces el paquete. El paquete se suelta sólo cuando está listo para enviarse. El UDP obtiene el número de puerto que se va a usar con el paquete.

NOTA: El témino puerto es u n método viejo para asociar una definición de estructura con una aplicación. La estructura contendrá datos que permitan al sistema operativo ver hacia a donde va a mandar los datos. Debe quedar claro, que hay dos puertos involucrados, el fuente y el destino. El puerto destino puede estar en la misma máquina en la que está el puerto fuente.

El número de puerto UDP también proporciona una refierencia al protocolo que es el Upcall (el protocolo que esta sobre el UDP) asociado con este paquete. Los números de puertos usados por SNMP son puertos “bien conocidos”. Esto significa que los números de puertos son configurados para el uso de SNMP. Los números de puertos 161 y 162 son para uso de SNMP. Con el 161 para intercambios normales de SNMP y el 162 para mensajes cle traps. Estos números de puertos tienen que ser configurados en algún lugar para que SNMP los accese. En un ambiente UNIX los puertos se configuran en “/etc/services”. En u n sistema fijo, generalmente no habrá una estructura de archivos y el número de puerto está muy ligado al código.

Las capas usadas por SNMP deben de ser capaces de proporcionar por lo menos cinco funciones. Estas son:

End-to-End Checksum: Generalmente amplia la confiabilidad de la transferencia de datos. Multiplexing/Demultiplexing: Proporciona servicios de multiplexamiento y de detnultiplexamiento. Routing: El ruteo proporciona la utilidad sobre todo para la administración de la red siendo capaz de redireccionar los paquetes alrededor de áreas con errores. Esto permite a la administración de red continuar operando durante pérdidas de servicios localizadas. Media Independence: Esta capacidad permite muchos tipos diferentes de elementos de red que sean administrados. Tratar el SNMP con un protocolc) de ligado de datos en particular limita la habilidad de SNMP de administrar una variedad de equipo de red. Fragmentation y Reassembly: Esto está relacionado con la independencia del medio.

Variable Lenght

ASN.l Encoded + I SNMP D a t a l 6 byte:;

20 bytes

14 bytes

Figura 3.3. Las capas de SNMP Transport

El PDU de SNMP primero se formula usando condificación ASN.1. Después es colocado en un buffer, y le se le dice al UDP “haz esto.” el SNMP llama a l servicio UDP para que se lleve el PDU usando el API UDP.

1 Community String SNMP Data I PDU Type Enterprise Address Type Variable Bindings

Figure 3.4. El PDU de SNMP

El PDU de SNMP está formado de un número de campos que se muestran en la figura 3.5.

Wrapper ... Object 2 Object 1 E:rror Index Error Status Request I.D. PDU Type

Wrapper Contains Athentication and Pricacy information PDU Type specifies the PDLl trasrnitted

Requies ID is used to correlate the request and response Error Status specifies exception condition

Error Index is a pointer to ythe variable causing the error Variable Binding Is the pairing of the object and its value

I

Figura 3.5. El PDU de SNMP con detalle

El PDU de SNMP se coloca en área de datos de un dlatagrama UDP. El área de datos de un datagrama sencillo UDP generalmente es suficiente para un PDU de SNMP, aún cuando el PDU de SNMP tiene múltiples variables asociadas a él.

El PDU de SNMP descrito anteriormente es encapsulado en el datagrama UDP. L a siguiente figura muestra la técnica de encapsulación.

Filled in when UDP Filled in when the massage arrives agent code starts

Checksum Filled from size Calcualted

of message

Como se puede ver en el dibujo, el hecho de que el Datagrama UDP contiene un PDU de SNMP no es de real importancia para el UDP. Este simplemente lo va ,a soltar al IP sin importar que datos lleve.

28

Cuando se lo suelta a IP, tenemos una capa más de encapsulación, y estamos más cerca de que el dato sea puesto en el cable.

Los párrafos anteriores, tratan acerca de los paquetes exteriores. Ahora se describen los pasos a seguir para recibir u n paquete. Casi siempre es lo inverso que para enviar un paquete.

Es importante entender que cuando el paquete se recibe, el primer paso es que el IP le quite el encabezado. Este checará la validez del paquete y después :se lo suelta al UDP, si éste es el protocolo referenciado en los datos de encabezado. En el caso de SNMP, el protocolo superior quizás sea UDP, el UDP le quitará el encabezado UDP después de la validación del paquete.

NOTA; Tanto el UDP como el IP están claramente definidos en los RFC’s, y aquí sólo se presenta un bosquejo. También se debe entender que un encabazado del medio precede el encabezado IP. El encabezado del medio puede ser token ring, ethernet, o cuallquier otro tipo de medio.

El UDP se da cuenta del identificador del “PUERTO” y asocia ese puerto con el SNMP. Recordando que el número de puerto para SNMP es el 161, y ningún otro portocolo usa ese número. El UDP entonces sabe que se presentó una interrupción y una llamada a SNMP. Si alguien más manda basura a tu dirección IP habilitando el puerto SNMP en el UDP, la basura puede llegar al agente SNMP. Muchos agentes tienen rutinas que tratan de recuperar un PDU malo. Si todo el paquete es basura, lo descarta. Muchos PDU’s con basura pueden ser recuperados; hasta cierto grado.

r IP &UDP Header I 1 N e t w o r d Header 1 SNMP

Header I Low IS0 I CMISE

Message

\ ASN.l Encoded 1

Figura 3.6 Mensaje

Trailer if used

4. Diagrama de clases de REMonitor.

Dispositivo Seleccionado

Intervalo de I Variables Seleccionadas Vector de DlsposItlvos Direcciones Resultados

del Reqwst

Alarmas

Datos del PDU SNMP PDU

\ \

PDU' s

/

i Network , , . . / - - " - ..-

"""""" """."

Fig. 4. l . Diagrama de clases de REMonitor

String NameFile; Boolean Keepopen, Save, DialOpen; REMonitor remonitor; QuestionDialog questionDialog; ConfirmationDialog confirmDialog; Component Item; public int tamy; public Dimension tam; public Panel panpri; private Scrollbar ver ; private void GuardList() public void SaveAs() public void Save() public void Open() public void Close() public void New() private int SearchIco()

Es la clase mediante la cual se realiza el control de archivos, ya sea apertura, guardado de información, salvar con u n nombre nuevo, y cerrar el archivo. Sirve además como interfaz para mostrar los dispositivos que se están monitoreando.

Constructor public REMFile (REMonitor remon)

Métodos :

private void GuardList()

ese momento. Es invocada por los métodos SaveAs y Save. Realiza el guardado de la configuración actual del archivo cuyos dispositivos se monitoran en

public void SaveAs()

recien creado. Guarda la configuración del archivo actual con un nombre diferente, o nuevo en caso de estar

public void Save()

ese momento. Hace el guardado de la configuración del archivo cu:yos dispositivos se están monitoreando en

public void Open() Muestra el diálogo de apertura de un archivo.

public void New() Crea una nueva configuración sin elementos.

private int SearchIco() Indica al mktodo Delete cual dispositivo se encuentra seleccionado en la configuración actual.

Long Time; String MaxDir, MinDir; TextField TFMaxDir, TFMinDir, TFTime; Button BotAccept, BotCancel; ConfirmationDialog confirmDialog; REMonitor remon; I public boolean ChKTokenString(Stri1Dir)I

Se usa como interfaz para configurar el rango de dir'ecciones IP, y su intervalo de tiempo para el envio de PDUs.

Constructor public Setup(REMonitor rem)

Métodos :

public boolean ChKTokenString(String Dir)

sean correctos. Verifica que el formato de las direcciones, y el intervalo de tiempo para el envio de PDUs

Setup setup; Vector activaCopia; REMonitor remon; public synchronized void ScanNet() public synchronized boolean OpcSetup() public void run()

Esta clase hace posible la ejecución simultánea de dos procesos : 0 El configurar el rango de direcciones IP y su intervalo de tiempo que se desean monitorear 0 El envio de PDUs a las direcciones preestablecidas por el usuario, si es que ya ha dado un rango

antes.

Constructor public MyThread(Vector copia,REMonitor rem)

32

"" P"

Métodos :

public synchronized void ScanNet()

ejecuta una vez que el usuario ha seleccionado la opción Start, y finaliza con la opción Stop. Es con el cual se envían los PDUs al rango de direlcciones que el usuario ha configurado. Se

public synchronized boolean OpcSetup()

tiempo para el envío del PDU a ellas. Con el se realiza la configuración de las direcciones IP a monitorear, así como el intervalo de

public void run() Coordina los dos métodos anteriores, se ejecuta durante todo el programa.

public String DirDevice; public byte TypeDevice; public String NameDevice; public short CoorDevice[J; public int Id; public short TamFrame[]; nublic boolean Status; public String GetDir() public void LetDir(String Dir) public int GetId() public void Letld(int Ident) public byte GetTypeO public void LetType(byte Tipo) public String GetName() public void LetName(String Name) public short[] GetCoorO nublic void Letcoodint xx.int w)

Es la clase que sirve como molde para la generación de nuevos dispositivos, y para la lecturdescritura de los mismos desde/a un archivo.

Constructor public Device()

Métodos :

public String GetDir() Regresa la dirección IP del dispositivo.

public void LetDir(String Dir) Coloca la dirección IP del dispositivo.

public int Getld() Regresa el identificador del dispositivo.

public void LetId(int Ident) Coloca el identificador correspondiente al dispositivo.

public byte GetTypeO Regresa el tipo de dispositivo al que pertenece.

public void LetType(byte Tipo) Coloca el tipo al dispositivo.

public String GetName() Regresa el nombre del dispositivo.

public void LetName(String Name) Coloca el nombre del dispositivo.

public short(] GetCoor() Regresa la posición objeto.

public void LetCoor(int xx,int yy) Guarda las coordenadas del dispositivo.

REMonitor rem; boolean valor; public InsertaDispositivo() private Panel datos() private boolean validaDatos() public void Delete()

Es la clase mediante la cual se realiza el control de los objetos de tipo dispositivo (los cuales por medio de esta clase se realizan las operaciones de anexar y eliminación dentro del vector guardando las características de los mismos objetos.

34

_I_ _. 111_1 ..

Métodos :

private Panel datos()

poder lnodificar uno seleccionado esto depende del valor que tenga la variable nuevo Este metodo solo pone en un panel los datos que se ]necesitan para un dispositivo nuevo o para

private boolean validaDatos()

datos() con respecto al tipo de dispositivo son validos, regresando falso en caso contrario. Si el tipo no a sido seleccionado se desplegara un mensaje de error colmentando que el tipo es incorrecto, obviamente sin poder dejar salir hasta que sea correcto, regrlesando un valor diciendo que los datos son incorrectos.

Este metodo regresa u n valor verdadero si los datos que fueron introducidos en el metodo

public void Delete()

activa. Siendo que el mismo método busca el elemento que se encuentre seleccionado, para después eliminarlo del vector de dispositivos.

El método delete() permite eliminar un determinado elemento del frame o de la ventana

REMonitor rem; Dispositivo temp; int tipo; public void InsertaIcono() public void DibujaVectorO public void unoSolo() private String tipoimagen()

Esta clase permite dibujar los iconos, representando los dispositivos en la pantalla con el nombre de este o su dirección y además el dibujo que lo represente, pudiendo dibujar todos los dispositivos contenidos en el vector o uno solo.

Constructor public Insertalcono(REMonitor rem)

Métodos :

public void DibujaVector()

dependiendo el tipo de dispositivo, llamando al metodo unoSlolo que se encarga de esto. Metodo que se encarga de dibujar en el frame que esta a la vista, toda la lista con los iconos,

public void unoSolo(Dispositivo temp)

de que tipo de dispositivo va ha dibujar en la pantalla con su respectiva etiqueta, siendo el icono a dibujar llamado con el método tipoimagen y este regresa el nombre de la imagen a dibujar.

El método LlnoSolo recibe como parámetro un Objeto tipo Dispositivo, esto para poder saber

private String tipoimagen(int tipo)

corresponde a la imagen, por default se regresa el user.gif El metodo tipoimagen recibe el numero de tipo de la imagen regresando el nombre que le

publicDispositivo() private Panel datos()

Con esta clase se realizan las operaciones de interfa;! de ingresar nuevo dispositivo o la modificación de algiln dispositivo que hay escogido; siendo para el caso de los dispositivos a modificar se le pone los datos del mismo para que sean camlSados.

Constructor private Dispositivo()

Métodos :

private Panel datos()

para poder modificar uno seleccionado esto depende del valor que tenga la variable nuevo. Este metodo solo pone en un panel los datos que se necesitan para un dispositivo nuevo o

SnmpAPI api; MibModule m 1 ; SnmpSession session; SnmpPDU pdu; public Frame frame; public Vector PDUs; private TextField fromTF, communityTF, enterpriseTF, agentTF, trap-typeTF, specific numberTF, timeTF; private TextArea varbindsTA; private Button bwd, fwd, ok; public int index; public alarms() public void run() private Panel pduDataSetup() protected Panel pduDescrSetup() protected Panel buttonsSetup() public void updateDisplay(int i ) boolean handleEvent( Event evt ) public Insets insets()

-

Esta clase se encarga de generar una sesión SNMP mediante un Thread con lo cual es posible estar escuchando desde que se inicia el programa y de una manera ininterrumpida al puerto de las

36

alarmas SNMP (puerto 162), dichas alarmas se van almacenando dentro de un Vector de PDU's, para . posteriormente poder mostrar todas las alarmas que hayan llegado al puerto antes mencionado.

Constructor public alarms()

El constructor se encarga de generar iniciar una nueva sesión de SNMP independiente, la cual también debe cargar las definiciones de la MIB del rfcl:213, y debe estar direccionada para que escuche al puerto 162. También genera un nuevo frame para. que se desplieguen las alarmas recibidos, aunque no se despliegue dicha ventana.

Métodos :

public void run()

162. Esta es un método propio de la clase Thread, la cual arranca proceso para escuchar el puerto

private Panel pduDataSetup()

dentro de las variables propias de la clase para posteriormente desplegarlas. Esta función lee los datos de u n PDU que este en el vector de PDU's recibidos, y los mete

protected Panel pduDescrSetup0

independiente ya que se despliega en un panel diferente. Esta función lee los datos del campo de descripciiin del PDU, este campo se lee de forma

protected Panel buttonsSetup()

alarmas. Esta función define las posiciones de los botones que se mostrarán en la ventana de las

public void updateDisplay(int i)

como parámetro. Esta función actualiza los datos de la ventana de alarmas dependiendo del índice que se reciba

boolean handleEvent( Event evt )

realizaran después de presionar los botones de la ventana. Esta función es propia de la clase frame la cual permite manipular las acciones que se

public Insets insets() Esta función es propia de la clase frame que permite redefinir los bordes del frame.

variablesPanel vp; selectedpanel sp; descrPanel dp; public buttonsPanel(variab1esPanel vp, selectedpanel sp, descrPanel dp) public boolean handleEvent( Event evt ) public Insets insets() private void addNode() nrivate void addA11NodesO

Esta clase es un panel el cual define como estarán colocados los botones que permiten agregar las variables a monitorear desde el panel de variables disponibles (variablespanel) o eliminar variables desde el panel de variables seleccionadas (selectedpanel).

Constructor public buttonsPaneI(variablesPane1 vp, selectedPane1 sp, descrpanel dp)

Métodos :

public boolean handleEvent( Event evt ) Esta función es propia de la clase frame, la cual nos permite manipular las acciones que se

realizarán cuando alguno de los botones sea presionado. Las acciones definidas son : agregar una variable, eliminar una variable, agregar todas las variables, e:liminar todas las variables.

public Insets insets()

panel Esta función es propia de la clase panel y permite redefinir el área de despliegue dentro del

private void addNode() Función que se ejecuta cuando se presiona el botón "Add", y busca que variable esta

seleccionada en ese momento en el panel de variables disponibles y la agrega al panel de variables seleccionadas.

private void addAIINodes() Esta función se ejecuta cuando se presiona el botón "Add All", la cual revisa en que nivel del

árbol de la MIB se encuentra el panel de variables y agrega todas las variables que sean hojas terminales.

38

"11 "" I "" P

private Vector nodes; private SnmpAPI api; private mibBrowser mb; private displayResults dr; public controlPanel(Vector nodes, SnmpAPI api, mibBrowser 111 b) public boolean handleEvent( Event evt )

Este panel especifica donde serán colocados los botones de control, con dichos botones se manejar las acciones se realizarán con las variables ya seleccionadas en selectedpanel.

Constructor public controlPanel(Vector nodes, SnmpAPI api, m ibBrowser mb)

El constructor define en que posiciones estarán colocados los botones así como sus propiedades.

Métodos :

public boolean handleEvent( Event evt )

ya sea que se confirme el envío de las variables o que se canlcele la operación de selección. Este método maneja las funciones que se realizarán cuando alguno de los botones se oprima,

TextArea text; Dublic descrPanel0

Este panel contiene la descripción de la variable seleccionada en el panel de variables disponibles. Dado que este campo es de tipo texto es necesario desplegarlo de manera diferente.

39

. "."..x .. ." _. .

public Vector PDUs; private Panel pduData, pduDescr, buttons; private Label hostNameLab, hostAddressLab, resultslab; private TextField hostNameTF, hostAddressTF; private TextArea resultsTA; private Button bwd, fwd, ok; public int index; public displayResults() protected Panel pduDataSetup0 protected Panel pduDescrSetup() protected Panel buttonssetup() public void updateDisplay(int i) public boolean handleEvent( Event evt )

Esta clase define la ventana donde se mostraran los PDU's que hayan llegado por el puerto de SNMP (1 6 1 ), los cuales van siendo almacenados por orden cle arribo en un vector.

Constructor public displayResults()

Define el esqueleto de la ventana sin mostrarla.

Métodos :

protected Panel pduDataSetup() Todos los PDU's que llegan se almacenan en un vector ; una vez almacenados cada PDU se

divide para fines de presentación en dos partes : la de datos generales y otra que es la descripción de los datos, para lo cual se definen a su vez dos paneles diferentes. En esta función se define el panel de los datos generales.

protected Panel pduDescrSetup()

mostrando. En esta función se define el panel en donde se pondrá la descripción del PDU que se esté

protected Panel buttonsSetup()

PDU's, así cotno para terminar de ver los PDU's. En esta función se define el panel que contendrá los botones de control, para ver todos los

public void updateDisplay(int i)

y sirve para pintar en la ventana los datos del PDU solicitado Esta función es mandada llamar cuando se selecciona uno de los botones del panel de botones

public boolean handleEvent( Event evt ) Esta función es propia de la clase panel y permite tomar el control de los botones que están

dentro del panel de botones. Si se elige el botón para adelantar se manda llamar el método para actualizar los datos con el índice actual mas uno. Si se elige el botón para retroceder se ejecuta el método para actualizar con el índice menos uno.

40

Esta clase define u n panel donde se mostrará la información del dispositivo que se haya seleccionado previamente y que es sobre el cual se realizalrá el query por seleccionar. El constructor recibe como parámetros la dirección 1P y el nombre del dispositivo a monitorear.

buttonsPane1 buttonsP; descrPanel descrP; static variablespanel variablesip; static selectedpanel selectedP; SnmpAPI api; public centralPanel(SnmpAP1 api)

Este panel, que es la parte central de la ventana MibBrowser, se divide en cuatro partes, cada una de las cuales es una clase independiente. Una parte contiene las variables disponibles en el árbol de la MIB (variablesPanel), otra parte contiene las variables que ya han sido seleccionadas (selectedPanel), otra parte contiene un panel en donde se muestra una breve descripción de la variable que este seleccionada en el panel de las variables disponibles (descrpanel) y por último una clase que contiene los botones de control para agregar y quitar variables (buttonspanel).

Esta clase es el contenedor de las tres clases que: conforman la ventana MibBrowser. El constructor inicializa la ventana y la muestra.

41

private static final int TIMEOUT = 10000; Datagramsocket echosocket = null; private InetAddress[] remoteMaclines; private static final int SMALLARRAY = 1; private String arguments; private Setup config; private Vector activa; private int totalNumber=O; public scanNetwork (Setup config, Vector activa) private String nextAddress(String previusAddress, String IastAddress) public void run() private int isInVector(String address) protected void printEchos(DatagramPacket[] echos) nrotected void finalize0

Esta clase toma el intervalo de direcciones a monitorear del panel de control y ejecuta un Thread el cual se ejecuta cada que se cumple el tiempo indicado en el panel de control ; dicho thread genera un paquete IP para cada una de las direcciones que se encuentren dentro del rango antes mencionado para comprobar el estado de tal equipo.

Constructor public scanNetwork (Setup config, Vector activa)

El constructor inicializa un vector de paquetes que es donde se almacenarán las respuestas de los dispositivos y trata de asociar a cada una de las direcciones IP un nombre, para posteriormente mandar solicitar el estado de cada dispositivo.

Métodos :

private String nextAddress(String previusAddress, String; IastAddress)

límite superior establecido por el intervalo configurado en e l panel de control. Este método permite generar una dirección IP a partir de números normales, hasta llegar al

public void run() Método propio de la clase Thread, que es este caso' comienza el envío de paquetes a cada una

de las direcciones generada por el método anterior, dichos paquetes van dirigidos al puerto ECHO, a f in de conocer si el dispositivo está en uso o no.

private int islnVector(String address)

están en la lista para conocer si se ha descubierto un nuevo dispositivo. Cada paquete que se reciba, es almacenado en un arreglo y comparado con los elementos que

42

"".x .. .. - .."II -

protected void printEchos(DatagramPacket[] echos) Una vez que se han recibido todos los paquetes o que se ha acabado el tiempo para los que no

llegaron, se verifica que los paquetes que hayan llegado estén en la pantalla de lo contrario se agrega los nuevos dispositivos y al mismo tiempo se actualiza el estado de los dispositivos anteriores.

protected void finalize() Este método para el Thread para que ya no siga mandando paquetes de redescubrimiento.

private Datagrampacket[] receivePackets; private Datagrampacket newpacket;

Esta clase define u n Thread que genera un socket para recibir todos los paquetes que lleguen a petición de un objeto de la clase scanNetwork

public List vars; public Vector nodes;

I public selectedPanel0 ~ ~~

Esta clase define el panel que contendrá las variables que se seleccionen con los botones del u n objeto de la clase buttonsPanel ; dichas variables se ocup,arán para generar el paquete SNMP que se enviará en la solicitud (get-request).

43

private static final int SNMP PORT = 161 ; private static final int TIMEGUT = ~OOOO; private String host; private Vector nodes; private SnmpSession session; private SnmpAPI api; private mibBrowser mb; private displayResults dr; public sender(SnmpAP1 api, String host, Vector nodes, mibBrowser mb, displayResults dr) public void run() protected void finalize()

Cuando se selecciona la opción “Send” dentro de un objeto de la clase controlpanel, se genera un objeto de la clase sender, que debe enviar la petición al objeto seleccionado sin interrumpir los demás procesos, es por esto que esta clase debe tener características de Thread.

Constructor public sender(SnmpAP1 api, String host, Vector nodes, mibBrowser mb, displayResults dr)

Establece el socket por donde saldrán los paquetes.

Métodos :

public void run() Busca todas las variables que estén seleccionadas en un objeto de la clase selectedpanel,

obtiene se notación ASN. 1 y genera el PDU con todas las variables que se vayan a pedir ; también tiene que revisar si la variable no es una tabla para agregar un cero al final de la notación ASN.l, de no ser así anotar agregar u n uno o el nilmero de la ocurrencia en una tabla.

protected void finalize() Detiene el proceso de envío del paquete.

List vars; Mi bModule rfc,rfc 15 14,rfc 127 1 ; SnmpAPI api; Vector children; descrPane1 dp; public variablesPanel(SnmpAP1 api, descrPanel

public boolean action( Event evt., Object obj ) private void expand(Líst vars, MibNode root) private void contract(List vars, MibNode root)

dP)

Este panel muestra todas las variables disponibles para seleccionar.

Constructor public variablesPanel(Stl~~~pAP1 api, descrPanel dp)

El constructor incializa el panel definiendo que módulos de variables son los que se compilarán, en Cste caso se compilan los siguientes módulos : rfc1213-MIB, rfc1514- HOSTRESOURCES. RFC 127 1 -RMON

Métodos :

public boolean action( Event evt, Object obj ) Controla los eventos que se generan dentro del panel, tales como son los doble-click

private void expand(List vars, MibNode root)

MIB, se expande este nodo. Si la variable sobre la que se hizo doble-click no es una hoja dentro de la estructura de la

private void contract(List vars, MibNode root)

padre de ese nodo. Si la variable sobre la que se hizo doble-click no es el nodo raíz entonces se despliega el

45

Anexo A

Operación de RENlonitor

Para comenzar a monitorear una red o un(os) dispositivo(s) se debe abrir o crear un nuevo archivo .rem, (que es la extensión de los archivos que crea REMonitor), mediante la opción Open o New del menú File, según corresponda (Figura 1). AI inicio REMonitor muestra habilitadas sólo estas dos opciones y Exit, que termina la sesión. Una vez abierto un archivo se tiene acceso a las demás opciones del sistema.

Del menú Monitoring (Figura 2), se selecciona la opción Setup para ingresar el rango de direcciones que se desea monitorear , el lapso de tiempo para el envío de PDUs se tiene por default de 3 minutos, es decir, que cada 3 minutos se le enviarán los PDUs a las direcciones que estén dentro del rango especificado. (Figura 3).

.',?&@S

Figura 2. Menú Network.

Figura 3. lnterfaz del Setup.

Si acaso se ingresa un mal rango de direcciones a monitorear, el sistema lo hará saber mediante el mensaje correspondiente, según sea el error que se haya cometido (Figura 4).

Una vez dado el rango de direcciones, del menú Monitoring se da la opción Start (Figura 5), con lo cual se inicia la sesión de monitoreo. REMonitor despliega un mensaje con la dirección ( o el nornbre del dispositivo) al cual se le esta enviando el PDU (Figura 6), si alguna dirección no responde, esto tambikm se notifica al administrador (Figura 7).

Figura 5. Menú Monitoring. ,-

Figura 6. Mensaje de envío.

Figura 7. Mensaje de notificación.

Para visualizar los dispositivos que se están rnonitoreando, del menú Network, se debe seleccionar la opción Layout, con lo cual aparecerán las direcciones IP de cada dispositivo junto con un pequeño icono representándolo (Figura 8).

P,' '

Figura 8. Visualización de dispositivos.

Para monitorear un dispositivo en especifico, primero se selecciona haciendo clik sobre 61 ; REMonitor indicará el dispositivo que esta

46

seleccionado, sombreando en otro color la dirección del mismo. Para proceder a seleccionar la(s) variable(s) que nos interesa(n), del menú Monitoring se da la opción Device, la cual permite recorrer el árbol de la MIB-2 en forma descendente a través de los grupos de variables que contiene (Figura 9).

Mediante el botón Add o Add All, puede seleccionar una o muchas variables, las cuales aparecerán en la lista del lado derecho. Ahora se debe enviar esta solicitud al dispositivo oprimiendo el botón Send. REMonitor abre una ventana con el resultado de la consulta (Figura 1 O).

Puede también agregar, borrar, o modificar un dispositivo, con las opciones

que nos muestra el menú Devices (Figura 11).

-

Figura 11. Menú Devices.

Las acciones de borrar o modificar se realizan sobre el dispositivo que se encuentra seleccionado en ese momento. AI agregar un nuevo dispositivo se muestra el diálogo en el que SE? debe dar la información necesaria para su monitoreo (Figura 12).

Figura 12. lnterfaz para agregar un dispositivo.

Si desea conocer los posibles traps que se hayan tenido, si es que los hubo, debe seleccionar la opción Alarms del menú Network, con lo cual permite visualizarlos en una ventana de REMonitor. Si no se tuvo ningún trap, se despliega sin ningún dato (Figura 13).

47

Para terminar la sesión de monitoreo, se da la opción Stop del menú Monitoring. Si quiere guardar esta vista de direcciones, puede dar Save As del menú File, que muestra la ventana para realizar esto (Figura 14).

Figura 14. lnterfaz de Save As.

Si da la opción Exit sin haber guardado antes la vista, REMonitor se encargará de recordarlo, con el mensaje que se muestra en la Figura 15.

Figura 15. lnterfaz de verificación.

Anexo B (Artículo Congreso Electro '97)

REMonitor: Monitor para Redes TCPIIP

Edgar Gutiérrez Sánchez, Miguel Trejo Kuri, Ruben León Rodriguez, Victor Ma.nue1 Ramos Ramos

Universidad Autónoma Metropolitana - Iztapalapa Departamento de lngeniería Eléctrica

Av. Michoacán y Av. Purísima, Col. Vicentina. México, D.F. 09340

Fax: (5) 724-46-28; Tel: (5:l 724-46-37 vicman@xanum.uam.mx egutiers@vmredipn.ipn.mx

RESUMEN: Se presenta REMonitor, un sistema de monitoreo para redes TCPilP construido con el lenguaje de programación JavaTM, y que utiliza el protocolo SNMP. REMonitor se diseñó con el propósito de implantar un sistema de monitoreo orientado a objetos y totalmente portable entre plataformas, para redes cuyos nodos ejecuten un agente SNMP.

ABSTRACT: A monitoring system for TCP/IP networks is presented, named REMonitor. The system is designed with the JavaTM programming language and uses the SNMP protocol. The primary goal of REMonitor is the implementation of an object oriented, platform independent, monitoring system, for networks with a running SNMP agent at each of its nodes.

I. INTRODUCCI~N En las últimas dos décadas se ha presentado un crecimiento sin precedentes en la necesidad de construir e implantar redes de comunicaciones, todas ellas con su propia arquitectura. Como resultado del proyecto ARPANET surgió la familia de protocolos TCP/IP (Transmission Control Protocol/Internet Protocol), y con ello la arquitectura de la gran red de redes que ahora llamamos Internet.

A medida que va creciendo una red de comunicaciones, se va haciendo cada vez más compleja la tarea de administrar y monitorear los recursos existentes en esta. Es necesario contar con un mecanismo estandarizado que permita conocer el estado de la red en cualquier instante sin que éste interfiera con el funcionamiento de la misma, y este mecanismo debe permitir realizar el siguiente tipo de tareas:

Generar, colectar, y almacenar estadísticas sobre las comunicaciones en la red y de las actividades relacionadas con la misma, Responder a comandos que le envíe algún sistema de control de la red tales como la transmisión de las estadísticas obtenidas; cambio, consulta, y establecimiento de parámetros y Generar tráfico de prueba.

Existen dos protocolos de administración de redes bien establecidos que funcionan en distintas implantaciones de redes de comunicaciones, ellos son: SNMP (Simple Network Management Protocol), y CMIP. El primero se utiliza en redes TCP/IP, y el segundo se usa regularmente en redes construidas de acuerdo al modelo OSI, aunque SNMP se viene usando ya con bastante aceptación en las redes OSI.

Eixisten sistemas de administración de redes comerciales bien conocidos, como son NetVilew/6000 de IBM, OpenView de Hewlett Packard. Estos sistemas son dependientes de la plataforma en la que se ejecuten y no pueden correr en plataformas distintas. Por ejemplo, NetView/6000 no se puede ejecutar en plataforma PC po'rque está construido para AIX, que es la versión UNIX de IBM. El lenguaje de programación Java permite generar aplicaciones que sean totalmente independientes de la plataforma y orientadas a objetos, razones muy motivantes para crear un sistema administrador de redes que se piense ejecutar en diversas plataformas sin necesidad de recompilar una sola línea de código.

El compilador de Java genera un archivo de código de bytes que es interpretado por una máquina virtual de Java en la plataforma que se vaya a ejecutar la aplicación. REMonitor está construido con el lenguaje de programación Java y,

por lo tanto, para ejecutarlo es necesario contar con la máquina virtual de Java. REMonitor utiliza el protocolo SNMP y permite monitorear redes TCPIIP cuyos nodos cuenten con un agente SNMP activo, por ello resulta importante mencionar los fundamentos básicos de SNMP antes de describir la arquitectura de REMonitov.

2. ANTECEDENTES TEóRICOS 2.1 SNMP REMonitor es un sistema inteligente (el administrador) que solicita información a los nodos adn?inistrudos, que es sobre los cuales se tiene el interés de gestionar los recursos, y éstos responden a órdenes o comandos del administrador.

SNMP (Simple Network Management Protocol) es un protocolo de diálogo entre el administrador y sus agentes. La lógica de SNMP va de acuerdo con el modelo TCP/IP cliente/servidor, y funciona en el nivel de aplicación. Cada agente se considera como un servidor de información que será útil para los propósitos de administración de recursos. El agente se encuentra qjecutando siempre un programa demonio (conocido como “daemon” en el ambiente de UNIX) que informa al cliente, que es el administrador, de la ocurrencia de sucesos extraordinarios. Visto de esta manera, se observa un ejemplo singular del modelo cliente/servidor, en el que existe un cliente que es el administrador, con varios servidores: los agentes. En un sistema de monitoreo se tiene comúnmente un solo administrador, pero existe la posibilidad de contar con más de uno.

Para establecer un diálogo SNMP entre el administrador y el agente, se deben utilizar las funciones del protocolo que trabajen sobre una base de informacih de administración, conocida como MIB (Management Information Base). La MIB es u n con.junto de variables de información que tienen un nombre y un significado, es un estándar, y es la base sobre la que funciona SNMP. Las reglas para la creación e identificación de estas variables están definidas en el RFC-1065 (Request For Comments) llamado SMI (Structure of Management Information). SMI utiliza un lenguaje formal de la IS0 llamado ASN.1 (Abstract Syntax Notation One), que se codifica usando las Reglas Básicas de Codificación (BER, Basic Encoding Rules) de OSI.

Se debe acentuar que la MIB es una base de datos que hace referencia a variables bien definidas, pero que no se encuentran almacenadas en una base de datos real que esté administrada por SNMP; la MIB es una base de datos virtual. El va1o.r de las variables se encuentra almacenado en alguna parte, y hay un programa servidor (que es el agente SNMP) que se encarga de buscar su valor cuando el administrador lo solicita.

A finales de 1989 se pasó de la MIB-I a la MIB-11, y eso quedó establecido en el RFC-1158. La IVIIB-I1 consta de 171 variables/objetos, a diferlencia de los 114 de la MIB-I. Es posible que coexistan juntas las dos MIBs, y se ve a la MIB-I1 como un subconjunto de la MIB-I; posteriormente se presentará la MIB-111.

2.2 F:unciones de SNMP En general, SNMP puede realizar cinco €unciones sobre las variables de la MIB, y estas funciones se transportan sobre las unidades de datos del pr~to~colo (PDUs): Get-request: Se utiliza para obtener el valor de una variable, que es un objeto de la MIB. Get-next-request: Se utiliza para obtener el valor de la variable siguiente en orden de profundidad o para recorrer la arborescencia de la MIB. Set-request: Se utiliza para establecer el valor de una variable de la MIB. Get-response: Es la respuesta al get o get-next que proporciona el valor de la variable. Trap: Indica al administrador la ocurrencia de un evento extraordinario.

Las funciones anteriores se transportan en un mensaje SNMP que contiene la versión de SNMP, la comunidad a la que se hace referencia, y la PDU de la función, las cuales se envían utilizando UDP sobre le1 puerto 161 para las funciones get y set, y el puerto 162 para los traps. El ambiente de interacción entre el administrador y el agente se esquematiza en la Figura 1, en donde puede verse que el agente responde a las peticiones de información que realiza el administrador.

SetRequest PDU

50

Figura I . Ambiente de interacción entre el administrador y el/los agentes.

3. ESTRUCTURACI~N Y FUNCIONAMIENTO DE REMONITOR

3.1 Alarmas Para lograr la comunicación entre la estación administradora y los objetos administrados, es necesario que estos últimos posean un programa residente en memoria (agentes SNMP), el cual avisa a la estación administradora de los eventos extraordinarios u n instante después de que éstos ocurren, mediante el envío de un trap con formato SNMP que contiene la dirección de la estación administradora y la información del evento que sucedió, así como la información del dispositivo de donde proviene. El hecho de estar al pendiente de los traps que ocurran no debe interferir con cualquier proceso que esté siendo ejecutado por el programa principal. Es por estas razones que REMonitor desde el inicio debe de estar al pendiente de los traps mediante un proceso controlado por él. pero que a la vez sea independiente de éste, permitiendo así la ejecución de las demás funciones de REMonitor. Para lograr lo anterior, se explota una de las características de Java, que es la capacidad de generar aplicaciones con múltiples hilos de control (denominados "threads"), permitiendo el multiprocesamiento. Este proceso de captura de traps se genera por medio de un ob.jeto de la clase Alarms, el cual a su vez es u n hilo de control. Dichos traps son recibidos por medio de u n socket UDP, creado en el puerto 162 de la estación administradora,

REMonitor guarda en una lista los traps que se reciben, para que en el momento en que sea llamada la opción "Alurm.~" se despliegue la información de estos traps, en u n objeto de la clase ShowAlarm (Figura 2).

Una vez que el administrador ha visto y analizado esta información, tiene la opción de eliminar una o varias de estas notificaciones, o si lo prefiiere, mantener esta información para su posterior consulta. 3.2 Autodetección El rastreo y detección de dispositivos en forma masiva dentro de una red se realiza mediante el envío de un datagrama dirigido al puerto número 7 de cada dispositivo. Para que el envío se lleve a cabo, se debe configurar el intervalo de direcciones IP que se desea administrar, además de definir cada cuanto se realizará el rastreo. Es importante que el administrador conozca el tamaño de la red a fin de que configure adecuadamente este intervalo de tiempo. La importancia de este intervalo de tiempo se ilustra mejor con un ejemplo: Supongamos que queremos monitorear los equipos que utilicen un dirección dentro del intervalo XXX 1 a X X X 2 5 4 cada segundo, esto significa que se van a enviar 254 datagramas cada segundo y que la estación administradora espera recibir un número igual de datagramas como respuesta; con esto vamos a ver las altas y bajas de equipo en la red, pero, jrealcnente necesita el administrador saber cuántos equiplos se encienden y se apagan cada segundo?, además, si el tiempo de respuesta de los dispositivos es de 3 segundos y la estación administradora envía datagramas cada segundo, entonces habrá un sobreflujo de información. El tiempo que se consume en realizar el envío de los datagramas a todas las direcciones dentro del intervalo depende precisamente del tamaño del mismo, y el tiempo en que se reciben las respuestas depende del tráfico existente en la red, la distancia entre los equipos y el tamaño del intervalo de direcciones. Es por esto que REMonitor no se puede quedar esperando a que tenga respuesta de todos los datagramas enviados para ejecutar otras funciones; siendo necesaria así la implantacidn de otro hilo de control, el cual se duerme durante el tiempo establecido previamente, cuando despierta realiza el envío de datagramas por medio de un objeto de la clase ScanNetwork, recibe sus respectivas respuestas, y se vuelve a dormir. Para que de inicio este proceso y finalice sólo se accesa a la opción "Start" y "Stop" respectivamente.

Ulna vez que se han recibido las respuestas de todos los dispositivos, en caso de que se hayan encontrado, o de haber transcurrido el tiempo

51

máximo de espera (ti/?wnut) en caso contrario, se puede desplegar esta información dentro de una ventana por medio de la opción "Layout". Dicha ventana contiene iconos que simbolizan a cada uno de los elementos junto con su dirección; la imagen con la que se representa cada dispositivo varía de acuerdo al estado actual del mismo, es decir si está apagado o encendido; todo esto para permitir al usuario tener una visión más clara de la red que se está monitoreando.

El rastreo de dispositivos, no se limita a monitorear sólo aquellos dispositivos que estén dentro del intervalo de direcciones especificado, sino que además permite la adición de dispositivos, los cuales serán incluidos en los posteriores rastreos.

3.3 Archivos y Dispositivos La apertura de u n archivo de REMonitor implica la carga de los objetos contenidos en una lista, o vector como se denomina en Java. El vector servirá para tener el control de los dispositivos monitoreados, ya que en éI se refleja cualquier cambio que suceda en la red. Si dicha red tiene una modificación, ya sea porque un dispositivo se agregó, se eliminó o cambió su estado, esto se refleja inmediatamente en el vector de dispositivos.

REMonitor además de que permite agregar un nuevo dispositivo ingresando su nombre, dirección y tipo de elemento, se puede modificar su información, y si se selecciona cualquier elemento de la ventana se podrá eliminar; cuando se ingresa un nuevo dispositivo no se verifica si es del tipo que se seleccionó, hasta que se haya realizado el siguiente rastreo.

3.4 Monitoreo Hasta este momento sólo se ha detectado los equipos en la red y se han recibido traps, pero, iqué es lo que se va a monitorear?; cuando hablamos de monitoreo, se nos viene a la mente estar sensando o midiendo con una determinada frecuencia algún parámetro, con el fin de poder tener una idea más general del progreso de un proceso o del funcionamiento de algún equipo. Las variables que son de importancia para el administrador dependen del tipo de dispositivo que se esté monitoreando, esto es, no es posible pedir parámetros de un módem, a una impresora. Dada la gran variedad de dispositivos de diferentes proveedores que existen en el mercado, el número

de variables que podrían ser monitoreados es muy grartde; dichas variables están definidas en los móclulos MIB propios de cada proveedor. La forma en que están estructuradas estas MIBs es de acuerdo al estándar ASN.1. Para que se pueda dar la interacción de los agentes SNMP y la estación administradora, es necesario que ambos equipos conozcan los mismos módulos MIB, de tal forma que, un agente se restringe a contestar solo las variables que conoce, y la estación administradora solo puede solicitar l a s variables que están definidas dentro de las MIBs cargadas. El módulo RFC- 12 13 cargado en REMonitor contiene las variables básicas de SNMP, que junto con los grupos de variables RMON y HOST- RESOURCES contenidos en otros módulos, han permitido extender la capacidad de variables que REMonitor puede solicitar, estos tres módulos son compilados por la clase MibModule del paquete SNMP de Advent versión 1.00 [l]. Para poder seleccionar las variables deseadas, REMonitor cuenta con una interfaz en la clase MibBrowser (Figura 3). Una vez seleccionadas las variables se genera una instancia de la clase Sender, el cual establlece una sesión SNMP mediante la clase SNMPSession, para enviar los datagramas por el puerto 161; los resultados de esta solicitud son mostrados por una instancia de la clase ShowResults, como se muestra en el diagrama de clases (Figura 4).

Es posible graficar el valor de una variable de tipo numérico cada determinado tiempo, con fines

52

4. CONCLUSIONES La capacidad de crecimiento de REMonitor es ilimitada, dado que la administración de equipo es restringida más bien por las potencialidades de los agentes que se utilicen, es decir, que es posible tener agentes que permitan el acceso remoto y bastaría con desarrollar u n módulo de REMonitor que se encargue de realizar este acceso. Dicho módulo puede ser desarrollado de forma independiente, aprovechando la característica del diseño orientado a objetos.

La extensibilidad de la MIB-I1 ha permitido que REMonitor sea capaz de trabajar con el protocolo RMON (Remote Monitoring Network), aún cuando los agentes que soportan este protocolo son pocos.

REMonitor es u n producto innovador ya que hace uso de las clases del JMAPI [2], liberado hace algunos meses por Sun, facilitando en gran medida la creación de una me.jor interfaz para el usuario y el buen funcionamiento del programa; también se utilizaron algunas de las clases del paquete SNMP de Advent versión I .OO, con las cuales se realizan las operaciones propias del protocolo.

53

CONCLUSIONES

Para el desarrollo de REMonitor se seleccionó el lenguaje de programación JavaTM (ver. 1 .O. l), el cuál ha empezado a surgir como un lenguaje innovador, con características que lo hacen portable para distintas plataformas y totalmente orientado a objetos, esto influyó totalmente en su elección ya que estas características hacen de REMonitor un producto también innovador, con posibilidades de crecimiento ilimitado, cualquier módulo que se desee agregar posteriormente puede implementarse fácilmente aprovechando las características de la programación orientada a objetos. Un punto importante para el desarrollo de REMonitor fué la decisión de crearlo como una aplicación y no como Applet, dadas las características de su diseño y funcionamiento que se tenían planeadas se concluyó que era mejor crearlo de esa forma. Debido a que JavaTM es un lenguaje joven (hace poco menos de un año de su lanzamiento), nos encontramos con el inconveniente de tener poca información respecto a su programación, no existía mucha documentación para su manejo, pero esto nos sirvió para explorar más sobre su fumcionamiento, encontrándonos algunas veces con bugs en el compilador JavaTM.

A pesar de que REMonitor hace uso de la MIB-I1 que incluye el protocolo RMON (Remote Monitoring Network), durante las pruebas que se hicieron con éI, no se encontraron muchos agentes que soporten dicho protocolo, será cuestión entonces de que aparezcan nuevos productos que tengan implementado RMON para que la capacidad cle REMonitor incremente. Respecto a SNMP, no se tuvo problema alguno al monitorear estaciones con agentes SNMP, la recuperación de valores de las variables pedidas se logró con éxito en todos los casos, comprobando con ello que SNMP sigue siendo uno de los protocolos más usados para la administración de redes.

54

------"-"'---"-- "

Bibliografía

Capitulo I

Stallings William Data and Computer Communications (Third Edition) Maxwell Macmillan International Editions

Tanenbautn Andrew S. Redes de Ordenadores (Segunda Edición) Prentice-Hall Hispanoamericana, S.A.

Black Uyless TCP/IP and Related Protocols McGrw-Hill

Marcelín J. Ricardo, Téllez A. Oreste, Vázquez M. Rubé11 Las Redes de Computadoras (monografía)

Capitulo I1

Douglas E. Comer Redes globales de información con internet Y TCP/IP

Prentice-Hall Hispanoamericana, S.A. f i l l )

Cnpitulo Ill

Black Uyless TCP/IP and Related Protocols McGrw-Hill

Marshall T. Rose The Simple Book An introduction to Management of TCP/IP-based Internets Prentice-Hall

Robert L. Twnsend Snmp Applications Developer's Guide Van Nostrand Reinhold

Black Uyless TCP/IP and Related Protocols McGrw-Hill