Protocolo

PROTOCOLO
SNMP: 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


1. Introducción

En una internet (con minúscula, redes locales) se conectan varias redes entre sí con el uso de
routers y un protocolo de interconexión de redes, de modo que los routers usan el protocolo para
encubrir las características de las redes y proporcionar un servicio uniforme entre ellas, es decir,
aunque cada red use una tecnología distinta y unas reglas específicas de transmisión, los hosts
de cada red ven a la red de igual manera. Éste es el poder de la abstracción de la interconexión
entre redes.

La principal tecnología de interconexión de redes es el conjunto de protocolos de Internet llamados TCP/IP,
que se crearon en la Agencia de Proyectos de Investigación Avanzada de Defensa (DARPA) y que son los que
se usan en la Red Internet, (con mayúscula, la red de redes global) pero también en la interconexión de
redes menores internet.
SNMP se sitúa en el tope de la capa de transporte de la pila OSI, o por encima de la capa UDP de la pila de
protocolos TCP/IP. Siempre en la capa de transporte. Gráficamente se podría ver así:

3


1. Necesidad de administrar redes

Los problemas que se presentan en la interconexión de redes son principalmente dos:

a) Dispositivos diferentes: la interconexión de redes permite diferentes tipos de dispositivos y éstos
son de distintos vendedores, todos ellos soportando el protocolo TCP/IP. Debido a esto, la
administración de redes se presenta como un problema. Sin embargo, usar una tecnología de
interconexión abierta permitió que existieran las redes formadas por dispositivos de distintos
fabricantes, por lo que para administrar estas redes, habrá que usar una tecnología de
administración de redes abierta.

b) Administraciones diferentes: como se permite la interconexión entre redes de distinto propósito y
distinto tamaño, hay que tener en cuenta que también están administradas, gestionadas y
financiadas de distinta forma.

2. Evolución histórica del Protocolo Simple de Gestión de Red (SNMP)

El protocolo Snmpv1 fue diseñado a mediados de los 80 por Case, McCloghrie, Rose, and
Waldbusser, como una solución a los problemas de comunicación entre diferentes tipos de redes.

En un principio, su principal meta era el lograr una solución temporal hasta la llegada de protocolos de
gestión de red con mejores diseños y mas completos. Pero esos administradores de red no llegaron y SNMPv1
se convirtió en la única opción para la gestión de red.

El manejo de este protocolo era simple, se basaba en el intercambio de información de red a través de
mensajes (PDU’s). Además de ser un protocolo fácilmente extensible a toda la red, debido a esto su uso se
estandarizo entre usuarios y empresas que no querían demasiadas complicaciones en la gestión de sus
sistemas informáticos dentro de una red.

No obstante este protocolo no era perfecto, además no estaba pensado para poder gestionar la inmensa
cantidad de redes que cada día iban apareciendo. Para subsanar sus carencias surgió la versión 2 (SNMP v2).
Las mayores innovaciones respecto a la primera versión son:

4


- Introducción de mecanismos de seguridad, totalmente ausentes en la versión 1. Estos mecanismos
protegen la privacidad de los datos, confieren autentificación a los usuarios y controlan el acceso.

- Mayor detalle en la definición de las variables.

- Se añaden estructuras de la tabla de datos para facilitar el manejo de los datos. El hecho de poder
usar tablas hace aumentar el número de objetos capaces de gestionar, con lo que el aumento de
redes dejó de ser un problema.

- Realmente esta versión 2 sólo supuso un parche, es más hubo innovaciones como los mecanismos de
seguridad que se quedaron en pura teoría, no se llegaron a implementar. Por estas razones, se ha
producido la estandarización de la versión 3. Con dos ventajas principales sobre sus predecesores:

- Añade algunas características de seguridad como privacidad, autentificación y autorización a la
versión 2 del protocolo.

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

5


2. Conceptos

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

Actualmente existen dos versiones de este entorno: el entorno original (Internet-standard Networking
Management Framework), compuesto por tres documentos, cada uno de los cuales es un estándar de Internet
con la condición de Recomendado; y el entorno que le sucedió (SNMPv2 Framework), formado por doce
documentos. Dos años después, este segundo entorno se revisó en ocho documentos, quedando algunos como
borradores de estándares y otros como proposiciones de estándares. Con el tiempo, estos documentos se
convirtieron en un completo estándar de Internet. Fue entonces cuando se declaró histórico el estándar
original y la comunidad se quedó con un solo entorno. Entre ambos entornos hubo dos pasos intermedios:
SNMP Security y SMP que fueron incluidos dentro del entorno SNMPv2, dejando sus documentos originales sólo
,
para interés histórico.

Un modelo

Un sistema de administración de red contiene cinco elementos:

1.Uno o más nodos administrables, conteniendo cada uno un agente.
2.Al menos una estación de administración de red (NMS) con soporte para una o más aplicaciones de
administración de la red.
3.Posiblemente una o más entidades de doble función, que pueden actuar como agente o como
administrador.
4.Un protocolo de administración de red, que es usado por la estación y los agentes para intercambiar
información.
5.Información que administrar.

1. Nodos administrables

Un nodo administrable es un dispositivo que puede clasificarse en una de las siguientes categorías:

- Un Host, como una estación de trabajo, mainframe, o impresora.
- Un sistema de enrutamiento.
- Un dispositivo de acceso al medio, como un repetidor, un puente o un hub.

6


Estas tres categorías coinciden en que clasifican a algún tipo de dispositivo con alguna capacidad de trabajo
en red. Las dos primeras categorías se caracterizan por ser normalmente independientes del medio, mientras
que la principal característica de los dispositivos de la tercera clase es la dependencia del medio.

1.1 El axioma fundamental

Un buen sistema de administración de red debe conocer la diversidad de dispositivos existentes y
proporcionar un entorno apropiado. Así, el axioma fundamental dice que:

El impacto de añadir una administración de red a un nodo administrable debe ser mínimo,
reflejando un común denominador más bajo.

El axioma fundamental se debe a las grandes diferencias entre los distintos nodos administrables que existen.

1.2 Características de los Nodos Administrables

Podemos considerar que cada nodo administrable está formado por tres componentes:

1.Funciones de usuario.
2.Un protocolo de administración, que permite monitorizar y controlar el nodo administrable.
3.Instrucciones de administración, que interactúan con la implementación del nodo administrable para
permitir la monitorización y el control.

La interacción entre estos tres componentes es sencilla: las instrucciones actúan como un pegamento entre
las funciones de usuario y el protocolo de administración. Esto se debe a un mecanismo de comunicación
interno en el que las estructuras de datos de las funciones de usuario deben ser accesibles y modificables a
petición del protocolo de administración.

1.3 Modelo Administrativo

Actualmente los intercambios de información son insuficientes para proporcionar la administración de los
nodos. El protocolo de administración trabaja en el entorno del modelo administrativo, que mantiene
políticas de autorización y autentificación. Esto permite determinar al nodo cómo se está administrando,
de modo que sólo los procesos de aplicaciones autorizadas realicen la administración.

7


2. Estación de Administración de Red

Una estación de administración de red es una máquina que ejecuta el protocolo de administración de red y
una o más aplicaciones de administración de red. Si el protocolo es el encargado de proporcionar los
mecanismos de administración, entonces las aplicaciones determinan la política que se usa para la
administración.

El axioma fundamental indica que añadir administración de red debería tener un impacto mínimo en los
nodos, en consecuencia la carga se desplaza a las estaciones. Sin embargo podríamos pensar que el sistema
que soporta la estación de administración es más potente que un nodo, así que ¿cuánta potencia es necesaria
entonces? La experiencia muestra que la mayoría de las estaciones de trabajo pueden proporcionar los
recursos necesarios para soportar una buena estación de administración.

Hay que tener en cuenta que a medida que hay más nodos administrables en una internet, se favorece
desplazar la carga hacia la estación de administración.

2.1 Entidades de doble función

Se ha dicho que las estaciones de administración sólo interactúan con los nodos. ¿Qué pasaría si el mismo nodo
también fuera una estación de administración? Es necesario apreciar que el modelo agente-administrador
puede soportar directamente, esto si consideramos que el software de cada estación de administración puede
realizar tanto la función de administrador como la de agente, es decir, que el modelo agente-administrador
es también un modelo peer-to-peer.

Teniendo esto en cuenta, se pueden construir relaciones jerárquicas entre las estaciones de administración.
Por ejemplo, se puede construir un sistema de administración donde cada segmento de una LAN tiene una
aplicación de administración que controla el estado de los dispositivos de ese segmento. Estas aplicaciones
deberían informar a aplicaciones de estaciones de administración regionales, las cuales deberían informar a
estaciones de administración entre empresas. En este ejemplo, el software de cada estación realiza un papel
de administrador al monitorizar y controlar dispositivos que dependen de él jerárquicamente, y un papel de
agente al informar y actuar según los comandos proporcionados por un superior jerárquico.

El concepto clave con las entidades de doble función es que la relación jerárquica depende de la
configuración, mientras que la relación peer-to-peer depende de la arquitectura.

8


3. Protocolo de Administración de Red

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

3.1 Operaciones

En el entorno de administración, cada nodo tiene una serie de variables, de modo que leyendo estas variables
se monitoriza el nodo, y cambiándoles el valor se controla. Se trata de un paradigma de depuración remota,
cuya ventaja es que es sencillo construir un protocolo de administración que realice estas funciones. Además
de las operaciones de lectura y escritura, existen otras dos:

1.Una operación cruzada, que permite determinar a la estación de administración qué variables soporta
un nodo.

2.Una operación de interrupción, que permite a los nodos informar a la estación de administración de un
evento extraordinario.

Veamos un poco más de ambas operaciones.

3.1.1 Operación de Examen

Como los nodos realizan distintas funciones, también contienen diferentes variables de administración. En
el entorno de administración, todas las variables relacionadas con una determinada funcionalidad se agrupan
juntas. Las estaciones deben determinar qué variables se soportan. Sin embargo, el protocolo debe
proporcionar un significado para examinar la lista de variables soportadas por un nodo.

También hay que tener en cuenta que pueden existir variables que aparezcan más de una vez. Por ejemplo,
la tabla de enrutamiento IP no es escalar, sino que está formada por una o más filas, cada una de las cuales
presenta varias columnas. Por tanto, el protocolo de administración debe proporcionar dos nuevas funciones:

- Un mecanismo para recuperar celdas de una tabla.
- Un mecanismo para recuperar números grandes de una celda de una tabla.

9


3.1.2 Operación de Interrupción

Desde el comienzo de los sistemas operativos, siempre se ha debatido acerca de utilizar un método de
interrupción o un método de sondeo. Esta discusión también se realiza en la administración de redes. Los
argumentos para cada uno de estos métodos son los siguientes:

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

Con el método basado en interrupciones, tenemos las siguientes desventajas: requiere recursos para generar
la interrupción ya que si la interrupción debe contener mucha información, el nodo perderá tiempo en
prepararla y no se dedicará a cosas útiles. Por supuesto, cuando se genera una interrupción, el agente asume
que la aplicación de administración está preparada para recibir la información. Por tanto hay que usar un
diseño cuidadoso para que las interrupciones sean recibidas sólo por aquellas estaciones interesadas. Más aún,
si ocurre un evento extraordinario, las interrupciones pueden ocupar un gran ancho de banda, lo cual es
poco deseable si se está informando de un problema de congestión de la red. Por eso se refina el método de
las interrupciones de modo que un nodo sólo informa cuando la ocurrencia de un evento sobrepasa un
determinado umbral, pero esto implica que el agente debe gastar tiempo para determinar cuándo debe
generar una interrupción. Es decir, el método basado en interrupciones tiene un fuerte impacto en el agente,
en la red o en ambos. En conclusión, como los nodos tienen una pequeña visión de toda la red, es conveniente
que las aplicaciones de administración detecten el problema de alguna otra forma.

Con el método basado en sondeo, una aplicación de administración pregunta periódicamente al nodo cómo
van las cosas, así el control lo tiene la aplicación, la cual sí tiene una visión global de la red.

La desventaja del método de sondeo es que la aplicación de administración no sabe qué elementos sondear
ni con qué frecuencia. Si el intervalo de frecuencia es breve, se ocupa mucho ancho de banda, y si es muy
largo, la respuesta a eventos catastróficos es demasiado lenta. Otra desventaja es el tráfico que se introduce
en la red, por lo que la aplicación de administración debe tener recursos de almacenamiento adicionales para
ello.

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

10


3.2 Forma de transporte

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

La aplicación de administración es la que debe decidir el nivel de fiabilidad deseado e implementar el
algoritmo apropiado, sin dejar esta decisión en manos del servicio de transporte. De esta manera, el nodo
tendría menos carga debido a esta elección. Todo esto conduce a elegir un servicio de transporte no orientado
a conexión. Esta elección implica un comportamiento “sin preocupaciones” por parte del agente y permite
a la aplicación controlar el nivel de fiabilidad. Hay otro motivo para elegir servicios de transporte no
orientados a conexión. Cuando la red está congestionada y es difícil establecer una conexión, un protocolo
orientado a conexión realiza ésta en tres pasos. Si la red está perdiendo paquetes, es más difícil establecer
este modo de conexión que otro modo de un solo paso. Por tanto es conveniente usar la segunda forma, ya
que en esos casos es cuando realmente la red necesita ser controlada y administrada.

4. Información de administración

Finalmente, hemos de explicar la información a intercambiar entre la estación de administración y el nodo,
utilizando el protocolo de administración. Una unidad de información de administración se denomina objeto
administrado (managed object), y un conjunto de dichos objetos se denomina Módulo de Base de Información
de Administración (Módulo MIB).

La característica más importante de los métodos usados para describir la información de
administración es la extensibilidad, de modo que se pueda comenzar con un pequeño conjunto
de definiciones, para aumentarlo según crezcan las necesidades.

Un efecto lateral de la extensibilidad, es que los vendedores de dispositivos pueden añadir sus propios objetos
para mejorar sus productos, lo que puede influir en la estandarización de la tecnología de administración.

11


4.1 Objetos Administrados (Managed Objects)

La instrumentación de administración actúa entre los protocolos del dispositivo y el protocolo de
administración, tomando la información del dispositivo y presentándola como un conjunto de objetos
administrados. Esta colección se denomina Recursos Objeto del Agente.

4.2 Revisión del Modelo Administrativo

Anteriormente se presentó el modelo administrativo como el responsable de proporcionar políticas de
autorización y autentificación. Ahora también podemos añadir que es el modelo administrativo el que
determina qué aplicación de administración puede acceder a qué objeto y con qué operaciones. Las
operaciones de administración permitidas a una aplicación por un agente se denominan política de acceso.
La colección de objetos administrados que son visibles para estas operaciones se denomina Vista del MIB, o
simplemente Vista.

4.3 Relaciones de tipo Proxy

A veces, un agente accede a información de administración no local. Cuando otro agente recibe la petición
de esa información, realiza una serie de operaciones para satisfacer la solicitud. Esto se denomina Interacción
de delegación (interacción Proxy) y el agente que la realiza se denomina Agente delegado (Agente Proxy).

Hay varias razones por las que utilizar las relaciones Proxy:

1. Cortafuegos administrativo (Firewall): puede ser útil que el agente proxy autentifique y autorice las
peticiones para no cargar a un dispositivo ocupado con estas tareas. Así, el agente proxy implementa
una política administrativa extensiva, y el dispositivo sólo responde a las peticiones realizadas por
el agente.
2. Caching Firewall: puede ser útil que el agente proxy tenga la información a modo de caché, también
para minimizar la carga del dispositivo.
3. Puentes de transporte: en una red multiprotocolo, un dispositivo soportaría el servicio punto a punto
de sólo un conjunto de protocolos. Idealmente, una estación de administración soportaría los
servicios punto a punto de todos los conjuntos de protocolos. De todas maneras, un agente proxy que
soporte servicios punto a punto del conjunto apropiado de protocolos puede utilizarse para establecer
un camino para las comunicaciones de administración entre el dispositivo y la estación.
4. Traducciones de protocolo: en el caso de que los dispositivos no soporten protocolos de
administración, las peticiones usadas en el protocolo son traducidas a una forma entendida por el
dispositivo. De igual forma, las respuestas son traducidas a la forma entendida por el protocolo.

12


Una propiedad importante de las relaciones tipo proxy es el principio de transparencia. La idea es aparentar
que la aplicación se está comunicando directamente con el agente real, es decir, una aplicación simplemente
especifica los recursos deseados y el agente proxy es el encargado de hacer que las cosas salgan bien, como
si la información de administración la tuviera el agente proxy localmente.

5. En perspectiva

El axioma fundamental del entorno de administración se basa en la noción de distribución universal.

Si se ve la administración de redes como un aspecto esencial, entonces debería distribuirse en la mayor
cantidad de dispositivos de la red. Como hay muchos más agentes que estaciones de administración, entonces
minimizando el impacto de la administración en los agentes, podremos solucionar el problema.

Otro principio importante es que la administración de red es distinta a cualquier otra aplicación. Cuando todo
falla, la administración de red debe seguir funcionando. Este principio indica que muchas de las funciones
que se encuentran en la capa de transporte, serán directamente direccionadas por aplicaciones en la estación
de administración, teniendo en cuenta que serán las propias aplicaciones las que definan el grado de
fiabilidad requerido de cada operación. Sin embargo, el servicio de transporte no debe “ayudar”, sólo debería
ser la forma más simple de permitir atravesar la red.

13


3. Modelo de Información

Para examinar el papel de la información de gestión en el entorno de administración, consideraremos las
siguientes cinco partes:

- Reglas para definir la información de administración.
- Ejemplos de colecciones de definiciones existentes.
- Reglas para definir los convenios textuales (definición de tipos de uso frecuente).
- Cómo se accede a éstas al definir información de administración.
- Coexistencia entre el entorno original y el entorno SNMPv2.

Antes de comenzar, hay que aclarar la relación entre variables, objetos y tipos de objetos. Un objeto
administrable tiene asociado una sintaxis y una semántica de tipo abstracto, mientras que una variable es
una instancia de un objeto particular. En este caso también se denomina instancia de un objeto.

ESTRUCTURA DE LA INFORMACIÓN DE ADMINISTRACIÓN

La Estructura de la Información de Administración (SMI) define las reglas para definir la
información de administración independientemente de los detalles de implementación. La SMI
se define usando ASN.1 (Abstract Syntax Notation).

Si se piensa que una colección de objetos administrados está almacenada, por ejemplo, en una base de
datos, la SMI define el esquema de esa base de datos. En realidad, esa base de datos se denomina Base de
Información de Administración (MIB).

1. Módulos de Información

Existen tres clases de módulos ASN.1, también llamados Módulos de Información, definidos por el SMI:

- Módulos MIB, que define una colección de objetos de administración afines.
- Sentencias de Conformidad, que definen un conjunto de requisitos de los nodos con respecto a uno
o más módulos MIB.
- Sentencias de Capacidad, que describe la capacidad de un nodo para implementar los objetos
definidos en uno o más módulos MIB.

14


Por supuesto, estas funciones deberían estar combinadas en un sólo módulo. Cada módulo de información
debe comenzar con la indicación de su identidad y la historia de sus revisiones (macro MODULE-IDENTITY).

Dentro de cada modulo existirán objetos, los cuales se definen con la macro OBJECT-TYPE, la expansión de
éstos se produce durante la implementación. También se usaran convenciones textuales (macro TEXTUAL-
CONVENTION), que son redefiniciones más precisas de algún tipo de datos, dentro de un MIB. Existen tres
tipos de MIB:

- Estándar: son módulos que se han convertido en un estándar.
- Experimental: Esperan su oportunidad de convertirse en estándar.
- Especifico: son propios de alguna empresa.

El modulo MIB de la V2 contiene 5 grupos de objetos: system, snmp, snmpComunity, SnmpSet y
SnmpBasicNotification.

15


4. Modelo Administrativo

Consideraremos cómo se definen políticas administrativas para aplicaciones de gestión y agentes. Esta parte
de la red de gestión ha sufrido la mayor revisión desde la introducción de SNMP. Desafortunadamente todavía
no existe un consenso en la solución más apropiada al problema.

1. Conceptos

En el entorno de gestión, una entidad SNMP es una “entidad lógica” en nombre de la cual un agente o una
aplicación de gestión están procesando un mensaje. El entorno de gestión es responsable de proporcionar:

- Autentificación: se refiere a cómo las entidades SNMP identifican sus mensajes.
- Privacidad: se refiere a cómo las entidades SNMP protegen sus mensajes.
- Autorización: se refiere a cómo una entidad agente SNMP determina los objetos que son accesibles
a una entidad de aplicación de gestión dada, y las operaciones que se pueden realizar en estos
objetos.

1.1 Autentificación

Cuando una entidad comienza una comunicación, es configurada para suministrar credenciales de
autentificación como una parte de la comunicación. Dependiendo de los mecanismos de autentificación,
serán válidas tres clases de servicios:

- Identificación origen, por la cual un mensaje puede ser asociado con una entidad origen.
- Integridad del mensaje, por la cual un mensaje alterado puede ser detectado con seguridad.
- Protección limitada de retransmisión, por la cual un mensaje que ha sido duplicado o retrasado por
la red o una tercera parte puede ser detectada fuera del tiempo de vida esperado del mensaje.

Tras esto podemos observar que prevenir las ocasiones de fuera de servicio, en las cuales una tercera parte
interrumpe una comunicación, no es un objetivo del entorno de gestión.

No obstante para alcanzar seguridad con las anteriores funciones deberemos usar:

- Encriptación con firma.
- Algoritmos (message digest).
- Relojes incrementados monótonamente.

16


1.2 Privacidad

Como las propiedades de autentificación están asociadas con la entidad que envía, las propiedades de
privacidad se pueden asociar con las entidades receptoras. Para lograr privacidad con seguridad, deberíamos
usar un algoritmo de encriptación y la clave asociada.

1.3 Autorización

Cuando un agente ejecuta una operación, primero deberá identificar la colección de recursos de objetos de
gestión a monitorizar. Si los recursos son accesibles mediante algún mecanismo local, se dice que la operación
se desarrolla desde el punto de vista del MIB, el cual es normalmente un conjunto adecuado de todos los
objetos gestionados controlados por una entidad. En cambio, si los recursos son accesibles mediante el envío
de mensajes SNMP a una entidad remota, entonces se dice que los objetos son validos a través de una relación
proxy.

Una vez que los recursos son identificados, sólo resta determinar las operaciones SNMP
empleadas en ellos. A esto se denomina Política de Acceso, y es usada para el control del flujo
de información entre la entidad agente SNMP y una entidad de aplicación de gestión dada.

2. Comunidades

SNMP v2 esta diseñado para soportar múltiples entornos de administración. El entorno que
veremos se denomina entorno de gestión basado en comunidades, debido a que usa el concepto
de comunidad empleado en el SNMP original.

SNMP define una comunidad como una relación entre entidades SNMP. Una comunidad SNMP se escribe como
una cadena de octetos sin interpretación. Esta cadena se llama nombre de comunidad. Cada octeto toma un
valor entre 0 y 255. Cuando se intercambian mensajes SNMP, contienen dos partes:

- Una cadena de comunidad, enviada en texto sencillo y,
- Datos, conteniendo una operación SNMP y los operandos asociados.

17


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

Identificación de origen: como las cadenas de comunidad son enviadas sin protección, cualquier tercera
parte capaz de interceptar un mensaje SNMP puede usar el mismo nombre de comunidad y de esa forma
demandar ser un miembro de la comunidad de mensajes.

Integridad del mensaje: cualquier tercera parte puede modificar un mensaje SNMP que intercepte.

Protección limitada de reenvíos: cualquier tercera parte puede retrasar un mensaje SNMP que haya
interceptado.

Privacidad: cualquier tercera parte puede leer el mensaje SNMP que haya interceptado.

Autorización: los agentes son responsables de mantener información local así como los MIB que contienen,
o las relaciones de proxy válidas. Será sencillo para una tercera parte obtener los accesos correctos de una
entidad autorizada para monitorizar o controlar esos objetos.

Todo lo que se puede decir es que aunque SNMP v2 ofrece enfoques técnicos para estos asuntos, sus
mecanismos no llevan a ninguna solución.

Naturalmente, el mercado se ha adaptado a estas carencias:

- Primero, varios diseñadores de módulos MIB son reacios a definir objetos, que maliciosamente
modificados puedan causar considerables dificultades en la red.
- Muchos implementadores de agentes no han implementado funciones de control SNMP a propósito.

3. Procedimientos

Veremos cómo se procesan los mensajes SNMP. Para empezar, veremos el formato del mensaje. Existen tres
partes:

- Versión: el número de versión del mensaje.
- Comunidad: la cadena de comunidad.
- Datos: una operación SNMP, definido como una estructura PDUs

18


3.1 Originando un mensaje

Usando conocimiento local, la entidad origen comienza seleccionando la comunidad apropiada la cual tiene
la autorización adecuada para usar las operaciones y el acceso a los objetos MIB deseados. Luego:

- Una estructura de mensaje es construida desde esta información.
- Es convertida en una cadena de octetos.
- Es enviada a la dirección de transporte de la entidad receptora.

3.2 Recibiendo un mensaje

Cuando un paquete es recibido del servicio de transporte, el contador (snmpInPkts) es incrementado. Luego
el paquete es examinado para ver si es una representación de una estructura de mensaje. Si no es una
representación de una estructura de mensaje, el contador (snmpInASNParseErrs) es incrementado y el
paquete es descartado. En caso afirmativo, la versión del mensaje es revisada para ver si se refiere a una
versión implementada por la entidad receptora. Si no es una versión implementada por la entidad receptora,
el contador (snmpInBadVersions) es incrementada y el paquete es descartado. En caso afirmativo, se chequea
la comunidad del mensaje para ver si se refiere a una conocida entidad receptora.

Si la comunidad no es conocida, el contador (snmpInBadCommunityNames) es incrementado y el paquete
descartado. En caso afirmativo, se chequea la comunidad para ver si esta tiene autorización para utilizar la
operación contenida en los datos del mensaje. Si no tuviera autorización, el contador
(snmpInBadCommunityUses) es incrementado y el paquete descartado. De otra forma, La entidad receptora
chequea para mirar que clase de recursos de objetos están asociados con la comunidad.

Si la comunidad se refiere a recursos de objetos locales, entonces la operación se desarrolla de acuerdo con
los MIBs apropiados asociados con la comunidad. En cambio si la comunidad se refiere a recursos de objetos
remotos, entonces:

- Si la operación es una respuesta, entonces es correlativa con la anterior petición, y una respuesta es
enviada a la entidad originaria de la petición.

- Si la operación es una Trap o un informe, entonces el agente proxy, usando conocimiento local,
determina la entidad SNMP que debería enviar el mensaje.

3.3 Esperando por mensajes

Normalmente las entidades SNMP esperan los mensajes en la dirección de transporte por defecto asociada
con cada dominio de transporte válido para el.

19


5. Modelo Operacional

Examinaremos el papel de las operaciones del protocolo en el entorno de administración. SNMP
es un protocolo asíncrono de petición-respuesta basado en el modelo de interrupción-sondeo
directo; esto significa que una entidad no necesita esperar una respuesta después de enviar un
mensaje, por lo que puede enviar otros mensajes o realizar otras actividades.

SNMP tiene pocos requisitos de transporte ya que usa un servicio de transporte no orientado a conexión, y
que normalmente es UDP. Aunque ésto ratifica el Axioma Fundamental, hay una razón más importante: Las
funciones de administración de red se realizan cuando hay problemas, de modo que la aplicación de
administración es la que decide qué restricciones realiza para el tráfico de administración. La elección de
un servicio de transporte no orientado a conexión permite a la estación determinar el nivel de retransmisión
necesario para complacer a las redes congestionadas.

1. Interacciones del Protocolo

Una interacción SNMP consiste en una petición de algún tipo, seguida por una respuesta. Hay cuatro
resultados posibles de una operación:

- Una respuesta sin excepción o error.
- Una respuesta con una o más excepciones.
- Una respuesta con error.
- Sobrepasar el tiempo de espera (timeout).

A continuación se describen los campos del tipo de dato PDU.

- request-id, valor entero usado por la aplicación para distinguir entre peticiones pendientes, lo que
permite a la aplicación mandar rápidamente varios mensajes SNMP, reconocer mensajes duplicados
en la red y medir el tiempo del tráfico que genera. Los agentes no pueden modificar este campo.

- error-status, si no es cero, representa un error al procesar la petición y que debería ignorarse el
campo variable-bindings.

- error-index, si no es cero indica qué variable de la petición es errónea.

- variable-bindings, Lista de variables, con su nombre y valor.

20


Las operaciones de SNMPv2 se pueden clasificar así:

- Recuperación: get, get-next y get-bulk.
- Modificación: set.
- Invocación: snmpv2-trap.
- Administradores: inform.

1.1 Interacciones

Veamos primero una interacción normal entre dos entidades SNMPv2, para más adelante estudiar sus
variaciones:

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

- Un único request-id.
- error-status/error-index a cero.
- Cero o más instancias de variables.

2. Si la operación no fue snmpv2-trap, la entidad que responde da una respuesta con:

- El mismo request-id.
- error-status a cero.
- Las mismas instancias de variables.

Si se solicita una operación de recuperación, en la petición, los valores asociados con las variables tienen el
valor unSpecified; si no, las instancias de variables esperan valores. Si no se solicita una operación de
recuperación, las instancias de las variables de la respuesta son iguales a las de la petición.

1.1.1 Interacción de Excepciones

Mientras se procesa una petición de recuperación, el agente podría encontrar una excepción, indicando que
una determinada variable no puede ser procesada. Hay tres tipos de valores de excepción:

- noSuchObject, indica que el tipo de objeto correspondiente a la variable no se implementa por el
agente.

- noSuchInstance, indica que la instancia de un objeto particular identificado por la variable no existe
en la vista del MIB para la operación.

- endOfMibView, indica que no hay más información en la vista del MIB para la operación.

21


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:

- Las mismas instancias de variables, pero con diferentes valores y uno o más valores de excepción.

1.1.2 Interacción de Error
Mientras se procesa alguna petición, el agente puede encontrar un error e indica que la operación no puede
procesarse. Hay varias clases de error. El funcionamiento de interacciones SNMPv2 con excepciones es de la
siguiente forma:

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


2. La entidad que responde da una respuesta con:

- Las mismas instancias de variables que la petición.

Teniendo en cuenta que los errores nunca se devuelven en una respuesta a una operación de invocación, hay
dos clases de errores que pueden devolverse en la respuesta a cualquier otra petición:

tooBig, indica que la respuesta podría ser demasiado larga para enviarla.
genErr, no debería devolverse excepto que no haya otra posibilidad.

22


Si se procesa una petición de modificación, hay otra case de errores que deberían devolverse, pero que se
verán más adelante.

1.1.3 Interacción de Timeout

Esta interacción ocurre cuando se envía una petición pero no se recibe respuesta. Hay varias posibilidades:

- La red omite la petición.
- El agente no está ejecutándose.
- El agente omite la petición.
- La red omite la respuesta.
- El tiempo de espera fue muy corto.

1.1.4 De la Interacción al Procesamiento

Para procesar las peticiones, primero debe aceptarse una estructura Message para que la evalúe la entidad.
Cuando la petición se procesa, se examina la lista de variables instanciadas; en el caso que el campo variable-
bindings esté vacío, termina el procesamiento devolviendo una respuesta noError.

2. Peticiones de Recuperación

Para examinar eficientemente la información de administración, el entorno de administración
usa un método inteligente para identificar las instancias: Es usado un OBJECT IDENTIFIER,
formado por la concatenación del nombre del tipo objeto con un sufijo.

1.2.1 El Operador Get

Si la aplicación de administración conoce las instancias que necesita, realiza una get-request. Sólo se pueden
devolver los errores tooBig y genErr.

Por otro lado, para cada variable de la petición, la instancia se recupera de la vista del MIB con esta
operación:

- Si el agente no implementa el tipo objeto asociado con la variable, se devuelve la excepción
noSuchObject.
- Si la instancia no existe o no la soporta el MIB, se devuelve la excepción noSuchInstance.
- Se devuelve el valor asociado a la instancia.

23


1.2.2 El Operador Get-Next

Si la aplicación no conoce exactamente la instancia de la información que necesita, realiza una get-next-
request. Sólo se pueden devolver los errores tooBig y genErr.

Por otro lado, para cada variable de la petición, se devuelve la primera instancia que siga a la variable que
esté en la vista del MIB con esta operación:

- Si no hay una próxima instancia para la variable en el MIB, se devuelve una excepción endOfMibView.

- Si se reconoce la siguiente instancia de la variable en el MIB, se devuelve el valor asociado.

El operador get-next puede usarse para comprobar si un objeto es soportado por un agente.

Debido al almacenamiento que se hace en el MIB, las tablas se examinan en un orden columna-fila; así, se
examina cada instancia de la primera columna, cada instancia de la segunda y así seguidamente hasta el final
de la tabla. Entonces, se devuelve la instancia del siguiente objeto , y sólo se devuelve una excepción si el
operando de get-next es mayor, lexicográficamente hablando, que la mayor instancia del MIB.

Como el operador get-next soporta múltiples operandos, se puede examinar eficientemente la tabla entera.
La aplicación de administración conoce que llega al final de la tabla cuando se devuelve un nombre cuyo
prefijo no coincide con el del objeto deseado.

Puede ocurrir que al usar el operador get-next con múltiples operandos para examinar una tabla vacía, se
devuelva un error de tipo tooBig en vez de devolver las múltiples instancias de la variable. Esto ocurre debido
a que el operador no pudo encontrar instancias en la tabla.

1.2.3 El Operador Get-Bulk

Su función es minimizar las interacciones en la red, permitiendo al agente devolver paquetes grandes. Este
esquema tiene que funcionar con un servicio de transporte no orientado a conexión de modo que la aplicación
sea la responsable de controlar las interacciones. Las aplicaciones de administración también deben controlar
los tiempos de las interacciones

24


El formato que sigue la SNMPv2 BulkPDU es el siguiente:

BulkPDU ::=
SEQUENCE {
request-id Integer32,
non-repeaters INTEGER(0..max-bindings),
max-repetitions INTEGER(0..max-bindings),
variable-bindings VarBindingList
}

Este formato es estructuralmente idéntico la del resto de operaciones SNMP, y los campos se describen a
continuación:

request-id, el usual.
non-repeaters, número de variables que deberían recuperarse de una vez.
max-repetitions, número máximo de veces que otras variables deberían recuperarse.
variable-bindings, el usual ignorando los valores.

Cuando un agente recibe una get-bulk, calcula el mínimo de:

- El tamaño máximo del mensaje del emisor.
- El tamaño de la generación de mensajes del propio agente.
- De aquí resta la suma de dos cantidades:
- El tamaño de las capas de privacidad/autentificación de la generación de la respuesta.
- El tamaño de una respuesta sin variables instanciadas.

Dicha diferencia indica la cantidad máxima de espacio posible para las instancias de las variables en la
respuesta. Si la diferencia es menor de cero, la respuesta se pierde; si no, se genera la respuesta, que tendrá
cero o más variables instanciadas.

El agente examina las variables de la petición usando el operador get-next y añadiendo cada nueva instancia
con su valor a la respuesta y decrementando la cantidad de espacio libre. Si no hay suficiente espacio, se
envía la respuesta antes de colapsar el espacio libre.

25


Finalmente, el espacio libre se ocupa, o se realiza el máximo número de repeticiones. Es importante tener
en cuenta que el agente puede terminar una repetición en cualquier momento.

Existe otra forma con la que la operación get-bulk termina prematuramente: Esto ocurre cuando al examinar
las variables de la tabla, se devuelve una excepción endOfMibView. En este caso, todas las futuras
repeticiones devolverán lo mismo y se omitirán de la respuesta.

Por último, es importante saber que cuando un agente decide procesar una petición get-bulk, sólo se puede
devolver el error genErr, ya que devolver tooBig no tiene sentido.

1.2.4 Más Características del Operador Get-Bulk

La respuesta a un operador get-bulk no es más que la concatenación de un número de respuestas max-
repitition de interacciones get-next.

La parte más interesante del operador get-bulk es que puede implementarse en el agente a alto nivel mejor
que en las rutinas específicas de los objetos.

3. Peticiones de Modificación

Sólo hay una petición de modificación: El operador set. Cuando una aplicación de administración
conoce exactamente las instancias que necesita, genera una set-request.

La semántica de la operación set es tal que la operación tiene éxito si y sólo si todas las variables se
actualizan. Para explicarlo usaremos el concepto del compromiso de las dos fases, pero antes de empezar,
se asegura que la respuesta no sea tan grande como para no poder ser enviada, ya que si no, se generaría
un error tooBig.

Dicho concepto consta de dos pasadas. En la primera, cada instancia se examina y se hace una comprobación
para verificar que:

- La variable es soportada por la vista del MIB para esa operación.

- Si la variable existe, el agente puede modificar las instancias del tipo objeto correspondiente.

26


- El valor proporcionado es correcto sintácticamente.

- Si la variable no existe, el agente es capaz de crear instancias del tipo de objeto correspondiente.

- El nombre y valor proporcionado son correctos sintácticamente y son consistentes con los valores de
las otras variables de la petición.

- Todos los recursos necesarios para el cambio están reservados.

Si alguna de estas condiciones no se verifica para alguna de las instancias, se devuelve el error apropiado y
se liberan los recursos.

SNMPv2 soporta nuevos códigos de error, además de los habituales, que son los siguientes, así como las causas
que los producen:

1. noAccess, la variable no es soportada por la vista del MIB para esa operación.

2. notWritable, La variable existe pero el agente no puede modificar instancias del tipo objeto
correspondiente.

3. wrongType, el nuevo valor proporcionado es de un tipo de datos ASN.1 erróneo.

4. wrongLength, el nuevo valor proporcionado es de longitud errónea.

5. wrongEncoding, el nuevo valor proporcionado está codificado erróneamente.

6. wrongValue, el nuevo valor está fuera del rango de valores admitidos para el tipo de objeto
correspondiente.

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

8. inconsistentName, la variable no existe y no puede ser creada porque el nombre de la instancia es
inconsistente con los valores de otro objeto en el agente.

9. inconsistentValue, el valor proporcionado es inconsistente con los valores de otro objeto en el agente.

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

27


Los códigos noCreation y notWritable son de tipo permanente, mientras que los tres últimos son de tipo
transitorio. El resto son casos que no deberían ocurrir si la aplicación y el agente tuvieran un mismo concepto
de los objetos en cuestión.

Sólo si cada instancia ha superado la primera pasada, se hace la segunda, en la cual se acomete el cambio
de cada instancia. Por experiencia, pueden existir fallos en esta segunda pasada. Si ocurre, el agente trata
de deshacer los cambios y devuelve uno de los dos siguientes tipos de error:

1. commitFailed, indica que hubo un fallo en la segunda pasada pero que se deshicieron los cambios.

2. undoFailed, indica que falló la segunda pasada y que algunos cambios no pudieron deshacerse.

Si se devuelve alguno de estos errores, se pone a cero el campo error-index, indicando que hay un problema
grave en el agente.

4. Manejo de Filas de Conceptos

Desde la perspectiva del protocolo, no existe el concepto de fila en SNMP En particular no existe
.
relación entre las variables presentadas en una lista de variables. Cualquier relación existe como
una característica del diseño de MIB, no por operaciones de protocolo.

Podemos considerar un reto el crear instancias en una fila de conceptos, dado el modelo operacional que usa
el entorno de administración. Hay que tener en cuenta:

1. El agente puede no ser capaz de implementar algunas columnas en una fila de conceptos.

2. El agente puede necesitar que algunas columnas se creen antes de usarlas.

3. Los valores de todas las columnas pueden no entrar en una sola PDU.

4. La aplicación de administración puede querer examinar los valores de algunas columnas.

5. Las aplicaciones que cooperan no quieren comisionar al crear nuevas filas.

28


En SNMPv2, la convención textual RowStatus se usa para expresar la forma de manipular una fila: cuando una
tabla se define en un módulo MIB, debe definirse una columna status con la sintaxis de RowStatus. El
significado de una variable de la columna status es que su valor indica la relación entre el dispositivo y la
fila de conceptos.

Un resumen de la convención textual RowStatus es la siguiente:

RowStatus ::= TEXTUAL-CONVENTION
...
SYNTAX INTEGER {
—dos valores de estado/acción que pueden ser leidos o escritos.
active(1),
notInService(2),
—un valor de estado, que solo puede ser leído.
notReady(3),
—tres valores de acción que sólo pueden ser escritos
createAndGo(4),
createAndWait(5),
destroy(6)
}

EN RESUMEN

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

29


2. 1.4.1 Creación de una Fila de Conceptos

El primer paso es la creación de un identificador de la instancia, que es específico para cada tabla MIB. El
identificador de instancia debe tener sentido semánticamente o ser usado singularmente. En el último caso,
el módulo MIB puede proporcionar un objeto para ayudar a elegir un identificador sin usar, aunque si dos
aplicaciones eligen el mismo identificador, la convención RowStatus genera un mecanismo para evitar la
colisión.

El siguiente paso es crear la fila, y se puede hacer de dos formas:

- Aproximación Directa, la fila se crea y se activa para ser usada por un dispositivo con una sola
operación set.

- Aproximación Negociada, se crea la fila y por medio de un conjunto de interacciones, se inicializa y
se activa para ser utilizada por el dispositivo.

La aplicación de administración debe determinar para cada columna:

- Qué columnas necesita el agente para activar la fila.

- Qué columnas no puede crear el agente, por alguna razón.

Una vez creada la fila, la aplicación realiza una operación get para cada columna que conoce, usando el
identificador seleccionado en el primer paso. Para cada columna requerida:

- Si se devuelve un valor, el agente está indicando que implementa esa columna.

- Si se devuelve una excepción noSuchInstance, el agente indica que implementa la columna, pero
que la instancia en sí no existe.

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

30


1.4.1.1 Aproximación Directa

Primero se selecciona el identificador deseado. Entonces la aplicación decide lanzar un get para
determinar los requisitos del agente para la columna. Todos los valores devueltos deberían ser
excepcionales, ya que si no se indicaría que la fila ya existe.

Entonces la aplicación enviará al agente un set, que contiene valores para las columnas con un MAX-ACCESS
de read-create y el estado de la columna puesto a createAndGo.

Cuando el agente procesa la columna de estados en las instancias, si la variable ya existe, devuelve un error
inconsistentValue; si no, el agente comprueba que tiene suficiente información (procedente del set y de
información local) para crear y activar la fila. Si hay suficiente información, entonces:

- Se crea la fila.

- Se devuelve una respuesta con noError

- El agente asigna valores por defecto a las columnas de las filas cuyos valores no se especificaron en
el set.

- La columna de estado se pone a active.

Si no hay suficiente información, se devuelve un error inconsistentValue.

Se debería tener en cuenta que puede que no todas las filas entren en una sola PDU. También,
la respuesta de get indica que aquellas columnas que implemente el agente deben ser
superconjuntos de las columnas que son obligatorias. Así, en el set, la aplicación sólo tiene que
preocuparse de las columnas con un MAX-ACCESS de read-create.

Para que esta aproximación funcione, la versión del módulo MIB que conoce la aplicación y el agente debe
coincidir.

31


1.4.1.2 Aproximación Negociada

Lo primero es seleccionar el identificador deseado. Entonces, la aplicación genera un set con la columna de
estado puesta a createAndWait y lo envía al agente. Cuando el agente procesa la columna de estado en las
instancias, si no soporta la creación negociada, devuelve un error wrongValue, o si la variable ya existe,
devuelve un error inconsistentValue. En otro caso:

- Se crea la fila.

- Se devuelve una respuesta noError.

- El agente asigna valores por defecto a las columnas de las filas cuyos valores no se especificaron en
el set.

- El agente debe asignar valores por defecto a aquellas filas que implementa de solo lectura.

- La columna de estado se activa a notInService o a notReady, según la información disponible del
agente.

La estación de administración puede usar entonces un get para determinar los requisitos de las columnas del
agente. Para cada columna read-create solicitada:

Si se devuelve un valor, el agente indica que implementa esa columna y que si a la aplicación no le gusta el
valor, debe generar un set para cambiarlo.

Si se devuelve una excepción noSuchInstance, el agente indica que antes de activar la fila, la aplicación
debe generar un set para proporcionar valores para la columna.

Si se devuelve una excepción noSuchObject, el agente indica que la aplicación no debe intentar dar un valor.
Cuando el valor de una columna de estado cambia a notInService, el agente indica que la fila está siendo
usada en el dispositivo y que la aplicación debería poner la columna de estado a activa. Hay que tener en
cuenta que es la aplicación la que determina el número de operaciones set que quiere realizar.

Si una fila se encuentra en el estado notInService o notReady, pueden aparecer problemas: Si el dispositivo
crea o modifica la misma fila que está siendo negociada entre la aplicación y el agente, entonces existirán
dos copias, una en el dispositivo y otra en el agente, aunque cuando la columna de estado se active en el
agente, ésta eliminará la del dispositivo. También puede ocurrir que el proceso de negociación se vea
interrumpido. Por eso, el agente debe almacenar de vez en cuando filas que no estén en estado activo.

32


1.4.2 Modificación de una Fila de Conceptos

Algunos módulos MIB precisan que se desactive una fila para poder modificarla. Para ello, la aplicación pone
la columna de estado a notInService. Si el agente no lo soporta, devuelve un error wrongValue; si no, la fila
no es accesible para el dispositivo y se devuelve una respuesta de noError. Desactivar una fila es útil cuando
las modificaciones no caben en una sola PDU. Por supuesto, hasta que no se hacen todas las modificaciones,
la fila no será consistente, por lo que el agente pone la columna de estado a notReady.

1.4.3 Eliminación de una Fila de Conceptos

La aplicación pone la columna de estado a destroy. El agente hace la fila inaccesible al dispositivo y a él
mismo y devuelve una respuesta noError.

33


5. Interacciones de Invocación

Cuando un agente detecta un evento extraordinario, se genera una invocación snmpV2-trap,
que se envía a una o más aplicaciones de administración. La invocación snmpV2-trap tiene un
formato idéntico a las PDU usadas en otras peticiones.

Las dos primeras instancias son especiales:

sysUpTime.0, momento en que se generó la invocación.
snmpTrapOID.0, el identificador de objeto de la invocación.

El Grupo snmpTrap

Hay dos objetos escalares relacionados con las invocaciones SNMP.

snmpTrap OBJECT IDENTIFIER ::={snmpMIBObjects 4}
snmpTrapOID OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS accesible-for-notify
...
::= {snmpTrap 1}

1.6 Interacciones entre Administradores

Cuando una aplicación quiere informar a otra aplicación, genera una inform-request. El formato de la
InformRequest-PDU es idéntico al de las otras PDU del resto de peticiones. Al igual que snmpV2-trap, las dos
primeras instancias indican el momento del evento y su identidad.

Como es de esperar, sólo algunos dispositivos pueden tener el papel de administrador. Hay que tener cuidado
para minimizar el número de informes que se generan. Actualmente, el control de la generación y
retransmisión de informes es una tarea específica de implementación.

34


1.6.1 Entidades de Doble Rol

Se trata de dispositivos que contienen agentes y aplicaciones de administración. Estos
dispositivos recogen y procesan información de los agentes y la proporcionan a la administración.
Así, según el entorno SNMPv2, una aplicación de administración es algo que inicia una interacción
entre peticiones y respuestas.

4. 2. Mapeo de Transporte

Las operaciones SNMP son independientes del protocolo de transporte, utilizando sólo un servicio
de transporte no orientado a conexión.

Para definir el mapeo de transporte, se especifican dos pasos:

- Reglas para tomar la estructura de un mensaje y transformarlo en una cadena de octetos para formar
un paquete.

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

Hay varios mapeos de transportes definidos y usan el mismo conjunto de reglas para el primer paso. Como
todos los objetos y estructuras SNMP se definen con el ASN.1 de OSI, el entorno de administración usa BER
(Basic Encoding Rules) de OSI para codificar las estructuras en octetos. Cuando éstos se reciben, se
transforman en una estructura de datos con una semántica idéntica.

35


2.1 Direcciones y Dominios de Transporte

La relación del protocolo de administración y el servicio de transporte se denomina Dominio de Transporte.

2.1.1 Dominio snmpUDPDomain

Identifica el uso de SNMPv2 sobre UDP. Este es el mapeo preferido.

Si un objeto TDomain tiene un valor de snmpUDPDomain, entonces el correspondiente objeto TAddress se
codifica en seis octetos:

SnmpUDPAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT “1d.1d.1d.1d/2d”
STATUS current
DESCRIPTION

36


SYNTAX OCTET STRING (SIZE (6))

La entidad que envía transforma y envía el mensaje como un único datagrama UDP a la dirección
de transporte de la entidad receptora. Por convención, los agentes SNMP escuchan en el puerto
UDP 161 y envían las notificaciones al puerto UDP 162, aunque una entidad debería configurarse
para usar cualquier selector de transporte aceptable.

Todas las entidades receptoras deben admitir mensajes de al menos 1472 octetos de longitud.

2.1.2 Dominios snmpCLNSDomain y snmpCONSDomain

Identifican el uso de SNMPv2 en los servicios de transporte no orientados a conexión de OSI (CLTS):
snmpCLNSDomain se usa cuando CLTS se ejecuta en servicios de red no orientados a conexión de OSI (CLNS),
mientras que snmpCONSDomain se usa cuando CLTS se ejecuta en servicios de red orientados a conexión de
OSI (CONS).

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

SnmpOSIAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT “*1x:/1x:”
STATUS current
DESCRIPTION

37


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

La entidad que envía transforma el mensaje y lo envía como una única unidad de datos del
servicio de transporte (TSDU) a la dirección de transporte de la entidad receptora. Los selectores
de transporte por defecto son:

Una entidad debería poder configurarse para usar cualquier selector de transporte aceptable. Todas las
entidades receptoras deben admitir mensajes de al menos 1472 octetos de longitud.

2.1.3 Dominio snmpDDPDomain

Identifica el uso de SNMPv2 sobre Appletalk’s DDP.

Si un objeto TDomain tiene un valor de snmpDDPDomain, entonces el correspondiente objeto TAddress se
codifica así:

SnmpNBPAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION

38


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

La entidad que envía transforma el mensaje y lo envía como un único datagrama DDP a la
dirección de transporte de la entidad receptora. Todos los agentes SNMP escuchan en el tipo NBP
SNMP Agent y las notificaciones se envían al tipo NBP SNMP Trap Handler. Todas las entidades
receptoras deben admitir mensajes de al menos 484 octetos de longitud.

2.1.4 Dominio snmpIPXDomain

Identifica el uso de SNMPv2 sobre NetWare’s IPX

Si un objeto TDomain tiene un valor de snmpIPXDomain, entonces el correspondiente objeto TAddress se
codifica así:

SnmpIPXAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT “4x.1x:1x:1x:1x:1x:1x.2d”
STATUS current
DESCRIPTION

39


SYNTAX OCTET STRING (SIZE (12))

La entidad que envía transforma y envía el mensaje como un único datagrama IPX a la dirección de transporte
de la entidad receptora. Por convención, los agentes SNMP escuchan en el socket IPX 36879 y envían las
notificaciones al socket IPX 36880, aunque una entidad debería configurarse para usar cualquier selector de
transporte aceptable.

Todas las entidades receptoras deben admitir mensajes de al menos 546 octetos de longitud.

EN RESUMEN

Para definir el mapeo de transporte, se especifican dos pasos:

- Reglas para tomar la estructura de un mensaje y transformarlo en una cadena de octetos para
formar un paquete.

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

40

Protocolo

Más contenido relacionado

La actualidad más candente

Similar a Protocolo

Más de 1 2d

Último

Protocolo