Protocolo

1,551 views
1,436 views

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,551
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
32
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Protocolo

  1. 1. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
  2. 2. ÍNDICE PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD 1. INTRODUCCIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 2. CONCEPTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 3. MODELO DE INFORMACIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 4. MODELO ADMINISTRATIVO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 5. MODELO OPERACIONAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
  3. 3. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD 1. Introducción En una internet (con minúscula, redes locales) se conectan varias redes entre sí con el uso de routers y un protocolo de interconexión de redes, de modo que los routers usan el protocolo para encubrir las características de las redes y proporcionar un servicio uniforme entre ellas, es decir, aunque cada red use una tecnología distinta y unas reglas específicas de transmisión, los hosts de cada red ven a la red de igual manera. Éste es el poder de la abstracción de la interconexión entre redes. La principal tecnología de interconexión de redes es el conjunto de protocolos de Internet llamados TCP/IP, que se crearon en la Agencia de Proyectos de Investigación Avanzada de Defensa (DARPA) y que son los que se usan en la Red Internet, (con mayúscula, la red de redes global) pero también en la interconexión de redes menores internet. SNMP se sitúa en el tope de la capa de transporte de la pila OSI, o por encima de la capa UDP de la pila de protocolos TCP/IP. Siempre en la capa de transporte. Gráficamente se podría ver así: 3
  4. 4. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD 1. Necesidad de administrar redes Los problemas que se presentan en la interconexión de redes son principalmente dos: a) Dispositivos diferentes: la interconexión de redes permite diferentes tipos de dispositivos y éstos son de distintos vendedores, todos ellos soportando el protocolo TCP/IP. Debido a esto, la administración de redes se presenta como un problema. Sin embargo, usar una tecnología de interconexión abierta permitió que existieran las redes formadas por dispositivos de distintos fabricantes, por lo que para administrar estas redes, habrá que usar una tecnología de administración de redes abierta. b) Administraciones diferentes: como se permite la interconexión entre redes de distinto propósito y distinto tamaño, hay que tener en cuenta que también están administradas, gestionadas y financiadas de distinta forma. 2. Evolución histórica del Protocolo Simple de Gestión de Red (SNMP) El protocolo Snmpv1 fue diseñado a mediados de los 80 por Case, McCloghrie, Rose, and Waldbusser, como una solución a los problemas de comunicación entre diferentes tipos de redes. En un principio, su principal meta era el lograr una solución temporal hasta la llegada de protocolos de gestión de red con mejores diseños y mas completos. Pero esos administradores de red no llegaron y SNMPv1 se convirtió en la única opción para la gestión de red. El manejo de este protocolo era simple, se basaba en el intercambio de información de red a través de mensajes (PDU’s). Además de ser un protocolo fácilmente extensible a toda la red, debido a esto su uso se estandarizo entre usuarios y empresas que no querían demasiadas complicaciones en la gestión de sus sistemas informáticos dentro de una red. No obstante este protocolo no era perfecto, además no estaba pensado para poder gestionar la inmensa cantidad de redes que cada día iban apareciendo. Para subsanar sus carencias surgió la versión 2 (SNMP v2). Las mayores innovaciones respecto a la primera versión son: 4
  5. 5. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD - Introducción de mecanismos de seguridad, totalmente ausentes en la versión 1. Estos mecanismos protegen la privacidad de los datos, confieren autentificación a los usuarios y controlan el acceso. - Mayor detalle en la definición de las variables. - Se añaden estructuras de la tabla de datos para facilitar el manejo de los datos. El hecho de poder usar tablas hace aumentar el número de objetos capaces de gestionar, con lo que el aumento de redes dejó de ser un problema. - Realmente esta versión 2 sólo supuso un parche, es más hubo innovaciones como los mecanismos de seguridad que se quedaron en pura teoría, no se llegaron a implementar. Por estas razones, se ha producido la estandarización de la versión 3. Con dos ventajas principales sobre sus predecesores: - Añade algunas características de seguridad como privacidad, autentificación y autorización a la versión 2 del protocolo. Usa Lenguajes Orientados a Objetos (Java, C++) para la construcción de los elementos propios del protocolo(objetos). Estas técnicas confieren consistencia y llevan implícita la seguridad, por lo que ayudan a los mecanismos de seguridad. 5
  6. 6. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD 2. Conceptos El entorno usado para administración en los protocolos de Internet se llama Internet-standard Networking Management Framework (entorno para la administración de redes basadas en Internet), y esto se debe a motivos históricos: los esquemas previos eran ocasionales y propietarios. Actualmente existen dos versiones de este entorno: el entorno original (Internet-standard Networking Management Framework), compuesto por tres documentos, cada uno de los cuales es un estándar de Internet con la condición de Recomendado; y el entorno que le sucedió (SNMPv2 Framework), formado por doce documentos. Dos años después, este segundo entorno se revisó en ocho documentos, quedando algunos como borradores de estándares y otros como proposiciones de estándares. Con el tiempo, estos documentos se convirtieron en un completo estándar de Internet. Fue entonces cuando se declaró histórico el estándar original y la comunidad se quedó con un solo entorno. Entre ambos entornos hubo dos pasos intermedios: SNMP Security y SMP que fueron incluidos dentro del entorno SNMPv2, dejando sus documentos originales sólo , para interés histórico. Un modelo Un sistema de administración de red contiene cinco elementos: 1.Uno o más nodos administrables, conteniendo cada uno un agente. 2.Al menos una estación de administración de red (NMS) con soporte para una o más aplicaciones de administración de la red. 3.Posiblemente una o más entidades de doble función, que pueden actuar como agente o como administrador. 4.Un protocolo de administración de red, que es usado por la estación y los agentes para intercambiar información. 5.Información que administrar. 1. Nodos administrables Un nodo administrable es un dispositivo que puede clasificarse en una de las siguientes categorías: - Un Host, como una estación de trabajo, mainframe, o impresora. - Un sistema de enrutamiento. - Un dispositivo de acceso al medio, como un repetidor, un puente o un hub. 6
  7. 7. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD Estas tres categorías coinciden en que clasifican a algún tipo de dispositivo con alguna capacidad de trabajo en red. Las dos primeras categorías se caracterizan por ser normalmente independientes del medio, mientras que la principal característica de los dispositivos de la tercera clase es la dependencia del medio. 1.1 El axioma fundamental Un buen sistema de administración de red debe conocer la diversidad de dispositivos existentes y proporcionar un entorno apropiado. Así, el axioma fundamental dice que: El impacto de añadir una administración de red a un nodo administrable debe ser mínimo, reflejando un común denominador más bajo. El axioma fundamental se debe a las grandes diferencias entre los distintos nodos administrables que existen. 1.2 Características de los Nodos Administrables Podemos considerar que cada nodo administrable está formado por tres componentes: 1.Funciones de usuario. 2.Un protocolo de administración, que permite monitorizar y controlar el nodo administrable. 3.Instrucciones de administración, que interactúan con la implementación del nodo administrable para permitir la monitorización y el control. La interacción entre estos tres componentes es sencilla: las instrucciones actúan como un pegamento entre las funciones de usuario y el protocolo de administración. Esto se debe a un mecanismo de comunicación interno en el que las estructuras de datos de las funciones de usuario deben ser accesibles y modificables a petición del protocolo de administración. 1.3 Modelo Administrativo Actualmente los intercambios de información son insuficientes para proporcionar la administración de los nodos. El protocolo de administración trabaja en el entorno del modelo administrativo, que mantiene políticas de autorización y autentificación. Esto permite determinar al nodo cómo se está administrando, de modo que sólo los procesos de aplicaciones autorizadas realicen la administración. 7
  8. 8. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD 2. Estación de Administración de Red Una estación de administración de red es una máquina que ejecuta el protocolo de administración de red y una o más aplicaciones de administración de red. Si el protocolo es el encargado de proporcionar los mecanismos de administración, entonces las aplicaciones determinan la política que se usa para la administración. El axioma fundamental indica que añadir administración de red debería tener un impacto mínimo en los nodos, en consecuencia la carga se desplaza a las estaciones. Sin embargo podríamos pensar que el sistema que soporta la estación de administración es más potente que un nodo, así que ¿cuánta potencia es necesaria entonces? La experiencia muestra que la mayoría de las estaciones de trabajo pueden proporcionar los recursos necesarios para soportar una buena estación de administración. Hay que tener en cuenta que a medida que hay más nodos administrables en una internet, se favorece desplazar la carga hacia la estación de administración. 2.1 Entidades de doble función Se ha dicho que las estaciones de administración sólo interactúan con los nodos. ¿Qué pasaría si el mismo nodo también fuera una estación de administración? Es necesario apreciar que el modelo agente-administrador puede soportar directamente, esto si consideramos que el software de cada estación de administración puede realizar tanto la función de administrador como la de agente, es decir, que el modelo agente-administrador es también un modelo peer-to-peer. Teniendo esto en cuenta, se pueden construir relaciones jerárquicas entre las estaciones de administración. Por ejemplo, se puede construir un sistema de administración donde cada segmento de una LAN tiene una aplicación de administración que controla el estado de los dispositivos de ese segmento. Estas aplicaciones deberían informar a aplicaciones de estaciones de administración regionales, las cuales deberían informar a estaciones de administración entre empresas. En este ejemplo, el software de cada estación realiza un papel de administrador al monitorizar y controlar dispositivos que dependen de él jerárquicamente, y un papel de agente al informar y actuar según los comandos proporcionados por un superior jerárquico. El concepto clave con las entidades de doble función es que la relación jerárquica depende de la configuración, mientras que la relación peer-to-peer depende de la arquitectura. 8
  9. 9. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD 3. Protocolo de Administración de Red Dependiendo del paradigma que se utilice para la administración de la red, un protocolo de administración puede tomar varias formas: 3.1 Operaciones En el entorno de administración, cada nodo tiene una serie de variables, de modo que leyendo estas variables se monitoriza el nodo, y cambiándoles el valor se controla. Se trata de un paradigma de depuración remota, cuya ventaja es que es sencillo construir un protocolo de administración que realice estas funciones. Además de las operaciones de lectura y escritura, existen otras dos: 1.Una operación cruzada, que permite determinar a la estación de administración qué variables soporta un nodo. 2.Una operación de interrupción, que permite a los nodos informar a la estación de administración de un evento extraordinario. Veamos un poco más de ambas operaciones. 3.1.1 Operación de Examen Como los nodos realizan distintas funciones, también contienen diferentes variables de administración. En el entorno de administración, todas las variables relacionadas con una determinada funcionalidad se agrupan juntas. Las estaciones deben determinar qué variables se soportan. Sin embargo, el protocolo debe proporcionar un significado para examinar la lista de variables soportadas por un nodo. También hay que tener en cuenta que pueden existir variables que aparezcan más de una vez. Por ejemplo, la tabla de enrutamiento IP no es escalar, sino que está formada por una o más filas, cada una de las cuales presenta varias columnas. Por tanto, el protocolo de administración debe proporcionar dos nuevas funciones: - Un mecanismo para recuperar celdas de una tabla. - Un mecanismo para recuperar números grandes de una celda de una tabla. 9
  10. 10. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD 3.1.2 Operación de Interrupción Desde el comienzo de los sistemas operativos, siempre se ha debatido acerca de utilizar un método de interrupción o un método de sondeo. Esta discusión también se realiza en la administración de redes. Los argumentos para cada uno de estos métodos son los siguientes: Con el método basado en interrupciones, tenemos las siguientes ventajas: cuando ocurre un evento extraordinario, el nodo envía una interrupción a la estación de administración adecuada (suponiendo que el dispositivo no ha caído y se puede alcanzar la estación). Por tanto tenemos la ventaja de una notificación inmediata. Con el método basado en interrupciones, tenemos las siguientes desventajas: requiere recursos para generar la interrupción ya que si la interrupción debe contener mucha información, el nodo perderá tiempo en prepararla y no se dedicará a cosas útiles. Por supuesto, cuando se genera una interrupción, el agente asume que la aplicación de administración está preparada para recibir la información. Por tanto hay que usar un diseño cuidadoso para que las interrupciones sean recibidas sólo por aquellas estaciones interesadas. Más aún, si ocurre un evento extraordinario, las interrupciones pueden ocupar un gran ancho de banda, lo cual es poco deseable si se está informando de un problema de congestión de la red. Por eso se refina el método de las interrupciones de modo que un nodo sólo informa cuando la ocurrencia de un evento sobrepasa un determinado umbral, pero esto implica que el agente debe gastar tiempo para determinar cuándo debe generar una interrupción. Es decir, el método basado en interrupciones tiene un fuerte impacto en el agente, en la red o en ambos. En conclusión, como los nodos tienen una pequeña visión de toda la red, es conveniente que las aplicaciones de administración detecten el problema de alguna otra forma. Con el método basado en sondeo, una aplicación de administración pregunta periódicamente al nodo cómo van las cosas, así el control lo tiene la aplicación, la cual sí tiene una visión global de la red. La desventaja del método de sondeo es que la aplicación de administración no sabe qué elementos sondear ni con qué frecuencia. Si el intervalo de frecuencia es breve, se ocupa mucho ancho de banda, y si es muy largo, la respuesta a eventos catastróficos es demasiado lenta. Otra desventaja es el tráfico que se introduce en la red, por lo que la aplicación de administración debe tener recursos de almacenamiento adicionales para ello. En el entorno de administración se usa el modelo interrupción-sondeo directo (trap-directed polling). Cuando ocurre un evento extraordinario, el nodo manda una interrupción simple a la aplicación. La aplicación es entonces la responsable de iniciar conversaciones con el nodo para determinar la naturaleza y la extensión del problema. Esto es muy efectivo ya que el impacto creado en los nodos es pequeño, en el ancho de banda es mínimo y los problemas se resuelven en el momento oportuno. Por tanto, las interrupciones actúan como una alarma previa, y se usa un sondeo de baja frecuencia. 10
  11. 11. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD 3.2 Forma de transporte La elección de un servicio de transporte por parte del protocolo de administración es importante ya que de los mecanismos internos del servicio de transporte depende la efectividad del protocolo, y de acuerdo con el axioma fundamental, hay que elegir la forma de comunicación menos impactante en el proceso. La aplicación de administración es la que debe decidir el nivel de fiabilidad deseado e implementar el algoritmo apropiado, sin dejar esta decisión en manos del servicio de transporte. De esta manera, el nodo tendría menos carga debido a esta elección. Todo esto conduce a elegir un servicio de transporte no orientado a conexión. Esta elección implica un comportamiento “sin preocupaciones” por parte del agente y permite a la aplicación controlar el nivel de fiabilidad. Hay otro motivo para elegir servicios de transporte no orientados a conexión. Cuando la red está congestionada y es difícil establecer una conexión, un protocolo orientado a conexión realiza ésta en tres pasos. Si la red está perdiendo paquetes, es más difícil establecer este modo de conexión que otro modo de un solo paso. Por tanto es conveniente usar la segunda forma, ya que en esos casos es cuando realmente la red necesita ser controlada y administrada. 4. Información de administración Finalmente, hemos de explicar la información a intercambiar entre la estación de administración y el nodo, utilizando el protocolo de administración. Una unidad de información de administración se denomina objeto administrado (managed object), y un conjunto de dichos objetos se denomina Módulo de Base de Información de Administración (Módulo MIB). La característica más importante de los métodos usados para describir la información de administración es la extensibilidad, de modo que se pueda comenzar con un pequeño conjunto de definiciones, para aumentarlo según crezcan las necesidades. Un efecto lateral de la extensibilidad, es que los vendedores de dispositivos pueden añadir sus propios objetos para mejorar sus productos, lo que puede influir en la estandarización de la tecnología de administración. 11
  12. 12. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD 4.1 Objetos Administrados (Managed Objects) La instrumentación de administración actúa entre los protocolos del dispositivo y el protocolo de administración, tomando la información del dispositivo y presentándola como un conjunto de objetos administrados. Esta colección se denomina Recursos Objeto del Agente. 4.2 Revisión del Modelo Administrativo Anteriormente se presentó el modelo administrativo como el responsable de proporcionar políticas de autorización y autentificación. Ahora también podemos añadir que es el modelo administrativo el que determina qué aplicación de administración puede acceder a qué objeto y con qué operaciones. Las operaciones de administración permitidas a una aplicación por un agente se denominan política de acceso. La colección de objetos administrados que son visibles para estas operaciones se denomina Vista del MIB, o simplemente Vista. 4.3 Relaciones de tipo Proxy A veces, un agente accede a información de administración no local. Cuando otro agente recibe la petición de esa información, realiza una serie de operaciones para satisfacer la solicitud. Esto se denomina Interacción de delegación (interacción Proxy) y el agente que la realiza se denomina Agente delegado (Agente Proxy). Hay varias razones por las que utilizar las relaciones Proxy: 1. Cortafuegos administrativo (Firewall): puede ser útil que el agente proxy autentifique y autorice las peticiones para no cargar a un dispositivo ocupado con estas tareas. Así, el agente proxy implementa una política administrativa extensiva, y el dispositivo sólo responde a las peticiones realizadas por el agente. 2. Caching Firewall: puede ser útil que el agente proxy tenga la información a modo de caché, también para minimizar la carga del dispositivo. 3. Puentes de transporte: en una red multiprotocolo, un dispositivo soportaría el servicio punto a punto de sólo un conjunto de protocolos. Idealmente, una estación de administración soportaría los servicios punto a punto de todos los conjuntos de protocolos. De todas maneras, un agente proxy que soporte servicios punto a punto del conjunto apropiado de protocolos puede utilizarse para establecer un camino para las comunicaciones de administración entre el dispositivo y la estación. 4. Traducciones de protocolo: en el caso de que los dispositivos no soporten protocolos de administración, las peticiones usadas en el protocolo son traducidas a una forma entendida por el dispositivo. De igual forma, las respuestas son traducidas a la forma entendida por el protocolo. 12
  13. 13. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD Una propiedad importante de las relaciones tipo proxy es el principio de transparencia. La idea es aparentar que la aplicación se está comunicando directamente con el agente real, es decir, una aplicación simplemente especifica los recursos deseados y el agente proxy es el encargado de hacer que las cosas salgan bien, como si la información de administración la tuviera el agente proxy localmente. 5. En perspectiva El axioma fundamental del entorno de administración se basa en la noción de distribución universal. Si se ve la administración de redes como un aspecto esencial, entonces debería distribuirse en la mayor cantidad de dispositivos de la red. Como hay muchos más agentes que estaciones de administración, entonces minimizando el impacto de la administración en los agentes, podremos solucionar el problema. Otro principio importante es que la administración de red es distinta a cualquier otra aplicación. Cuando todo falla, la administración de red debe seguir funcionando. Este principio indica que muchas de las funciones que se encuentran en la capa de transporte, serán directamente direccionadas por aplicaciones en la estación de administración, teniendo en cuenta que serán las propias aplicaciones las que definan el grado de fiabilidad requerido de cada operación. Sin embargo, el servicio de transporte no debe “ayudar”, sólo debería ser la forma más simple de permitir atravesar la red. 13
  14. 14. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD 3. Modelo de Información Para examinar el papel de la información de gestión en el entorno de administración, consideraremos las siguientes cinco partes: - Reglas para definir la información de administración. - Ejemplos de colecciones de definiciones existentes. - Reglas para definir los convenios textuales (definición de tipos de uso frecuente). - Cómo se accede a éstas al definir información de administración. - Coexistencia entre el entorno original y el entorno SNMPv2. Antes de comenzar, hay que aclarar la relación entre variables, objetos y tipos de objetos. Un objeto administrable tiene asociado una sintaxis y una semántica de tipo abstracto, mientras que una variable es una instancia de un objeto particular. En este caso también se denomina instancia de un objeto. ESTRUCTURA DE LA INFORMACIÓN DE ADMINISTRACIÓN La Estructura de la Información de Administración (SMI) define las reglas para definir la información de administración independientemente de los detalles de implementación. La SMI se define usando ASN.1 (Abstract Syntax Notation). Si se piensa que una colección de objetos administrados está almacenada, por ejemplo, en una base de datos, la SMI define el esquema de esa base de datos. En realidad, esa base de datos se denomina Base de Información de Administración (MIB). 1. Módulos de Información Existen tres clases de módulos ASN.1, también llamados Módulos de Información, definidos por el SMI: - Módulos MIB, que define una colección de objetos de administración afines. - Sentencias de Conformidad, que definen un conjunto de requisitos de los nodos con respecto a uno o más módulos MIB. - Sentencias de Capacidad, que describe la capacidad de un nodo para implementar los objetos definidos en uno o más módulos MIB. 14
  15. 15. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD Por supuesto, estas funciones deberían estar combinadas en un sólo módulo. Cada módulo de información debe comenzar con la indicación de su identidad y la historia de sus revisiones (macro MODULE-IDENTITY). Dentro de cada modulo existirán objetos, los cuales se definen con la macro OBJECT-TYPE, la expansión de éstos se produce durante la implementación. También se usaran convenciones textuales (macro TEXTUAL- CONVENTION), que son redefiniciones más precisas de algún tipo de datos, dentro de un MIB. Existen tres tipos de MIB: - Estándar: son módulos que se han convertido en un estándar. - Experimental: Esperan su oportunidad de convertirse en estándar. - Especifico: son propios de alguna empresa. El modulo MIB de la V2 contiene 5 grupos de objetos: system, snmp, snmpComunity, SnmpSet y SnmpBasicNotification. 15
  16. 16. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD 4. Modelo Administrativo Consideraremos cómo se definen políticas administrativas para aplicaciones de gestión y agentes. Esta parte de la red de gestión ha sufrido la mayor revisión desde la introducción de SNMP. Desafortunadamente todavía no existe un consenso en la solución más apropiada al problema. 1. Conceptos En el entorno de gestión, una entidad SNMP es una “entidad lógica” en nombre de la cual un agente o una aplicación de gestión están procesando un mensaje. El entorno de gestión es responsable de proporcionar: - Autentificación: se refiere a cómo las entidades SNMP identifican sus mensajes. - Privacidad: se refiere a cómo las entidades SNMP protegen sus mensajes. - Autorización: se refiere a cómo una entidad agente SNMP determina los objetos que son accesibles a una entidad de aplicación de gestión dada, y las operaciones que se pueden realizar en estos objetos. 1.1 Autentificación Cuando una entidad comienza una comunicación, es configurada para suministrar credenciales de autentificación como una parte de la comunicación. Dependiendo de los mecanismos de autentificación, serán válidas tres clases de servicios: - Identificación origen, por la cual un mensaje puede ser asociado con una entidad origen. - Integridad del mensaje, por la cual un mensaje alterado puede ser detectado con seguridad. - Protección limitada de retransmisión, por la cual un mensaje que ha sido duplicado o retrasado por la red o una tercera parte puede ser detectada fuera del tiempo de vida esperado del mensaje. Tras esto podemos observar que prevenir las ocasiones de fuera de servicio, en las cuales una tercera parte interrumpe una comunicación, no es un objetivo del entorno de gestión. No obstante para alcanzar seguridad con las anteriores funciones deberemos usar: - Encriptación con firma. - Algoritmos (message digest). - Relojes incrementados monótonamente. 16
  17. 17. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD 1.2 Privacidad Como las propiedades de autentificación están asociadas con la entidad que envía, las propiedades de privacidad se pueden asociar con las entidades receptoras. Para lograr privacidad con seguridad, deberíamos usar un algoritmo de encriptación y la clave asociada. 1.3 Autorización Cuando un agente ejecuta una operación, primero deberá identificar la colección de recursos de objetos de gestión a monitorizar. Si los recursos son accesibles mediante algún mecanismo local, se dice que la operación se desarrolla desde el punto de vista del MIB, el cual es normalmente un conjunto adecuado de todos los objetos gestionados controlados por una entidad. En cambio, si los recursos son accesibles mediante el envío de mensajes SNMP a una entidad remota, entonces se dice que los objetos son validos a través de una relación proxy. Una vez que los recursos son identificados, sólo resta determinar las operaciones SNMP empleadas en ellos. A esto se denomina Política de Acceso, y es usada para el control del flujo de información entre la entidad agente SNMP y una entidad de aplicación de gestión dada. 2. Comunidades SNMP v2 esta diseñado para soportar múltiples entornos de administración. El entorno que veremos se denomina entorno de gestión basado en comunidades, debido a que usa el concepto de comunidad empleado en el SNMP original. SNMP define una comunidad como una relación entre entidades SNMP. Una comunidad SNMP se escribe como una cadena de octetos sin interpretación. Esta cadena se llama nombre de comunidad. Cada octeto toma un valor entre 0 y 255. Cuando se intercambian mensajes SNMP, contienen dos partes: - Una cadena de comunidad, enviada en texto sencillo y, - Datos, conteniendo una operación SNMP y los operandos asociados. 17
  18. 18. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD La cadena de comunidad es un simple manejador para las relaciones de gestión. Ahora realizamos una valoración de las propiedades de gestión de SNMP: Identificación de origen: como las cadenas de comunidad son enviadas sin protección, cualquier tercera parte capaz de interceptar un mensaje SNMP puede usar el mismo nombre de comunidad y de esa forma demandar ser un miembro de la comunidad de mensajes. Integridad del mensaje: cualquier tercera parte puede modificar un mensaje SNMP que intercepte. Protección limitada de reenvíos: cualquier tercera parte puede retrasar un mensaje SNMP que haya interceptado. Privacidad: cualquier tercera parte puede leer el mensaje SNMP que haya interceptado. Autorización: los agentes son responsables de mantener información local así como los MIB que contienen, o las relaciones de proxy válidas. Será sencillo para una tercera parte obtener los accesos correctos de una entidad autorizada para monitorizar o controlar esos objetos. Todo lo que se puede decir es que aunque SNMP v2 ofrece enfoques técnicos para estos asuntos, sus mecanismos no llevan a ninguna solución. Naturalmente, el mercado se ha adaptado a estas carencias: - Primero, varios diseñadores de módulos MIB son reacios a definir objetos, que maliciosamente modificados puedan causar considerables dificultades en la red. - Muchos implementadores de agentes no han implementado funciones de control SNMP a propósito. 3. Procedimientos Veremos cómo se procesan los mensajes SNMP. Para empezar, veremos el formato del mensaje. Existen tres partes: - Versión: el número de versión del mensaje. - Comunidad: la cadena de comunidad. - Datos: una operación SNMP, definido como una estructura PDUs 18
  19. 19. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD 3.1 Originando un mensaje Usando conocimiento local, la entidad origen comienza seleccionando la comunidad apropiada la cual tiene la autorización adecuada para usar las operaciones y el acceso a los objetos MIB deseados. Luego: - Una estructura de mensaje es construida desde esta información. - Es convertida en una cadena de octetos. - Es enviada a la dirección de transporte de la entidad receptora. 3.2 Recibiendo un mensaje Cuando un paquete es recibido del servicio de transporte, el contador (snmpInPkts) es incrementado. Luego el paquete es examinado para ver si es una representación de una estructura de mensaje. Si no es una representación de una estructura de mensaje, el contador (snmpInASNParseErrs) es incrementado y el paquete es descartado. En caso afirmativo, la versión del mensaje es revisada para ver si se refiere a una versión implementada por la entidad receptora. Si no es una versión implementada por la entidad receptora, el contador (snmpInBadVersions) es incrementada y el paquete es descartado. En caso afirmativo, se chequea la comunidad del mensaje para ver si se refiere a una conocida entidad receptora. Si la comunidad no es conocida, el contador (snmpInBadCommunityNames) es incrementado y el paquete descartado. En caso afirmativo, se chequea la comunidad para ver si esta tiene autorización para utilizar la operación contenida en los datos del mensaje. Si no tuviera autorización, el contador (snmpInBadCommunityUses) es incrementado y el paquete descartado. De otra forma, La entidad receptora chequea para mirar que clase de recursos de objetos están asociados con la comunidad. Si la comunidad se refiere a recursos de objetos locales, entonces la operación se desarrolla de acuerdo con los MIBs apropiados asociados con la comunidad. En cambio si la comunidad se refiere a recursos de objetos remotos, entonces: - Si la operación es una respuesta, entonces es correlativa con la anterior petición, y una respuesta es enviada a la entidad originaria de la petición. - Si la operación es una Trap o un informe, entonces el agente proxy, usando conocimiento local, determina la entidad SNMP que debería enviar el mensaje. 3.3 Esperando por mensajes Normalmente las entidades SNMP esperan los mensajes en la dirección de transporte por defecto asociada con cada dominio de transporte válido para el. 19
  20. 20. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD 5. Modelo Operacional Examinaremos el papel de las operaciones del protocolo en el entorno de administración. SNMP es un protocolo asíncrono de petición-respuesta basado en el modelo de interrupción-sondeo directo; esto significa que una entidad no necesita esperar una respuesta después de enviar un mensaje, por lo que puede enviar otros mensajes o realizar otras actividades. SNMP tiene pocos requisitos de transporte ya que usa un servicio de transporte no orientado a conexión, y que normalmente es UDP. Aunque ésto ratifica el Axioma Fundamental, hay una razón más importante: Las funciones de administración de red se realizan cuando hay problemas, de modo que la aplicación de administración es la que decide qué restricciones realiza para el tráfico de administración. La elección de un servicio de transporte no orientado a conexión permite a la estación determinar el nivel de retransmisión necesario para complacer a las redes congestionadas. 1. Interacciones del Protocolo Una interacción SNMP consiste en una petición de algún tipo, seguida por una respuesta. Hay cuatro resultados posibles de una operación: - Una respuesta sin excepción o error. - Una respuesta con una o más excepciones. - Una respuesta con error. - Sobrepasar el tiempo de espera (timeout). A continuación se describen los campos del tipo de dato PDU. - request-id, valor entero usado por la aplicación para distinguir entre peticiones pendientes, lo que permite a la aplicación mandar rápidamente varios mensajes SNMP, reconocer mensajes duplicados en la red y medir el tiempo del tráfico que genera. Los agentes no pueden modificar este campo. - error-status, si no es cero, representa un error al procesar la petición y que debería ignorarse el campo variable-bindings. - error-index, si no es cero indica qué variable de la petición es errónea. - variable-bindings, Lista de variables, con su nombre y valor. 20
  21. 21. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD Las operaciones de SNMPv2 se pueden clasificar así: - Recuperación: get, get-next y get-bulk. - Modificación: set. - Invocación: snmpv2-trap. - Administradores: inform. 1.1 Interacciones Veamos primero una interacción normal entre dos entidades SNMPv2, para más adelante estudiar sus variaciones: 1. La entidad que inicia el protocolo hace una petición con: - Un único request-id. - error-status/error-index a cero. - Cero o más instancias de variables. 2. Si la operación no fue snmpv2-trap, la entidad que responde da una respuesta con: - El mismo request-id. - error-status a cero. - Las mismas instancias de variables. Si se solicita una operación de recuperación, en la petición, los valores asociados con las variables tienen el valor unSpecified; si no, las instancias de variables esperan valores. Si no se solicita una operación de recuperación, las instancias de las variables de la respuesta son iguales a las de la petición. 1.1.1 Interacción de Excepciones Mientras se procesa una petición de recuperación, el agente podría encontrar una excepción, indicando que una determinada variable no puede ser procesada. Hay tres tipos de valores de excepción: - noSuchObject, indica que el tipo de objeto correspondiente a la variable no se implementa por el agente. - noSuchInstance, indica que la instancia de un objeto particular identificado por la variable no existe en la vista del MIB para la operación. - endOfMibView, indica que no hay más información en la vista del MIB para la operación. 21
  22. 22. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD Por tanto, el funcionamiento de interacciones SNMPv2 con excepciones es de la siguiente forma: 1. La entidad que inicia el protocolo hace una petición de recuperación con: - Un único request-id. - error-status/error-index a cero. - Cero o más instancias de variables. 2. La entidad que responde da una respuesta con: - El mismo request-id. - error-status a cero. - Las mismas instancias de variables, pero con diferentes valores y uno o más valores de excepción. 1.1.2 Interacción de Error Mientras se procesa alguna petición, el agente puede encontrar un error e indica que la operación no puede procesarse. Hay varias clases de error. El funcionamiento de interacciones SNMPv2 con excepciones es de la siguiente forma: 1. La entidad que inicia el protocolo hace una petición de recuperación con: - Un único request-id. - error-status/error-index a cero. - Cero o más instancias de variables. 2. La entidad que responde da una respuesta con: - El mismo request-id. - error-status a cero. - Las mismas instancias de variables que la petición. Teniendo en cuenta que los errores nunca se devuelven en una respuesta a una operación de invocación, hay dos clases de errores que pueden devolverse en la respuesta a cualquier otra petición: tooBig, indica que la respuesta podría ser demasiado larga para enviarla. genErr, no debería devolverse excepto que no haya otra posibilidad. 22
  23. 23. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD Si se procesa una petición de modificación, hay otra case de errores que deberían devolverse, pero que se verán más adelante. 1.1.3 Interacción de Timeout Esta interacción ocurre cuando se envía una petición pero no se recibe respuesta. Hay varias posibilidades: - La red omite la petición. - El agente no está ejecutándose. - El agente omite la petición. - La red omite la respuesta. - El tiempo de espera fue muy corto. 1.1.4 De la Interacción al Procesamiento Para procesar las peticiones, primero debe aceptarse una estructura Message para que la evalúe la entidad. Cuando la petición se procesa, se examina la lista de variables instanciadas; en el caso que el campo variable- bindings esté vacío, termina el procesamiento devolviendo una respuesta noError. 2. Peticiones de Recuperación Para examinar eficientemente la información de administración, el entorno de administración usa un método inteligente para identificar las instancias: Es usado un OBJECT IDENTIFIER, formado por la concatenación del nombre del tipo objeto con un sufijo. 1.2.1 El Operador Get Si la aplicación de administración conoce las instancias que necesita, realiza una get-request. Sólo se pueden devolver los errores tooBig y genErr. Por otro lado, para cada variable de la petición, la instancia se recupera de la vista del MIB con esta operación: - Si el agente no implementa el tipo objeto asociado con la variable, se devuelve la excepción noSuchObject. - Si la instancia no existe o no la soporta el MIB, se devuelve la excepción noSuchInstance. - Se devuelve el valor asociado a la instancia. 23
  24. 24. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD 1.2.2 El Operador Get-Next Si la aplicación no conoce exactamente la instancia de la información que necesita, realiza una get-next- request. Sólo se pueden devolver los errores tooBig y genErr. Por otro lado, para cada variable de la petición, se devuelve la primera instancia que siga a la variable que esté en la vista del MIB con esta operación: - Si no hay una próxima instancia para la variable en el MIB, se devuelve una excepción endOfMibView. - Si se reconoce la siguiente instancia de la variable en el MIB, se devuelve el valor asociado. El operador get-next puede usarse para comprobar si un objeto es soportado por un agente. Debido al almacenamiento que se hace en el MIB, las tablas se examinan en un orden columna-fila; así, se examina cada instancia de la primera columna, cada instancia de la segunda y así seguidamente hasta el final de la tabla. Entonces, se devuelve la instancia del siguiente objeto , y sólo se devuelve una excepción si el operando de get-next es mayor, lexicográficamente hablando, que la mayor instancia del MIB. Como el operador get-next soporta múltiples operandos, se puede examinar eficientemente la tabla entera. La aplicación de administración conoce que llega al final de la tabla cuando se devuelve un nombre cuyo prefijo no coincide con el del objeto deseado. Puede ocurrir que al usar el operador get-next con múltiples operandos para examinar una tabla vacía, se devuelva un error de tipo tooBig en vez de devolver las múltiples instancias de la variable. Esto ocurre debido a que el operador no pudo encontrar instancias en la tabla. 1.2.3 El Operador Get-Bulk Su función es minimizar las interacciones en la red, permitiendo al agente devolver paquetes grandes. Este esquema tiene que funcionar con un servicio de transporte no orientado a conexión de modo que la aplicación sea la responsable de controlar las interacciones. Las aplicaciones de administración también deben controlar los tiempos de las interacciones 24
  25. 25. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD El formato que sigue la SNMPv2 BulkPDU es el siguiente: BulkPDU ::= SEQUENCE { request-id Integer32, non-repeaters INTEGER(0..max-bindings), max-repetitions INTEGER(0..max-bindings), variable-bindings VarBindingList } Este formato es estructuralmente idéntico la del resto de operaciones SNMP, y los campos se describen a continuación: request-id, el usual. non-repeaters, número de variables que deberían recuperarse de una vez. max-repetitions, número máximo de veces que otras variables deberían recuperarse. variable-bindings, el usual ignorando los valores. Cuando un agente recibe una get-bulk, calcula el mínimo de: - El tamaño máximo del mensaje del emisor. - El tamaño de la generación de mensajes del propio agente. - De aquí resta la suma de dos cantidades: - El tamaño de las capas de privacidad/autentificación de la generación de la respuesta. - El tamaño de una respuesta sin variables instanciadas. Dicha diferencia indica la cantidad máxima de espacio posible para las instancias de las variables en la respuesta. Si la diferencia es menor de cero, la respuesta se pierde; si no, se genera la respuesta, que tendrá cero o más variables instanciadas. El agente examina las variables de la petición usando el operador get-next y añadiendo cada nueva instancia con su valor a la respuesta y decrementando la cantidad de espacio libre. Si no hay suficiente espacio, se envía la respuesta antes de colapsar el espacio libre. 25
  26. 26. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD Finalmente, el espacio libre se ocupa, o se realiza el máximo número de repeticiones. Es importante tener en cuenta que el agente puede terminar una repetición en cualquier momento. Existe otra forma con la que la operación get-bulk termina prematuramente: Esto ocurre cuando al examinar las variables de la tabla, se devuelve una excepción endOfMibView. En este caso, todas las futuras repeticiones devolverán lo mismo y se omitirán de la respuesta. Por último, es importante saber que cuando un agente decide procesar una petición get-bulk, sólo se puede devolver el error genErr, ya que devolver tooBig no tiene sentido. 1.2.4 Más Características del Operador Get-Bulk La respuesta a un operador get-bulk no es más que la concatenación de un número de respuestas max- repitition de interacciones get-next. La parte más interesante del operador get-bulk es que puede implementarse en el agente a alto nivel mejor que en las rutinas específicas de los objetos. 3. Peticiones de Modificación Sólo hay una petición de modificación: El operador set. Cuando una aplicación de administración conoce exactamente las instancias que necesita, genera una set-request. La semántica de la operación set es tal que la operación tiene éxito si y sólo si todas las variables se actualizan. Para explicarlo usaremos el concepto del compromiso de las dos fases, pero antes de empezar, se asegura que la respuesta no sea tan grande como para no poder ser enviada, ya que si no, se generaría un error tooBig. Dicho concepto consta de dos pasadas. En la primera, cada instancia se examina y se hace una comprobación para verificar que: - La variable es soportada por la vista del MIB para esa operación. - Si la variable existe, el agente puede modificar las instancias del tipo objeto correspondiente. 26
  27. 27. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD - El valor proporcionado es correcto sintácticamente. - Si la variable no existe, el agente es capaz de crear instancias del tipo de objeto correspondiente. - El nombre y valor proporcionado son correctos sintácticamente y son consistentes con los valores de las otras variables de la petición. - Todos los recursos necesarios para el cambio están reservados. Si alguna de estas condiciones no se verifica para alguna de las instancias, se devuelve el error apropiado y se liberan los recursos. SNMPv2 soporta nuevos códigos de error, además de los habituales, que son los siguientes, así como las causas que los producen: 1. noAccess, la variable no es soportada por la vista del MIB para esa operación. 2. notWritable, La variable existe pero el agente no puede modificar instancias del tipo objeto correspondiente. 3. wrongType, el nuevo valor proporcionado es de un tipo de datos ASN.1 erróneo. 4. wrongLength, el nuevo valor proporcionado es de longitud errónea. 5. wrongEncoding, el nuevo valor proporcionado está codificado erróneamente. 6. wrongValue, el nuevo valor está fuera del rango de valores admitidos para el tipo de objeto correspondiente. 7. noCreation, la variable no existe y el agente no puede crear instancias del tipo objeto correspondiente. 8. inconsistentName, la variable no existe y no puede ser creada porque el nombre de la instancia es inconsistente con los valores de otro objeto en el agente. 9. inconsistentValue, el valor proporcionado es inconsistente con los valores de otro objeto en el agente. 10. resourceUnvailable, un recurso requerido no puede ser reservado. 27
  28. 28. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD Los códigos noCreation y notWritable son de tipo permanente, mientras que los tres últimos son de tipo transitorio. El resto son casos que no deberían ocurrir si la aplicación y el agente tuvieran un mismo concepto de los objetos en cuestión. Sólo si cada instancia ha superado la primera pasada, se hace la segunda, en la cual se acomete el cambio de cada instancia. Por experiencia, pueden existir fallos en esta segunda pasada. Si ocurre, el agente trata de deshacer los cambios y devuelve uno de los dos siguientes tipos de error: 1. commitFailed, indica que hubo un fallo en la segunda pasada pero que se deshicieron los cambios. 2. undoFailed, indica que falló la segunda pasada y que algunos cambios no pudieron deshacerse. Si se devuelve alguno de estos errores, se pone a cero el campo error-index, indicando que hay un problema grave en el agente. 4. Manejo de Filas de Conceptos Desde la perspectiva del protocolo, no existe el concepto de fila en SNMP En particular no existe . relación entre las variables presentadas en una lista de variables. Cualquier relación existe como una característica del diseño de MIB, no por operaciones de protocolo. Podemos considerar un reto el crear instancias en una fila de conceptos, dado el modelo operacional que usa el entorno de administración. Hay que tener en cuenta: 1. El agente puede no ser capaz de implementar algunas columnas en una fila de conceptos. 2. El agente puede necesitar que algunas columnas se creen antes de usarlas. 3. Los valores de todas las columnas pueden no entrar en una sola PDU. 4. La aplicación de administración puede querer examinar los valores de algunas columnas. 5. Las aplicaciones que cooperan no quieren comisionar al crear nuevas filas. 28
  29. 29. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD En SNMPv2, la convención textual RowStatus se usa para expresar la forma de manipular una fila: cuando una tabla se define en un módulo MIB, debe definirse una columna status con la sintaxis de RowStatus. El significado de una variable de la columna status es que su valor indica la relación entre el dispositivo y la fila de conceptos. Un resumen de la convención textual RowStatus es la siguiente: RowStatus ::= TEXTUAL-CONVENTION ... SYNTAX INTEGER { —dos valores de estado/acción que pueden ser leidos o escritos. active(1), notInService(2), —un valor de estado, que solo puede ser leído. notReady(3), —tres valores de acción que sólo pueden ser escritos createAndGo(4), createAndWait(5), destroy(6) } EN RESUMEN La principal tecnología de interconexión de redes es el conjunto de protocolos de Internet llamados TCP/IP, que se crearon en la Agencia de Proyectos de Investigación Avanzada de Defensa(DARPA) y que son los que se usan en la Red Internet, (con mayúscula, la red de redes global) pero también en la interconexión de redes menores internet, (con minúscula, redes locales). 29
  30. 30. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD 2. 1.4.1 Creación de una Fila de Conceptos El primer paso es la creación de un identificador de la instancia, que es específico para cada tabla MIB. El identificador de instancia debe tener sentido semánticamente o ser usado singularmente. En el último caso, el módulo MIB puede proporcionar un objeto para ayudar a elegir un identificador sin usar, aunque si dos aplicaciones eligen el mismo identificador, la convención RowStatus genera un mecanismo para evitar la colisión. El siguiente paso es crear la fila, y se puede hacer de dos formas: - Aproximación Directa, la fila se crea y se activa para ser usada por un dispositivo con una sola operación set. - Aproximación Negociada, se crea la fila y por medio de un conjunto de interacciones, se inicializa y se activa para ser utilizada por el dispositivo. La aplicación de administración debe determinar para cada columna: - Qué columnas necesita el agente para activar la fila. - Qué columnas no puede crear el agente, por alguna razón. Una vez creada la fila, la aplicación realiza una operación get para cada columna que conoce, usando el identificador seleccionado en el primer paso. Para cada columna requerida: - Si se devuelve un valor, el agente está indicando que implementa esa columna. - Si se devuelve una excepción noSuchInstance, el agente indica que implementa la columna, pero que la instancia en sí no existe. - Si se devuelve una excepción noSuchObject, el agente indica que no implementa el tipo de objeto correspondiente a esa columna. 30
  31. 31. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD 1.4.1.1 Aproximación Directa Primero se selecciona el identificador deseado. Entonces la aplicación decide lanzar un get para determinar los requisitos del agente para la columna. Todos los valores devueltos deberían ser excepcionales, ya que si no se indicaría que la fila ya existe. Entonces la aplicación enviará al agente un set, que contiene valores para las columnas con un MAX-ACCESS de read-create y el estado de la columna puesto a createAndGo. Cuando el agente procesa la columna de estados en las instancias, si la variable ya existe, devuelve un error inconsistentValue; si no, el agente comprueba que tiene suficiente información (procedente del set y de información local) para crear y activar la fila. Si hay suficiente información, entonces: - Se crea la fila. - Se devuelve una respuesta con noError - El agente asigna valores por defecto a las columnas de las filas cuyos valores no se especificaron en el set. - La columna de estado se pone a active. Si no hay suficiente información, se devuelve un error inconsistentValue. Se debería tener en cuenta que puede que no todas las filas entren en una sola PDU. También, la respuesta de get indica que aquellas columnas que implemente el agente deben ser superconjuntos de las columnas que son obligatorias. Así, en el set, la aplicación sólo tiene que preocuparse de las columnas con un MAX-ACCESS de read-create. Para que esta aproximación funcione, la versión del módulo MIB que conoce la aplicación y el agente debe coincidir. 31
  32. 32. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD 1.4.1.2 Aproximación Negociada Lo primero es seleccionar el identificador deseado. Entonces, la aplicación genera un set con la columna de estado puesta a createAndWait y lo envía al agente. Cuando el agente procesa la columna de estado en las instancias, si no soporta la creación negociada, devuelve un error wrongValue, o si la variable ya existe, devuelve un error inconsistentValue. En otro caso: - Se crea la fila. - Se devuelve una respuesta noError. - El agente asigna valores por defecto a las columnas de las filas cuyos valores no se especificaron en el set. - El agente debe asignar valores por defecto a aquellas filas que implementa de solo lectura. - La columna de estado se activa a notInService o a notReady, según la información disponible del agente. La estación de administración puede usar entonces un get para determinar los requisitos de las columnas del agente. Para cada columna read-create solicitada: Si se devuelve un valor, el agente indica que implementa esa columna y que si a la aplicación no le gusta el valor, debe generar un set para cambiarlo. Si se devuelve una excepción noSuchInstance, el agente indica que antes de activar la fila, la aplicación debe generar un set para proporcionar valores para la columna. Si se devuelve una excepción noSuchObject, el agente indica que la aplicación no debe intentar dar un valor. Cuando el valor de una columna de estado cambia a notInService, el agente indica que la fila está siendo usada en el dispositivo y que la aplicación debería poner la columna de estado a activa. Hay que tener en cuenta que es la aplicación la que determina el número de operaciones set que quiere realizar. Si una fila se encuentra en el estado notInService o notReady, pueden aparecer problemas: Si el dispositivo crea o modifica la misma fila que está siendo negociada entre la aplicación y el agente, entonces existirán dos copias, una en el dispositivo y otra en el agente, aunque cuando la columna de estado se active en el agente, ésta eliminará la del dispositivo. También puede ocurrir que el proceso de negociación se vea interrumpido. Por eso, el agente debe almacenar de vez en cuando filas que no estén en estado activo. 32
  33. 33. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD 1.4.2 Modificación de una Fila de Conceptos Algunos módulos MIB precisan que se desactive una fila para poder modificarla. Para ello, la aplicación pone la columna de estado a notInService. Si el agente no lo soporta, devuelve un error wrongValue; si no, la fila no es accesible para el dispositivo y se devuelve una respuesta de noError. Desactivar una fila es útil cuando las modificaciones no caben en una sola PDU. Por supuesto, hasta que no se hacen todas las modificaciones, la fila no será consistente, por lo que el agente pone la columna de estado a notReady. 1.4.3 Eliminación de una Fila de Conceptos La aplicación pone la columna de estado a destroy. El agente hace la fila inaccesible al dispositivo y a él mismo y devuelve una respuesta noError. 33
  34. 34. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD 5. Interacciones de Invocación Cuando un agente detecta un evento extraordinario, se genera una invocación snmpV2-trap, que se envía a una o más aplicaciones de administración. La invocación snmpV2-trap tiene un formato idéntico a las PDU usadas en otras peticiones. Las dos primeras instancias son especiales: sysUpTime.0, momento en que se generó la invocación. snmpTrapOID.0, el identificador de objeto de la invocación. El Grupo snmpTrap Hay dos objetos escalares relacionados con las invocaciones SNMP. snmpTrap OBJECT IDENTIFIER ::={snmpMIBObjects 4} snmpTrapOID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS accesible-for-notify ... ::= {snmpTrap 1} 1.6 Interacciones entre Administradores Cuando una aplicación quiere informar a otra aplicación, genera una inform-request. El formato de la InformRequest-PDU es idéntico al de las otras PDU del resto de peticiones. Al igual que snmpV2-trap, las dos primeras instancias indican el momento del evento y su identidad. Como es de esperar, sólo algunos dispositivos pueden tener el papel de administrador. Hay que tener cuidado para minimizar el número de informes que se generan. Actualmente, el control de la generación y retransmisión de informes es una tarea específica de implementación. 34
  35. 35. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD 1.6.1 Entidades de Doble Rol Se trata de dispositivos que contienen agentes y aplicaciones de administración. Estos dispositivos recogen y procesan información de los agentes y la proporcionan a la administración. Así, según el entorno SNMPv2, una aplicación de administración es algo que inicia una interacción entre peticiones y respuestas. 4. 2. Mapeo de Transporte Las operaciones SNMP son independientes del protocolo de transporte, utilizando sólo un servicio de transporte no orientado a conexión. Para definir el mapeo de transporte, se especifican dos pasos: - Reglas para tomar la estructura de un mensaje y transformarlo en una cadena de octetos para formar un paquete. - Reglas para enviar el paquete por el servicio de transporte. Hay varios mapeos de transportes definidos y usan el mismo conjunto de reglas para el primer paso. Como todos los objetos y estructuras SNMP se definen con el ASN.1 de OSI, el entorno de administración usa BER (Basic Encoding Rules) de OSI para codificar las estructuras en octetos. Cuando éstos se reciben, se transforman en una estructura de datos con una semántica idéntica. 35
  36. 36. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD 2.1 Direcciones y Dominios de Transporte La relación del protocolo de administración y el servicio de transporte se denomina Dominio de Transporte. 2.1.1 Dominio snmpUDPDomain Identifica el uso de SNMPv2 sobre UDP. Este es el mapeo preferido. Si un objeto TDomain tiene un valor de snmpUDPDomain, entonces el correspondiente objeto TAddress se codifica en seis octetos: SnmpUDPAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT “1d.1d.1d.1d/2d” STATUS current DESCRIPTION 36
  37. 37. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD SYNTAX OCTET STRING (SIZE (6)) La entidad que envía transforma y envía el mensaje como un único datagrama UDP a la dirección de transporte de la entidad receptora. Por convención, los agentes SNMP escuchan en el puerto UDP 161 y envían las notificaciones al puerto UDP 162, aunque una entidad debería configurarse para usar cualquier selector de transporte aceptable. Todas las entidades receptoras deben admitir mensajes de al menos 1472 octetos de longitud. 2.1.2 Dominios snmpCLNSDomain y snmpCONSDomain Identifican el uso de SNMPv2 en los servicios de transporte no orientados a conexión de OSI (CLTS): snmpCLNSDomain se usa cuando CLTS se ejecuta en servicios de red no orientados a conexión de OSI (CLNS), mientras que snmpCONSDomain se usa cuando CLTS se ejecuta en servicios de red orientados a conexión de OSI (CONS). Si un objeto TDomain tiene alguno de estos dos valores, el correspondiente objeto TAddress se codifica así: SnmpOSIAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT “*1x:/1x:” STATUS current DESCRIPTION 37
  38. 38. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD SYNTAX OCTET STRING (SIZE (1 | 4...85)) La entidad que envía transforma el mensaje y lo envía como una única unidad de datos del servicio de transporte (TSDU) a la dirección de transporte de la entidad receptora. Los selectores de transporte por defecto son: Una entidad debería poder configurarse para usar cualquier selector de transporte aceptable. Todas las entidades receptoras deben admitir mensajes de al menos 1472 octetos de longitud. 2.1.3 Dominio snmpDDPDomain Identifica el uso de SNMPv2 sobre Appletalk’s DDP. Si un objeto TDomain tiene un valor de snmpDDPDomain, entonces el correspondiente objeto TAddress se codifica así: SnmpNBPAddress ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION 38
  39. 39. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD SYNTAX OCTET STRING (SIZE (3...99)) La entidad que envía transforma el mensaje y lo envía como un único datagrama DDP a la dirección de transporte de la entidad receptora. Todos los agentes SNMP escuchan en el tipo NBP SNMP Agent y las notificaciones se envían al tipo NBP SNMP Trap Handler. Todas las entidades receptoras deben admitir mensajes de al menos 484 octetos de longitud. 2.1.4 Dominio snmpIPXDomain Identifica el uso de SNMPv2 sobre NetWare’s IPX Si un objeto TDomain tiene un valor de snmpIPXDomain, entonces el correspondiente objeto TAddress se codifica así: SnmpIPXAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT “4x.1x:1x:1x:1x:1x:1x.2d” STATUS current DESCRIPTION 39
  40. 40. PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD SYNTAX OCTET STRING (SIZE (12)) La entidad que envía transforma y envía el mensaje como un único datagrama IPX a la dirección de transporte de la entidad receptora. Por convención, los agentes SNMP escuchan en el socket IPX 36879 y envían las notificaciones al socket IPX 36880, aunque una entidad debería configurarse para usar cualquier selector de transporte aceptable. Todas las entidades receptoras deben admitir mensajes de al menos 546 octetos de longitud. EN RESUMEN Para definir el mapeo de transporte, se especifican dos pasos: - Reglas para tomar la estructura de un mensaje y transformarlo en una cadena de octetos para formar un paquete. - Reglas para enviar el paquete por el servicio de transporte. 40

×