PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

NDICE
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
1. INTRODUCCIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 2. CONCEPTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 3. MODELO DE INFORMACIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 4. MODELO ADMINISTRATIVO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 5. MODELO OPERACIONAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

1. Introduccin
En una internet (con minscula, redes locales) se conectan varias redes entre s con el uso de routers y un protocolo de interconexin de redes, de modo que los routers usan el protocolo para encubrir las caractersticas de las redes y proporcionar un servicio uniforme entre ellas, es decir, aunque cada red use una tecnologa distinta y unas reglas especficas de transmisin, los hosts de cada red ven a la red de igual manera. ste es el poder de la abstraccin de la interconexin entre redes.

La principal tecnologa de interconexin de redes es el conjunto de protocolos de Internet llamados TCP/IP, que se crearon en la Agencia de Proyectos de Investigacin Avanzada de Defensa (DARPA) y que son los que se usan en la Red Internet, (con mayscula, la red de redes global) pero tambin en la interconexin de redes menores internet. SNMP se sita 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. Grficamente se podra ver as:

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

1. Necesidad de administrar redes
Los problemas que se presentan en la interconexin de redes son principalmente dos: a) Dispositivos diferentes: la interconexin de redes permite diferentes tipos de dispositivos y stos son de distintos vendedores, todos ellos soportando el protocolo TCP/IP. Debido a esto, la administracin de redes se presenta como un problema. Sin embargo, usar una tecnologa de interconexin abierta permiti que existieran las redes formadas por dispositivos de distintos fabricantes, por lo que para administrar estas redes, habr que usar una tecnologa de administracin de redes abierta. b) Administraciones diferentes: como se permite la interconexin entre redes de distinto propsito y distinto tamao, hay que tener en cuenta que tambin estn administradas, gestionadas y financiadas de distinta forma.

2. Evolucin histrica del Protocolo Simple de Gestin de Red (SNMP)

El protocolo Snmpv1 fue diseado a mediados de los 80 por Case, McCloghrie, Rose, and Waldbusser, como una solucin a los problemas de comunicacin entre diferentes tipos de redes.

En un principio, su principal meta era el lograr una solucin temporal hasta la llegada de protocolos de gestin de red con mejores diseos y mas completos. Pero esos administradores de red no llegaron y SNMPv1 se convirti en la nica opcin para la gestin de red. El manejo de este protocolo era simple, se basaba en el intercambio de informacin de red a travs de mensajes (PDUs). Adems de ser un protocolo fcilmente extensible a toda la red, debido a esto su uso se estandarizo entre usuarios y empresas que no queran demasiadas complicaciones en la gestin de sus sistemas informticos dentro de una red. No obstante este protocolo no era perfecto, adems no estaba pensado para poder gestionar la inmensa cantidad de redes que cada da iban apareciendo. Para subsanar sus carencias surgi la versin 2 (SNMP v2). Las mayores innovaciones respecto a la primera versin son:

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

- Introduccin de mecanismos de seguridad, totalmente ausentes en la versin 1. Estos mecanismos protegen la privacidad de los datos, confieren autentificacin a los usuarios y controlan el acceso. - Mayor detalle en la definicin de las variables. - Se aaden estructuras de la tabla de datos para facilitar el manejo de los datos. El hecho de poder usar tablas hace aumentar el nmero de objetos capaces de gestionar, con lo que el aumento de redes dej de ser un problema. - Realmente esta versin 2 slo supuso un parche, es ms hubo innovaciones como los mecanismos de seguridad que se quedaron en pura teora, no se llegaron a implementar. Por estas razones, se ha producido la estandarizacin de la versin 3. Con dos ventajas principales sobre sus predecesores: - Aade algunas caractersticas de seguridad como privacidad, autentificacin y autorizacin a la versin 2 del protocolo. Usa Lenguajes Orientados a Objetos (Java, C++) para la construccin de los elementos propios del protocolo(objetos). Estas tcnicas confieren consistencia y llevan implcita la seguridad, por lo que ayudan a los mecanismos de seguridad.

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

2. Conceptos
El entorno usado para administracin en los protocolos de Internet se llama Internet-standard Networking Management Framework (entorno para la administracin de redes basadas en Internet), y esto se debe a motivos histricos: 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 estndar de Internet con la condicin de Recomendado; y el entorno que le sucedi (SNMPv2 Framework), formado por doce documentos. Dos aos despus, este segundo entorno se revis en ocho documentos, quedando algunos como borradores de estndares y otros como proposiciones de estndares. Con el tiempo, estos documentos se convirtieron en un completo estndar de Internet. Fue entonces cuando se declar histrico el estndar 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 slo para inters histrico. Un modelo Un sistema de administracin de red contiene cinco elementos: 1.Uno o ms nodos administrables, conteniendo cada uno un agente. 2.Al menos una estacin de administracin de red (NMS) con soporte para una o ms aplicaciones de administracin de la red. 3.Posiblemente una o ms entidades de doble funcin, que pueden actuar como agente o como administrador. 4.Un protocolo de administracin de red, que es usado por la estacin y los agentes para intercambiar informacin. 5.Informacin que administrar. 1. Nodos administrables Un nodo administrable es un dispositivo que puede clasificarse en una de las siguientes categoras: - Un Host, como una estacin de trabajo, mainframe, o impresora. - Un sistema de enrutamiento. - Un dispositivo de acceso al medio, como un repetidor, un puente o un hub.

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

Estas tres categoras coinciden en que clasifican a algn tipo de dispositivo con alguna capacidad de trabajo en red. Las dos primeras categoras se caracterizan por ser normalmente independientes del medio, mientras que la principal caracterstica de los dispositivos de la tercera clase es la dependencia del medio. 1.1 El axioma fundamental Un buen sistema de administracin de red debe conocer la diversidad de dispositivos existentes y proporcionar un entorno apropiado. As, el axioma fundamental dice que:

El impacto de aadir una administracin de red a un nodo administrable debe ser mnimo, reflejando un comn denominador ms bajo.

El axioma fundamental se debe a las grandes diferencias entre los distintos nodos administrables que existen. 1.2 Caractersticas de los Nodos Administrables Podemos considerar que cada nodo administrable est formado por tres componentes: 1.Funciones de usuario. 2.Un protocolo de administracin, que permite monitorizar y controlar el nodo administrable. 3.Instrucciones de administracin, que interactan con la implementacin del nodo administrable para permitir la monitorizacin y el control. La interaccin entre estos tres componentes es sencilla: las instrucciones actan como un pegamento entre las funciones de usuario y el protocolo de administracin. Esto se debe a un mecanismo de comunicacin interno en el que las estructuras de datos de las funciones de usuario deben ser accesibles y modificables a peticin del protocolo de administracin. 1.3 Modelo Administrativo Actualmente los intercambios de informacin son insuficientes para proporcionar la administracin de los nodos. El protocolo de administracin trabaja en el entorno del modelo administrativo, que mantiene polticas de autorizacin y autentificacin. Esto permite determinar al nodo cmo se est administrando, de modo que slo los procesos de aplicaciones autorizadas realicen la administracin.

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

2. Estacin de Administracin de Red Una estacin de administracin de red es una mquina que ejecuta el protocolo de administracin de red y una o ms aplicaciones de administracin de red. Si el protocolo es el encargado de proporcionar los mecanismos de administracin, entonces las aplicaciones determinan la poltica que se usa para la administracin. El axioma fundamental indica que aadir administracin de red debera tener un impacto mnimo en los nodos, en consecuencia la carga se desplaza a las estaciones. Sin embargo podramos pensar que el sistema que soporta la estacin de administracin es ms potente que un nodo, as que cunta potencia es necesaria entonces? La experiencia muestra que la mayora de las estaciones de trabajo pueden proporcionar los recursos necesarios para soportar una buena estacin de administracin. Hay que tener en cuenta que a medida que hay ms nodos administrables en una internet, se favorece desplazar la carga hacia la estacin de administracin. 2.1 Entidades de doble funcin Se ha dicho que las estaciones de administracin slo interactan con los nodos. Qu pasara si el mismo nodo tambin fuera una estacin de administracin? Es necesario apreciar que el modelo agente-administrador puede soportar directamente, esto si consideramos que el software de cada estacin de administracin puede realizar tanto la funcin de administrador como la de agente, es decir, que el modelo agente-administrador es tambin un modelo peer-to-peer. Teniendo esto en cuenta, se pueden construir relaciones jerrquicas entre las estaciones de administracin. Por ejemplo, se puede construir un sistema de administracin donde cada segmento de una LAN tiene una aplicacin de administracin que controla el estado de los dispositivos de ese segmento. Estas aplicaciones deberan informar a aplicaciones de estaciones de administracin regionales, las cuales deberan informar a estaciones de administracin entre empresas. En este ejemplo, el software de cada estacin realiza un papel de administrador al monitorizar y controlar dispositivos que dependen de l jerrquicamente, y un papel de agente al informar y actuar segn los comandos proporcionados por un superior jerrquico. El concepto clave con las entidades de doble funcin es que la relacin jerrquica depende de la configuracin, mientras que la relacin peer-to-peer depende de la arquitectura.

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

3. Protocolo de Administracin de Red Dependiendo del paradigma que se utilice para la administracin de la red, un protocolo de administracin puede tomar varias formas: 3.1 Operaciones En el entorno de administracin, cada nodo tiene una serie de variables, de modo que leyendo estas variables se monitoriza el nodo, y cambindoles el valor se controla. Se trata de un paradigma de depuracin remota, cuya ventaja es que es sencillo construir un protocolo de administracin que realice estas funciones. Adems de las operaciones de lectura y escritura, existen otras dos: 1.Una operacin cruzada, que permite determinar a la estacin de administracin qu variables soporta un nodo. 2.Una operacin de interrupcin, que permite a los nodos informar a la estacin de administracin de un evento extraordinario. Veamos un poco ms de ambas operaciones. 3.1.1 Operacin de Examen Como los nodos realizan distintas funciones, tambin contienen diferentes variables de administracin. En el entorno de administracin, 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. Tambin hay que tener en cuenta que pueden existir variables que aparezcan ms de una vez. Por ejemplo, la tabla de enrutamiento IP no es escalar, sino que est formada por una o ms filas, cada una de las cuales presenta varias columnas. Por tanto, el protocolo de administracin debe proporcionar dos nuevas funciones: - Un mecanismo para recuperar celdas de una tabla. - Un mecanismo para recuperar nmeros grandes de una celda de una tabla.

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

3.1.2 Operacin de Interrupcin Desde el comienzo de los sistemas operativos, siempre se ha debatido acerca de utilizar un mtodo de interrupcin o un mtodo de sondeo. Esta discusin tambin se realiza en la administracin de redes. Los argumentos para cada uno de estos mtodos son los siguientes: Con el mtodo basado en interrupciones, tenemos las siguientes ventajas: cuando ocurre un evento extraordinario, el nodo enva una interrupcin a la estacin de administracin adecuada (suponiendo que el dispositivo no ha cado y se puede alcanzar la estacin). Por tanto tenemos la ventaja de una notificacin inmediata. Con el mtodo basado en interrupciones, tenemos las siguientes desventajas: requiere recursos para generar la interrupcin ya que si la interrupcin debe contener mucha informacin, el nodo perder tiempo en prepararla y no se dedicar a cosas tiles. Por supuesto, cuando se genera una interrupcin, el agente asume que la aplicacin de administracin est preparada para recibir la informacin. Por tanto hay que usar un diseo cuidadoso para que las interrupciones sean recibidas slo por aquellas estaciones interesadas. Ms an, 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 congestin de la red. Por eso se refina el mtodo de las interrupciones de modo que un nodo slo informa cuando la ocurrencia de un evento sobrepasa un determinado umbral, pero esto implica que el agente debe gastar tiempo para determinar cundo debe generar una interrupcin. Es decir, el mtodo basado en interrupciones tiene un fuerte impacto en el agente, en la red o en ambos. En conclusin, como los nodos tienen una pequea visin de toda la red, es conveniente que las aplicaciones de administracin detecten el problema de alguna otra forma. Con el mtodo basado en sondeo, una aplicacin de administracin pregunta peridicamente al nodo cmo van las cosas, as el control lo tiene la aplicacin, la cual s tiene una visin global de la red. La desventaja del mtodo de sondeo es que la aplicacin de administracin 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 catastrficos es demasiado lenta. Otra desventaja es el trfico que se introduce en la red, por lo que la aplicacin de administracin debe tener recursos de almacenamiento adicionales para ello. En el entorno de administracin se usa el modelo interrupcin-sondeo directo (trap-directed polling). Cuando ocurre un evento extraordinario, el nodo manda una interrupcin simple a la aplicacin. La aplicacin es entonces la responsable de iniciar conversaciones con el nodo para determinar la naturaleza y la extensin del problema. Esto es muy efectivo ya que el impacto creado en los nodos es pequeo, en el ancho de banda es mnimo y los problemas se resuelven en el momento oportuno. Por tanto, las interrupciones actan como una alarma previa, y se usa un sondeo de baja frecuencia.

10

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

3.2 Forma de transporte

La eleccin de un servicio de transporte por parte del protocolo de administracin 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 comunicacin menos impactante en el proceso.

La aplicacin de administracin es la que debe decidir el nivel de fiabilidad deseado e implementar el algoritmo apropiado, sin dejar esta decisin en manos del servicio de transporte. De esta manera, el nodo tendra menos carga debido a esta eleccin. Todo esto conduce a elegir un servicio de transporte no orientado a conexin. Esta eleccin implica un comportamiento sin preocupaciones por parte del agente y permite a la aplicacin controlar el nivel de fiabilidad. Hay otro motivo para elegir servicios de transporte no orientados a conexin. Cuando la red est congestionada y es difcil establecer una conexin, un protocolo orientado a conexin realiza sta en tres pasos. Si la red est perdiendo paquetes, es ms difcil establecer este modo de conexin 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. Informacin de administracin Finalmente, hemos de explicar la informacin a intercambiar entre la estacin de administracin y el nodo, utilizando el protocolo de administracin. Una unidad de informacin de administracin se denomina objeto administrado (managed object), y un conjunto de dichos objetos se denomina Mdulo de Base de Informacin de Administracin (Mdulo MIB).

La caracterstica ms importante de los mtodos usados para describir la informacin de administracin es la extensibilidad, de modo que se pueda comenzar con un pequeo conjunto de definiciones, para aumentarlo segn crezcan las necesidades.

Un efecto lateral de la extensibilidad, es que los vendedores de dispositivos pueden aadir sus propios objetos para mejorar sus productos, lo que puede influir en la estandarizacin de la tecnologa de administracin.

11

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

4.1 Objetos Administrados (Managed Objects) La instrumentacin de administracin acta entre los protocolos del dispositivo y el protocolo de administracin, tomando la informacin del dispositivo y presentndola como un conjunto de objetos administrados. Esta coleccin se denomina Recursos Objeto del Agente. 4.2 Revisin del Modelo Administrativo Anteriormente se present el modelo administrativo como el responsable de proporcionar polticas de autorizacin y autentificacin. Ahora tambin podemos aadir que es el modelo administrativo el que determina qu aplicacin de administracin puede acceder a qu objeto y con qu operaciones. Las operaciones de administracin permitidas a una aplicacin por un agente se denominan poltica de acceso. La coleccin 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 informacin de administracin no local. Cuando otro agente recibe la peticin de esa informacin, realiza una serie de operaciones para satisfacer la solicitud. Esto se denomina Interaccin de delegacin (interaccin 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 poltica administrativa extensiva, y el dispositivo slo responde a las peticiones realizadas por el agente. Caching Firewall: puede ser til que el agente proxy tenga la informacin a modo de cach, tambin para minimizar la carga del dispositivo. Puentes de transporte: en una red multiprotocolo, un dispositivo soportara el servicio punto a punto de slo un conjunto de protocolos. Idealmente, una estacin de administracin soportara 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 administracin entre el dispositivo y la estacin. Traducciones de protocolo: en el caso de que los dispositivos no soporten protocolos de administracin, 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.

2. 3.

4.

12

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

Una propiedad importante de las relaciones tipo proxy es el principio de transparencia. La idea es aparentar que la aplicacin se est comunicando directamente con el agente real, es decir, una aplicacin simplemente especifica los recursos deseados y el agente proxy es el encargado de hacer que las cosas salgan bien, como si la informacin de administracin la tuviera el agente proxy localmente. 5. En perspectiva El axioma fundamental del entorno de administracin se basa en la nocin de distribucin universal. Si se ve la administracin de redes como un aspecto esencial, entonces debera distribuirse en la mayor cantidad de dispositivos de la red. Como hay muchos ms agentes que estaciones de administracin, entonces minimizando el impacto de la administracin en los agentes, podremos solucionar el problema. Otro principio importante es que la administracin de red es distinta a cualquier otra aplicacin. Cuando todo falla, la administracin de red debe seguir funcionando. Este principio indica que muchas de las funciones que se encuentran en la capa de transporte, sern directamente direccionadas por aplicaciones en la estacin de administracin, teniendo en cuenta que sern las propias aplicaciones las que definan el grado de fiabilidad requerido de cada operacin. Sin embargo, el servicio de transporte no debe ayudar, slo debera ser la forma ms simple de permitir atravesar la red.

13

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

3. Modelo de Informacin
Para examinar el papel de la informacin de gestin en el entorno de administracin, consideraremos las siguientes cinco partes: Reglas para definir la informacin de administracin. Ejemplos de colecciones de definiciones existentes. Reglas para definir los convenios textuales (definicin de tipos de uso frecuente). Cmo se accede a stas al definir informacin de administracin. Coexistencia entre el entorno original y el entorno SNMPv2.

Antes de comenzar, hay que aclarar la relacin entre variables, objetos y tipos de objetos. Un objeto administrable tiene asociado una sintaxis y una semntica de tipo abstracto, mientras que una variable es una instancia de un objeto particular. En este caso tambin se denomina instancia de un objeto. ESTRUCTURA DE LA INFORMACIN DE ADMINISTRACIN

La Estructura de la Informacin de Administracin (SMI) define las reglas para definir la informacin de administracin independientemente de los detalles de implementacin. La SMI se define usando ASN.1 (Abstract Syntax Notation).

Si se piensa que una coleccin 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 Informacin de Administracin (MIB). 1. Mdulos de Informacin Existen tres clases de mdulos ASN.1, tambin llamados Mdulos de Informacin, definidos por el SMI: - Mdulos MIB, que define una coleccin de objetos de administracin afines. - Sentencias de Conformidad, que definen un conjunto de requisitos de los nodos con respecto a uno o ms mdulos MIB. - Sentencias de Capacidad, que describe la capacidad de un nodo para implementar los objetos definidos en uno o ms mdulos MIB.

14

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

Por supuesto, estas funciones deberan estar combinadas en un slo mdulo. Cada mdulo de informacin debe comenzar con la indicacin de su identidad y la historia de sus revisiones (macro MODULE-IDENTITY). Dentro de cada modulo existirn objetos, los cuales se definen con la macro OBJECT-TYPE, la expansin de stos se produce durante la implementacin. Tambin se usaran convenciones textuales (macro TEXTUALCONVENTION), que son redefiniciones ms precisas de algn tipo de datos, dentro de un MIB. Existen tres tipos de MIB: - Estndar: son mdulos que se han convertido en un estndar. - Experimental: Esperan su oportunidad de convertirse en estndar. - Especifico: son propios de alguna empresa. El modulo MIB de la V2 contiene 5 grupos de objetos: system, snmp, snmpComunity, SnmpSet y SnmpBasicNotification.

15

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

4. Modelo Administrativo
Consideraremos cmo se definen polticas administrativas para aplicaciones de gestin y agentes. Esta parte de la red de gestin ha sufrido la mayor revisin desde la introduccin de SNMP. Desafortunadamente todava no existe un consenso en la solucin ms apropiada al problema. 1. Conceptos En el entorno de gestin, una entidad SNMP es una entidad lgica en nombre de la cual un agente o una aplicacin de gestin estn procesando un mensaje. El entorno de gestin es responsable de proporcionar: - Autentificacin: se refiere a cmo las entidades SNMP identifican sus mensajes. - Privacidad: se refiere a cmo las entidades SNMP protegen sus mensajes. - Autorizacin: se refiere a cmo una entidad agente SNMP determina los objetos que son accesibles a una entidad de aplicacin de gestin dada, y las operaciones que se pueden realizar en estos objetos. 1.1 Autentificacin Cuando una entidad comienza una comunicacin, es configurada para suministrar credenciales de autentificacin como una parte de la comunicacin. Dependiendo de los mecanismos de autentificacin, sern vlidas tres clases de servicios: - Identificacin 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. - Proteccin limitada de retransmisin, 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 comunicacin, no es un objetivo del entorno de gestin. No obstante para alcanzar seguridad con las anteriores funciones deberemos usar: - Encriptacin con firma. - Algoritmos (message digest). - Relojes incrementados montonamente.

16

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

1.2 Privacidad Como las propiedades de autentificacin estn asociadas con la entidad que enva, las propiedades de privacidad se pueden asociar con las entidades receptoras. Para lograr privacidad con seguridad, deberamos usar un algoritmo de encriptacin y la clave asociada. 1.3 Autorizacin Cuando un agente ejecuta una operacin, primero deber identificar la coleccin de recursos de objetos de gestin a monitorizar. Si los recursos son accesibles mediante algn mecanismo local, se dice que la operacin 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 envo de mensajes SNMP a una entidad remota, entonces se dice que los objetos son validos a travs de una relacin proxy.

Una vez que los recursos son identificados, slo resta determinar las operaciones SNMP empleadas en ellos. A esto se denomina Poltica de Acceso, y es usada para el control del flujo de informacin entre la entidad agente SNMP y una entidad de aplicacin de gestin dada.

2. Comunidades

SNMP v2 esta diseado para soportar mltiples entornos de administracin. El entorno que veremos se denomina entorno de gestin basado en comunidades, debido a que usa el concepto de comunidad empleado en el SNMP original.

SNMP define una comunidad como una relacin entre entidades SNMP. Una comunidad SNMP se escribe como una cadena de octetos sin interpretacin. 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 operacin SNMP y los operandos asociados.

17

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

La cadena de comunidad es un simple manejador para las relaciones de gestin. Ahora realizamos una valoracin de las propiedades de gestin de SNMP: Identificacin de origen: como las cadenas de comunidad son enviadas sin proteccin, 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. Proteccin limitada de reenvos: cualquier tercera parte puede retrasar un mensaje SNMP que haya interceptado. Privacidad: cualquier tercera parte puede leer el mensaje SNMP que haya interceptado. Autorizacin: los agentes son responsables de mantener informacin local as como los MIB que contienen, o las relaciones de proxy vlidas. 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 tcnicos para estos asuntos, sus mecanismos no llevan a ninguna solucin. Naturalmente, el mercado se ha adaptado a estas carencias: - Primero, varios diseadores de mdulos 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 propsito. 3. Procedimientos Veremos cmo se procesan los mensajes SNMP. Para empezar, veremos el formato del mensaje. Existen tres partes: - Versin: el nmero de versin del mensaje. - Comunidad: la cadena de comunidad. - Datos: una operacin SNMP, definido como una estructura PDUs

18

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 autorizacin adecuada para usar las operaciones y el acceso a los objetos MIB deseados. Luego: - Una estructura de mensaje es construida desde esta informacin. - Es convertida en una cadena de octetos. - Es enviada a la direccin 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 representacin de una estructura de mensaje. Si no es una representacin de una estructura de mensaje, el contador (snmpInASNParseErrs) es incrementado y el paquete es descartado. En caso afirmativo, la versin del mensaje es revisada para ver si se refiere a una versin implementada por la entidad receptora. Si no es una versin 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 autorizacin para utilizar la operacin contenida en los datos del mensaje. Si no tuviera autorizacin, el contador (snmpInBadCommunityUses) es incrementado y el paquete descartado. De otra forma, La entidad receptora chequea para mirar que clase de recursos de objetos estn asociados con la comunidad. Si la comunidad se refiere a recursos de objetos locales, entonces la operacin 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 operacin es una respuesta, entonces es correlativa con la anterior peticin, y una respuesta es enviada a la entidad originaria de la peticin. - Si la operacin es una Trap o un informe, entonces el agente proxy, usando conocimiento local, determina la entidad SNMP que debera enviar el mensaje. 3.3 Esperando por mensajes Normalmente las entidades SNMP esperan los mensajes en la direccin de transporte por defecto asociada con cada dominio de transporte vlido para el.

19

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

5. Modelo Operacional
Examinaremos el papel de las operaciones del protocolo en el entorno de administracin. SNMP es un protocolo asncrono de peticin-respuesta basado en el modelo de interrupcin-sondeo directo; esto significa que una entidad no necesita esperar una respuesta despus 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 conexin, y que normalmente es UDP. Aunque sto ratifica el Axioma Fundamental, hay una razn ms importante: Las funciones de administracin de red se realizan cuando hay problemas, de modo que la aplicacin de administracin es la que decide qu restricciones realiza para el trfico de administracin. La eleccin de un servicio de transporte no orientado a conexin permite a la estacin determinar el nivel de retransmisin necesario para complacer a las redes congestionadas. 1. Interacciones del Protocolo Una interaccin SNMP consiste en una peticin de algn tipo, seguida por una respuesta. Hay cuatro resultados posibles de una operacin: Una respuesta sin excepcin o error. Una respuesta con una o ms excepciones. Una respuesta con error. Sobrepasar el tiempo de espera (timeout).

A continuacin se describen los campos del tipo de dato PDU. - request-id, valor entero usado por la aplicacin para distinguir entre peticiones pendientes, lo que permite a la aplicacin mandar rpidamente varios mensajes SNMP, reconocer mensajes duplicados en la red y medir el tiempo del trfico que genera. Los agentes no pueden modificar este campo. - error-status, si no es cero, representa un error al procesar la peticin y que debera ignorarse el campo variable-bindings. - error-index, si no es cero indica qu variable de la peticin es errnea. - variable-bindings, Lista de variables, con su nombre y valor.

20

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

Las operaciones de SNMPv2 se pueden clasificar as: - Recuperacin: get, get-next y get-bulk. - Modificacin: set. - Invocacin: snmpv2-trap. - Administradores: inform. 1.1 Interacciones Veamos primero una interaccin normal entre dos entidades SNMPv2, para ms adelante estudiar sus variaciones: 1. La entidad que inicia el protocolo hace una peticin con: - Un nico request-id. - error-status/error-index a cero. - Cero o ms instancias de variables. 2. Si la operacin 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 operacin de recuperacin, en la peticin, los valores asociados con las variables tienen el valor unSpecified; si no, las instancias de variables esperan valores. Si no se solicita una operacin de recuperacin, las instancias de las variables de la respuesta son iguales a las de la peticin. 1.1.1 Interaccin de Excepciones Mientras se procesa una peticin de recuperacin, el agente podra encontrar una excepcin, indicando que una determinada variable no puede ser procesada. Hay tres tipos de valores de excepcin: - 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 operacin. - endOfMibView, indica que no hay ms informacin en la vista del MIB para la operacin.

21

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 peticin de recuperacin con: - Un nico request-id. - error-status/error-index a cero. - Cero o ms 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 ms valores de excepcin. 1.1.2 Interaccin de Error Mientras se procesa alguna peticin, el agente puede encontrar un error e indica que la operacin 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 peticin de recuperacin con: - Un nico request-id. - error-status/error-index a cero. - Cero o ms 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 peticin. Teniendo en cuenta que los errores nunca se devuelven en una respuesta a una operacin de invocacin, hay dos clases de errores que pueden devolverse en la respuesta a cualquier otra peticin: tooBig, indica que la respuesta podra ser demasiado larga para enviarla. genErr, no debera devolverse excepto que no haya otra posibilidad.

22

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

Si se procesa una peticin de modificacin, hay otra case de errores que deberan devolverse, pero que se vern ms adelante. 1.1.3 Interaccin de Timeout Esta interaccin ocurre cuando se enva una peticin pero no se recibe respuesta. Hay varias posibilidades: La red omite la peticin. El agente no est ejecutndose. El agente omite la peticin. La red omite la respuesta. El tiempo de espera fue muy corto.

1.1.4 De la Interaccin al Procesamiento Para procesar las peticiones, primero debe aceptarse una estructura Message para que la evale la entidad. Cuando la peticin se procesa, se examina la lista de variables instanciadas; en el caso que el campo variablebindings est vaco, termina el procesamiento devolviendo una respuesta noError.

2. Peticiones de Recuperacin

Para examinar eficientemente la informacin de administracin, el entorno de administracin usa un mtodo inteligente para identificar las instancias: Es usado un OBJECT IDENTIFIER, formado por la concatenacin del nombre del tipo objeto con un sufijo.

1.2.1 El Operador Get Si la aplicacin de administracin conoce las instancias que necesita, realiza una get-request. Slo se pueden devolver los errores tooBig y genErr. Por otro lado, para cada variable de la peticin, la instancia se recupera de la vista del MIB con esta operacin: - Si el agente no implementa el tipo objeto asociado con la variable, se devuelve la excepcin noSuchObject. - Si la instancia no existe o no la soporta el MIB, se devuelve la excepcin noSuchInstance. - Se devuelve el valor asociado a la instancia.

23

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

1.2.2 El Operador Get-Next Si la aplicacin no conoce exactamente la instancia de la informacin que necesita, realiza una get-nextrequest. Slo se pueden devolver los errores tooBig y genErr. Por otro lado, para cada variable de la peticin, se devuelve la primera instancia que siga a la variable que est en la vista del MIB con esta operacin: - Si no hay una prxima instancia para la variable en el MIB, se devuelve una excepcin 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 slo se devuelve una excepcin si el operando de get-next es mayor, lexicogrficamente hablando, que la mayor instancia del MIB. Como el operador get-next soporta mltiples operandos, se puede examinar eficientemente la tabla entera. La aplicacin de administracin 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 mltiples operandos para examinar una tabla vaca, se devuelva un error de tipo tooBig en vez de devolver las mltiples 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 funcin 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 conexin de modo que la aplicacin sea la responsable de controlar las interacciones. Las aplicaciones de administracin tambin deben controlar los tiempos de las interacciones

24

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 idntico la del resto de operaciones SNMP, y los campos se describen a continuacin: request-id, el usual. non-repeaters, nmero de variables que deberan recuperarse de una vez. max-repetitions, nmero mximo de veces que otras variables deberan recuperarse. variable-bindings, el usual ignorando los valores. Cuando un agente recibe una get-bulk, calcula el mnimo de: El tamao mximo del mensaje del emisor. El tamao de la generacin de mensajes del propio agente. De aqu resta la suma de dos cantidades: El tamao de las capas de privacidad/autentificacin de la generacin de la respuesta. El tamao de una respuesta sin variables instanciadas.

Dicha diferencia indica la cantidad mxima 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 ms variables instanciadas. El agente examina las variables de la peticin usando el operador get-next y aadiendo cada nueva instancia con su valor a la respuesta y decrementando la cantidad de espacio libre. Si no hay suficiente espacio, se enva la respuesta antes de colapsar el espacio libre.

25

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

Finalmente, el espacio libre se ocupa, o se realiza el mximo nmero de repeticiones. Es importante tener en cuenta que el agente puede terminar una repeticin en cualquier momento. Existe otra forma con la que la operacin get-bulk termina prematuramente: Esto ocurre cuando al examinar las variables de la tabla, se devuelve una excepcin endOfMibView. En este caso, todas las futuras repeticiones devolvern lo mismo y se omitirn de la respuesta. Por ltimo, es importante saber que cuando un agente decide procesar una peticin get-bulk, slo se puede devolver el error genErr, ya que devolver tooBig no tiene sentido. 1.2.4 Ms Caractersticas del Operador Get-Bulk La respuesta a un operador get-bulk no es ms que la concatenacin de un nmero de respuestas maxrepitition de interacciones get-next. La parte ms interesante del operador get-bulk es que puede implementarse en el agente a alto nivel mejor que en las rutinas especficas de los objetos. 3. Peticiones de Modificacin

Slo hay una peticin de modificacin: El operador set. Cuando una aplicacin de administracin conoce exactamente las instancias que necesita, genera una set-request.

La semntica de la operacin set es tal que la operacin tiene xito si y slo 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 generara un error tooBig. Dicho concepto consta de dos pasadas. En la primera, cada instancia se examina y se hace una comprobacin para verificar que: - La variable es soportada por la vista del MIB para esa operacin. - Si la variable existe, el agente puede modificar las instancias del tipo objeto correspondiente.

26

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

- El valor proporcionado es correcto sintcticamente. - Si la variable no existe, el agente es capaz de crear instancias del tipo de objeto correspondiente. - El nombre y valor proporcionado son correctos sintcticamente y son consistentes con los valores de las otras variables de la peticin. - Todos los recursos necesarios para el cambio estn 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 cdigos de error, adems de los habituales, que son los siguientes, as como las causas que los producen: 1. 2. noAccess, la variable no es soportada por la vista del MIB para esa operacin. notWritable, La variable existe pero el agente no puede modificar instancias del tipo objeto correspondiente. wrongType, el nuevo valor proporcionado es de un tipo de datos ASN.1 errneo. wrongLength, el nuevo valor proporcionado es de longitud errnea. wrongEncoding, el nuevo valor proporcionado est codificado errneamente. wrongValue, el nuevo valor est fuera del rango de valores admitidos para el tipo de objeto correspondiente. noCreation, la variable no existe y el agente no puede crear instancias del tipo objeto correspondiente. 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. inconsistentValue, el valor proporcionado es inconsistente con los valores de otro objeto en el agente.

3. 4. 5. 6.

7.

8.

9.

10. resourceUnvailable, un recurso requerido no puede ser reservado.

27

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

Los cdigos noCreation y notWritable son de tipo permanente, mientras que los tres ltimos son de tipo transitorio. El resto son casos que no deberan ocurrir si la aplicacin y el agente tuvieran un mismo concepto de los objetos en cuestin. Slo 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 relacin entre las variables presentadas en una lista de variables. Cualquier relacin existe como una caracterstica del diseo 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 administracin. Hay que tener en cuenta: 1. 2. 3. 4. 5. El agente puede no ser capaz de implementar algunas columnas en una fila de conceptos. El agente puede necesitar que algunas columnas se creen antes de usarlas. Los valores de todas las columnas pueden no entrar en una sola PDU. La aplicacin de administracin puede querer examinar los valores de algunas columnas. Las aplicaciones que cooperan no quieren comisionar al crear nuevas filas.

28

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

En SNMPv2, la convencin textual RowStatus se usa para expresar la forma de manipular una fila: cuando una tabla se define en un mdulo 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 relacin entre el dispositivo y la fila de conceptos. Un resumen de la convencin textual RowStatus es la siguiente:

RowStatus ::= TEXTUAL-CONVENTION ... SYNTAX INTEGER { dos valores de estado/accin que pueden ser leidos o escritos. active(1), notInService(2), un valor de estado, que solo puede ser ledo. notReady(3), tres valores de accin que slo pueden ser escritos createAndGo(4), createAndWait(5), destroy(6) }

EN RESUMEN La principal tecnologa de interconexin de redes es el conjunto de protocolos de Internet llamados TCP/IP, que se crearon en la Agencia de Proyectos de Investigacin Avanzada de Defensa(DARPA) y que son los que se usan en la Red Internet, (con mayscula, la red de redes global) pero tambin en la interconexin de redes menores internet, (con minscula, redes locales).

29

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

2. 1.4.1 Creacin de una Fila de Conceptos El primer paso es la creacin de un identificador de la instancia, que es especfico para cada tabla MIB. El identificador de instancia debe tener sentido semnticamente o ser usado singularmente. En el ltimo caso, el mdulo MIB puede proporcionar un objeto para ayudar a elegir un identificador sin usar, aunque si dos aplicaciones eligen el mismo identificador, la convencin RowStatus genera un mecanismo para evitar la colisin. El siguiente paso es crear la fila, y se puede hacer de dos formas: - Aproximacin Directa, la fila se crea y se activa para ser usada por un dispositivo con una sola operacin set. - Aproximacin 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 aplicacin de administracin debe determinar para cada columna: - Qu columnas necesita el agente para activar la fila. - Qu columnas no puede crear el agente, por alguna razn. Una vez creada la fila, la aplicacin realiza una operacin 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 excepcin noSuchInstance, el agente indica que implementa la columna, pero que la instancia en s no existe. - Si se devuelve una excepcin noSuchObject, el agente indica que no implementa el tipo de objeto correspondiente a esa columna.

30

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

1.4.1.1 Aproximacin Directa

Primero se selecciona el identificador deseado. Entonces la aplicacin decide lanzar un get para determinar los requisitos del agente para la columna. Todos los valores devueltos deberan ser excepcionales, ya que si no se indicara que la fila ya existe.

Entonces la aplicacin 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 informacin (procedente del set y de informacin local) para crear y activar la fila. Si hay suficiente informacin, 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 informacin, se devuelve un error inconsistentValue.

Se debera tener en cuenta que puede que no todas las filas entren en una sola PDU. Tambin, 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 aplicacin slo tiene que preocuparse de las columnas con un MAX-ACCESS de read-create.

Para que esta aproximacin funcione, la versin del mdulo MIB que conoce la aplicacin y el agente debe coincidir.

31

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

1.4.1.2 Aproximacin Negociada Lo primero es seleccionar el identificador deseado. Entonces, la aplicacin genera un set con la columna de estado puesta a createAndWait y lo enva al agente. Cuando el agente procesa la columna de estado en las instancias, si no soporta la creacin 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, segn la informacin disponible del agente. La estacin de administracin 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 aplicacin no le gusta el valor, debe generar un set para cambiarlo. Si se devuelve una excepcin noSuchInstance, el agente indica que antes de activar la fila, la aplicacin debe generar un set para proporcionar valores para la columna. Si se devuelve una excepcin noSuchObject, el agente indica que la aplicacin 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 aplicacin debera poner la columna de estado a activa. Hay que tener en cuenta que es la aplicacin la que determina el nmero 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 aplicacin y el agente, entonces existirn 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. Tambin puede ocurrir que el proceso de negociacin se vea interrumpido. Por eso, el agente debe almacenar de vez en cuando filas que no estn en estado activo.

32

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

1.4.2 Modificacin de una Fila de Conceptos Algunos mdulos MIB precisan que se desactive una fila para poder modificarla. Para ello, la aplicacin 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 Eliminacin de una Fila de Conceptos La aplicacin 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

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

5. Interacciones de Invocacin
Cuando un agente detecta un evento extraordinario, se genera una invocacin snmpV2-trap, que se enva a una o ms aplicaciones de administracin. La invocacin snmpV2-trap tiene un formato idntico a las PDU usadas en otras peticiones.

Las dos primeras instancias son especiales: sysUpTime.0, momento en que se gener la invocacin. snmpTrapOID.0, el identificador de objeto de la invocacin. 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 aplicacin quiere informar a otra aplicacin, genera una inform-request. El formato de la InformRequest-PDU es idntico 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, slo algunos dispositivos pueden tener el papel de administrador. Hay que tener cuidado para minimizar el nmero de informes que se generan. Actualmente, el control de la generacin y retransmisin de informes es una tarea especfica de implementacin.

34

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

1.6.1 Entidades de Doble Rol

Se trata de dispositivos que contienen agentes y aplicaciones de administracin. Estos dispositivos recogen y procesan informacin de los agentes y la proporcionan a la administracin. As, segn el entorno SNMPv2, una aplicacin de administracin es algo que inicia una interaccin entre peticiones y respuestas.

4. 2. Mapeo de Transporte

Las operaciones SNMP son independientes del protocolo de transporte, utilizando slo un servicio de transporte no orientado a conexin.

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 administracin 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 semntica idntica.

35

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

2.1 Direcciones y Dominios de Transporte La relacin del protocolo de administracin 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

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

SYNTAX OCTET STRING (SIZE (6))

La entidad que enva transforma y enva el mensaje como un nico datagrama UDP a la direccin de transporte de la entidad receptora. Por convencin, los agentes SNMP escuchan en el puerto UDP 161 y envan las notificaciones al puerto UDP 162, aunque una entidad debera 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 conexin de OSI (CLTS): snmpCLNSDomain se usa cuando CLTS se ejecuta en servicios de red no orientados a conexin de OSI (CLNS), mientras que snmpCONSDomain se usa cuando CLTS se ejecuta en servicios de red orientados a conexin 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

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

SYNTAX OCTET STRING (SIZE (1 | 4...85))

La entidad que enva transforma el mensaje y lo enva como una nica unidad de datos del servicio de transporte (TSDU) a la direccin de transporte de la entidad receptora. Los selectores de transporte por defecto son:

Una entidad debera 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 Appletalks 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

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

SYNTAX OCTET STRING (SIZE (3...99))

La entidad que enva transforma el mensaje y lo enva como un nico datagrama DDP a la direccin de transporte de la entidad receptora. Todos los agentes SNMP escuchan en el tipo NBP SNMP Agent y las notificaciones se envan 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 NetWares 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

PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD

SYNTAX OCTET STRING (SIZE (12)) La entidad que enva transforma y enva el mensaje como un nico datagrama IPX a la direccin de transporte de la entidad receptora. Por convencin, los agentes SNMP escuchan en el socket IPX 36879 y envan las notificaciones al socket IPX 36880, aunque una entidad debera 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