Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Leccion 2. Protocolo SNMP. Estudio en Profundidad
Leccion 2. Protocolo SNMP. Estudio en Profundidad
SNMP: ESTUDIO EN
PROFUNDIDAD
© élogos Conocimiento, S.L. Madrid 2009. Todos los derechos de Propiedad Intelectual e Industrial de esta obra pertenecen a élogos Conocimiento, S.L.
ÍNDICE
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
1. INTRODUCCIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
2. CONCEPTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
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.
3
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
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
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
- 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:
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
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
2. Conceptos
El entorno usado para administración en los protocolos de Internet se llama Internet-standard Networking
Management Framework (entorno para la administración de redes basadas en Internet), y esto se debe a
motivos históricos: los esquemas previos eran ocasionales y propietarios.
Actualmente existen dos versiones de este entorno: el entorno original (Internet-standard Networking
Management Framework), compuesto por tres documentos, cada uno de los cuales es un estándar de Internet
con la condición de Recomendado; y el entorno que le sucedió (SNMPv2 Framework), formado por doce
documentos. Dos años después, este segundo entorno se revisó en ocho documentos, quedando algunos como
borradores de estándares y otros como proposiciones de estándares. Con el tiempo, estos documentos se
convirtieron en un completo estándar de Internet. Fue entonces cuando se declaró histórico el estándar
original y la comunidad se quedó con un solo entorno. Entre ambos entornos hubo dos pasos intermedios:
SNMP Security y SMP, que fueron incluidos dentro del entorno SNMPv2, dejando sus documentos originales sólo
para interés histórico.
Un modelo
1. Nodos administrables
Un nodo administrable es un dispositivo que puede clasificarse en una de las siguientes categorías:
6
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
Estas tres categorías coinciden en que clasifican a algún tipo de dispositivo con alguna capacidad de trabajo
en red. Las dos primeras categorías se caracterizan por ser normalmente independientes del medio, mientras
que la principal característica de los dispositivos de la tercera clase es la dependencia del medio.
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.
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.
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
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
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.
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
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
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.
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:
9
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
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.
10
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
4. Información de administración
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
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
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
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
Una propiedad importante de las relaciones tipo proxy es el principio de transparencia. La idea es aparentar
que la aplicación se está comunicando directamente con el agente real, es decir, una aplicación simplemente
especifica los recursos deseados y el agente proxy es el encargado de hacer que las cosas salgan bien, como
si la información de administración la tuviera el agente proxy localmente.
5. En perspectiva
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
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
3. Modelo de Información
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.
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:
14
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
Por supuesto, estas funciones deberían estar combinadas en un sólo módulo. Cada módulo de información
debe comenzar con la indicación de su identidad y la historia de sus revisiones (macro MODULE-IDENTITY).
Dentro de cada modulo existirán objetos, los cuales se definen con la macro OBJECT-TYPE, la expansión de
éstos se produce durante la implementación. También se usaran convenciones textuales (macro TEXTUAL-
CONVENTION), que son redefiniciones más precisas de algún tipo de datos, dentro de un MIB. Existen tres
tipos de MIB:
15
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
4. Modelo Administrativo
Consideraremos cómo se definen políticas administrativas para aplicaciones de gestión y agentes. Esta parte
de la red de gestión ha sufrido la mayor revisión desde la introducción de SNMP. Desafortunadamente todavía
no existe un consenso en la solución más apropiada al problema.
1. Conceptos
En el entorno de gestión, una entidad SNMP es una “entidad lógica” en nombre de la cual un agente o una
aplicación de gestión están procesando un mensaje. El entorno de gestión es responsable de proporcionar:
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:
16
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
1.2 Privacidad
Como las propiedades de autentificación están asociadas con la entidad que envía, las propiedades de
privacidad se pueden asociar con las entidades receptoras. Para lograr privacidad con seguridad, deberíamos
usar un algoritmo de encriptación y la clave asociada.
1.3 Autorización
Cuando un agente ejecuta una operación, primero deberá identificar la colección de recursos de objetos de
gestión a monitorizar. Si los recursos son accesibles mediante algún mecanismo local, se dice que la operación
se desarrolla desde el punto de vista del MIB, el cual es normalmente un conjunto adecuado de todos los
objetos gestionados controlados por una entidad. En cambio, si los recursos son accesibles mediante el envío
de mensajes SNMP a una entidad remota, entonces se dice que los objetos son validos a través de una relación
proxy.
Una vez que los recursos son identificados, sólo resta determinar las operaciones SNMP
empleadas en ellos. A esto se denomina Política de Acceso, y es usada para el control del flujo
de información entre la entidad agente SNMP y una entidad de aplicación de gestión dada.
2. Comunidades
SNMP v2 esta diseñado para soportar múltiples entornos de administración. El entorno que
veremos se denomina entorno de gestión basado en comunidades, debido a que usa el concepto
de comunidad empleado en el SNMP original.
SNMP define una comunidad como una relación entre entidades SNMP. Una comunidad SNMP se escribe como
una cadena de octetos sin interpretación. Esta cadena se llama nombre de comunidad. Cada octeto toma un
valor entre 0 y 255. Cuando se intercambian mensajes SNMP, contienen dos partes:
17
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
La cadena de comunidad es un simple manejador para las relaciones de gestión. Ahora realizamos una
valoración de las propiedades de gestión de SNMP:
Identificación de origen: como las cadenas de comunidad son enviadas sin protección, cualquier tercera
parte capaz de interceptar un mensaje SNMP puede usar el mismo nombre de comunidad y de esa forma
demandar ser un miembro de la comunidad de mensajes.
Integridad del mensaje: cualquier tercera parte puede modificar un mensaje SNMP que intercepte.
Protección limitada de reenvíos: cualquier tercera parte puede retrasar un mensaje SNMP que haya
interceptado.
Privacidad: cualquier tercera parte puede leer el mensaje SNMP que haya interceptado.
Autorización: los agentes son responsables de mantener información local así como los MIB que contienen,
o las relaciones de proxy válidas. Será sencillo para una tercera parte obtener los accesos correctos de una
entidad autorizada para monitorizar o controlar esos objetos.
Todo lo que se puede decir es que aunque SNMP v2 ofrece enfoques técnicos para estos asuntos, sus
mecanismos no llevan a ninguna solución.
- 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:
18
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
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:
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 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.
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
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
5. Modelo Operacional
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.
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:
- 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.
20
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
1.1 Interacciones
Veamos primero una interacción normal entre dos entidades SNMPv2, para más adelante estudiar sus
variaciones:
- Un único request-id.
- error-status/error-index a cero.
- Cero o más instancias de variables.
- 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.
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:
- 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
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
- Un único request-id.
- error-status/error-index a cero.
- Cero o más instancias de variables.
- 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.
- Un único request-id.
- error-status/error-index a cero.
- Cero o más instancias de variables.
- El mismo request-id.
- error-status a cero.
- Las mismas instancias de variables que la petición.
Teniendo en cuenta que los errores nunca se devuelven en una respuesta a una operación de invocación, hay
dos clases de errores que pueden devolverse en la respuesta a cualquier otra petición:
tooBig, indica que la respuesta podría ser demasiado larga para enviarla.
genErr, no debería devolverse excepto que no haya otra posibilidad.
22
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
Si se procesa una petición de modificación, hay otra case de errores que deberían devolverse, pero que se
verán más adelante.
Esta interacción ocurre cuando se envía una petición pero no se recibe respuesta. Hay varias posibilidades:
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
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:
23
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
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.
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.
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
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
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.
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
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
Finalmente, el espacio libre se ocupa, o se realiza el máximo número de repeticiones. Es importante tener
en cuenta que el agente puede terminar una repetición en cualquier momento.
Existe otra forma con la que la operación get-bulk termina prematuramente: Esto ocurre cuando al examinar
las variables de la tabla, se devuelve una excepción endOfMibView. En este caso, todas las futuras
repeticiones devolverán lo mismo y se omitirán de la respuesta.
Por último, es importante saber que cuando un agente decide procesar una petición get-bulk, sólo se puede
devolver el error genErr, ya que devolver tooBig no tiene sentido.
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:
- Si la variable existe, el agente puede modificar las instancias del tipo objeto correspondiente.
26
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
- 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.
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.
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.
9. inconsistentValue, el valor proporcionado es inconsistente con los valores de otro objeto en el agente.
27
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
Los códigos noCreation y notWritable son de tipo permanente, mientras que los tres últimos son de tipo
transitorio. El resto son casos que no deberían ocurrir si la aplicación y el agente tuvieran un mismo concepto
de los objetos en cuestión.
Sólo si cada instancia ha superado la primera pasada, se hace la segunda, en la cual se acomete el cambio
de cada instancia. Por experiencia, pueden existir fallos en esta segunda pasada. Si ocurre, el agente trata
de deshacer los cambios y devuelve uno de los dos siguientes tipos de error:
1. commitFailed, indica que hubo un fallo en la segunda pasada pero que se deshicieron los cambios.
2. undoFailed, indica que falló la segunda pasada y que algunos cambios no pudieron deshacerse.
Si se devuelve alguno de estos errores, se pone a cero el campo error-index, indicando que hay un problema
grave en el agente.
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.
3. Los valores de todas las columnas pueden no entrar en una sola PDU.
28
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
En SNMPv2, la convención textual RowStatus se usa para expresar la forma de manipular una fila: cuando una
tabla se define en un módulo MIB, debe definirse una columna status con la sintaxis de RowStatus. El
significado de una variable de la columna status es que su valor indica la relación entre el dispositivo y la
fila de conceptos.
EN RESUMEN
29
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
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.
- Aproximación Directa, la fila se crea y se activa para ser usada por un dispositivo con una sola
operación set.
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 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
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
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.
- El agente asigna valores por defecto a las columnas de las filas cuyos valores no se especificaron en
el set.
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
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
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.
- 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 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
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
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.
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
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
5. Interacciones de Invocación
El Grupo snmpTrap
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
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
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.
- Reglas para tomar la estructura de un mensaje y transformarlo en una cadena de octetos para formar
un paquete.
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
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
36
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
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.
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í:
37
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
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.
38
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
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.
39
PROTOCOLO SNMP: ESTUDIO EN PROFUNDIDAD
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
- Reglas para tomar la estructura de un mensaje y transformarlo en una cadena de octetos para
formar un paquete.
40