protocolo

PROTOCOLOSNMP: ESTUDIO EN

PROFUNDIDAD

Í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

1. Introducción

En una internet (con minúscula, redes locales) se conectan varias redes entre sí con el uso derouters y un protocolo de interconexión de redes, de modo que los routers usan el protocolo paraencubrir 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 hostsde cada red ven a la red de igual manera. Éste es el poder de la abstracción de la interconexiónentre 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 quese usan en la Red Internet, (con mayúscula, la red de redes global) pero también en la interconexión deredes 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 deprotocolos TCP/IP. Siempre en la capa de transporte. Gráficamente se podría ver así:


4

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 éstosson de distintos vendedores, todos ellos soportando el protocolo TCP/IP. Debido a esto, laadministración de redes se presenta como un problema. Sin embargo, usar una tecnología deinterconexión abierta permitió que existieran las redes formadas por dispositivos de distintosfabricantes, por lo que para administrar estas redes, habrá que usar una tecnología deadministración de redes abierta.

b) Administraciones diferentes: como se permite la interconexión entre redes de distinto propósito ydistinto tamaño, hay que tener en cuenta que también están administradas, gestionadas yfinanciadas 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, andWaldbusser, 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 degestión de red con mejores diseños y mas completos. Pero esos administradores de red no llegaron y SNMPv1se 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 demensajes (PDU’s). Además de ser un protocolo fácilmente extensible a toda la red, debido a esto su uso seestandarizo entre usuarios y empresas que no querían demasiadas complicaciones en la gestión de sussistemas informáticos dentro de una red.

No obstante este protocolo no era perfecto, además no estaba pensado para poder gestionar la inmensacantidad 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:

- Introducción de mecanismos de seguridad, totalmente ausentes en la versión 1. Estos mecanismosprotegen 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 poderusar tablas hace aumentar el número de objetos capaces de gestionar, con lo que el aumento deredes dejó de ser un problema.

- Realmente esta versión 2 sólo supuso un parche, es más hubo innovaciones como los mecanismos deseguridad que se quedaron en pura teoría, no se llegaron a implementar. Por estas razones, se haproducido 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 laversión 2 del protocolo.

Usa Lenguajes Orientados a Objetos (Java, C++) para la construcción de los elementos propios delprotocolo(objetos). Estas técnicas confieren consistencia y llevan implícita la seguridad, por lo que ayudana los mecanismos de seguridad.


5

2. Conceptos

El entorno usado para administración en los protocolos de Internet se llama Internet-standard NetworkingManagement Framework (entorno para la administración de redes basadas en Internet), y esto se debe amotivos históricos: los esquemas previos eran ocasionales y propietarios.

Actualmente existen dos versiones de este entorno: el entorno original (Internet-standard NetworkingManagement Framework), compuesto por tres documentos, cada uno de los cuales es un estándar de Internetcon la condición de Recomendado; y el entorno que le sucedió (SNMPv2 Framework), formado por docedocumentos. Dos años después, este segundo entorno se revisó en ocho documentos, quedando algunos comoborradores de estándares y otros como proposiciones de estándares. Con el tiempo, estos documentos seconvirtieron en un completo estándar de Internet. Fue entonces cuando se declaró histórico el estándaroriginal 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ólopara 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

Estas tres categorías coinciden en que clasifican a algún tipo de dispositivo con alguna capacidad de trabajoen red. Las dos primeras categorías se caracterizan por ser normalmente independientes del medio, mientrasque 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 yproporcionar 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 entrelas funciones de usuario y el protocolo de administración. Esto se debe a un mecanismo de comunicacióninterno en el que las estructuras de datos de las funciones de usuario deben ser accesibles y modificables apetición del protocolo de administración.

1.3 Modelo Administrativo

Actualmente los intercambios de información son insuficientes para proporcionar la administración de losnodos. El protocolo de administración trabaja en el entorno del modelo administrativo, que mantienepolí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.

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 yuna o más aplicaciones de administración de red. Si el protocolo es el encargado de proporcionar losmecanismos de administración, entonces las aplicaciones determinan la política que se usa para laadministración.

El axioma fundamental indica que añadir administración de red debería tener un impacto mínimo en losnodos, en consecuencia la carga se desplaza a las estaciones. Sin embargo podríamos pensar que el sistemaque soporta la estación de administración es más potente que un nodo, así que ¿cuánta potencia es necesariaentonces? La experiencia muestra que la mayoría de las estaciones de trabajo pueden proporcionar losrecursos 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 favorecedesplazar 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 nodotambién fuera una estación de administración? Es necesario apreciar que el modelo agente-administradorpuede soportar directamente, esto si consideramos que el software de cada estación de administración puederealizar tanto la función de administrador como la de agente, es decir, que el modelo agente-administradores 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 unaaplicación de administración que controla el estado de los dispositivos de ese segmento. Estas aplicacionesdeberían informar a aplicaciones de estaciones de administración regionales, las cuales deberían informar aestaciones de administración entre empresas. En este ejemplo, el software de cada estación realiza un papelde administrador al monitorizar y controlar dispositivos que dependen de él jerárquicamente, y un papel deagente 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 laconfiguración, mientras que la relación peer-to-peer depende de la arquitectura.


8

3. Protocolo de Administración de Red

Dependiendo del paradigma que se utilice para la administración de la red, un protocolo de administraciónpuede tomar varias formas:

3.1 Operaciones

En el entorno de administración, cada nodo tiene una serie de variables, de modo que leyendo estas variablesse 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ásde 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 soportaun nodo.

2.Una operación de interrupción, que permite a los nodos informar a la estación de administración de unevento 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. Enel entorno de administración, todas las variables relacionadas con una determinada funcionalidad se agrupanjuntas. Las estaciones deben determinar qué variables se soportan. Sin embargo, el protocolo debeproporcionar 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 cualespresenta 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

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 deinterrupción o un método de sondeo. Esta discusión también se realiza en la administración de redes. Losargumentos para cada uno de estos métodos son los siguientes:

Con el método basado en interrupciones, tenemos las siguientes ventajas: cuando ocurre un eventoextraordinario, el nodo envía una interrupción a la estación de administración adecuada (suponiendo que eldispositivo no ha caído y se puede alcanzar la estación). Por tanto tenemos la ventaja de una notificacióninmediata.

Con el método basado en interrupciones, tenemos las siguientes desventajas: requiere recursos para generarla interrupción ya que si la interrupción debe contener mucha información, el nodo perderá tiempo enprepararla y no se dedicará a cosas útiles. Por supuesto, cuando se genera una interrupción, el agente asumeque la aplicación de administración está preparada para recibir la información. Por tanto hay que usar undiseñ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 espoco deseable si se está informando de un problema de congestión de la red. Por eso se refina el método delas interrupciones de modo que un nodo sólo informa cuando la ocurrencia de un evento sobrepasa undeterminado umbral, pero esto implica que el agente debe gastar tiempo para determinar cuándo debegenerar 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 convenienteque 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ómovan 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 sondearni con qué frecuencia. Si el intervalo de frecuencia es breve, se ocupa mucho ancho de banda, y si es muylargo, la respuesta a eventos catastróficos es demasiado lenta. Otra desventaja es el tráfico que se introduceen la red, por lo que la aplicación de administración debe tener recursos de almacenamiento adicionales paraello.

En el entorno de administración se usa el modelo interrupción-sondeo directo (trap-directed polling). Cuandoocurre un evento extraordinario, el nodo manda una interrupción simple a la aplicación. La aplicación esentonces la responsable de iniciar conversaciones con el nodo para determinar la naturaleza y la extensióndel problema. Esto es muy efectivo ya que el impacto creado en los nodos es pequeño, en el ancho de bandaes mínimo y los problemas se resuelven en el momento oportuno. Por tanto, las interrupciones actúan comouna alarma previa, y se usa un sondeo de baja frecuencia.


10


11

3.2 Forma de transporte

La elección de un servicio de transporte por parte del protocolo de administración es importanteya que de los mecanismos internos del servicio de transporte depende la efectividad delprotocolo, y de acuerdo con el axioma fundamental, hay que elegir la forma de comunicaciónmenos impactante en el proceso.

La aplicación de administración es la que debe decidir el nivel de fiabilidad deseado e implementar elalgoritmo apropiado, sin dejar esta decisión en manos del servicio de transporte. De esta manera, el nodotendría menos carga debido a esta elección. Todo esto conduce a elegir un servicio de transporte no orientadoa conexión. Esta elección implica un comportamiento “sin preocupaciones” por parte del agente y permitea la aplicación controlar el nivel de fiabilidad. Hay otro motivo para elegir servicios de transporte noorientados a conexión. Cuando la red está congestionada y es difícil establecer una conexión, un protocoloorientado a conexión realiza ésta en tres pasos. Si la red está perdiendo paquetes, es más difícil establecereste modo de conexión que otro modo de un solo paso. Por tanto es conveniente usar la segunda forma, yaque 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 objetoadministrado (managed object), y un conjunto de dichos objetos se denomina Módulo de Base de Informaciónde Administración (Módulo MIB).

La característica más importante de los métodos usados para describir la información deadministración es la extensibilidad, de modo que se pueda comenzar con un pequeño conjuntode 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 objetospara mejorar sus productos, lo que puede influir en la estandarización de la tecnología de administración.

4.1 Objetos Administrados (Managed Objects)

La instrumentación de administración actúa entre los protocolos del dispositivo y el protocolo deadministración, tomando la información del dispositivo y presentándola como un conjunto de objetosadministrados. 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 deautorización y autentificación. Ahora también podemos añadir que es el modelo administrativo el quedetermina qué aplicación de administración puede acceder a qué objeto y con qué operaciones. Lasoperaciones 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, osimplemente 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ónde esa información, realiza una serie de operaciones para satisfacer la solicitud. Esto se denomina Interacciónde 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 laspeticiones para no cargar a un dispositivo ocupado con estas tareas. Así, el agente proxy implementauna política administrativa extensiva, y el dispositivo sólo responde a las peticiones realizadas porel agente.

2. Caching Firewall: puede ser útil que el agente proxy tenga la información a modo de caché, tambiénpara minimizar la carga del dispositivo.

3. Puentes de transporte: en una red multiprotocolo, un dispositivo soportaría el servicio punto a puntode sólo un conjunto de protocolos. Idealmente, una estación de administración soportaría losservicios punto a punto de todos los conjuntos de protocolos. De todas maneras, un agente proxy quesoporte servicios punto a punto del conjunto apropiado de protocolos puede utilizarse para establecerun 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 deadministración, las peticiones usadas en el protocolo son traducidas a una forma entendida por eldispositivo. De igual forma, las respuestas son traducidas a la forma entendida por el protocolo.


12

Una propiedad importante de las relaciones tipo proxy es el principio de transparencia. La idea es aparentarque la aplicación se está comunicando directamente con el agente real, es decir, una aplicación simplementeespecifica los recursos deseados y el agente proxy es el encargado de hacer que las cosas salgan bien, comosi 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 mayorcantidad de dispositivos de la red. Como hay muchos más agentes que estaciones de administración, entoncesminimizando 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 todofalla, la administración de red debe seguir funcionando. Este principio indica que muchas de las funcionesque se encuentran en la capa de transporte, serán directamente direccionadas por aplicaciones en la estaciónde administración, teniendo en cuenta que serán las propias aplicaciones las que definan el grado defiabilidad requerido de cada operación. Sin embargo, el servicio de transporte no debe “ayudar”, sólo deberíaser la forma más simple de permitir atravesar la red.


13


14

3. Modelo de Información

Para examinar el papel de la información de gestión en el entorno de administración, consideraremos lassiguientes 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 objetoadministrable tiene asociado una sintaxis y una semántica de tipo abstracto, mientras que una variable esuna 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 lainformación de administración independientemente de los detalles de implementación. La SMIse define usando ASN.1 (Abstract Syntax Notation).

Si se piensa que una colección de objetos administrados está almacenada, por ejemplo, en una base dedatos, la SMI define el esquema de esa base de datos. En realidad, esa base de datos se denomina Base deInformació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.

Por supuesto, estas funciones deberían estar combinadas en un sólo módulo. Cada módulo de informacióndebe 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 trestipos 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 ySnmpBasicNotification.


15

4. Modelo Administrativo

Consideraremos cómo se definen políticas administrativas para aplicaciones de gestión y agentes. Esta partede la red de gestión ha sufrido la mayor revisión desde la introducción de SNMP. Desafortunadamente todavíano 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 unaaplicació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 estosobjetos.

1.1 Autentificación

Cuando una entidad comienza una comunicación, es configurada para suministrar credenciales deautentificació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 parteinterrumpe 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

1.2 Privacidad

Como las propiedades de autentificación están asociadas con la entidad que envía, las propiedades deprivacidad se pueden asociar con las entidades receptoras. Para lograr privacidad con seguridad, deberíamosusar 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 degestión a monitorizar. Si los recursos son accesibles mediante algún mecanismo local, se dice que la operaciónse desarrolla desde el punto de vista del MIB, el cual es normalmente un conjunto adecuado de todos losobjetos gestionados controlados por una entidad. En cambio, si los recursos son accesibles mediante el envíode mensajes SNMP a una entidad remota, entonces se dice que los objetos son validos a través de una relaciónproxy.

Una vez que los recursos son identificados, sólo resta determinar las operaciones SNMPempleadas en ellos. A esto se denomina Política de Acceso, y es usada para el control del flujode 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 queveremos se denomina entorno de gestión basado en comunidades, debido a que usa el conceptode comunidad empleado en el SNMP original.

SNMP define una comunidad como una relación entre entidades SNMP. Una comunidad SNMP se escribe comouna cadena de octetos sin interpretación. Esta cadena se llama nombre de comunidad. Cada octeto toma unvalor 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.

La cadena de comunidad es un simple manejador para las relaciones de gestión. Ahora realizamos unavaloración de las propiedades de gestión de SNMP:

Identificación de origen: como las cadenas de comunidad son enviadas sin protección, cualquier terceraparte capaz de interceptar un mensaje SNMP puede usar el mismo nombre de comunidad y de esa formademandar 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 hayainterceptado.

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 unaentidad 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, susmecanismos 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 maliciosamentemodificados 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 trespartes:

- 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

3.1 Originando un mensaje

Usando conocimiento local, la entidad origen comienza seleccionando la comunidad apropiada la cual tienela 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. Luegoel paquete es examinado para ver si es una representación de una estructura de mensaje. Si no es unarepresentación de una estructura de mensaje, el contador (snmpInASNParseErrs) es incrementado y elpaquete es descartado. En caso afirmativo, la versión del mensaje es revisada para ver si se refiere a unaversió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 chequeala 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 paquetedescartado. En caso afirmativo, se chequea la comunidad para ver si esta tiene autorización para utilizar laoperació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 receptorachequea 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 conlos MIBs apropiados asociados con la comunidad. En cambio si la comunidad se refiere a recursos de objetosremotos, entonces:

- Si la operación es una respuesta, entonces es correlativa con la anterior petición, y una respuesta esenviada 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 asociadacon cada dominio de transporte válido para el.


19


20

5. Modelo Operacional

Examinaremos el papel de las operaciones del protocolo en el entorno de administración. SNMPes un protocolo asíncrono de petición-respuesta basado en el modelo de interrupción-sondeodirecto; esto significa que una entidad no necesita esperar una respuesta después de enviar unmensaje, 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, yque normalmente es UDP. Aunque ésto ratifica el Axioma Fundamental, hay una razón más importante: Lasfunciones de administración de red se realizan cuando hay problemas, de modo que la aplicación deadministración es la que decide qué restricciones realiza para el tráfico de administración. La elección deun servicio de transporte no orientado a conexión permite a la estación determinar el nivel de retransmisiónnecesario 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 cuatroresultados 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 quepermite a la aplicación mandar rápidamente varios mensajes SNMP, reconocer mensajes duplicadosen 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 elcampo 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.

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 susvariaciones:

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 elvalor unSpecified; si no, las instancias de variables esperan valores. Si no se solicita una operación derecuperació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 queuna 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 elagente.

- noSuchInstance, indica que la instancia de un objeto particular identificado por la variable no existeen 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

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:


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 ErrorMientras se procesa alguna petición, el agente puede encontrar un error e indica que la operación no puedeprocesarse. Hay varias clases de error. El funcionamiento de interacciones SNMPv2 con excepciones es de lasiguiente forma:

1. La entidad que inicia el protocolo hace una petición de recuperación con:


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, haydos 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

Si se procesa una petición de modificación, hay otra case de errores que deberían devolverse, pero que severá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ónusa 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 puedendevolver 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 estaoperación:

- Si el agente no implementa el tipo objeto asociado con la variable, se devuelve la excepciónnoSuchObject.

- 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.

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 queesté 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í, seexamina cada instancia de la primera columna, cada instancia de la segunda y así seguidamente hasta el finalde la tabla. Entonces, se devuelve la instancia del siguiente objeto , y sólo se devuelve una excepción si eloperando 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 cuyoprefijo 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, sedevuelva un error de tipo tooBig en vez de devolver las múltiples instancias de la variable. Esto ocurre debidoa 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. Esteesquema tiene que funcionar con un servicio de transporte no orientado a conexión de modo que la aplicaciónsea la responsable de controlar las interacciones. Las aplicaciones de administración también deben controlarlos tiempos de las interacciones


24


25

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 acontinuació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 larespuesta. 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 instanciacon su valor a la respuesta y decrementando la cantidad de espacio libre. Si no hay suficiente espacio, seenvía la respuesta antes de colapsar el espacio libre.


26

Finalmente, el espacio libre se ocupa, o se realiza el máximo número de repeticiones. Es importante teneren 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 examinarlas variables de la tabla, se devuelve una excepción endOfMibView. En este caso, todas las futurasrepeticiones 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 puededevolver 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 mejorque 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ónconoce 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 seactualizan. 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íaun error tooBig.

Dicho concepto consta de dos pasadas. En la primera, cada instancia se examina y se hace una comprobaciónpara 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.

- 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 delas 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 yse liberan los recursos.

SNMPv2 soporta nuevos códigos de error, además de los habituales, que son los siguientes, así como las causasque 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 objetocorrespondiente.

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 objetocorrespondiente.

7. noCreation, la variable no existe y el agente no puede crear instancias del tipo objetocorrespondiente.

8. inconsistentName, la variable no existe y no puede ser creada porque el nombre de la instancia esinconsistente 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

Los códigos noCreation y notWritable son de tipo permanente, mientras que los tres últimos son de tipotransitorio. El resto son casos que no deberían ocurrir si la aplicación y el agente tuvieran un mismo conceptode 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 cambiode cada instancia. Por experiencia, pueden existir fallos en esta segunda pasada. Si ocurre, el agente tratade 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 problemagrave 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 existerelación entre las variables presentadas en una lista de variables. Cualquier relación existe comouna 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 usael 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.


29

En SNMPv2, la convención textual RowStatus se usa para expresar la forma de manipular una fila: cuando unatabla se define en un módulo MIB, debe definirse una columna status con la sintaxis de RowStatus. Elsignificado de una variable de la columna status es que su valor indica la relación entre el dispositivo y lafila 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 escritoscreateAndGo(4),createAndWait(5),destroy(6)}

EN RESUMEN

La principal tecnología de interconexión de redes es el conjunto de protocolos de Internetllamados TCP/IP, que se crearon en la Agencia de Proyectos de Investigación Avanzada deDefensa(DARPA) y que son los que se usan en la Red Internet, (con mayúscula, la red de redesglobal) pero también en la interconexión de redes menores internet, (con minúscula, redeslocales).

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. Elidentificador 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 dosaplicaciones eligen el mismo identificador, la convención RowStatus genera un mecanismo para evitar lacolisió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 solaoperación set.

- Aproximación Negociada, se crea la fila y por medio de un conjunto de interacciones, se inicializa yse 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 elidentificador 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, peroque la instancia en sí no existe.

- Si se devuelve una excepción noSuchObject, el agente indica que no implementa el tipo de objetocorrespondiente a esa columna.


30


31

1.4.1.1 Aproximación Directa

Primero se selecciona el identificador deseado. Entonces la aplicación decide lanzar un get paradeterminar los requisitos del agente para la columna. Todos los valores devueltos deberían serexcepcionales, 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-ACCESSde 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 errorinconsistentValue; si no, el agente comprueba que tiene suficiente información (procedente del set y deinformació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 enel 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 sersuperconjuntos de las columnas que son obligatorias. Así, en el set, la aplicación sólo tiene quepreocuparse 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 debecoincidir.

1.4.1.2 Aproximación Negociada

Lo primero es seleccionar el identificador deseado. Entonces, la aplicación genera un set con la columna deestado puesta a createAndWait y lo envía al agente. Cuando el agente procesa la columna de estado en lasinstancias, 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 enel 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 delagente.

La estación de administración puede usar entonces un get para determinar los requisitos de las columnas delagente. 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 elvalor, debe generar un set para cambiarlo.

Si se devuelve una excepción noSuchInstance, el agente indica que antes de activar la fila, la aplicacióndebe 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á siendousada en el dispositivo y que la aplicación debería poner la columna de estado a activa. Hay que tener encuenta 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 dispositivocrea o modifica la misma fila que está siendo negociada entre la aplicación y el agente, entonces existirándos copias, una en el dispositivo y otra en el agente, aunque cuando la columna de estado se active en elagente, ésta eliminará la del dispositivo. También puede ocurrir que el proceso de negociación se veainterrumpido. Por eso, el agente debe almacenar de vez en cuando filas que no estén en estado activo.


32

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 ponela columna de estado a notInService. Si el agente no lo soporta, devuelve un error wrongValue; si no, la filano es accesible para el dispositivo y se devuelve una respuesta de noError. Desactivar una fila es útil cuandolas 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 élmismo y devuelve una respuesta noError.


33


34

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 unformato 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-TYPESYNTAX OBJECT IDENTIFIERMAX-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 laInformRequest-PDU es idéntico al de las otras PDU del resto de peticiones. Al igual que snmpV2-trap, las dosprimeras 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 cuidadopara minimizar el número de informes que se generan. Actualmente, el control de la generación yretransmisión de informes es una tarea específica de implementación.


35

1.6.1 Entidades de Doble Rol

Se trata de dispositivos que contienen agentes y aplicaciones de administración. Estosdispositivos 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ónentre peticiones y respuestas.

4. 2. Mapeo de Transporte

Las operaciones SNMP son independientes del protocolo de transporte, utilizando sólo un serviciode 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 formarun 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. Comotodos 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, setransforman en una estructura de datos con una semántica idéntica.


36

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 secodifica en seis octetos:

SnmpUDPAddress ::= TEXTUAL-CONVENTIONDISPLAY-HINT “1d.1d.1d.1d/2d”STATUS currentDESCRIPTION


37

SYNTAX OCTET STRING (SIZE (6))

La entidad que envía transforma y envía el mensaje como un único datagrama UDP a la direcciónde transporte de la entidad receptora. Por convención, los agentes SNMP escuchan en el puertoUDP 161 y envían las notificaciones al puerto UDP 162, aunque una entidad debería configurarsepara 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 deOSI (CONS).

Si un objeto TDomain tiene alguno de estos dos valores, el correspondiente objeto TAddress se codifica así:

SnmpOSIAddress ::= TEXTUAL-CONVENTIONDISPLAY-HINT “*1x:/1x:”STATUS currentDESCRIPTION


38

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 delservicio de transporte (TSDU) a la dirección de transporte de la entidad receptora. Los selectoresde transporte por defecto son:

Una entidad debería poder configurarse para usar cualquier selector de transporte aceptable. Todas lasentidades 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 secodifica así:

SnmpNBPAddress ::= TEXTUAL-CONVENTIONSTATUS currentDESCRIPTION


39

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

La entidad que envía transforma el mensaje y lo envía como un único datagrama DDP a ladirección de transporte de la entidad receptora. Todos los agentes SNMP escuchan en el tipo NBPSNMP Agent y las notificaciones se envían al tipo NBP SNMP Trap Handler. Todas las entidadesreceptoras 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 secodifica así:

SnmpIPXAddress ::= TEXTUAL-CONVENTIONDISPLAY-HINT “4x.1x:1x:1x:1x:1x:1x.2d”STATUS currentDESCRIPTION


40

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 transportede la entidad receptora. Por convención, los agentes SNMP escuchan en el socket IPX 36879 y envían lasnotificaciones al socket IPX 36880, aunque una entidad debería configurarse para usar cualquier selector detransporte 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 paraformar un paquete.

- Reglas para enviar el paquete por el servicio de transporte.

protocolo

Education